Solar Опубликовано 22 декабря, 2012 · Жалоба Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Судя по выводу show processes cpu "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети. Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 декабря, 2012 · Жалоба Начните с поиска интерфейса, в который прёт много бродкаста. Начать поиски с команды show int | i (line protocol|Received) А лучше нарисуйте графики по бродкст-трафику на каждом порту Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 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 и ограничивать трафик, который жрет очень много. Дальше уже можно разбираться - а почему, главное, что сервис не убивает. Фичу где-то здесь писал, со ссылкой, но сходу не увидел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flow Опубликовано 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 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 был выше нормальных уровенй, и вы сразу увидите, на графике, что были проблемы, которые надо решать. Но при этом все остальные сервисы не падают насмерть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 23 декабря, 2012 · Жалоба Ну, с такой логикой и storm-control - бесполезная штука, потому что блокирует в том числе и полезный трафик. Только я писал про storm-control уровней ниже. Если вы вешаете storm-control(или различные его вариации) на абонентский порт на коммутаторе доступа, то "страдает" один абонент(в самом деле, скорее всего он и так не работает, если с его порта штормит). Когда же вы зарезаете поток arp-трафика применительно ко всему CP или индивидуально к линейной карте, то страдают от этого абоненты всего шасси(либо абоненты, сидящие на этой линейной карте(если CoPP-овский service-policy применён к слоту)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 23 декабря, 2012 · Жалоба Начните с поиска интерфейса, в который прёт много бродкаста. Начать поиски с команды show int | i (line protocol|Received) А лучше нарисуйте графики по бродкст-трафику на каждом порту графики будут реально полезны. +1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 23 декабря, 2012 · Жалоба Во всем этом есть один пренеприятнейший момент, CoPP не спасает от arp-флуда, те полиси настроена и применена, но проц не спасает, это плохо, но это факт встреченный в сети и возпроизведенный на тестовом стенде. единственный способ - ставить storm-control на порту абонента, а лучше, не раздумывая, вешать сразу на все абонентские порты, и не придется искать того конкретного, от кого эта гадость идет, хотя после включения контроля это не составит труда, ибо (по крайней мере каталисты) посылают system message о том что был был обнаружен шторм Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 23 декабря, 2012 · Жалоба Во всем этом есть один пренеприятнейший момент, CoPP не спасает от arp-флуда, те полиси настроена и применена, но проц не спасает, это плохо, но это факт встреченный в сети и возпроизведенный на тестовом стенде. Не проверял на платформах c6500/c7600, но на huawei на старших S-свитчах и NE/CX-платформах оно работает(там кстати разделяется arp на несколько типов - arp-miss, arp-reply, arp-request). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 23 декабря, 2012 · Жалоба не рискнул бы утверждать что это так на всех устройствах, но в моем случае это была Cisco 7600, а так как тут мы говорим о 6500, то смею предположить что результат будет таким же Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 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"... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 26 декабря, 2012 · Жалоба один лишь момент, conf t ip arp proxy disable насколько % снижает нагрузку на rp? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 27 декабря, 2012 · Жалоба один лишь момент, conf t ip arp proxy disable насколько % снижает нагрузку на rp? Разницы практически нет. У нас на всех IP интерфейсах стоит "no ip proxy-arp". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 27 декабря, 2012 · Жалоба А что говорит "sh ip arp sum"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 27 декабря, 2012 · Жалоба один лишь момент, conf t ip arp proxy disable насколько % снижает нагрузку на rp? Если arp proxy запрещен глобально или на интерфейсах - то процесс ARP Input кушает не больше 1%. Но однако arp proxy нужен. Может local-proxy-arp меньше грузит RP? Какие либо будут советы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 27 декабря, 2012 · Жалоба А что говорит "sh ip arp sum"? 2554 IP ARP entries, with 21 of them incomplete Это в 9 утра, при этом "ARP Input" кушает 13%. При максимальной нагрузке точную цифру не вспомню - но точно меньше 5000. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 27 декабря, 2012 · Жалоба Но однако arp proxy нужен. если он нужен везде - стоит пересмотреть архитектуру всей сети, или переложить L3 на более умные железки (ASR1k/9k например) если нужен не везде - повырубать на лишних интерфейсах, и свести его присутствие до минимума. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shvlad1 Опубликовано 27 декабря, 2012 · Жалоба COPP на control-plane, storm-control на интерфейсах ну и глобально mls rate-limit - что и как ставить - ищется по лучшим практикам на сайте циски Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
IVB Опубликовано 27 декабря, 2012 · Жалоба Но однако arp proxy нужен. если он нужен везде - стоит пересмотреть архитектуру всей сети, или переложить L3 на более умные железки (ASR1k/9k например) если нужен не везде - повырубать на лишних интерфейсах, и свести его присутствие до минимума. Вы, наверное, не заметили мой сегодняшний пост от 07:35. У меня на всех интерфейсах, где arp proxy не нужен, он выключен. А нужен он всего на одном vlan'е... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 28 декабря, 2012 · Жалоба Статическая таблица arp не уменьшит нагрузку? Процессор, по идее, не будет тратить время на обработку запросов и резолвинг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Savaoff Опубликовано 28 декабря, 2012 · Жалоба Может у вас периодически кольцо возникает в каком-нибудь влане? У себя на 6506х видел высокую загрузку процессом arp input только при кольцах в сети. В эти моменты на каталюгу надежно можно попасть только через консольный порт. Быстро найти, где возникло кольцо - не тривиальная задача, т.к. возникнуть оно может (из-за ошибок персонала, конечно) между двумя дотаточно примитивными свичами на окраине сети, но шторм все равно доберется по какому-либо из вланов до core-роутеров со всеми вытекающими... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 29 декабря, 2012 · Жалоба Может у вас периодически кольцо возникает в каком-нибудь влане? У себя на 6506х видел высокую загрузку процессом arp input только при кольцах в сети. В эти моменты на каталюгу надежно можно попасть только через консольный порт. Быстро найти, где возникло кольцо - не тривиальная задача, т.к. возникнуть оно может (из-за ошибок персонала, конечно) между двумя дотаточно примитивными свичами на окраине сети, но шторм все равно доберется по какому-либо из вланов до core-роутеров со всеми вытекающими... Именно в момент восстановления кольца такая ситуация и наблюдалась. Схема влан на абонента, примерно по 10-15 коммутаторов кольце, управляющий влан был общий для всех колец, STP на абонентских коммутаторах не включен. me3400g с такой схемой справлялся без проблем а вот sap720-3b чего то не нравится. Сейчас несколько колец переделал - включил STP на абонентских коммутаторах и выделил отдельные управляющие вланы для колец - вроде полегче стало. Надо видать все переделывать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Solar Опубликовано 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'е загрузка пришла в норму, циска больше не впадает в кататонический ступор. К сожалению, так и не удалось понять саму физику данного явления, т.е. все это происходит потому, что где-то что-то банально недонастроено, или мы уперлись в какие-то аппаратные/программные ограничения? Чтение цисковской документации пока ответа не дает, если есть знатоки, разбирающиеся в вопросе, огромная просьба поделиться информацией. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...