Jump to content
Калькуляторы

100% загрузка routing processor'a на коммутаторе Cisco 6509

Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%.

Судя по выводу show processes cpu "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это).

Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети.

Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы?

Share this post


Link to post
Share on other sites

Начните с поиска интерфейса, в который прёт много бродкаста. Начать поиски с команды

show int | i (line protocol|Received)

 

А лучше нарисуйте графики по бродкст-трафику на каждом порту

Share this post


Link to post
Share on other sites

Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе 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 и ограничивать трафик, который жрет очень много. Дальше уже можно разбираться - а почему, главное, что сервис не убивает. Фичу где-то здесь писал, со ссылкой, но сходу не увидел.

Share this post


Link to post
Share on other sites

Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе 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

Share this post


Link to post
Share on other sites

Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе 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

Share this post


Link to post
Share on other sites

Не-е, применять 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.

Share this post


Link to post
Share on other sites

Не-е, применять 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 был выше нормальных уровенй, и вы сразу увидите, на графике, что были проблемы, которые надо решать. Но при этом все остальные сервисы не падают насмерть.

Share this post


Link to post
Share on other sites

Ну, с такой логикой и storm-control - бесполезная штука, потому что блокирует в том числе и полезный трафик.

 

Только я писал про storm-control уровней ниже. Если вы вешаете storm-control(или различные его вариации) на абонентский порт на коммутаторе доступа, то "страдает" один абонент(в самом деле, скорее всего он и так не работает, если с его порта штормит). Когда же вы зарезаете поток arp-трафика применительно ко всему CP или индивидуально к линейной карте, то страдают от этого абоненты всего шасси(либо абоненты, сидящие на этой линейной карте(если CoPP-овский service-policy применён к слоту))

Share this post


Link to post
Share on other sites

Начните с поиска интерфейса, в который прёт много бродкаста. Начать поиски с команды

show int | i (line protocol|Received)

 

А лучше нарисуйте графики по бродкст-трафику на каждом порту

графики будут реально полезны.

+1

Share this post


Link to post
Share on other sites

Во всем этом есть один пренеприятнейший момент, CoPP не спасает от arp-флуда, те полиси настроена и применена, но проц не спасает, это плохо, но это факт встреченный в сети и возпроизведенный на тестовом стенде.

единственный способ - ставить storm-control на порту абонента, а лучше, не раздумывая, вешать сразу на все абонентские порты, и не придется искать того конкретного, от кого эта гадость идет, хотя после включения контроля это не составит труда, ибо (по крайней мере каталисты) посылают system message о том что был был обнаружен шторм

Share this post


Link to post
Share on other sites

Во всем этом есть один пренеприятнейший момент, CoPP не спасает от arp-флуда, те полиси настроена и применена, но проц не спасает, это плохо, но это факт встреченный в сети и возпроизведенный на тестовом стенде.

 

Не проверял на платформах c6500/c7600, но на huawei на старших S-свитчах и NE/CX-платформах оно работает(там кстати разделяется arp на несколько типов - arp-miss, arp-reply, arp-request).

Share this post


Link to post
Share on other sites

не рискнул бы утверждать что это так на всех устройствах, но в моем случае это была Cisco 7600, а так как тут мы говорим о 6500, то смею предположить что результат будет таким же

Share this post


Link to post
Share on other sites
Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе 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"...

Share this post


Link to post
Share on other sites

один лишь момент,

conf t

ip arp proxy disable

насколько % снижает нагрузку на rp?

Share this post


Link to post
Share on other sites

один лишь момент,

conf t

ip arp proxy disable

насколько % снижает нагрузку на rp?

Разницы практически нет.

 

У нас на всех IP интерфейсах стоит "no ip proxy-arp".

Share this post


Link to post
Share on other sites

один лишь момент,

conf t

ip arp proxy disable

насколько % снижает нагрузку на rp?

 

Если arp proxy запрещен глобально или на интерфейсах - то процесс ARP Input кушает не больше 1%.

Но однако arp proxy нужен.

Может local-proxy-arp меньше грузит RP?

Какие либо будут советы?

Share this post


Link to post
Share on other sites

А что говорит "sh ip arp sum"?

2554 IP ARP entries, with 21 of them incomplete

Это в 9 утра, при этом "ARP Input" кушает 13%.

 

При максимальной нагрузке точную цифру не вспомню - но точно меньше 5000.

Share this post


Link to post
Share on other sites

Но однако arp proxy нужен.

если он нужен везде - стоит пересмотреть архитектуру всей сети, или переложить L3 на более умные железки (ASR1k/9k например)

если нужен не везде - повырубать на лишних интерфейсах, и свести его присутствие до минимума.

Share this post


Link to post
Share on other sites

COPP на control-plane, storm-control на интерфейсах

ну и глобально mls rate-limit - что и как ставить - ищется по лучшим практикам на сайте циски

Share this post


Link to post
Share on other sites

Но однако arp proxy нужен.

если он нужен везде - стоит пересмотреть архитектуру всей сети, или переложить L3 на более умные железки (ASR1k/9k например)

если нужен не везде - повырубать на лишних интерфейсах, и свести его присутствие до минимума.

Вы, наверное, не заметили мой сегодняшний пост от 07:35.

 

У меня на всех интерфейсах, где arp proxy не нужен, он выключен. А нужен он всего на одном vlan'е...

Share this post


Link to post
Share on other sites

Статическая таблица arp не уменьшит нагрузку? Процессор, по идее, не будет тратить время на обработку запросов и резолвинг.

Share this post


Link to post
Share on other sites

Может у вас периодически кольцо возникает в каком-нибудь влане? У себя на 6506х видел высокую загрузку процессом arp input только при кольцах в сети. В эти моменты на каталюгу надежно можно попасть только через консольный порт. Быстро найти, где возникло кольцо - не тривиальная задача, т.к. возникнуть оно может (из-за ошибок персонала, конечно) между двумя дотаточно примитивными свичами на окраине сети, но шторм все равно доберется по какому-либо из вланов до core-роутеров со всеми вытекающими...

Share this post


Link to post
Share on other sites

Может у вас периодически кольцо возникает в каком-нибудь влане? У себя на 6506х видел высокую загрузку процессом arp input только при кольцах в сети. В эти моменты на каталюгу надежно можно попасть только через консольный порт. Быстро найти, где возникло кольцо - не тривиальная задача, т.к. возникнуть оно может (из-за ошибок персонала, конечно) между двумя дотаточно примитивными свичами на окраине сети, но шторм все равно доберется по какому-либо из вланов до core-роутеров со всеми вытекающими...

 

Именно в момент восстановления кольца такая ситуация и наблюдалась.

Схема влан на абонента, примерно по 10-15 коммутаторов кольце, управляющий влан был общий для всех колец, STP на абонентских коммутаторах не включен.

me3400g с такой схемой справлялся без проблем а вот sap720-3b чего то не нравится.

Сейчас несколько колец переделал - включил STP на абонентских коммутаторах и выделил отдельные управляющие вланы для колец - вроде полегче стало.

Надо видать все переделывать.

Share this post


Link to post
Share on other sites

Симптомы удалось снять. Загрузка процессора вернулась с норму. Существовала вот такая конструкция:

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'е загрузка пришла в норму, циска больше не впадает в кататонический ступор.

К сожалению, так и не удалось понять саму физику данного явления, т.е. все это происходит потому, что где-то что-то банально недонастроено, или мы уперлись в какие-то аппаратные/программные ограничения? Чтение цисковской документации пока ответа не дает, если есть знатоки, разбирающиеся в вопросе, огромная просьба поделиться информацией.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this