Azamat Опубликовано 26 февраля, 2012 · Жалоба Несколько приходящих транков, иногда возникает приличный флуд на 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 на клиентских вланах тоже не влияет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 26 февраля, 2012 · Жалоба На длинке 3528 убивал ацлкой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 26 февраля, 2012 · Жалоба Есть сомнения , что вы сможете это зделать обычным acl , если на железяке включено что то типа igmp-snooping или multicast-routing. Если оно так то надо другими методами лочить такие вещи и желательно по ближе к источнику. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 27 февраля, 2012 · Жалоба igmp-snooping включен везде и на источниках тоже. Кроме того, читал что у Cisco igmp-snooping не распространяется на служебную сеть 224.0.0.0/24 (но не поручусь за достоверность), хотя как именно это негативно влияет на действие acl ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Hawk128 Опубликовано 27 февраля, 2012 · Жалоба В моем случае, igmp-snooping включен и ism-vlan тоже, услугу iptv по мультикасту даем. Простая acl на свитчах доступа вырезала этот трафик прекрасно. Проблему вызывали Tplink TP-1043 в случае одновременного присутствия 2-х роутеров в доме, осебенно на соседних свитчах. Начинали оба флудить мультикастом примерно по 11 kpps, при этом вырубаешь одного - второй флуд прекращает. Вроде иправили в последней прошивке, но я уже вырезал к тому моменту и про проблему забыл... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 27 февраля, 2012 · Жалоба Что за пакеты ? Какие параметры ip заголовков , например TTL ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
config Опубликовано 27 февраля, 2012 · Жалоба igmp-snooping включен везде и на источниках тоже. Кроме того, читал что у Cisco igmp-snooping не распространяется на служебную сеть 224.0.0.0/24 (но не поручусь за достоверность), хотя как именно это негативно влияет на действие acl ? Не скажу точно , но зависит отархитектуры , так igmp snoop подразумевает обработку пакета процессором , тут либо делайте это на доступе , либо смотрите что там у вас на 3750 можносделать относительно мультикаст потока, в данном случае у вас на циску приходит просто поток мультикаста причем не известного ей , и на ней конечно нет записи куда этот поток кинуть , нет подписки , и какие там у вас роут порты, вопросов много. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 27 февраля, 2012 · Жалоба http://en.wikipedia.org/wiki/Link-local_Multicast_Name_Resolution Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 27 февраля, 2012 · Жалоба там читалось еще до экспериментов с асл на 3750. что то не помогло знание, рецепт блокировки не нашелся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 20 декабря, 2012 · Жалоба Подниму старую тему, т.к. тогда не был найден рецепт. Может быть кто-то сможет выручить на новом витке эволюции ? все то же - как убить LLMNR если доступ на cisco 2950T, аггрег. на 3750 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
teer Опубликовано 20 декабря, 2012 · Жалоба На 3750 должно быть возможным посредством mac access list. По крайней мере на 3750ME я любые мультикасты резал им. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 20 декабря, 2012 · Жалоба мак лист есть, но не помогает пробовали. Или что то не то делали, хотя возможности ошибиться не много. deny был from any на мак группы 224.0.0.252 - все равно в процессор падал трафик. Там ТТЛ = 1, может это дело раньше мак-листа в проц валится ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 20 декабря, 2012 · Жалоба а флуд идет во все порты влана с мультикастом? как вариант если на портах нет bpdu фильтра, коммутатор получая с порта tcn пакет начинает флудить мультикастом во все порты этого влана. команда "no ip igmp snooping tcn flood" на портах - запрещает это дело. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 20 декабря, 2012 · Жалоба igmp profile / igmp filter не катит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 20 декабря, 2012 · Жалоба для того, чтобы появился флуд по tcn - собственно сам ивент tcn должен где то в сети появиться. Реально, проблему дает мультикаст со спуфленного IP адреса, почему то этим страдает зоопарк ТП-Линк/Тенда - в какой-то момент вполне себе правильно настроенная точка доступа начинает флудить на 224.0.0.252 c чужого IP адреса. И очень приличным ппс - порядка 8-10 кппс. И к этому флуду начинают подключаться еще несколько точек доступа того же вендора в этом влане. Тут уж проц на 3750 взлетает до 95 проц. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
denis_vid Опубликовано 20 декабря, 2012 · Жалоба Поробуйте простой acl вида deny any any 224.0.0.252 permit any any Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 20 декабря, 2012 · Жалоба это было сделано в первую очередь до обращения в форум. подобных тем полоно в гугле, на различных форумах. Но решения никто так и не нашел судя по репликам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 20 декабря, 2012 · Жалоба на доступе: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 20 декабря, 2012 · Жалоба была похожая ситуация - никакие igmp/multicast фильтры не помогают с диапазоном 224.0.0.0/24. пришлось на нижестоящем dgs-3120 делать acl в сторону даунлинков с привязкой в абонентским vlan не принимать из абонентских никаких multicast, т.к. iptv в отдельном VLAN, то на лигитимный трафик это не влияет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
denis_vid Опубликовано 20 декабря, 2012 · Жалоба это было сделано в первую очередь до обращения в форум. подобных тем полоно в гугле, на различных форумах. Но решения никто так и не нашел судя по репликам. Вы точно указывали именно any any? Потому что ip any/udp any эффекта не дадут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 21 декабря, 2012 · Жалоба пробовали VACL c permit ip any 224.0.0.252 action drop Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...