[roma33rus]

Всем привет. Решил написать более опытным товарищам. Ситуация такая. Есть длинк 3200-28/B1 (1.83.B005) , за ним абонент. И иногда начинается такое, что от абонента прет мультикаст непонятный. И на большинстве коммутаторов в сети cpu загрузка в два раза больше, а то и под 100% бывает. Абонент, как говорится, не в курсе вообще, что там за мультикаст у него. График скину, ниже приложу счетчики на порту. Шторм контроль включали, conf multicast port_filter выставляли. Кто как борется с этим делом? и можно ли вообще бороться? Может вообще ACLем заблокировать весь мультикаст на порту? И еще дополнительный вопрос, кто как на длинках снимает дамп трафика удаленно? Интересно посмотреть, что там прет?

 

Вот счетчики:

Command: show packet ports 6


Port Number : 6
Frame Size    Frame Counts  Frames/sec    Frame Type   Total       Total/sec
------------  ------------  ----------    ----------   ----------  ---------
64            9738787       0             RX Bytes     1086003155  867395
65-127        61796499      1             RX Frames    1842977497  5253
128-255       1760967293    5251
256-511       492272        0             TX Bytes     3408973894  318
512-1023      208025        2             TX Frames    143297534   2
1024-1518     9774620       0

Unicast RX    85938245      0
Multicast RX  1757039224    5251
Broadcast RX  28            2

 

И вот график:

[s.lobanov]

скорее всего это ipv6 multiast мусор, вы tcpdump-ом посмотрите. на длинках легко убивается ACL-ем, но могут быть нюансы если включены какие-нибудь nd-снупинги

[roma33rus]

скорее всего это ipv6 multiast мусор, вы tcpdump-ом посмотрите. на длинках легко убивается ACL-ем, но могут быть нюансы если включены какие-нибудь nd-снупинги

Точно, про v6 то я и не подумал. Спасибо глянем. Удаленно с длинков можно как-то дамп снять не подскажете? rspan не пойдет для этого дела?

[s.lobanov]

roma33rus

Зачем вам чё-то спанить, если это мусор, гуляющий по всей сети, то просто заведите проблемные вланы на какой-нибудь сервер и там делайте дамп

[roma33rus]

roma33rus

Зачем вам чё-то спанить, если это мусор, гуляющий по всей сети, то просто заведите проблемные вланы на какой-нибудь сервер и там делайте дамп

 

Да, логично :-) спасибо. Так и сделаем.

[straus]

А там точно мультикаст? Или как раз тот случай, когда совпадение хэшей в таблице, и 3200 переходят в режим хабов?

[pingz]

Авторизация какая? Дамп удаленно не получится нужно ехать с ноутом.

[nixx]

И иногда начинается такое, что от абонента прет мультикаст непонятный.

у роутеров длинк (может, и у других, но я неоднократно сталкивался именно с длинками) есть нехорошая привычка сходить с ума, пытаясь получить ipv6-адрес - начинают основательно флудить мультикастовыми dhcpv6-запросами.

при этом клиент практически ничего не замечает, ipv4 работает норм.

[rdc]

В большинстве случаев это два провайдера, воткнутые в один свич-мыльницу у абонента.

Мультикастовое телевидение одного из провайдеров заливается во второго.

 

Простейшее решение - зарезать до минимума шторм-контролем.

Фильтровать мультикаст полностью низя - сломаете ipv6.

[s.lobanov]

В большинстве случаев это два провайдера, воткнутые в один свич-мыльницу у абонента.

Мультикастовое телевидение одного из провайдеров заливается во второго.

 

Простейшее решение - зарезать до минимума шторм-контролем.

Фильтровать мультикаст полностью низя - сломаете ipv6.

 

Как будто тут IPv6 работает хотя бы у трети участников форума... да особенно без pppoe. не верю!

 

А если инет pppoe, то для ipv6 там не нужен нейтив мультикаст

[Ivan_83]

ipv6 мультикаст легко отделяется от ipv4 на уровне ACL по оффсетам.

[pppoetest]

Емнип, дело в шляпемаке, у ипв6 первые два байта 33:33

[roma33rus]

Авторизация какая? Дамп удаленно не получится нужно ехать с ноутом.

IPoE dhcp у нас получается.

 

А там точно мультикаст? Или как раз тот случай, когда совпадение хэшей в таблице, и 3200 переходят в режим хабов?

 

Вот дамп левого трафика. Не особо похож на мультикаст :-)

flood_ipv6-dhcp.zip

 

И иногда начинается такое, что от абонента прет мультикаст непонятный.

у роутеров длинк (может, и у других, но я неоднократно сталкивался именно с длинками) есть нехорошая привычка сходить с ума, пытаясь получить ipv6-адрес - начинают основательно флудить мультикастовыми dhcpv6-запросами.

при этом клиент практически ничего не замечает, ipv4 работает норм.

 

А вы правы :-) там dhcpv6 запросы.

 

В большинстве случаев это два провайдера, воткнутые в один свич-мыльницу у абонента.

Мультикастовое телевидение одного из провайдеров заливается во второго.

 

Простейшее решение - зарезать до минимума шторм-контролем.

Фильтровать мультикаст полностью низя - сломаете ipv6.

 

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

[s.lobanov]

Почему не похож на мультикаст? нормальный ipv6 мультикаст. если у вас native ipv6 не используется, то просто блокируйте весь трафик на dst-mac=33-33-xx-xx-xx-xx с помощью ACL-ей на D-Link-е

[roma33rus]

ipv6 мультикаст легко отделяется от ipv4 на уровне ACL по оффсетам.

 

А если вообще ipv6 на портах зарезать, думаете будет толк? Или проблемы лишние вылезут? Как выяснилось у нас проблема в dhcpv6

 

Почему не похож на мультикаст? нормальный ipv6 мультикаст. если у вас native ipv6 не используется, то просто блокируйте весь трафик на dst-mac=33-33-xx-xx-xx-xx с помощью ACL-ей на D-Link-е

 

На сети вообще ipv6 никак не используем. Только v4. Отлично, тогда попробуем так залочить :-)

[s.lobanov]

roma33rus

а что значит вообще? зарезать вы можете либо по ip, либо по mac. по mac резать проще, т.к. не все свитчи умеют ipv6 acl. но по IP вы можете зарезать весь ACL, по макам - только мультикаст, который мусорит вам в сеть

[Demiurgos]

Можно и по ethertype зарезать, если никак не используется - 0x86DD

[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 используются давно. Единственное, в чём не уверен - это в их эффективности - написал, но не проверял. :-)

[s.lobanov]

AlKov

В целом такие ACL эффектины, лишь с нюансом на то, что из-за всяких включенных снупингов трафик может пройти через CPU в обход ACL

[purecopper]

На a1/b1 dhcpv6 не победить вообще никакими ACL. Не помогает даже фильтрация по ethertype. Единственное решение - C1 со свежими прошивками и config address_binding dhcp snooping ports

[AlKov]

AlKov

В целом такие ACL эффектины, лишь с нюансом на то, что из-за всяких включенных снупингов трафик может пройти через CPU в обход ACL

Да, я в курсе.

В моей сети мультикаст отсутствует совсем, а в дилинке снупинг отключён по-дефолту.

Поэтому надеюсь, что всё работает, как задумано. :-)

 

На a1/b1 dhcpv6 не победить вообще никакими ACL. Не помогает даже фильтрация по ethertype. Единственное решение - C1 со свежими прошивками и config address_binding dhcp snooping ports

Т.е. получается, что не всё гладко в моём королевстве? А1/B1 у меня большинство..

[purecopper]

Ну, как уже сказали выше, возможен вариант фильтрации по ethertype на вышестоящем коммутаторе.

[Demiurgos]

На a1/b1 dhcpv6 не победить вообще никакими ACL. Не помогает даже фильтрация по ethertype.

Насколько я помню у D-Link манипуляции с multicast/broadcast через CPU ACL

[purecopper]

Demiurgos ни через CPU ACL, ни через ACL не помогало.

[s.lobanov]

purecopper

а есть подтверждение от длинка по этому вопросу? или это ваш личный опыт?