Hi!
At one of the nodes used catalyst 6500 with sup32 running software12.2(33)SXH5 , there are problems with high load CPU due to interrapts:
-
CPU utilization for five seconds: 56%/45%; one minute: 57%; five minutes: 55%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
8 67138180 7538435 8906 7.19% 5.74% 5.70% 0 ARP Input
100 17392892 145853 119253 1.35% 1.90% 1.95% 0 HC Counter Timer
89 23849784 388043 61462 0.87% 1.06% 1.11% 0 Compute load avg
196 7210696 749626 9619 0.55% 0.87% 0.85% 0 CEF: IPv4 proces
138 3505932 17454349 200 0.31% 0.44% 0.38% 0 ADJ resolve proc
136 7986672 29865853 267 0.23% 0.35% 0.34% 0 IP Input
181 2713632 106885 25388 0.07% 0.13% 0.11% 0 IPC LC Message H
--
I installed the SPAN session on RP and found an ordinary network traffic clients (http, etc.), that must be harhware CEF switched.
It is obvious that the traffic enters the process switching:
--
--
Interface information:
Interface IBC0/0(idb 0x454A98F0)
Hardware is Mistral IBC (revision 5)
0 minute rx rate 231062000 bits/sec, 40653 packets/sec
0 minute tx rate 230981000 bits/sec, 40542 packets/sec
768441545 packets input, 763672035960 bytes
0 broadcasts received
763863117 packets output, 763298719016 bytes
2 broadcasts sent
0 Inband input packet drops
0 Bridge Packet loopback drops
0 Rx packets dropped with Multicast MAC and Unicast IP
767110946 Packets CEF Switched, 1279 Packets Fast Switched
0 Packets SLB Switched, 0 Packets CWAN Switched
Potential/Actual paks copied to process level 1309036/1308996 (40 dropped, 40 spd drops)
514919227 inband interrupts
71265 transmit ring cleanups
514994756 ibl inputs
71265 total tx interrupts set
71265 tx ints due to packets outstanding
0 tx ints due low free buffers in pool
0 tx ints due to application setting
tx dma done batch size=32
buffers free minimum before tx int=4
mistral ran out of tx descriptors 0 times
mistral tx interrupt inconsisteny occured 0 times
Label switched pkts dropped: 0
Xconnect pkts processed: 0, dropped: 0
IBC resets = 2; last at 14:15:03.733 msd Tue Mar 29 2011
--
I took the document https: / / supportforums.cisco.com/docs/DOC-14086, but he could not understand on what basis the traffic enters the process switching.
Some logs:
--
sup32-TEST###sh cef not-cef-switched
% Command accepted but obsolete, see 'show (ip|ipv6) cef switching statistics [feature]'
IPv4 CEF Packets passed on to next switching layer
Slot No_adj No_encap Unsupp'ted Redirect Receive Options Access Frag
RP 0 0 293175 0 99949 0 288300 0
5/0 0 0 0 0 0 0 0 0
--
or:
--
sup32-TEST###sh ip cef switching statistics
Reason Drop Punt Punt2Host
RP LES Packet destined for us 0 100098 0
RP LES No adjacency 7609 0 0
RP LES Incomplete adjacency 979470 0 313
RP LES TTL expired 0 0 4511
RP LES Discard 7811 0 0
RP LES Features 3127605 0 288855
RP LES Unclassified reason 833 0 0
RP LES Neighbor resolution req 507057 58 0
RP LES Total 4630385 100156 293679
All Total 4630385 100156 293679
--
The organization of this site is simple enough:
uplink (Vlan24, 2GB EtherChannel) and about 3500 SVI with IP Unnimbered feature and static routes with 32 bit mask for customers, for example:
!
interface Vlan101
ip unnumbered Loopback0
ip access-group 110 in
end
ip route 192.168.100.101 255.255.255.255 Vlan 101
!
interface Loopback0
ip address 192.168.100.1 255.255.255.0
ip address 192.168.101.1 255.255.255.0
!
etc...
Default route is obtained by the EIGRP
The essence of my question: How can I determine the reason the traffic hits the CPU?
I would be grateful for any ideas, ready to provide any diagnostic data.
Thanks for your help.
--
Regards,
Dmitry
