[c-nsp] OSPF processes

Sergio D. sdanelli at gmail.com
Thu Feb 15 17:36:06 EST 2007


Justin,
Thanks for your response. NPE-400 and yes a VXR chassis.

I second your point on how tricky it can be to determine if its ospf thats
causing it or if ospf going down is merely a symptom of something else. I
tend to think is the latter actually since CPU is at 50% during regular
business hours and it seems to be interrupt driven since there is no
processes that are high. I just don't think this routers can handle it.
besides buying a new router, can we just upgrade the NPE?

Thanks again,

- Sergio


On Thu, 15 Feb 2007, Sergio D. wrote:

> I was wondering if its a possibility that we have too many ospf processes
> running. In this one we have about 10 vrfs, I know on one of those vrfs we
> have a large amount of LSAs. Is there a limit on the ospf process amount
or
> size of the database on each process? any response will be helpful.

The trick is finding out whether some other type of instability is causing
the OSPF instability and driving up your CPU usage, or if your CPU usage
is already high enough to cause your router to miss OSPF hellos...

I don't think there is a specific limit to the number of OSPF processes or
LSAs that each process' link-state database can hold, outside of any CPU
and memory constraints you might have.  Also, what kind of NPE do you have
in that 7200?  It's a 7200 VXR chassis, correct?

You can do a few things:
1. Check the logs for interesting messages that might point to the cause
of the CPU utilization spike
2. Make sure CEF is enabled globally and per interface.  The default on
many interfaces is to enable CEF, but it's worth checking anyway.
3. Look at your running processes to determine what might be consuming
your CPU resources.
4. Turn on OSPF event debugging (debug ip ospf events), turn your logging
level up to debugging (logging trap debugging) if it's not there already
and see what shows up in the logs.  I would be cautions about doing this
from the console if console logging is enabled, or from a vty if you're
using "term mon", as the log noise can be tough to read and can make the
high CPU problem worse.

jms
-- 
Sergio Danellli
JNCIE #170


More information about the cisco-nsp mailing list