‚ < ‚ Free Open Study ‚ > ‚ |
SPF Running Constantly ‚ Cause: Neighbor Flap Within the NetworkA neighbor flap also causes SPF to run. A neighbor flap can happen because of several reasons discussed already in this chapter. When a link goes down, the neighbor goes down as well. When a neighbor goes down, it causes a change in topology, so SPF runs. In Figure 9-101, R3 is suffering from a neighbor flap, and all the routers in area 0 are running SPF because of this. Figure 9-101. OSPF Neighbor Flap Causes SPF to Run Figure 9-102 shows the flowchart to follow to solve this problem. Figure 9-102. Problem-Resolution Flowchart Debugs and VerificationExample 9-267 shows that SPF is being run constantly in area 0. Example 9-267 Determining How Often SPF Is RunningR1# show ip ospf Routing Process "ospf 1" with ID 192.168.254.13 Supports only single TOS(TOS0) routes It is an area border SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs Number of external LSA 8. Checksum Sum 0x48C3E Number of DCbitless external LSA 0 Number of DoNotAge external LSA 0 Number of areas in this router is 3. 2 normal 1 stub 0 nssa Area BACKBONE(0) Number of interfaces in this area is 1 Area has no authentication SPF algorithm executed 2458 times The next thing to do here is to go to R3 and check the logs, as done in previous example. There is a way to track the neighbor changes in OSPF. Configure ospf log- adjacency -changes under router ospf to track all the neighbor changes. Example 9-268 shows how to configure ospf log-adjacency-changes. Example 9-268 Configuring ospf log-adjacency-changes on R3R3# router ospf 1 ospf log-adjacency-changes When this command is configured, it saves all the neighbor state changes in the router's sys log. Example 9-269 shows a sys log message of R3 that shows neighbor state changes. The output shows one instance, but there are a lot of instances of neighbor change. Example 9-269 Sys Log Messages of R3 Shows OSPF State ChangesR3# show log %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from FULL to DOWN, Neighbor Down %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from FULL to INIT , 1-Way %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from DOWN to INIT, Received Hello %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from INIT to 2WAY, 2-Way Received %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from 2WAY to EXSTART, AdjOK? %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from EXSTART to EXCHANGE, Negotiation Done %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from EXCHANGE to LOADING, Exchange Done %OSPF-5-ADJCHG: Process 1, Nbr 192.168.4.4 on Serial1 from LOADING to FULL , Loading Done In some older versions of Cisco IOS Software, the ospf log-adjacency-changes command is not available or might not be configured on the router. In this case, the show ip ospf neighbor command helps. Example 9-270 shows that R3 sees R4 going from FULL to INIT and then back to FULL through the show ip ospf neighbor command. This process keeps repeating. Example 9-270 Determining Neighbor StateR3# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.4.4 1 FULL/- 00:00:34 131.108.1.1 Serial1.1 _____________________________________________________________________________________ R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.4.4 1 INIT/- 00:00:33 131.108.1.1 Serial1.1 _____________________________________________________________________________________ R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.4.4 1 FULL /- 00:00:37 131.108.1.1 Serial1.1 SolutionThis problem is common in Frame Relay hub-and-spoke environments. If there are too many neighbors in Frame Relay, there is a high chance that their Hellos might start dropping. The solution in this case is to tune the broadcast queue so that it doesn't drop the OSPF Hello packets. The neighbor goes into INIT after FULL because the neighbor missed three Hellos and declared R2 dead. This can be confirmed by looking at the show interface statistics that indicate that the serial interface broadcast queue is dropping many packets. Example 9-271 shows the output of show interface for the Serial 1 interface, which shows a significant number of drops in the Frame Relay broadcast queue. Example 9-271 Displaying Broadcast Queue StatusR3# show interface Serial1 Serial1 is up, line protocol is up Hardware is MK5025 Description: Charlotte Frame Relay Port DLCI 100 MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Broadcast queue 64/64, broadcasts sent/dropped 1769202/1849660, interface broadcasts 3579215 The output in Example 9-271 further proves that there is some problem at the interface level. Too many drops are occurring at the interface level. This is causing the route to flap. To correct this problem, you must tune the Frame Relay broadcast queue accordingly . Tuning the Frame Relay broadcast queue is beyond the scope of this book, but several papers on Cisco's web site discuss how to tune the Frame Relay broadcast queue. For further research, you can consult them at the following URLs:
Example 9-272 shows that after fixing the interface drop problem, route flapping disappears. The broadcast queue size is changed from 64 to 256. The correct number can be determined after reading the URLs mentioned earlier for tuning the broadcast queue. Example 9-272 Verifying That the Broadcast Queue Has Been FixedR3# show interface Serial1 Serial1 is up, line protocol is up Hardware is MK5025 Description: Charlotte Frame Relay Port DLCI 100 MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, rely 255/255, load 44/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Broadcast queue 0/256, broadcasts sent/dropped 1769202/0 , interface broadcasts 3579215 |
‚ < ‚ Free Open Study ‚ > ‚ |