Есть клиентский коммутатор, с которого осуществляется коммерческое подключение пользователей. Пользователи поделены на виланы/сети, каждому выделен ip-адрес, с помощью ACL на каждом порту разрешены протоколы ARP, IPv4(запросы в сеть только из под выделенного для пользователя ip-адреса).

Имеется следующий неприятный эффект: если во время активной работы пользователя его соединение неожидано "кладется", то мак-адрес такого пользователя тут-же удаляется из FDB-таблицы коммутатора подключения пользователя, но поток трафика в рамках незавершенных сетевых сессий продолжает идти в его адрес(в силу того, что arp-запись пользователя на маршрутизаторе и mac-запись в fdb-таблицах на транзитных коммутаторах еще закеширована). Соответственно такой трафик начинает отправляться на все клиентские порты в рамках того же самого вилана, что и порт, который перестал быть активным.

Понятно, что этот эффект продлится не больше времени MAC Address Aging Time и ARP Aging Time, в нашем случае - 5 мин, но ухудшает ситуацию то, что клиентские порты иногда "падают/поднимаются" каждые 1-2 минуты и скорости скачивания у пользователей бывают значительные - 50-80Мбит/с и случаются ситуации, при которых другие пользователи в течении 10-15 минут на скорости под 50Мбит получают чужой трафик у себя на порту, всвязи с чем они выказывают недовольство

ACL-фильтрация здесь не поможет, т.к. фильтруются пакеты, приходящие на клиентский порт, а не наоборот. Может есть еще какая-то опция в конфигурации, которую я не нашел? Типа опции не вычищать преждевременно из fdb-таблицы mac-запись при деактивации порта, а ждать пока она не устареет по aging time?

ena flood
conf flood trap ena
conf flood syslog ena

ну и смотрим на трапы и сислоги

Я не понял, чем мне это поможет? enable flood-fdb вылавливает одинаковые hash записи в FDB таблице. Функция только информирует. У меня нет ведь такой проблемы.

Мне кажется, что проблема могла быть просто решена наличием опции, вроде запрета сброса счетчика времени кеширования для mac-записи в fdb-таблице при деактивации порта. А фреймы, приходящие в адрес такого мас-адреса просто бы отбрасывались в силу неативности порта назначения. Хотелось бы услышать мнение представителей Длинка относительно этого. Ведь согласитесь, что работа коммутатора в режиме хаба в течении нескольких минут(а порой и десятков минут) - не есть гут?

Как вариант Static FDB Entry.

_________________
С уважением,
Бигаров Руслан.

для сети из 10 000 пользователей это ведь не решение. Проблема не с одним и тем же пользователем возникает, а непредсказуемо в сети.

Вы не воспользовались советом terrible, а он имел ввиду, что с помощью этих функций можно понять связана ли эта проблема с hash-ами или нет.

_________________
С уважением,
Бигаров Руслан.

Нет, не связана. Как я понял - решения нет.

К сожалению (или к счастью) не имел дел с DES-3028, но тем не менее всё же рискну предложить:
А нет ли в этой модельке коммутатора функции traffic control применительно к unicast-пакетам с неизвестным destination-MAC, т.е. что-то типа "config traffic control ... unicast ..." или "config traffic control ... dlf ..."? Если оно есть, то не здесь ли зарыто решение?

Да, такое есть и скорее всего его действительно можно тут использовать, только действие поставить drop.

Вообще это не проблема fdb, если пользователь отключился от порта и линк на порту погас, то его fdb запись удаляется из таблицы.

Верно пишите, но пакеты продолжают приходить на такой коммутатор на уже отсутствующий mac отключившегося пользователя, поскольку на остальных коммутаторах, через который он включен, мас все еще присутствует в fdb-таблице.
Предложенный вариант с "config traffic control...." попробую, спасибо за идею.

Для 3028(Build 2.40.B08) опции для блокировки unknown unicast пакетов с помощью "config traffic control...." - нет. Может в последней прошивке появилась эта возможность?

Как это нет?