[nsp] High "IP Input"/process switching on 5800

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Fri Jan 10 09:23:37 EST 2003


Hi Steven,


> Have 5800s suffering from high CPU utilization (up to say 60% at peak
> times).  Seems to be causing packet loss across the directly-connected
> ethernet (no errors on interfaces) except for accumulating "flushes":

"Flushes" are a result of Selected Packet Discard (SPD) which is kicking
in as soon as the IP input queue (i.e. process-switched packets, under
normal circumstances pkts to the router itself) is filling up to avoid
dropping "important" packet like routing protocol hellos/updates, etc.

[...]

> 
> Do have global CEF configured, but the group async interface 
> seems to be unable to participate:
>[...]
> 
> Should Cisco 5800-series have the capability to CEF switch across the
> entire box?  Am finding that although global CEF can be applied to the
> fast e interface, but not group async (it takes the command, 
> but doesn't seem to stick).

Correct, we can't CEF-switch from async interfaces on this platform,
ingress pkts are fast-switched when they arrive on the async. But we are
able to switch pkts *to* async/vaccess interfaces (if CEF is enabled on
the ingress FastEthernet interface). Since exactly those packets are our
concern here, there must be something configured on the egress
async/vaccess interface that causes the packet to be punted to the
process path.

Do you happen to have any sort of compression (tcp header or stac/mppc)
configured on the async or vtemplate? This will cause process-switching,
regardless of whether compression has actually been negotiated with the
peer.
BTW: CSCdu26701 "fixes" this and only causes process switching when
compression is actually being used.

If this is not the case I would suggest to open a TAC case so we can
take a look at possible bugs. Which IOS are you using?

	oli



More information about the cisco-nsp mailing list