[purecopper]

s.lobanov

Во время подобной проблемы общался с инженерами длинк. Делали и CPU ACL и "просто" ACL - не помогало ничего.

Поднял переписку - точнее так. Спасает "просто" ACL на коммутаторе с проблемным абонентом (вырезаем весь ipv6). При этом на самом коммутаторе CPU utilization заметно увеличивается, но флуд дальше него не идет.

Изменено 25 августа, 2017 пользователем purecopper

[s.lobanov]

нет, ну они подтвердили что это нерешаемо?

[purecopper]

s.lobanov

Как отписал выше, частично решаемо. На ревизии C1 решаемо. Функция rate-limit dhcp-запросов есть на свежих прошивках.

[AlKov]

Спасает "просто" ACL на коммутаторе с проблемным абонентом (вырезаем весь ipv6). При этом на самом коммутаторе CPU utilization заметно увеличивается, но флуд дальше него не идет.

Не понял..

В таком случае получается, что те ACL, которые я приводил в пример, должны решить проблему.

Или это касается только DES-3200 ревизии С1?

[purecopper]

Да, должны решить проблему

[roma33rus]

В 25.08.2017 в 12:20, AlKov сказал:

roma33rus

Попробуйте вот такую конструкцию

create access_profile profile_id 1 ethernet vlan 0xFFF destination_mac FF-FF-FF-FF-FF-FF ethernet_type
config access_profile profile_id 1 add access_id 1 ethernet ethernet_type 0x86D port 1-10 deny
config access_profile profile_id 1 add access_id 2 ethernet destination_mac 01-00-5E-00-00-00 mask FF-FF-FF-00-00-00 port 1-10 deny

 

 

Первое правило должно прибить ipv6, второе - ipv4 multicast.

У меня такие ACL используются давно. Единственное, в чём не уверен - это в их эффективности - написал, но не проверял. :-)

Спасибо, попробуем, как в следующий раз словим такую ситуацию. Что-то подобное на просторах интернета видел. Только не помогало. purecopper писал, что на A1/B1 ревизиях никак с этим бороться не получиться. Посмотрел и как раз, обсуждаемая проблема была с ревизией A1. Это печальное.

[roma33rus]

Вообще бы было хорошо сымитировать проблему, да попробовать зарезать ipv6.