[c-nsp] portchannel & dcef?

[Rodney Dunn]

> I found the problem.  During a DoS, someone turned on 'ip accounting
> output-packets' on an OC3 transit interface.  That apparently causes
> traffic received on the port channel and destined for the OC3 to be
> process switched by the RSP.

It shouldn't be process switched but rather CEF switched on the RSP.
That's why the route-cache line increments there.  We don't support
ip accounting in the dCEF path (use netflow) so that's why the
traffic was getting punted to the RSP for switching.

> 
> I noticed that change (via rancid) coincided with a large increase in RSP
> CPU utilization on our snmp graphs.  After turning off the accounting and
> seeing RSP CPU usage go way down.

It's always about the trigger. :)

> 
> As you suggested, I checked ip cache flow on the RSP both before and after
> re-enabling ip accounting, and without it, the RSP only sees a tiny
> fraction of traffic that gets process switched.  With ip accounting on,
> the RSP sees it all (or at least quite a bit more).

You should see very little.  You will see some because there are valid
punt reasons (ie: packets to/from the RSP, packets with options set, etc.)

> 
> I kind of wonder now if the ip accounting (causing roughly 50mbit/s of
> traffic to be process switched by the RSP4) could be the cause of some of
> the problems we've been having and could cause an upgrade done via
> force-switchover to appear to hang the box and a subsequent cold reboot to
> take 20 minutes or so for the router to fully boot up and start routing /
> being responsive at the CLI?

Well, most likely not based on my experience.  You would have to be
getting traffic to the box in the first place and usually the routing
doesn't converge that quickly.  I once thought we could do a faster
software ugprade with SSO and FSU but that wasn't true.  If the RSP's
are not on the same version of code it falls back to RPR mode during
the upgrade so it's not that much faster.  The time to boot depends
on how many cards you have, features enabled, # of routes, etc.
And yeah the traffic hitting the box as soon as it comes up could
come in to play also.  One of the things that makes it slow to boot
is that the ucode is loaded for the boot image and also again for
the RSP load.  With the new RSP (RSP16 I think) we don't do that
anymore so the boot time is faster.


> 
> > As for a code suggestion with the features you mentioned
> > that gets a bit more difficult.  Are you interested
> > in MPLS HA?
> 
> That'd be nice, but we're not dependant on it yet.
> 
> > Are you putting the PC subinterfaces in a VRF or
> > are you doing MPLS over the PC?
> 
> We have some PC subinterfaces in VRFs.
> 
> Oh...and I forgot to list HSRP in the "things we need to work".

I'm not sure if port-channels are supported in SSO mode but
regardless the scenario you have should work in 12.2S.

If it were me and you had a lab to verify the basic setup
I would probably look at 12.0(27)S or so based on my work
in similar setups lately.  It's the port-channel setup
that I haven't worked with.

Rodney


> ----------------------------------------------------------------------
>  Jon Lewis                   |  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________