HIGH CPU due OSPF process

[cristschcisco]

Hello,

Could an OSPF process missing the passive-interface default configuration cause high CPU utilization?

% Ambiguous command:  "sh pro cpu "
MZ-CE-SR-1A#sh pro cpu | i OSPFC cpu | i OSPF
 378      252604  15214152         16  0.00%  0.00%  0.00%   0 OSPF-244 Router  
 450  1646220948  40780674      40368 45.43% 20.98% 19.82%   0 OSPF-50 Router 

[Richard Burts]

You do not provide much information to work with so we must trust to generalities in attempting to answer your question. It certainly is possible that the OSPF routing process could contribute to high CPU utilization, especially if it were processing SPF calculations frequently. So it might be helpful to look at output of show ip ospf several times over a period of time and see how frequently it is doing SPF calculations.

If there are a lot of SPF calculations then the question becomes whether there are some interfaces that are active in OSPF, that would not have been included in OSPF if the passive-interface default were applied, and if those interfaces are generating lots of events that cause SPF calculation.

HTH

Rick

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I've seen additional/needless redundancy add to OSPF processing load, and even cause network instability if there's a flapping network, which judicious passive-interface precluded, but on the whole, I doubt not using passive-interface, alone, is the cause of your high OSPF CPU.

Look for some kind of link instability.

[cristschcisco]

Hello Joseph, thanks for your help.

I don't see network instability until now, the OSPF 50 neighbors are up an full for a long time without flaps. We configured the passive-interface default, but the 6500 still reaching cpu spikes of 60% during the day and night.

I'm trying to find if there are many SPF calculation.

[Joseph W. Doherty]

What does show ip ospf statistics reveal?

[Richard Burts]

It is good that OSPF 50 neighbors are up and full for a long time. But that does not mean that there have not been events that cause SPF calculation. It might be helpful if you post the output of show ip ospf and of show ip ospf statistics.

HTH

Rick

[cristschcisco]

I got the show ip ospf statistics.

[Richard Burts]

Thanks for providing the OSPF statistics. I am not clear about the significance of the ip routing selected the way it was. The OSPF statistics show 1103 SPF runs. So do that display, wait a while, and do it again. Then tell us how quickly that number is incrementing.

It is interesting and perhaps helpful to note that it looks like what is triggering SPF are changes in external routes. This confirms your observation that neighbors have been stable and not flapping or bouncing. What is changing are routes that are being redistributed into OSPF.

HTH

Rick

[cristschcisco]

Thanks Richard and Joseph, I checked the show ip ospf statistics again today, but no changes to the SPF algorithm executed field, it contínuos with the same value of 2 days ago. I checked the OSPF configuration and found a BGP redistribution into OSPF without filters. Also checked that we have many BGP routes flapping, maybe this is causing the high CPU in the OSPF process. router ospf 50 redistribute bgp 65000 metric-type 1 subnets

[Richard Burts]

Thanks for the additional information. It is interesting that the number for SPF calculations has not changed. So it is not the SPF calculation which is driving CPU utilization. If there are many BGP routes that are flapping (which is not unusual if this is actual Internet BGP routes) and are being redistributed into OSPF then it is quite possible that it is the processing of updating the OSPF database for these routes and updating the IP routing table with these routes that is driving up CPU utilization.

HTH

Rick