Монитиринг брудкаст-штормов

[Wingman]

Суть проблемы: время от времени в сети возникают либо петли, которые длинки по каким-то причинам не могут отловить на своих портах, либо адские брудкаст-штормы, которые, опять же, акцесс-свитчи почему-то не ловят шторм-контролем.

 

При этом аггрегирующим шеститонникам сносит крышу от ARP Input, процессор в полке.

 

В забиксе у нас мониторятся все свитчи аггрегации и в идеале в подобных случаях быстро получается найти аномалию.

Однако иногда бывает так:

 

На графике портов 6506 видно, что лавинообразно вырос брудкаст на одном из 10g-портов:

 

Однако вот график брудкаста на портах железки, висящей на этом порту:

 

Из него видно, что одновременно вырос инпут брудкаст на всех портах. Возможно, шторм прилетает в один порт и улетает во все другие, где есть соответствующие вланы, и в них же прилетает обратно - отсюда инпут на всех портах.

Но как в таких условиях понять, откуда изначально прилетела бяка? Часто получается просто погасить часть портов, включить обратно - и шторм пропадает, но его источник при этом остаётся неизвестен ;(

 

Трафик-контрол (шторм-контрол) на аггрегации тут не сильно поможет, т.к. неизвестно заранее, сколько абонентов и трафика может быть на одном порту. Может быть один акцесс-свитч, а может быть пол-города.

 

Кто как у себя решает подобные проблемы?

[Negator]

Я бы попробовал найти влан в котором проблемы и погасить его на нужных портах.

Далее искать проблему на агрегации и доступе.

Т.е. пробуйте гасит не порты, а вланы.

ну и сегментировать сеть, чтобы при гашении одного влана это не задело много абонентов.

[Wingman]

Ну то есть только эмпирическим путём :)

Примерно так тоже пробуем, да, иногда - получается. Но хочется как-то всё-таки автоматизировать и замониторить такие вещи ;(

[zhenya`]

а если замерять количество броадкаста в SVI ? найдите проблемный влан )

[Wingman]

Да их у нас тыщи три :) Можно, конечно, но хрен знает, как оперативно в такой массе всплески найти

 

Но тоже вариант, да

[zhenya`]

Тогда дальше на агрегации ловить..

[Wingman]

А про это я уже написал выше ;(

[v_r]

Но как в таких условиях понять, откуда изначально прилетела бяка? Часто получается просто погасить часть портов, включить обратно - и шторм пропадает, но его источник при этом остаётся неизвестен ;(

 

При большой загрузке из-за ARP Input разобраться очень просто, включаете на шеститоннике debug ip arp и в логах читаете в каких виланах есть проблемы и с какими конкретно мак-адресами. Дальше отслеживаете путь вилана в сети и разбираетесь почему получилась петля. И на шеститоннике можно включить storm control на broadcast и multicast на довольно малые значения - посмотрите сколько трафика в нормальном режиме бегает и установите storm-control на значение в 10 раз больше но не более 1000pps.

Еще при "петлях" в зависимости от топологии сети мак-адреса могут переходить с порта на порт, здесь вам поможет включение mac move notification.

[Wingman]

При большой загрузке из-за ARP Input разобраться очень просто, включаете на шеститоннике debug ip arp и в логах читаете в каких виланах есть проблемы и с какими конкретно мак-адресами.

 

А она не сдохнет моментально от дебага-то? При:

#sh ip arp summary

21436 IP ARP entries, with 386 of them incomplete

 

А макфлапы мониторим, да

[v_r]

А она не сдохнет моментально от дебага-то?

 

 

При ограничении броадкаста на портах точно не сдохнет, тем более что включать дебаг стоит секунд на 5. Включал на 45й во время шторма (правда там ARP было поменьше), большой разницы в загрузке процессора не замечал. Как вариант можете сливать зеркало порта CPU на компьютер и анализировать трафик там если шеститонник такое умеет.