Симптомы удалось снять. Загрузка процессора вернулась с норму. Существовала вот такая конструкция:
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'е загрузка пришла в норму, циска больше не впадает в кататонический ступор.
К сожалению, так и не удалось понять саму физику данного явления, т.е. все это происходит потому, что где-то что-то банально недонастроено, или мы уперлись в какие-то аппаратные/программные ограничения? Чтение цисковской документации пока ответа не дает, если есть знатоки, разбирающиеся в вопросе, огромная просьба поделиться информацией.
|
