Элтекс

Добрый день!

Из последних пяти свичей один не "пропускает" DHCP-пакеты:



Свичи присутствуют как с SW-ver. 1.1.38 так и с 1.1.22, - конфиг одинаковый, полет нормальный.

Отправьте конфигурацию на почту
3200@eltex.org
Подробно опишите схему проверки. Есть ли еще коммутатор с такой же версией и таким же конфигом? Или на других версия 1.1.22?
Также коммутатор пришел с версией 1.1.38 или вы его вручную обновляли?

DHCP snooping включен?
ip dhcp snooping trust не забыли?

Конфиг без snmp-server и username


Через trunk c ip dhcp snooping trust dhcp-пакеты ходят c других свичей, абоненты работают. На самом коммутаторе, получаем такое:
show ip dhcp snooping binding


tcpdump -nn -s 0 -v port 67 or port 68 ничего не ловит с этого коммутатора (:

Как пример другой коммутатор, в таких же условиях:


show ip dhcp snooping binding


Ну а вообще пока что по почте с поддержкой общаемся. Соберу на столе с обнуление конфига.
До этого собирался, есть один момент что в vlan 1(default) все работает!

И еще - оба коммутатора стоят между других свичей(на некоторых ветка присутсвует гирдянда), схема:

[ isc-dhcp-server ] ----- [ switch ] ----- [ mes1124 ] ----- [ switch ]

При вашей настройке DHCP запросы идут в uplink в vlan 1017(к примеру с порта 1). Дальше надо смотреть кто в этом vlane ответил на этот запрос.

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

Опишите подробней, что имели в виду. Наличие двух запросов в оригинальном vlan и vlan, в который происходит relay?

Имеем цепочку свитчей. На каждом два влана, клиентский (один и тот же на всех свичах), и управляющий.
Получается такая ситуация:
1. Клиент отправляет широковещательный DHCP запрос.
2. Свитч, в который воткнут клиент его релеит на сервер. Здесь вроде все нормально.
3. Оригинальный запрос летит по влану дальше, попадая по очереди на остальные свитчи в этой цепочке.
4. Каждый свитч релеит опять этот запрос на сервер.

Нужно сделать, чтоб свитч, который релеит запрос клиента, убивал оригинальный запрос клиента.
Т.е. так как у длинка. Цель то в общем заменить длинки на элтексы.

Vans, это баг, поправим в следующих версиях ПО

Очень надеюсь, что это произойдет достаточно быстро....

Нет ли движений по этому багу? Он становится все более критичным для нас.

Задача на проработку стоит. Точные сроки исправления пока сказать не могу, ориентировочно октябрь

Если это поможет скорейшему выходу исправления, тоже подпишусь под этим багом. Пока работаем "как есть", но количество DHCP-запросов к серверу умножается на количество коммутаторов, которые релеят такие запросы в пользовательском ВЛАНе. Само-DDoS получается.