[c-nsp] OSPF processes

[Joseph Jackson]

You can,  The NPE G1 and G2 are out. I've only ever used the G1 so far
and haven't had any problems.
I just don't think you should having these problems on a npe-400.   

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Sergio D.
> Sent: Thursday, February 15, 2007 2:36 PM
> To: streiner at cluebyfour.org
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OSPF processes
> 
> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>