when is cpu used on Multlilayer switches

carl_townshend · ‎04-14-2009

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 ?

Joseph W. Doherty · ‎04-14-2009

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.

carl_townshend · ‎04-14-2009

can you give me some examples ?

Joseph W. Doherty · ‎04-14-2009

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).

karel.stadler · ‎04-14-2009

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 ....

JamesLuther · ‎04-14-2009

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

carl_townshend · ‎04-14-2009

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 ?

gnijs · ‎04-14-2009

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.