[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