Wingman Опубликовано 11 октября, 2015 · Жалоба Суть проблемы: время от времени в сети возникают либо петли, которые длинки по каким-то причинам не могут отловить на своих портах, либо адские брудкаст-штормы, которые, опять же, акцесс-свитчи почему-то не ловят шторм-контролем. При этом аггрегирующим шеститонникам сносит крышу от ARP Input, процессор в полке. В забиксе у нас мониторятся все свитчи аггрегации и в идеале в подобных случаях быстро получается найти аномалию. Однако иногда бывает так: На графике портов 6506 видно, что лавинообразно вырос брудкаст на одном из 10g-портов: Однако вот график брудкаста на портах железки, висящей на этом порту: Из него видно, что одновременно вырос инпут брудкаст на всех портах. Возможно, шторм прилетает в один порт и улетает во все другие, где есть соответствующие вланы, и в них же прилетает обратно - отсюда инпут на всех портах. Но как в таких условиях понять, откуда изначально прилетела бяка? Часто получается просто погасить часть портов, включить обратно - и шторм пропадает, но его источник при этом остаётся неизвестен ;( Трафик-контрол (шторм-контрол) на аггрегации тут не сильно поможет, т.к. неизвестно заранее, сколько абонентов и трафика может быть на одном порту. Может быть один акцесс-свитч, а может быть пол-города. Кто как у себя решает подобные проблемы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Negator Опубликовано 11 октября, 2015 · Жалоба Я бы попробовал найти влан в котором проблемы и погасить его на нужных портах. Далее искать проблему на агрегации и доступе. Т.е. пробуйте гасит не порты, а вланы. ну и сегментировать сеть, чтобы при гашении одного влана это не задело много абонентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 октября, 2015 · Жалоба Ну то есть только эмпирическим путём :) Примерно так тоже пробуем, да, иногда - получается. Но хочется как-то всё-таки автоматизировать и замониторить такие вещи ;( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 11 октября, 2015 · Жалоба а если замерять количество броадкаста в SVI ? найдите проблемный влан ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 октября, 2015 · Жалоба Да их у нас тыщи три :) Можно, конечно, но хрен знает, как оперативно в такой массе всплески найти Но тоже вариант, да Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 11 октября, 2015 · Жалоба Тогда дальше на агрегации ловить.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 октября, 2015 · Жалоба А про это я уже написал выше ;( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 11 октября, 2015 · Жалоба Но как в таких условиях понять, откуда изначально прилетела бяка? Часто получается просто погасить часть портов, включить обратно - и шторм пропадает, но его источник при этом остаётся неизвестен ;( При большой загрузке из-за ARP Input разобраться очень просто, включаете на шеститоннике debug ip arp и в логах читаете в каких виланах есть проблемы и с какими конкретно мак-адресами. Дальше отслеживаете путь вилана в сети и разбираетесь почему получилась петля. И на шеститоннике можно включить storm control на broadcast и multicast на довольно малые значения - посмотрите сколько трафика в нормальном режиме бегает и установите storm-control на значение в 10 раз больше но не более 1000pps. Еще при "петлях" в зависимости от топологии сети мак-адреса могут переходить с порта на порт, здесь вам поможет включение mac move notification. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 11 октября, 2015 · Жалоба При большой загрузке из-за ARP Input разобраться очень просто, включаете на шеститоннике debug ip arp и в логах читаете в каких виланах есть проблемы и с какими конкретно мак-адресами. А она не сдохнет моментально от дебага-то? При: #sh ip arp summary 21436 IP ARP entries, with 386 of them incomplete А макфлапы мониторим, да Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 11 октября, 2015 · Жалоба А она не сдохнет моментально от дебага-то? При ограничении броадкаста на портах точно не сдохнет, тем более что включать дебаг стоит секунд на 5. Включал на 45й во время шторма (правда там ARP было поменьше), большой разницы в загрузке процессора не замечал. Как вариант можете сливать зеркало порта CPU на компьютер и анализировать трафик там если шеститонник такое умеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...