04-14-2009 02:05 AM - edited 03-06-2019 05:09 AM
Hi all, Can anyone tell me what kind of things require cpu usage on a multilayer switch, ie switching only needs the ASIC, How come a loop will cause the CPU to be heavy utilized ?
04-14-2009 04:41 AM
Two common usages of L3 switches primary CPU are "control plane" processing and "data plane" that the ASICs can't process. High load against either can often quickly tax the CPU.
04-14-2009 04:52 AM
can you give me some examples ?
04-14-2009 05:10 AM
Enable RIP on a 3560/3750, set the timers down to minimum values, watch the CPU rise as the platform processes the routing updates ("control plane" processing).
04-14-2009 05:21 AM
Depending how your router is configured every control plane thingy can utilize the CPU.
F.E. type "show proc cpu" may your STP-Prozess takes up a bit of CPU cycles for generating BPDU's ....
04-14-2009 06:56 AM
Hi Carl,
To answer "How come a loop will cause the CPU to be heavy utilized"
If it's a broadcast storm then braodcast traffic is process switched.
Also if the routing protocol is constantly recalculting then traffic will be process switched as each recalculation deletes the CEF entry. Plus the recalulation will cause CPU.
Add to this the fact that if there is a loop then there is an ever growing increase in traffic (as it's looping).
Regards
04-14-2009 07:46 AM
I was told that on a multilayer switch, you would see the cpu go up due to broadcast storm?
How would I check on the switch for a broadcast storm ?
04-14-2009 01:00 PM
James,
Very good point. This could be catastrophic. I assume Cisco has also assigned the OSPF process "high priority", thus enabling it to take all available cpu when needed. Is there any way in limiting the effort a switch takes in bringing back ospf when it is failing ? for example, exponential backoff in re-trying to establish ospf neighbors: ie. retry in 1 second, fail ? retry in 2 seconds, fail ? retry in 4 seconds, fail ? retry in 8 seconds ? etc..
this is much better than to constantly trying to get ospf up and running, using 100% cpu, generating maybe other problems. For example, one failing ospf neighbor can delete cef entries, increasing cpu (software punted). Plus the ospf recalculation will cause more cpu load. This can lead to other failing ospf neighbors resulting in even more ospf updates and recalculation. This could lead to a positive feedback loop, that brings down the network.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide