Возможно тема уже обсуждалась.

Схема:

[dhcp]<->[агрегация]<->25[DES3200-28#1]27<->25[DES3200-28#2]

Конфигурация у DES3200-28 типовая: включен dhcp-relay для всех вланов. И там и там клиенты.
FW: 1.52-b003

когда клиенты с DES3200-28#2 отправляют запросы REQUEST на DHCP, то почему-то DES3200-28#1 отвечает на них (не понятно каким образом) NAK причем в броадкасте 255.255.255.255.

С чем может быть связано такое поведение у DES3200-28#1?

где вывод комманды sh conf curr in "dhcp_relay" ?

Начиная с релиза 1.50.B003 до 1.52.B003 в данной серии релей странно работает.
Мы у себя откатили на 1.42.B001, проблем нет.

Странно, у меня стоит 1.50.B003, траблов вроде незамечено. Единственно зачто хочется "поблагодарить", за грозозащищщенность

На стенде с 1.42b001 баг не проявился.
Ночером накатимся на продакшин.

а в 1.50 сделали что коммутатор релеит и unicast dhcp запросы, почему нужно было отходить от RFC и почему типа фича не отключаемая, совершенно не понятно.

Я думаю это баг просто, надеюсь починят в будущих прошивках. Кстати из-за этих нововведений не продлевают лизы такие девайсы как микротик например.

До сих пор не починили.

Мало того, что релеит и unicast dhcp запросы, так еще заменяет option82 при этом не смотря ни на какие настройки!
Это совсем никуда не годится и просто убивает данный коммутатор в качестве полноценного девайса на доступ.
А если учесть, что почему-то в ДЛинке наотрез отказываются реализовывать trusted порты - перспектива не очень радостная.

Кто-нибудь из ДЛинка, прокомментируйте все же данную ситуацию:

1. Зачем DES-3200 релеит unicast dhcp запросы ?
2. Если релеит unicast dhcp запросы - зачем при этом ломает OPT82 не взирая ни на какие настройки.
3. И когда все же ждать исправления данных багов.

Можно поподробнее описать проблему и чем она грозит? Играет ли здесь какую либо роль опция stash-agent-options выставленная в true?

_________________
D-Link Switches: Tips & Tricks

stash-agent-options вообще обязательна к применению при opt82. При ней ISC DHCPD запоминает для клиентской лизы эту самую opt82. Так как запросы клиента на продление идут юникастом и в подавляющем большинстве случаев без opt82 - то сервер при таких запросах сопоставляет эти запомненые данные, и правила где матчится opt82 нормально срабатывают. Ибо без opt82 совпадения не будет и клиент получит отлуп и не сможет продлить адрес. Вот выжимка из мана по ISC DHCPD:


В случае же с DES-3200, когда он релеит юникасты с заменой opt82 на себя, имеем след ситуацию.
Если есть цепочка коммутаторов на доступе (при этом SW1, SW2 могут быть любыми с opt82)

Когда с коммутаторов SW1 или SW2 прилетают запросы на продление юникастом, то DES-3200 их перехватывает и переписывает opt82 на свои, например на DES_3200_MAC/port25. Но сервер то выдавал адррес клиенту по данным SW1_MAC/port1. Имеем несовпадение и клиент получает DHCNACK

Пример НЕПРАВИЛЬНОЙ работы. Время аренды адреса 10минут. Первым в цепочке DES-3200 (как на вышеуказанной схеме). На коммутаторах, подключенных через него - у клиентов проблемы при получении адресов.

Пример ПРАВИЛЬНОЙ работы. Первым в цепочке другой коммутатор - НЕ DES-3200 (схема аналогична, настройки на коммутаторах идентичны). На коммутаторах, подключенных через него - у клиентов никаких проблем при получении адресов.

А можете привести пример настройки DHCP_relay на проблемном коммутаторе. Была схожая проблема из-за того что в настройках на коммутаторе было включено

и

покопавшись на форуме набрел на такое сообщение от ШК длинка:

перенастроил свитчи на чек дизейбл и полиси кип, после чего с проблемой не сталкивался.
F/W: 1.52B005 (DES-3200-28), 2.80B08 (DES-3028)

_________________
LanCom/PowerNet

Естественно стоит
Однако, как было указано выше, проверялись все комбинации настроек - эффекта на Build 1.52.B007 ноль .

Что в общем то логично - ибо запросы на продление аренды идут юникастом и без OPT82. А если коммутатор трогает
такие DHCP-пакеты, то он при отсутствии в пакете этой opt82 согласно второй колонке по любой полиси эту OPT82 туда вставит.
Только пакет то от клиента на коммутаторе где-то дальше по цепочке, и в данном пакете чужая OPT82 не нужна.

Отсюда вывод программерам прошивок - не надо изобретать велосипед и делать нестандартные фичи. Все уже давно придумано -
либо не трогайте юникаст-пакеты,
либо, что лучше - РЕАЛИЗУЙТЕ концепцию Trusted-ports ! 1000 проблем сразу исчезнет

p.s. Лирическое отступление.

Подтверждаю проблему. Только что сам отлетел из-за вышеописанного глюка.

Уважаемый D-Link, очень хотим решения проблемы и срочно! Прошивку откатить не можем, т.к. часть коммутаторов ревизии B1!

upd: Вроде бы релей внутри влана спасает. Надо будет все перенастроить. Эх, а так не хотелось...

_________________
D-Link Switches: Tips & Tricks

Типа использовать только dhcp_local_relay?
Если у вас в влане больше одного коммутатора - то все они будут ловить dhcp-пакеты с аплинков и размножать их, тоже не выход.

Нет, использовать dhcp_relay (не local), но настроенный не глобально, а для влана:

А из ipif System сервера удаляем.

_________________
D-Link Switches: Tips & Tricks

Это было проверено сразу же - поведение не отличается, бага остается.