> http://xgu.ru/wiki/Dynamic_ARP_Protection не поможет?

Спасибо, как детально разберусь что к чему, буду пробовать, на живых людях экспериментировать не комильфо...

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

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