 100% загрузка routing processor,  Solar, 22-Дек-12, 20:15 [смотреть все]Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Судя по выводу show processes cpu, "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети. Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы?
|
- 100% загрузка routing processor, Andrey, 16:53 , 23-Дек-12 (1)
> Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509
> (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при
> этом switching processor загружен едва ли на 5%. Судя по выводу
> show processes cpu, "давит" процессор ARP Input. В шасси приблизительно 200
> активных портов, выяснить с какого именно из них идет ARP флуд
> пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать
> это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера,
> что весьма болезненно т.к. он стоит на агрегации довольно большой сети.
> Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли
> причину, нашли ли какие-либо эффективные способы решения проблемы?http://xgu.ru/wiki/Dynamic_ARP_Protection не поможет?
- 100% загрузка routing processor, Solar, 11:46 , 25-Дек-12 (2)
- 100% загрузка routing processor, Solar, 14:55 , 31-Дек-12 (4)
Симптомы удалось снять. Загрузка процессора вернулась с норму. Существовала вот такая конструкция:
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'е загрузка пришла в норму, циска больше не впадает в кататонический ступор.
К сожалению, так и не удалось понять саму физику данного явления, т.е. все это происходит потому, что где-то что-то банально недонастроено, или мы уперлись в какие-то аппаратные/программные ограничения? Чтение цисковской документации пока ответа не дает, если есть знатоки, разбирающиеся в вопросе, огромная просьба поделиться информацией.
- 100% загрузка routing processor, eek, 07:16 , 26-Дек-12 (3)
DAI поможет только если у вас абоненты напрямую воткнуты в шеститонник, в остальных случаях надо будет что-то думать на доступе. Иначе он будет рубить вам порт за которым может находиться более одного абонента.
|
Версия для распечатки
