when is cpu used on Multlilayer switches

Unanswered Question
Apr 14th, 2009
User Badges:

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 ?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joseph W. Doherty Tue, 04/14/2009 - 04:41
User Badges:
  • Super Bronze, 10000 points or more

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.

Joseph W. Doherty Tue, 04/14/2009 - 05:10
User Badges:
  • Super Bronze, 10000 points or more

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

JamesLuther Tue, 04/14/2009 - 06:56
User Badges:
  • Silver, 250 points or more

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 Tue, 04/14/2009 - 07:46
User Badges:

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 Tue, 04/14/2009 - 13:00
User Badges:
  • Bronze, 100 points or more

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.

Actions

This Discussion