Добрый день.
Подскажите пожалуйста решение проблемы unicast шторма

Есть сеть на несколько тысяч абонентов
В ядре стоят Extreme X350 и DGS-3420-52
На агрегации стоят коммутаторы DGS-3120-24
На доступе DES-3200-18, DES-3200-26 и DES-1210-28
Несколько раз в сутки сетку в сети появляется unicast шторм.

Описываю причину:

Юзер качает торренты, потом выключает комп. В таблице маков свичей исчезает его мак. На шлюзе его мак еще есть, так как время expire в районе 10-20 минут. Так что есть время когда мак на шлюзе есть, а юзера в сети уже нет. Торренты из внешнего мира по инерции шлют трафик на юзера. Шлюз без вопрос передает трафик на свич.
На свиче нету мака, и согласно протоколу:
Если MAC-адрес хоста-получателя не ассоциирован с каким-либо портом коммутатора, то кадр будет отправлен на все порты, за исключением того порта, с которого он был получен.
Таким образом, весь трафик шлется по всей сети, а точнее по всему влану. И так будет до тех пор, пока мак на шлюзе не исчезнет по истечению expire time.

О решении проблемы методом уменьшения кол-ва юзеров во влане уже задумывались (Вероятность качальщиков будет уменьшаться) К примеру, в сетях где до 1000 чел на влан, штормов почти нет.Но этот метод растянется на несколько месяцев, а шторм мешает нормальной работе сети уже сейчас.
Возможно есть функции на свичах, чтобы такого избежать.
Сможет ли помочь в данной ситуации включение traffic control unknown unicast. И по какому принципу работает traffic control unknown unicast, не вызовет ли его включение поток жалоб клиентов.
Поможет-ли уменьшние или увеличение времени хранения мака на свичах (Зависит от того, как считается время хранения мака на свиче – от первого появления, либо от последнего пакета)
Или может вы можете предложить какоето другое, более правильное, решение этой проблемы.
Заранее благодарен.

По моему первое, что надо сделать, это выровнять время жизни мака на всем железе в сети примерно в 300 секунд, а затем сделать время жизни arp меньше чем время жизни мака, хотя бы секунд на 60, и всё станет замечательно.

Поддерживаю. arp age на маршрутизаторах должен быть меньше fdb age на доступе.

1000 чел в влане это много. Мы используем влан на коммутатор. На порт при этом отводится по 8 адресов. Итого 192 мака в влане максимум, на практике это значение меньше 40.

_________________
D-Link Switches: Tips & Tricks

А реально это мешает кому-нибудь? У меня были времена когда арп-таймаут стоял по несколько суток на L3 свитчах (из-за перегруза по процу, сейчас то понятно такое убрал) и никто не жаловался..

На всех коммутаторах стоит fdb age 300 секунд (по умолчанию), а сам dlink рекомендует выставить arp age 1200 сек на DGS-3612G
Как правильно то?

теоретически должно помочь включение traffic control unicast на аплинковском порту каждого коммутатора доступа. На агрегации я бы не включал - если мак абонента по какой-то причине не попадет в таблицу коммутации из-за проблем с хешем - у абонента будут проблемы.

Главное не в режиме shutdown

_________________
D-Link Switches: Tips & Tricks

Не знаю, что там рекомендуют, а вот на практике если arp больше fdb постоянно идут юникаст штормы.

не могу найти тему, где про это писали. Но, пробежавшись поиском, не нашёл ни одной темы где написано что на DGS-36 нужно ставить ARP меньше 300 секунд

Это рекомендация не для длинк, это рекомендация принципе для l3 свитчей. Например для циско http://mailman.nanog.org/pipermail/nano ... 11328.html
Актуально и для джунипер. По ссылке расписано что происходит, когда arp таймер больше fdb.

Я вам больше скажу, я прочитав эту тему выставил arp timeout на интерфесах 3610-26G в 120 секунд. Тоесть меньше чем mac aging time.
В итоге абоненты начали жаловаться на то, что у них каждые 2 минуты пропадает на 5 секунд интернет.
Выставил 300 секунд, тоесть столько же, сколько и маки. Понаблюдаю за ситуацией.

_________________
Не важно веришь ли ты в бога, важно верит ли он в тебя...

to: SuiSide: И как у Вас, перестали "отпадать" клиенты?

_________________
AB-Style: Выходных дней два в году - Новый Год и Апокалипсис. Да и то что-то с Апокалипсисом не везёт...
D-Link User: DES-3526/3550, DES-3528, DES-3018, DES-3200-XX, DGS-3612/3627G, DCS-9x0, DCS-3220, DVG-5112S, DPH-400S + разные роутеры и медиаконвертеры

Наверное злые клиенты "убили"