[Solar]

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

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

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

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

[s.lobanov]

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

show int | i (line protocol|Received)

 

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

[SergeiK]

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

[flow]

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

[SergeiK]

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

[s.lobanov]

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

[SergeiK]

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

[s.lobanov]

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

 

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

[dmvy]

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

show int | i (line protocol|Received)

 

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

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

+1

[zi_rus]

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

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

[s.lobanov]

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

 

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

[zi_rus]

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

[IVB]

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

[darkagent]

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

conf t

ip arp proxy disable

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

[IVB]

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

conf t

ip arp proxy disable

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

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

 

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

[s.lobanov]

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

[NikAlexAn]

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

conf t

ip arp proxy disable

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

 

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

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

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

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

[IVB]

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

2554 IP ARP entries, with 21 of them incomplete

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

 

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

[darkagent]

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

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

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

[shvlad1]

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

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

[IVB]

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

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

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

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

 

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

[andryas]

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

[Savaoff]

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

[NikAlexAn]

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

 

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

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

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

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

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

[Solar]

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

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

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