Добрый всем день.
Имеем городскую сеть. Клиенты подключены к DES-3028 и DES-3200 (разные варианты).
При этом, часто приходится делать из этих свичей цепочку по несколько штук (до 3-4).
Клиентские вланы, управляющий влан.
Схема - звезда. В центре стек из нескольких DGS-3627G и пара цисок.

Настала пора выдавать сетевые параметры по DHCP. Автоматизация, защита и пр...

Настройки свичей (DES-3028 и DES-3200):
DHCP Relay State: Enabled
DHCP Relay Hops Count Limit = 1 (DHCP сервер в управляющем влане, на него релеить не надо)
DHCP Relay Time Threshold = 0
DHCP Relay Agent Information Option 82 State: Enabled (сервер выдает IP на основании MAC и порт свича)
DHCP Relay Agent Information Option 82 Check: Disabled (управляемый влан защищен, подмены быть не может, так что проверять смысла не вижу)
DHCP Relay Agent Information Option 82 Policy: Drop (нефиг делать...)
DHCP Relay Agent Information Option 82 Remote ID: Default (идентификация свича по MAC)

Дополнительно, включен глобально DHCP Local Relay (без настройки вланов - чтобы задавить прорвавшиеся бродкастовые запросы)

Защита.
DHCP Snoop State: Enabled
Настройки клиентского порта: Loose, Allow Zero IP - Allow, Forward DHCP Packet - Forward, Mode - ARP, SLT = 500

И вроде все замечательно, но...
[Центр]=[DES-3200-28, 1.52.B007]26=25[DES-3028, 2.80.B11]. Проблемный клиент подключен к DES-3028.
На сервер DHCP сыпятся запросы с этого DES-3200, 26 порт, клиентский влан, MAC клиента, подключенного к DES-3028. Запрос типа DHCPREQUEST.
Т.е. клиентский запрос прошел через первый свитч (несмотря на DHCP Local Relay и DHCP Relay) и благополучно отрелеился следующим свичом на DHCP в управляющий влан. На сервер DHCP приходит примерно равное к-во нормальных запросов (от DES-3028) и "прорвавшихся" через него от DES-3200.
Пока что не страшно - пробуем. Но в дальнейшем, думаю, а не захлебнется ли сервер DHCP от бесполезных запросов?
Да и не понятно как-то. Похоже, реализация DHCP Local Relay и DHCP Relay в этих свичах разная. Если запрос "неправильный", так почему один пропускает, а другой релеит? Меня устроило бы, если б они работали просто одинаково. Т.е. одинаковые запросы одинаково обрабатывали.

Вторая ложка дегтя...
DES-3200-18, 1.52.B007. Настройки те же.
У клиента стоит винда. DHCP был недоступен, винда не получила во-время IP и назначила свой (169.254.х.х)... MAC клиента благополучно попал в Block List (DHCP Snoop).
В логах "Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 169.254.196.23, MAC: 00-22-15-17-25-96, Port: 5)".
И после этого ни один DHCP запрос от него не проходит (5 часов)! Удаляю бан - он опять появляется. Удалить получилось только добавив эти IP/MAC/Port в IMP Binding Entry. Только после этого клиент смог получить свой IP. Переподнятие порта не помогало. Перезапуск компьютера не помогал.
Хорошо что это наш сотрудник (тестируем). А как с клиентом говорить?

Аналогичная ситуация с моделью DES-3028 разрешается на-ура. Достаточно клиенту запросить и получить IP по DHCP - бан снимается.
Т.е. при блокировке по маку (DHCP Snoop) в модели DES-3028 запрсы DHCP релеются, а в модели DES-3200-18 (1.52.B007) не релеются.

И как быть?
Ну и глобальный вопрос - в чем существенном еще отличается работа DHCP Relay, DHCP Local Relay и DHCP Snooping в моделях 3028 и 3200??

Поставьте везде: Option 82 Policy: Keep

Чтобы пропускать DHCP запросы с Option 82 от клиента? Вот уж не надо...

По поводу первой проблемы понятно:
Тема тут

Хотелось бы конечно знать хоть примерные сроки...

По поводу второй - есть идея. На порту клиента ACL, разрешающий должный IP и запрещающий остальные. Убрал, сегодня постараюсь поэкспериментировать, отпишусь.

Первую проблему вроде бы победил. DHCP сервер на перле, изменил маленько логику.
Теперь при поступлении DHCPREQUEST запроса и нужных свитч-порт нет в базе, в ответ отправляется DHCPNAK. Клиент обязан начать с широковещательного DHCPDISCOVER и дальше все нормально. Наблюдаю. ))

Факир был пьян, и фокус не удался...

Ответы DHCPNAK на "левые" DHCPREQUEST количество этих "левых" DHCPREQUEST не уменьшило.
Надо на DES3028 релеить юникастовые DHCP запросы. Как долго "ждать звезду"?

По второй проблеме - очистка ACL ничего не дала. WIN-клиент, система автоматом назначила адрес из 169.254.0.0/16, MAC в бане, DHCP запросы не проходят. И клиент остается в бане "навечно".
Проблема очень актуальна, прошу ответить.

Расписания пока не дали, но надеемся, что появится в самом ближайшем будущем.


Это на какой модели коммутатора и с какой прошивкой?

Клиент:
[DHCP сервер]=[стек из DGS-3627G]=оптика, клиент далеко (1-1.5 км)=[DES-3200-18, Firmware 1.52.B009]=[клиент WIN-7]

На DHCP сервере отключаю этого клиента (ответы ему слать не будет). Удаляю запись DHCP Snooping Entries. Переподнимаю порт на свиче. Получаю "Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 169.254.196.23, MAC: 00-22-15-17-25-96, Port: 5)". Клиент в бане. На DHCP сервер запросы не приходят.
На DHCP сервере включаю клиента. Жду, перезапускаю порт - на DHCP запросы не приходят. Ради проверки ждал 3 часа. На DHCP - тишина.
Добавляю IP: 169.254.196.23, MAC: 00-22-15-17-25-96, Port: 5 в статик IMP Binding Entry Settings. Можно подождать, можно перезапустить порт - клиент нормально получает IP.
Убираю статик IMP Binding Entry Settings, клиент нормально работает.

Стенд:
[DHCP сервер]=[стек из DGS-3627G]=несколько промежуточных свичей=[DES-3200-18, Firmware 1.52.B009]=[клиент WIN-7]

На DHCP сервере отключаю этого клиента (ответы ему слать не будет). Удаляю запись DHCP Snooping Entries. Переподнимаю порт на свиче. Получаю "Unauthenticated IP-MAC address and discarded by ip mac port binding (IP: 169.254.112.47, MAC: B8-70-F4-F1-29-27, Port: 1)". Клиент в бане. На DHCP сервер запросы приходят регулярно.
На DHCP сервере включаю клиента. Можно подождать, можно перезапустить порт - клиент нормально получает IP.
---------
Т.е. на стенде ситуация не воспроизводится. Конфигурации свичей один в один. CPU Utilization на клиентском свиче 10-30%%, Port Utilization (UpLink) - 10%%.

Уже голову сломал. Может есть какие идеи? Остается попробовать принести клиенту этот ноут, который пробовал на стенде. Если получится - сегодня попробую.

Тему можно закрывать. У клиента были "левые" настройки интерфейса.
Утилита восстановления сетевых настроек от MS (MicrosoftFixit50199.msi) не помогла. Помогло удаление адаптера в диспетчере устройств и последующее обновление.
После этого все работает "на ура".

Закрываю