А почему вообще допускается ситуация, когда линк на порту потух, а связка в IMPB по этому порту еще висит? В чем сакральный смысл сего действия? Если абонент перетыкает кабель из одного сетевого устройства в другое - в этот момент свич по потухшему линку на порту должен вроде как убить все привязки на этом порту. Точно также, как он чистит FDB по этому порту. Ибо это логично. А вот где логика в поведении свича? Почему остается висеть связка в IMPB?

P.S. Насколько я понимаю, данная проблема присуща не только серии 3200, но и 3528, 3550, 3526?

Я протестирую и напишу.

некоторые ОС при быстром перетыкании сетевого кабеля могу продолжить использовать старую лизу и не просить новый адрес. так что пусть висит бинд до конца лизы.

По поводу данной ситуации есть замечание.
Связка на порту остается в состоянии Inactive. В случае, если хост вернулся - он может послать Request/Ack, как выше заметили - не переполучая адрес по новой. Lease time в связке обновляется, она вновь становится активной.
Сейчас в работе impb по этому поводу есть одна небольшая ошибка, о которой уже отписано в ШК.

Да эта связка в состоянии Inactive в общем то необязательна чтобы хост вернулся. Как уже было отмечено - она создастся снова при Request/Ack. А вот другой хост, ранее получавший такой же адрес на этом же порту уже споткнётся об эту связку, перешедшую в Active, т.к. МАК-адрес при повторной активации видимо не проверяется. И в связи с увеличением числа абонентов кол-во жалоб на то, что при смене подключаемого устройства (комп, ноут) интернет не работает. Некоторые вообще жестко привязывают маки к портам и сразу говорят об этом абоненту - но это не наш метод. Раз есть средства (здесь в частности DHCP Snooping), позволяющие делать привязку автоматически - этим и пользуемся, только вот работает оно не корректно. Сами понимаете - абоненту должно быть максимум удобно.

О том, что мак адрес не обновляется при подключении другого устройства при прохождении ack от сервера уже сообщено в ШК, проблема анализируется.

Что-нибудь прояснилось по этому вопросу ?

Да, как раз только что предоставили расписание.
Исправление будет доступно во второй половине ноября.

Вышла 1.81.B005 для A1/B1, в которой поправлена работа dhcp snooping: обновление mac адреса в связке происходит при прохождении ACK от сервера в ответ на Request от клиента.
Прошивка доступна в соответствующей теме.

Спасибо, проверим.
А для 3200 rev.С1 и 3028 будут исправления? Там тоже аналогичное поведение и у нас стоят по сети такие свичи. По идее это нужно исправлять по всей линейке свичей с поддержкой DHCP-Snooping чтобы было одинаково правильное поведение и больше никто с подобным не сталкивался на других моделях.

На DES-3200 С1 мы аналогичного поведения на стенде не обнаружили. Сообщите, пожалуйста, по результатам на DES-3200 A1/B1 и если результаты будут положительные, то мы запросим аналогичный фикс для DES-3028.

Денис, очень слезно прошу проверить аналогичное поведение на стенде моделей DES-3526 и DES-3528!

На DES-3526 и DES-3528 такой проблемы нет. Для DES-3028 исправление будет ближе к концу декабря.

Спасибо!

Не за что.