OSPFCCNA 200-301

OSPF Causing High CPU Due to Constant SPF Recalculations

Presenting Symptom

Router CPU utilization is consistently high (above 80%) and OSPF SPF runs are occurring multiple times per second, causing network instability and slow convergence.

Network Context

An enterprise campus network with a collapsed core design, using Cisco Catalyst 3850 switches running IOS XE 16.9. OSPF is deployed as the IGP with all devices in area 0. The network has approximately 50 routers and 200 OSPF routes. The issue started after a new distribution switch was added with multiple /30 point-to-point links.

Diagnostic Steps

1

Check CPU utilization and identify high CPU processes

show processes cpu sorted | include OSPF
PID   Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
123   4567890        12345       370      15.20% 12.50% 10.80%   0 OSPF Router

If OSPF process shows high CPU (e.g., >10% in 5Sec), it indicates OSPF is consuming significant CPU. Normal OSPF CPU usage should be under 5% in stable networks.

2

Check OSPF SPF statistics to see frequency of SPF calculations

show ip ospf statistics
Area 0: SPF algorithm executed 500 times in the last 60 seconds
 SPF calculation frequency: 8.33 times/sec
 SPF last executed 0.120 sec ago

High SPF frequency (e.g., >1 per second) indicates constant topology changes. Normal is less than once per minute in a stable network.

3

Identify OSPF neighbors and check for flapping

show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2          1   FULL/DR        00:00:32     192.168.1.2     GigabitEthernet0/1
10.0.0.3          1   FULL/DR        00:00:33     192.168.2.2     GigabitEthernet0/2
10.0.0.4          1   FULL/DR        00:00:31     192.168.3.2     GigabitEthernet0/3

Look for neighbors in INIT or EXSTART/EXCHANGE state, or neighbors that appear/disappear. If all neighbors are FULL, the issue may be internal (e.g., route flapping).

4

Check for route flapping using debug (caution: use in maintenance window)

debug ip routing
RT: add 10.1.1.0/24 via 192.168.1.2, ospf metric [110/2]
RT: delete 10.1.1.0/24 via 192.168.1.2, ospf metric [110/2]
RT: add 10.1.1.0/24 via 192.168.1.2, ospf metric [110/2]

Repeated add/delete of the same route indicates route flapping. Note the specific prefix that is flapping.

5

Identify the flapping interface or neighbor causing the route changes

show log | include OSPF|LINK|LINEPROTO
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/4, changed state to down
%OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.5 on GigabitEthernet0/4 from FULL to DOWN, Neighbor Down: Dead timer expired
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/4, changed state to up
%OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.5 on GigabitEthernet0/4 from LOADING to FULL, loading done

Repeated interface up/down messages indicate a flapping link. This triggers OSPF adjacency changes and subsequent SPF recalculations.

Root Cause

A faulty fiber optic cable on GigabitEthernet0/4 connecting to a new distribution switch is causing the interface to flap (go up/down repeatedly). Each interface state change triggers OSPF neighbor state changes, which in turn cause SPF recalculations. The constant SPF runs consume high CPU and destabilize the network.

Resolution

Replace the faulty fiber cable. If immediate fix needed, shut down the flapping interface: interface GigabitEthernet0/4 shutdown Then replace the cable and re-enable: interface GigabitEthernet0/4 no shutdown If the issue is due to a misconfiguration (e.g., mismatched MTU), correct the configuration: interface GigabitEthernet0/4 mtu 1500 ip ospf mtu-ignore

Verification

After fix, verify: 1. show processes cpu sorted | include OSPF Expected: OSPF CPU usage below 5% in 5Sec. 2. show ip ospf statistics Expected: SPF algorithm executed 0 times in last 60 seconds (or very low). 3. show ip ospf neighbor Expected: All neighbors in FULL state, no flapping. 4. show interfaces GigabitEthernet0/4 Expected: Interface up/up, no input errors or CRC errors.

Prevention

1. Use interface error counters and SNMP monitoring to detect flapping interfaces early. 2. Implement OSPF SPF throttling to limit the impact of frequent SPF runs: router ospf 1 timers throttle spf 10 100 5000 3. Use physical layer redundancy (e.g., EtherChannel) to minimize impact of single link failures.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario appears in troubleshooting questions where you must identify the cause of high CPU due to OSPF. The exam tests your ability to interpret show commands like 'show processes cpu', 'show ip ospf statistics', and 'show ip ospf neighbor' to isolate the problem. Key fact: OSPF SPF recalculations are triggered by topology changes; frequent SPF runs indicate instability.

Exam Tips

1.

Memorize the 'show processes cpu sorted' command to quickly identify CPU-hungry processes.

2.

Know that 'show ip ospf statistics' displays SPF execution count and frequency; high frequency indicates a problem.

3.

Understand that interface flapping is a common cause of OSPF instability; check logs for 'LINEPROTO-5-UPDOWN' messages.

Commands Used in This Scenario

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions