На DES-3200 A1/B1 поведение подтянут в декабре 2013 в R1.84

Здравствуйте!
Есть ли какие-нибудь новости по релизу прошивки 1.84. Проблема с traffic control на A1/B1 очень актуальна...

Сегодня второе декабря, понедельник, первый рабочий день недели и декабря. До конца месяца еще четыре недели и 29 дней.

Здравствуйте!
Я конечно понимаю, что сегодня тринадцатое декабря, пятница, последний рабочий день недели и до конца месяца еще 18 дней, НО хотелось бы узнать хотя бы ориентировочные даты 1.84

Озвученные сроки - 27 декабря.

Здравствуйте!
Есть новости по 1.84?
В теме http://forum.dlink.ru/viewtopic.php?f=2&t=92700 последнее обновление от 23.12.13.

Расписание сместили на конец января/начало февраля.

Шо опять?

Емнип, в это время у китайцев свой НГ, так шо точно скорее всего не раньше марта

Не оправдаю ваших ожиданий...

Прошивка 1.84 доступна в соответствующей теме, также во вложении документ с описанием реализованного функционала и командами CLI.

Отлично! Будем обкатывать.
Сразу по traffic_control:
Не добавили возможность выставлять время автоматического восстановления работоспособности порта, по аналогии с C1
config traffic control auto_recover_time 30
То есть, так и будет поднимать штормящий порт через 5 минут (неизменяемый параметр).

У меня что-то не прокатывает..

Пытаюсь сконфигурить (команда из примера) -
Что не так??

Попробуйте
config traffic control 1-9 broadcast enable multicast disable action shutdown threshold 500 countdown disable time_interval 10

Вот таксработало.
По-видимому, unicast по-умолчанию был enable.

P.S. Я так понимаю, что если auto_recover отсутствует, после shutdown порт придётся поднимать вручную?

Собрал тестовый стенд и провел тестирование нового traffic control.
Тестируемый коммутатор DES-3200-28 A1 с прошивкой 1.84

Атакующий коммутатор DES-3200-52 с дефолтным конфигом, на котором я замкнул патчкордом 2 порта и подключил вторым патчкордом к тестируемому коммутатора на 5 порт
После этого смотрим статистику пакетов на тестируемом коммутаторе:

148810 мультикаст пакетов в секунду... Серьезный поток.
Включаем traffic control на тестируемом коммутаторе

Смотрим логи:

Коммутатор обнаружил мультикаст шторм и положил 5 порт. Отлично!
Ждем 5 минут и смотрим логи:

Порт автоматически поднялся через 5 минут, и traffic control отработал снова.
В ревизии C1 есть возможность настроить время автоматического восстановления.

На A1/B1 в прошивку 1.84 этот функционал не добавили.
Спасибо за countdown disable! Теперь коммутатор не смотрит на штормящий порт 5 минут, как в прошлых прошивках.
А вот насройка auto_recover_time все-таки необходима...

Попробую поделится своими мыслями и наработками насчёт штормов.

Для борьбы со штормами Traffic control не подходит. По сути, он просто выключает порт, но причина шторма и "вредный" трафик никуда не деваются.

У меня при сраче от сгоревшего порта при отключенном loopdetect в логе появляется запись possible spoofing attack. При включенном loopdetect срабатывает. Порт можно просто отключить.

А тут уже интересней. Проверив пару десятков штормов от абонентов и понаблюдав за логами пришёл к выводу, что у меня в сети 100% абонентских штормов имеют одну природу.
Допустим, абонент получил IP адрес 10.109.82.50. По какой то неведомой мне причине(кстати, если кто-нибудь подскажет по какой и как лечить буду благодарен) компьютер абонента
начинает каждые 10 минут слать широковещательные arp запросы на IP адреса от 10.109.82.1 до 10.109.82.255(Их нет в ARP таблице, но всё равно шлёт). Свич распознаёт их как шторм.



Отключать порт абонента я не могу: он платит деньги, хочет стабильную связь с интернетом и даже не подозревает что срёт в сеть.

Для борьбы с "левым" трафиком я использую ACL. Разрешаю "правильные" пакеты: трафик в интернет, DHCP, ICMP(на некоторые IP адреса), ARP(только на IP основного шлюза!!!)... и запрещаю всё остальное.
Такой подход блокирует весь "левый" трафик(IPv6, Netbios, мультикаст, ARP...) и пропускает только полезный.
Весь шторм от абонента умирает на порту, не распространяясь дальше. Абонент шарится в инете, не испытывая неудобств. L3 свичи довольны, что шторма к ним не проходят.

Сейчас я начинаю потихоньку отключать Traffic control на уровне доступа, чтобы записи не засоряли лог. Оставляю лишь на L3, чтоб проверять вдруг забыл ACL залить и шторм прошёл.
В принципе, если лень долго заморачиватся с ACL, то для борьбы с ARP штормами можно разрешить ARP на IP основного шлюза и запретить все остальные ARP.

Ещё раз повторю, у меня в сети других штормов от абонентов, кроме ARP broadcast, я ни разу за 4 года не видел!!!
ACL начал юзать недавно. Пройдёт ли шторм от сгоревшего порта с ACL не знаю, сейчас не на чем проверить. Если пройдёт, выяснить что порт битый и отключить его труда не составит.
Надеюсь информация кому-нибудь поможет.

Всем спасибо за внимание, Вы отличная аудитория. Всего доброго и до новых встреч.

PS. Спрошу ещё раз, если кто-нибудь знает как у абонента на компьютере отключить рассылку широковещательных ARP-запросов на посторонние IP, подскажите. Буду благодарен.