zillingen Posted September 8, 2011 Posted September 8, 2011 В ядре сети стоят два Catalyst 4500, Supervisor IV WS-X4515. Один из них настроен как обычный свитч 2-го уровня, на нем один из Вланов очень большой, настроен почти на всех портах и в нем находится очень много абонентов. Так вот, иногда загрузку CPU на коммутаторе зашкаливает под 100%, основная загрузка на процессе Cat4k Mgmt LoPri. Я мониторил процессорные очереди, так же мониторил трафик в этом большом Влане. В итоге моих наблюдений я заметил, что когда на Циску приходят IP пакеты с destination address 224.0.0.xxx, то она начинает флудить их на все порты, где есть этот Влан и как раз на это и расходуются все ресурсы процессора. Вот что нашел в документации: Groups with IP addresses in the 224.0.0—255 range are reserved for routing control packets and are flooded to all forwarding ports of the VLAN. These addresses map to the multicast MAC address range 0100.5E00.0001 to 0100.5E00.00FF. Чтобы убрать флуд я создал vlan access-map, запрещающую пакеты с source и destination 224.0.0.0 0.0.0.255. Так же настроил на всех портах ip igmp group, разрешающую только наши IPTV группы 224.0.42.xxx. Но один хрен CPU utilization периодически зашкаливает и в эти моменты в дампе трафика я вижу пакеты с IP-адресами 224.0.0.xxx. Вопрос: Как ограничить ненужный мультикаст, не вешать же на все порты ACL? Были ли у кого-нибудь похожие проблемы с CPU utilization на Catalyst 4500 и как их решали? Вставить ник Quote
mschedrin Posted September 8, 2011 Posted September 8, 2011 Шторм контроль не пробовали включать на портах? Вставить ник Quote
darkagent Posted September 8, 2011 Posted September 8, 2011 а вы прям таки убийца. просто посмотрите что вы в итоге убили: http://www.networksorcery.com/enp/protocol/ip/multicast.htm начните с http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a00804cef15.shtml Вставить ник Quote
zillingen Posted September 8, 2011 Author Posted September 8, 2011 Шторм контроль не пробовали включать на портах? Нет, я про него как-то забыл:-), но на этом супервизоре stormcontrol можно включить только на broadcast, причем в этой платформе(Suprevisor IV) broadcast supression софтварный, а multicast supression вроде вообще нет... Вставить ник Quote
zillingen Posted September 8, 2011 Author Posted September 8, 2011 просто посмотрите что вы в итоге убили: http://www.networkso...p/multicast.htm Я в курсе, но фильтр я повесил как раз только на большой клиентский Влан начните с http://www.cisco.com...0804cef15.shtml Уже читал, эта статья мне как раз помогла найти причину, но вот что с ней теперь делать...? Проблему скорее всего можно решить установкой Supervisor engine V, там есть hardware multicast and broadcast supression, или разделением влана на несколько меньших. Но эти решения слишком долгие. Вставить ник Quote
s.lobanov Posted September 8, 2011 Posted September 8, 2011 Ну значит надо большой клиентский влан разбить на много маленьких, чтобы ресурсы cpu не тратились на рассылку multicast на все порты. Вставить ник Quote
st_re Posted September 8, 2011 Posted September 8, 2011 мне так кажется, что зарубив 224.0.0.0/24 Вы зарубили IGMP, и теперь действительно без шансов, мультикаст будет литься во все порты влана. наверное нужно таки открыть IGMP и настроить его со стороны кошек, тогда телефидение будет литься только в порты, где есть подписчики. Все остальное (не относящее к TV и IGMP зарубить для 224.0.0.0/4) Какойи именно адрес был в сети 224.0.42.0/24 куда много лилось? По идее там много быть не должно. Если много, то найти и лицо набить (зафильтровать его там, поближе к источнику). Вставить ник Quote
zillingen Posted September 8, 2011 Author Posted September 8, 2011 (edited) мне так кажется, что зарубив 224.0.0.0/24 Вы зарубили IGMP, и теперь действительно без шансов, мультикаст будет литься во все порты влана. наверное нужно таки открыть IGMP и настроить его со стороны кошек, тогда телефидение будет литься только в порты, где есть подписчики. Все остальное (не относящее к TV и IGMP зарубить для 224.0.0.0/4) Какойи именно адрес был в сети 224.0.42.0/24 куда много лилось? По идее там много быть не должно. Если много, то найти и лицо набить (зафильтровать его там, поближе к источнику). С сетью 224.0.42.0/24 проблем нет, я наоборот на портах разрешил только её igmp запросы. ТВ у нас в отдельных вланах, в них проблем нет. Проблема только в одном большом пользовательском влане, т.к. он почти на всех портах. Причем сыпятся в основном пакеты у которых адрес 224.0.0.ххх, а порт 5353 - это Multicast DNS, нахрен он нужен не понятно. Не знаю может повесить ACL на все порты, только не охренеет ли кошка, т.к. в ней 3 модуля по 48 портов и наверно более 1000 абонентов. Влан фильтр я тоже пока снял, т.к. он не решает проблему, так что теперь igmp разрешен. Edited September 8, 2011 by zillingen Вставить ник Quote
zillingen Posted September 8, 2011 Author Posted September 8, 2011 На самом деле больше всего лезет вот таких пакетов: IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 Поэтому пока создал влан фильтр, дропающий только пакеты с destination 224.0.0.251:5353.... Посмотрю что будет... Вставить ник Quote
marikoda Posted September 8, 2011 Posted September 8, 2011 Вроде бы всякие zeroconf генерят такое? Они сейчас в моде на разных операционках. Слышал, что zeroconf отрубается, если завести в DNS зону .local Вставить ник Quote
xcme Posted September 8, 2011 Posted September 8, 2011 Слышал, что zeroconf отрубается, если завести в DNS зону .local А как zeroconf найдет dns? Вставить ник Quote
tester-str Posted September 9, 2011 Posted September 9, 2011 На самом деле больше всего лезет вот таких пакетов: IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 IP x.x.x.x.mdns > 224.0.0.251.mdns: UDP, length 62 Поэтому пока создал влан фильтр, дропающий только пакеты с destination 224.0.0.251:5353.... Посмотрю что будет... Такие вещи надо резать на доступе. Вставить ник Quote
XaTTa6bl4 Posted February 13, 2012 Posted February 13, 2012 Слышал, что zeroconf отрубается, если завести в DNS зону .local А можно по подробнее про это? Просто сейчас проблема возобновилась, но в достаточно маленьком VLAN. Вычислили, что некоторые клиенты начинают флудить такими пакетами (MDNS по 64 байта). Флуд длится обычно около 4-х секннд, потом перерыв секунд на 30. Никому с таким бороться не приходилось? Вставить ник Quote
Elnemo Posted February 13, 2012 Posted February 13, 2012 Никому с таким бороться не приходилось? Приходилось, ACL Вот у мужика те же проблемы были: http://www.ryanhicks.net/blog/2008/12/cisco-4500-intermittant-high-cpu-utilization---part-2.html Вставить ник Quote
XaTTa6bl4 Posted February 14, 2012 Posted February 14, 2012 Вообщем, если кому интересно, решил принять комплексные меры. 1) Подняли в DNS зону .local. Часть zeroconf сервисов действетельно, видя что она обслуживается DNS серверами, сами вырубаются. mDNS трафика стало меньше. 2) Будем набивать ACL на доступе Elnemo спасибо за линк Вставить ник Quote
xcme Posted February 14, 2012 Posted February 14, 2012 И все же, как зироконф находит днс? о_О? Вставить ник Quote
XaTTa6bl4 Posted February 14, 2012 Posted February 14, 2012 xcme Не углублялся в эту тему, но, по крайней мере, демон avahi сразу выключается с сообщением на экран Но поднятие зоны .local все-таки не принесло полезных результатов, тк флуд повторился вновь и мне только что удалось вычислить источник и прикрыть ACL. Только тогда ситуация нормализовалась. Кстати, мне думается, что это нечто типа вируса, так как начинает флудить один IP и периодически к нему присоединяются совершенно разные. Но стоит прикрыть этого самого активного, как все проходит .... хмм... Вставить ник Quote
SergeiK Posted February 15, 2012 Posted February 15, 2012 Есть специальный механихм защиты CPU 4500 коммутатора. Называется CPP. http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/cntl_pln.html Сначало можно просто включить, ничего не резать, а по счетчикам посмотреть, что приходит, по какой группе. Потом уже эту группу ограничить, опытным путем установив предел, при котором свичт работает, но и проблему видно. Решали такую задачу, CPU уходил в такой перегруз, что рвал OSPF с соседями по timeout-у. Поставили лимит, теперь спойкойно. Приходил какой-то левый трафик с RP, причину выяснить достоверно не удалось, но она нас и не беспокоит особенно :). Там CPU довольно слабый, платформа древняя, и проблема перегрузки CPU довольно известная. Вставить ник Quote
XaTTa6bl4 Posted February 16, 2012 Posted February 16, 2012 SergeiK спасибо, погуглил - похоже это реально может помочь. Займусь изучением =) Вставить ник Quote
XaTTa6bl4 Posted February 20, 2012 Posted February 20, 2012 Клиент, с порта которого шел флуд, выяснил откуда ноги растут (мож кому пригодится): "Проблема была в неконтроллируемом поведении медиаплееров popcornhour, которые начинали массовые рассылки запросов по протоколу mdns." Вставить ник Quote
s.lobanov Posted February 20, 2012 Posted February 20, 2012 Клиент, с порта которого шел флуд, выяснил откуда ноги растут (мож кому пригодится): "Проблема была в неконтроллируемом поведении медиаплееров popcornhour, которые начинали массовые рассылки запросов по протоколу mdns." Это конечно полезно, но по большому счёту не должно быть важно чем мусорит клиент, в идеале, весь мусор должен урезаться до незначительных величин(или полностью, если он 100% не нужный трафик) на оборудовании isp Вставить ник Quote
XaTTa6bl4 Posted February 20, 2012 Posted February 20, 2012 s.lobanov, полностью с Вами согласен. Как раз занимаемся модернизацией/оптимизацией сети)) Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.