Перейти к содержимому
Калькуляторы

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

Несколько приходящих транков, иногда возникает приличный флуд на 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 на клиентских вланах тоже не влияет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

deny any any 224.0.0.252

permit any any

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на доступе:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

пробовали VACL c

permit ip any 224.0.0.252

action drop

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.