Ок. Ждем.

Если использовать dhcp relay, то проблема, фактически, себя не проявит - широковещательные пакеты соседей просто не попадут к стороннему dhcp серверу на клиентских портах.
Попробуйте использовать как временное решение.

Но всё таки интересует ответ ШК.

Как будут новости - я обязательно напишу.

Знаю, у нас релей и работает, я его специально выключил ради проверки, и вон оно чо получилось, Михалыч. (((

Ну так включите обратно
Все дело в том, что все эти фичи завязаны на работе acl - и если проблема, по большому счету, встречается только в определенных тестах, а не в реальной сети - я рекомендую использовать решение с dhcp relay и не придумывать самому себе грабли.

О ситуации я в любом случае отписал в ШК. Посмотрим, каким будет ответ.

Доброе время суток.

Вообщем проблема следующая живем в Сибири на Байкале оч частые перепады напряжения и магнитные бури. Сеть построена на управляющих коммутаторах в основном des-3200 в сети 50/50 IPoe и pppoe .
После каждой сильной грозы мы обнаруживаем в сети около 10-20 роутеров (в основном марки dlink dir-300) которые сходят с ума и посылают через ван порт IP 192.168.1.1 при том что на порту LAN настроен 192.168.0.1 и при этом на 192.168.1.1 работает DHCP и защита блокирует роутер полностью, а если убрать защиту то они начинают навязывать свои IP другим аббонентам. роутеры и сбрасывали и перепрошивали, толку нет. не подскажите как запретить на свитчах DHCP запросы с этих портов? или как быть ?

1. Включите dhcp server screening на абонентских портах - в этом случае dhcp offer от таких клиентов будут блокироваться
2. Используйте address binding - тогда эти роутеры просто будут блокироваться коммутатором

А роутер будет блокироваться полностью ? абонент сможет работать ? просто когда он сходит с ума мы снимаем защиту (айпи мак порт биндинг) и роутер тогда работает, но посылает нам запросы. хотелось бы чтобы люди смогли дальше работать.

traffic_segmentation решает

1) Первые 62 правила -- системные. Попробуй нумерацию начинать вручную, например, со 100.

2) Ответы от DHCP сервера идут на порт 68(44 -- шестн.), а не на 67(43 -- шестн.).

3) user define ... mask 0x0000FFFF, а не 0xFFFF0000.

Попробуй как ток так:



Проверишь, отпишись.


Но это, по-моему плохое применение ACL. Лучше не блокировать то, что не нужно отдельными правилами, а разрешить всё, что нужно, а всё остальное(не нужное) запретить последним правилом. Так удобно блокировать, например, ARP-шторма.

На след. неделе попробую, но вот по поводу

Я в курсе, и блочить пытаюсь src 67, тут ты немного ошибся, и в ответ предлагаешь dst 68 блочить, что впринципе однохренственно.

Кстати да. Эт я погорячился. Тогда у меня вариантов нет.
Твой вариант АЦЛ у меня отрабатывает нормально. DHCP-ответы блочатся на порту. Даже с номером меньше 62.

А ты уверен что это отрабатывают именно аклы? А тебя dhcp_relay включен? Если да, попробуй выключить - удивишься.

Фикс будет в конце сентября - начале октября.