SPF Running Constantly-Cause: Neighbor Flap Within the Network

‚  < ‚  Free Open Study ‚  > ‚  

SPF Running Constantly ‚ Cause: Neighbor Flap Within the Network

A 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

graphics/09fig101.gif

Figure 9-102 shows the flowchart to follow to solve this problem.

Figure 9-102. Problem-Resolution Flowchart

graphics/09fig102.gif

Debugs and Verification

Example 9-267 shows that SPF is being run constantly in area 0.

Example 9-267 Determining How Often SPF Is Running
 R1#  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 R3
 R3#  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 Changes
 R3#  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 State
 R3#  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 

Solution

This 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 Status
 R3#  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:

www.cisco.com/warp/partner/synchronicd/cc/techno/media/wan/frame/prodlit/256_pb.htm

www.cisco.com/warp/public/125/20.html

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 Fixed
 R3#  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 ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net