Solar Posted December 22, 2012 Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Судя по выводу show processes cpu "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети. Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted December 22, 2012 Начните с поиска интерфейса, в который прёт много бродкаста. Начать поиски с команды show int | i (line protocol|Received) А лучше нарисуйте графики по бродкст-трафику на каждом порту Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SergeiK Posted December 22, 2012 Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Судя по выводу show processes cpu "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети. Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы? Тут много тем по процу 6500, да и на Cisco написано много. Лучший способ, по моему мнению - поставить policy на control plane и ограничивать трафик, который жрет очень много. Дальше уже можно разбираться - а почему, главное, что сервис не убивает. Фичу где-то здесь писал, со ссылкой, но сходу не увидел. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
flow Posted December 23, 2012 Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Судя по выводу show processes cpu "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети. Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы? Тут много тем по процу 6500, да и на Cisco написано много. Лучший способ, по моему мнению - поставить policy на control plane и ограничивать трафик, который жрет очень много. Дальше уже можно разбираться - а почему, главное, что сервис не убивает. Фичу где-то здесь писал, со ссылкой, но сходу не увидел. Смотреть в сторону mls qos protocol arp police Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SergeiK Posted December 23, 2012 Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Судя по выводу show processes cpu "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети. Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы? Тут много тем по процу 6500, да и на Cisco написано много. Лучший способ, по моему мнению - поставить policy на control plane и ограничивать трафик, который жрет очень много. Дальше уже можно разбираться - а почему, главное, что сервис не убивает. Фичу где-то здесь писал, со ссылкой, но сходу не увидел. Смотреть в сторону mls qos protocol arp police Не-е, применять policy именно на control=plane. http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html Ну и это, в целом, стоит почитать: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/best/practices/recommendations.html Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted December 23, 2012 Не-е, применять policy именно на control=plane. http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html И что же мы при этом получаем? Да, график загрузки CPU будет красивым, CLI не будет тормозить, но при этом будет дропаться не только "вредный" arp-трафик, но и полезный, т.е. получаем некую деградацию сервиса, но внешне выглядет как-будто всё хорошо, это называется "спрятать голову в песок" В самом деле, защита control-plane в точке терминирования это лишь дополнительные меры на случай, если что-то прошло через защиты(всякие broadcast-контроли и т.п.) уровней ниже. Как правило, полисеры в сторону control-plane вешаются либо на весь CP, либо на линейную карту, даже per-port уже редкость, не говоря уже про per-port-per-vlan. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
SergeiK Posted December 23, 2012 Не-е, применять policy именно на control=plane. http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html И что же мы при этом получаем? Да, график загрузки CPU будет красивым, CLI не будет тормозить, но при этом будет дропаться не только "вредный" arp-трафик, но и полезный, т.е. получаем некую деградацию сервиса, но внешне выглядет как-будто всё хорошо, это называется "спрятать голову в песок" В самом деле, защита control-plane в точке терминирования это лишь дополнительные меры на случай, если что-то прошло через защиты(всякие broadcast-контроли и т.п.) уровней ниже. Как правило, полисеры в сторону control-plane вешаются либо на весь CP, либо на линейную карту, даже per-port уже редкость, не говоря уже про per-port-per-vlan. Стоп какой per-port? Он вешается именно на control-plane, что была возможность управлять потоками трафика на CPU. Ну, с такой логикой и storm-control - бесполезная штука, потому что блокирует в том числе и полезный трафик. На самом деле, да, дополнительный уровень защиты CPU, но позволяет сохранить управляемость при проблемах. По умолчанию вообще ничего не режется, но вы можете посмотреть, а что же падает на CPU, и что может быть проблемой. Потмо ставьте уровни, чтоб, при загрузке, CPU был выше нормальных уровенй, и вы сразу увидите, на графике, что были проблемы, которые надо решать. Но при этом все остальные сервисы не падают насмерть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted December 23, 2012 Ну, с такой логикой и storm-control - бесполезная штука, потому что блокирует в том числе и полезный трафик. Только я писал про storm-control уровней ниже. Если вы вешаете storm-control(или различные его вариации) на абонентский порт на коммутаторе доступа, то "страдает" один абонент(в самом деле, скорее всего он и так не работает, если с его порта штормит). Когда же вы зарезаете поток arp-трафика применительно ко всему CP или индивидуально к линейной карте, то страдают от этого абоненты всего шасси(либо абоненты, сидящие на этой линейной карте(если CoPP-овский service-policy применён к слоту)) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dmvy Posted December 23, 2012 Начните с поиска интерфейса, в который прёт много бродкаста. Начать поиски с команды show int | i (line protocol|Received) А лучше нарисуйте графики по бродкст-трафику на каждом порту графики будут реально полезны. +1 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted December 23, 2012 Во всем этом есть один пренеприятнейший момент, CoPP не спасает от arp-флуда, те полиси настроена и применена, но проц не спасает, это плохо, но это факт встреченный в сети и возпроизведенный на тестовом стенде. единственный способ - ставить storm-control на порту абонента, а лучше, не раздумывая, вешать сразу на все абонентские порты, и не придется искать того конкретного, от кого эта гадость идет, хотя после включения контроля это не составит труда, ибо (по крайней мере каталисты) посылают system message о том что был был обнаружен шторм Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted December 23, 2012 Во всем этом есть один пренеприятнейший момент, CoPP не спасает от arp-флуда, те полиси настроена и применена, но проц не спасает, это плохо, но это факт встреченный в сети и возпроизведенный на тестовом стенде. Не проверял на платформах c6500/c7600, но на huawei на старших S-свитчах и NE/CX-платформах оно работает(там кстати разделяется arp на несколько типов - arp-miss, arp-reply, arp-request). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zi_rus Posted December 23, 2012 не рискнул бы утверждать что это так на всех устройствах, но в моем случае это была Cisco 7600, а так как тут мы говорим о 6500, то смею предположить что результат будет таким же Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
IVB Posted December 26, 2012 Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Уточнение: SP загружен примерно на 30%, его загрузка не меняется при изменениях загрузки RP. А с RP картина грустная. В "нормальном" режиме процесс "ARP Input" кушает примерно 30% (что, на мой взгляд, тоже очень много!), а в критические моменты (когда Циска перестает отвечать) процесс "ARP Input" начинает отжирать 90-95%%, при этом общая загрузка становится 99%/2% (т.е. даже на прерывания не остается ресурсов). Что самое непонятное - понаблюдали за бродкастом - нет интерфейсов, на которых было бы чрезмерное количество броадкастных пакетов (ни входящих, ни исходящих). Через 3 часа после "clear counters" самое большое количество броадкастных пакетов не превысило 3000. Т.е. мы пока не можем понять, чем занят процесс "ARP Input"... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
darkagent Posted December 26, 2012 один лишь момент, conf t ip arp proxy disable насколько % снижает нагрузку на rp? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
IVB Posted December 27, 2012 один лишь момент, conf t ip arp proxy disable насколько % снижает нагрузку на rp? Разницы практически нет. У нас на всех IP интерфейсах стоит "no ip proxy-arp". Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted December 27, 2012 А что говорит "sh ip arp sum"? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NikAlexAn Posted December 27, 2012 один лишь момент, conf t ip arp proxy disable насколько % снижает нагрузку на rp? Если arp proxy запрещен глобально или на интерфейсах - то процесс ARP Input кушает не больше 1%. Но однако arp proxy нужен. Может local-proxy-arp меньше грузит RP? Какие либо будут советы? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
IVB Posted December 27, 2012 А что говорит "sh ip arp sum"? 2554 IP ARP entries, with 21 of them incomplete Это в 9 утра, при этом "ARP Input" кушает 13%. При максимальной нагрузке точную цифру не вспомню - но точно меньше 5000. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
darkagent Posted December 27, 2012 Но однако arp proxy нужен. если он нужен везде - стоит пересмотреть архитектуру всей сети, или переложить L3 на более умные железки (ASR1k/9k например) если нужен не везде - повырубать на лишних интерфейсах, и свести его присутствие до минимума. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
shvlad1 Posted December 27, 2012 COPP на control-plane, storm-control на интерфейсах ну и глобально mls rate-limit - что и как ставить - ищется по лучшим практикам на сайте циски Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
IVB Posted December 27, 2012 Но однако arp proxy нужен. если он нужен везде - стоит пересмотреть архитектуру всей сети, или переложить L3 на более умные железки (ASR1k/9k например) если нужен не везде - повырубать на лишних интерфейсах, и свести его присутствие до минимума. Вы, наверное, не заметили мой сегодняшний пост от 07:35. У меня на всех интерфейсах, где arp proxy не нужен, он выключен. А нужен он всего на одном vlan'е... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
andryas Posted December 28, 2012 Статическая таблица arp не уменьшит нагрузку? Процессор, по идее, не будет тратить время на обработку запросов и резолвинг. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Savaoff Posted December 28, 2012 Может у вас периодически кольцо возникает в каком-нибудь влане? У себя на 6506х видел высокую загрузку процессом arp input только при кольцах в сети. В эти моменты на каталюгу надежно можно попасть только через консольный порт. Быстро найти, где возникло кольцо - не тривиальная задача, т.к. возникнуть оно может (из-за ошибок персонала, конечно) между двумя дотаточно примитивными свичами на окраине сети, но шторм все равно доберется по какому-либо из вланов до core-роутеров со всеми вытекающими... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NikAlexAn Posted December 29, 2012 Может у вас периодически кольцо возникает в каком-нибудь влане? У себя на 6506х видел высокую загрузку процессом arp input только при кольцах в сети. В эти моменты на каталюгу надежно можно попасть только через консольный порт. Быстро найти, где возникло кольцо - не тривиальная задача, т.к. возникнуть оно может (из-за ошибок персонала, конечно) между двумя дотаточно примитивными свичами на окраине сети, но шторм все равно доберется по какому-либо из вланов до core-роутеров со всеми вытекающими... Именно в момент восстановления кольца такая ситуация и наблюдалась. Схема влан на абонента, примерно по 10-15 коммутаторов кольце, управляющий влан был общий для всех колец, STP на абонентских коммутаторах не включен. me3400g с такой схемой справлялся без проблем а вот sap720-3b чего то не нравится. Сейчас несколько колец переделал - включил STP на абонентских коммутаторах и выделил отдельные управляющие вланы для колец - вроде полегче стало. Надо видать все переделывать. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Solar Posted December 31, 2012 Симптомы удалось снять. Загрузка процессора вернулась с норму. Существовала вот такая конструкция: interface Loopback13 ip address 10.0.0.1 255.255.255.0 ip address 10.* 255.255.255.0 secondary ip address 10.* 255.255.255.0 secondary ip address 10.* 255.255.255.0 secondary no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip route-cache policy end данный интерфейс навешивался на все пользовательские vlan'ы, vlan'ы, соответственно, настроены следующим образом: interface Vlan1120 ip unnumbered Loopback13 ip helper-address 192.168.105.138 no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip route-cache policy end В vlan'ах есть как пользователи авторизующиеся при помощи DHCP + opt82 (которым в качестве шлюза выдается 10.0.0.1), так и пользователи авторизующиеся при помощи Dual Access РРРоЕ. Серые IP последних подроблены на подсети класса С. Шлюз для каждой такой сетки и повешен на тот же loopback интерфейс в каче стве secondary IP. Так вот, выяснилось, что с увеличением этих самых secondary адресов на loopback интерфейсе растет ARP Input. После того, как было снижено количество этих вторичных адресов на loopback'е загрузка пришла в норму, циска больше не впадает в кататонический ступор. К сожалению, так и не удалось понять саму физику данного явления, т.е. все это происходит потому, что где-то что-то банально недонастроено, или мы уперлись в какие-то аппаратные/программные ограничения? Чтение цисковской документации пока ответа не дает, если есть знатоки, разбирающиеся в вопросе, огромная просьба поделиться информацией. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...