[c-nsp] CEF CPUHOG on GSR 12.0(S)
achatz at forthnet.gr
Mon Oct 15 03:08:27 EDT 2007
It could be this too:
Externally found enhancement (Sev6) bug: Assigned (A)
Short mask prefixes cause CPUHOG in CEF LC IPC Background
In an network environment which has a default route (0.0.0.0/0) present, the
advertisement of a short mask prefix (x.x.x.x/1) will result in a CPUHOG
on Engine 4 or Engine4+ linecards each time the route is advertised or
%SYS-3-CPUHOG: Task ran for 3660 msec (1/1), process = CEF LC IPC Background,
PC = 400DC1D0.
This behaviour is seen on IOS releases 12.0(21)S onwards.
Workaround: Prefix filters in BGP applied at the edge of the network can be used
to block short mask prefixes. This will not prevent the route being advertised
via an IGP.
David Freedman wrote on 14/10/2007 3:34 μμ:
> Recently we've been seeing some messages in the log with regards to
> a CPUHOG event occuring on some engine 2 linecards we have running.
> It didn't seem to be traffic affecting, and looked a little like this:
> SLOT 6:Oct 12 03:17:41 DST: %SYS-3-CPUHOG: Task ran for 7312 msec (0/0),
> process = CEF LC IPC Background, PC = 400FC324.
> Box is running 12.0(32)S5 and has not logged these messages before.
> This slot faces an upstream provider.
> Upon speaking with another provider, running 12.0(32)S6, they have
> been seeing the same messages on their kit but not at the same times, on
> E2 linecards facing an IXP, they are running S6.
> We are both running IPv6 and I have all routing messages filtered on the
> upstream port (in case this was related to any RH0 nastyness)
> #sh ipv6 access-list
> IPv6 access list bogons6
> deny ipv6 any any routing sequence 10
> One thing of note is that this could be related to bugid CSCsb12281 but
> this does not seem to effect S6, could any friendly cisco people on here
> expand a bit on this bug?
> Many thanks,
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp