Плз подскажите, как убить LLMNR (224.0.0.252:5355) на с3750 ?

[Azamat]

Несколько приходящих транков, иногда возникает приличный флуд на 224.0.0.252:5355 от владельцев wi-fi роутеров TP-Link, и видимо, вин7 (виста). Как они оказались взаимосвязаны - хз. Но если флуд возникает, то пока 100 проц случаев в такой связке. Причем в пакетах мак TP-Link, а src IP адреса произвольные. Утилизация CPU с3750 в этот момент растет до 85% и выше, иногда даже отваливались BGP сессии на пару мин.

 

Плз подскажите, кто знает, как можно порезать траф на 224.0.0.252:5355 на 3750 ?

 

уже пробовал :

 

deny udp any host 224.0.0.252

deny udp any host 224.0.0.251

permit ip any any

 

и назначить ip acc-gr in на приходящих транках, не влияет.

 

и vaсl на клиентских вланах тоже не влияет.

[Hawk128]

На длинке 3528 убивал ацлкой.

[config]

Есть сомнения , что вы сможете это зделать обычным acl , если на железяке включено что то типа igmp-snooping или multicast-routing. Если оно так то надо другими методами лочить такие вещи и желательно по ближе к источнику.

[Azamat]

igmp-snooping включен везде и на источниках тоже. Кроме того, читал что у Cisco igmp-snooping не распространяется на служебную сеть 224.0.0.0/24 (но не поручусь за достоверность), хотя как именно это негативно влияет на действие acl ?

[Hawk128]

В моем случае, igmp-snooping включен и ism-vlan тоже, услугу iptv по мультикасту даем. Простая acl на свитчах доступа вырезала этот трафик прекрасно. Проблему вызывали Tplink TP-1043 в случае одновременного присутствия 2-х роутеров в доме, осебенно на соседних свитчах. Начинали оба флудить мультикастом примерно по 11 kpps, при этом вырубаешь одного - второй флуд прекращает. Вроде иправили в последней прошивке, но я уже вырезал к тому моменту и про проблему забыл...

[config]

Что за пакеты ? Какие параметры ip заголовков , например TTL ?

[config]

igmp-snooping включен везде и на источниках тоже. Кроме того, читал что у Cisco igmp-snooping не распространяется на служебную сеть 224.0.0.0/24 (но не поручусь за достоверность), хотя как именно это негативно влияет на действие acl ?

 

Не скажу точно , но зависит отархитектуры , так igmp snoop подразумевает обработку пакета процессором , тут либо делайте это на доступе , либо смотрите что там у вас на 3750 можносделать относительно мультикаст потока, в данном случае у вас на циску приходит просто поток мультикаста причем не известного ей , и на ней конечно нет записи куда этот поток кинуть , нет подписки , и какие там у вас роут порты, вопросов много.

[Ivan_83]

http://en.wikipedia.org/wiki/Link-local_Multicast_Name_Resolution

[Azamat]

там читалось еще до экспериментов с асл на 3750.

что то не помогло знание, рецепт блокировки не нашелся.

[Azamat]

Подниму старую тему, т.к. тогда не был найден рецепт.

Может быть кто-то сможет выручить на новом витке эволюции ?

 

все то же - как убить LLMNR если доступ на cisco 2950T, аггрег. на 3750 ?

[teer]

На 3750 должно быть возможным посредством mac access list. По крайней мере на 3750ME я любые мультикасты резал им.

[Azamat]

мак лист есть, но не помогает

пробовали. Или что то не то делали, хотя возможности ошибиться не много.

 

deny был from any на мак группы 224.0.0.252 - все равно в процессор падал трафик. Там ТТЛ = 1, может это дело раньше мак-листа в проц валится ?

[Minya]

а флуд идет во все порты влана с мультикастом?

как вариант если на портах нет bpdu фильтра, коммутатор получая с порта tcn пакет начинает флудить мультикастом во все порты этого влана.

команда "no ip igmp snooping tcn flood" на портах - запрещает это дело.

[darkagent]

igmp profile / igmp filter не катит?

[Azamat]

для того, чтобы появился флуд по tcn - собственно сам ивент tcn должен где то в сети появиться.

Реально, проблему дает мультикаст со спуфленного IP адреса, почему то этим страдает зоопарк ТП-Линк/Тенда - в какой-то момент вполне себе правильно настроенная точка доступа начинает флудить на 224.0.0.252 c чужого IP адреса. И очень приличным ппс - порядка 8-10 кппс. И к этому флуду начинают подключаться еще несколько точек доступа того же вендора в этом влане. Тут уж проц на 3750 взлетает до 95 проц.

[denis_vid]

Поробуйте простой acl вида

deny any any 224.0.0.252

permit any any

[Azamat]

это было сделано в первую очередь до обращения в форум.

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

[darkagent]

на доступе:

ip igmp profile 1

deny

range 224.0.0.252

!

int range fa0/1 - 24

ip igmp filter 1

 

но если честно, все это шаманство. если хотите решать проблему наверняка, начните с детальной диагностики.

 

на 3750 на даунлинках проделать следующее:

int GX/Y/Z

storm-control multicast level pps 4k

storm-control unicast level pps 4k

storm-control action trap

и при возникновении трапа смотрим

show storm-control

 

собсна в момент 100% загрузки проца интересуют выводы следующих команд:

show processes cpu sorted 5sec (первые 5 строк)

show controllers cpu-interface

show ip traffic

[dmvy]

была похожая ситуация - никакие igmp/multicast фильтры не помогают с диапазоном 224.0.0.0/24. пришлось на нижестоящем dgs-3120 делать acl в сторону даунлинков с привязкой в абонентским vlan не принимать из абонентских никаких multicast, т.к. iptv в отдельном VLAN, то на лигитимный трафик это не влияет.

[denis_vid]

это было сделано в первую очередь до обращения в форум.

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

Вы точно указывали именно any any?

Потому что ip any/udp any эффекта не дадут.

[Azamat]

пробовали VACL c

permit ip any 224.0.0.252

action drop