Перейти к содержимому
Калькуляторы

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 флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это).

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

show int | i (line protocol|Received)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

show int | i (line protocol|Received)

 

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

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

+1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

conf t

ip arp proxy disable

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

conf t

ip arp proxy disable

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

conf t

ip arp proxy disable

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

2554 IP ARP entries, with 21 of them incomplete

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.