[c-nsp] GSR CPU Process is very HIGH 95%

[Eninja]

Sent from my iPhone - apologies for typos.

On Oct 8, 2009, at 4:31 AM, e ninja <eninja at gmail.com> wrote:

>
>
> On Wed, Oct 7, 2009 at 2:01 PM, Lasher, Donn <DLasher at newedgenetworks.com 
> > wrote:
> -----Original Message-----
> From: Pete Templin [mailto:petelists at templin.org]
> Subject: Re: [c-nsp] GSR CPU Process is very HIGH 95%
>
> Lasher, Donn wrote:
>
> >> To clarify, this depends on both the card type (engine 0/1/2/3/4/5)
> and
> >> traffic type (mpls, DSCP marking, etc).  You can be doing  
> everything
> >> right, and still have 50% CPU with the wrong combination of those
> two..
> >> (For example, MPLS Labeling and Engine0 GIG-E card at 100M of
> traffic)
>
> >Right, but that'd be 50% CPU on the linecard, not on the xRP, right?
> >
> >(In other words, you'd find 50% CPU by doing 'execute-on all sh  
> proc c
> s
> >| e 0.0.%' but wouldn't find it by doing 'sh proc c s | e 0.0.%'.)
>
> No, in the example I gave, 100M of CE-PE MPLS traffic (IE the router  
> is
> labeling/unlabeling) on an Engine0 1-port GIG-E line card will run the
> Processor CPU up nice and high.
>
> That is because an Eng 0 LC switches traffic in software i.e. the LC  
> CPU does each and every lookup off the LC FIB table ( a rather CPU  
> intensive activity - at....you guessed it, LC CPU "interrupt level")  
> - which was downloaded as normal from the RP FIB table.
>
> (GSR Architecture in four bullet points)
>
> The GSR (and most distributed platforms are designed as follows...
> RP takes care of coalescing routes, creating FIB tables and all  
> other housekeeping activities.
> RP pushes FIB table down to all LCs and IOS 'inconsistency checker'  
> runs every so often to ensure the 'consistency' of RP and LC copies  
> of FIB tables et al.
> If LC has hardware switching capabilities (i.e. > Eng 1)...yipppe.  
> It switches packets in HW (ASIC) or else...
> It switches in software i.e. LC CPU 'manually' does the CEF table  
> lookup for each and every packet header - very CPU intensive.  
> However, if, for some strange reason, a route doesn't exists on LC  
> CEF table, the LC will punt to RP CPU. And RP will the final say on  
> what happens to the packet.
PS. Needless to say that nearly all packets that get punted to the RP  
will be 'management' traffic and packets destined to the device itself  
- which should be little since these are core routers and therefore  
have minimal impact on RP CPUs.

Bottomline, the whole idea of distributed switching is to take the  
'load' off the RP and 'outsource' packet switching to the ingress LCs.  
Therefore, RP CPU on a distributed architecture platform that is  
configured well _should_ never be under a consistently heavy CPU load  
above device baseline figures.

Eninja