Problem: OSPF Neighbor Stuck in EXSTARTEXCHANGE

‚  < ‚  Free Open Study ‚  > ‚  

Problem: OSPF Neighbor Stuck in EXSTART/EXCHANGE

This is an important state during the OSPF adjacency process. In this state, the router elects a master and a slave and the initial sequence number. The whole database also is exchanged during this state. If a neighbor is stuck in EXSTART/EXCHANGE for a long time, it is an indication of a problem. For more information on the EXSTART/EXCHANGE state, refer to Chapter 8.

The most common possible causes of this problem are as follows :

  • Mismatched interface MTU

  • Duplicate router IDs on neighbors

  • Inability to ping across with more than certain MTU size

  • Broken unicast connectivity because of the following:

    - Wrong VC/DLCI mapping in Frame Relay/ATM switch

    - Access list blocking the unicast

    - NAT translating the unicast

  • Network type of point-to-point between PRI and BRI/dialer

Figure 9-32 shows two routers running OSPF. This setup produces the stuck in EXSTART/EXCHANGE problem in OSPF.

Figure 9-32. Network Setup to Produce Stuck in EXSTART/EXCHANGE Problem

graphics/09fig32.gif

Example 9-86 shows the output of show ip ospf neighbor, which indicates that the neighbor is stuck in EXSTART/EXCHANGE.

Example 9-86 show ip ospf neighbor Command Output Indicates That a Neighbor Is Stuck in EXSTART/EXCHANGE
 R2#  show ip ospf neighbor  Neighbor ID   Pri  State     Dead Time   Address         Interface 131.108.2.1    1  EXSTART/-  00:00:33    131.108.1.1     Serial0 

OSPF Neighbor Stuck in EXSTART/EXCHANGE ‚ Cause: Mismatched Interface MTU

OSPF sends the interface MTU in a database description packet. If there is a MTU mis-match, OSPF will not form an adjacency. The interface MTU option was added in RFC 2178. Previously, there was no mechanism to detect the interface MTU mismatch. This option was added in Cisco IOS Software Release 12.0.3 and later.

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

Figure 9-33. Problem-Resolution Flowchart

graphics/09fig33.gif

Debugs and Verification

Example 9-87 shows the output of the debug ip ospf adj command on R1, which indicates that the neighbor MTU is higher. As a result, OSPF can't form an adjacency.

Example 9-87 debug ip ospf adj Command Output Indicates a Mismatched Interface MTU
 R1#  debug ip ospf adj  OSPF: Retransmitting DBD to 131.108.1.2 on Serial0.1 OSPF: Send DBD to 131.108.1.2 on Serial0.1 seq 0x1E55 opt 0x2 flag 0x7 len 32 OSPF: Rcv DBD from 131.108.1.2 on Serial0.1 seq 0x22AB opt 0x2 flag 0x7 len 32  mtu 1500 state EXSTART  OSPF: Nbr 131.108.1.2 has larger interface MTU  

Example 9-88 shows the output of show ip interface on R1 and R2. The IP interface MTU on R1 is set to 1400 bytes; on R2, it is set to 1500 bytes. This creates an MTU mismatch problem.

Example 9-88 show ip interface Command Output on R1 and R2 Pinpoints the MTU Mismatch
 R1#  show ip interface serial 0.1  Serial0.1 is up, line protocol is up   Internet address is 131.108.1.1/24   Broadcast address is 255.255.255.255  MTU is 1400 bytes  _____________________________________________________________________________________ R2#  show ip interface serial 0.1  Serial0.1 is up, line protocol is up   Internet address is 131.108.1.2/24   Broadcast address is 255.255.255.255  MTU is 1500 bytes  
Solutions

In Cisco IOS Software Release 12.0.3 and later, if there is a MTU mismatch, Cisco IOS Software will indicate this in a debug message, as shown in Example 9-87. If R2's MTU is smaller than R1's, this message is not generated. Also, if R1 is not running Cisco IOS Software Release 12.0.3 or later, this message does not appear in the debug. The only way to detect this MTU mismatch is to check the interface configurations on both sides.

To correct this problem, make sure that the MTU is set to the same value on both sides. Example 9-89 shows the new configuration on R1 that fixes this problem.

Example 9-89 Setting the Same MTU Value on R1
 R1#  interface Serial0.1 multipoint   ip address 141.108.10.3 255.255.255.248   mtu 1500  

There is another situation that could lead to a MTU mismatch ‚ when a router is connected through FDDI to a switch with the route switch module (RSM) blade in it. Figure 9-34 shows this setup.

Figure 9-34. Network Setup That Reproduces MTU Mismatch Problem

graphics/09fig34.gif

The VLAN 1 interface is the virtual Ethernet interface with the MTU of 1500 bytes, while the FDDI interface on R2 has the MTU of 4470, as shown in Example 9-90.

Example 9-90 Configuration of RSM and R2 Shows MTU Mismatch
 RSM#  show interface vlan 1  Vlan1 is up, line protocol is up   Hardware is Cat5k RP Virtual Ethernet, address is 0030.f2c9.8338 (bia 0030.f2)   Internet address is 131.108.1.1/24  MTU 1500 bytes  , BW 10000 Kbit, DLY 1000 usec, _____________________________________________________________________________________ R2#  show interface fddi 0  Fddi0 is up, line protocol is up   Hardware is DAS FDDI, address is 0000.0c17.acbf (bia 0000.0c17.acbf)   Internet address is 131.108.1.2/24  MTU 4470 bytes  , BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255 

This is a normal setup in a Catalyst switch environment. When a packet is received on a switch FDDI port, it goes across the switch backplane to the slot where the RSM is installed. The conversion/fragmentation from FDDI to Ethernet happens at the switch level.

With the MTU mismatch-detection feature, these two routers never form an adjacency. For this particular situation, an interface-level command, ip ospf mtu-ignore , was added in Cisco IOS Software Release 12.1.3 and later. This command ignores the FDDI MTU and forms an adjacency in this particular situation. This command must never be used in any other situation because MTU mismatch detection is important for troubleshooting purposes. To use this command, apply it under the interface. In this example, it should be applied under the VLAN 1 interface.

Example 9-91 shows the output of show ip ospf neighbor after fixing the MTU problem.

Example 9-91 Verifying That the MTU Mismatch Has Been Resolved
 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface 131.108.2.1  1    FULL/DR    00:00:32   131.108.1.1   Fddi0 

OSPF Neighbor Stuck in EXSTART/EXCHANGE ‚ Cause: Duplicate Router IDs on Neighbors

When OSPF sends a DBD packet to elect a master and a slave, the router with the highest router ID becomes the master. This happens in the EXSTART process. If there is any problem with election, the router will be stuck in the EXSTART/EXCHANGE state.

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

Figure 9-35. Problem-Resolution Flowchart

graphics/09fig35.gif

Debugs and Verification

Example 9-92 shows the output of show ip ospf neighbor on R1 indicating that the neighbor is stuck in the EXSTART state.

Example 9-92 show ip ospf neighbor Command Output Shows That R1 Is in the EXSTART State
 R2#  show ip ospf neighbor  Neighbor ID   Pri  State     Dead Time   Address         Interface 131.108.2.1    1  EXSTART/-  00:00:33    131.108.1.1     Serial0 

Example 9-93 shows the output of debug ip ospf adj. If the DBD packets keep retransmitting and the flag value remains 7, this is an indication of a problem. This means that neither router can determine which will be the master and which will be a slave. A flag is a 3-bit value that comes from the DBD packet format and represents the I, M, and MS bits. The value of the flag is set to 7 in the first DBD ‚ this means that the I, M, and MS bit values are set to 1. For more information on the I, M, and MS bits, refer to Chapter 8.

Example 9-93 debug Output Shows That a Master and Slave Are Not Being Formed
 R2#  debug ip ospf adj  OSPF: Retransmitting DBD to 131.108.2.1 on Serial0 OSPF: Send DBD to 131.108.2.1 on Serial0 seq 0x793 opt 0x2  flag 0x7  len 32 OSPF: Rcv DBD from  131.108.2.1  on Serial0 seq 0x25F7 opt 0x2  flag 0x7  len 32  mtu 0 state EXSTART  OSPF: First DBD and we are not SLAVE  

Example 9-94 shows the output of show ip ospf interface serial0 on R2, which displays the router ID as 131.108.2.1 ‚ the same as the neighbor's. This prevents the election of master and slave.

Example 9-94 Router ID of R2 Is Same as Neighbor R1's
 R2#  show ip ospf interface serial 0  Serial0 is up, line protocol is up   Internet Address 131.108.1.2/24, Area 1   Process ID 1,  Router ID 131.108.2.1  , Network Type POINT_TO_POINT, Cost: 64 
Solution

Example 9-93 shows that R2 is sending a DBD packet with a flag of 7, saying, "I am the master." R2 also receives a DBD from R1 saying, "I am the master." R2 compares R1's router ID and sees that it is not higher than its own, so it sends the DBD packet to R1 saying, "I am the master." So, both routers keep fighting for the master status and the router gets stuck in the EXSTART state.

To solve this problem, carefully review the neighbor router ID and the local router ID to see if they are exactly the same. If so, you must change the router ID for one of the routers and restart the OSPF process so that it can take effect.

NOTE

Cisco IOS Software Release 12.0 and later provide a warning message, OSPF-3-DUP_RTRID, that warns if there is a duplicate router ID.


Example 9-95 shows the output of show ip ospf neighbor after this problem is fixed.

Example 9-95 Verifying That the Duplicate Router ID Problem Has Been Fixed and an OSPF Adjacency Can Be Established
 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/-    00:00:32   131.108.1.1   Serial0  

OSPF Neighbor Stuck in EXSTART/EXCHANGE ‚ Cause: Can't Ping Across with More Than Certain MTU Size

When OSPF begins forming an adjacency with its neighbor, it goes through several states. In EXSTART state, OSPF determines which will be the master and which will be the slave. After the routers decided this, they start exchanging the LSA header in the form of DBD packets. If the database is huge, OSPF uses the interface MTU and tries to send as much data as possible up to the limit of the interface MTU. If there is a problem with Layer 2 accepting large packets that are within the interface MTU range, the OSPF adjacency will be stuck in the EXCHANGE state.

Figure 9-36 shows the network setup that reproduces this problem. The Layer 2 medium intentionally is not shown in this figure because this problem can happen in any Layer 2 media.

Figure 9-36. Network Setup Used to Reproduce MTU Problem

graphics/09fig36.gif

Example 9-96 shows the output of show ip ospf neighbor on R2, which is stuck in the EXCHANGE state with R1 on the serial link. This means that the master and slave negotiation already has taken place.

Example 9-96 show ip ospf neighbor Command Output Indicates an EXSTART Problem
 R2#  show ip ospf neighbor  Neighbor ID     Pri   State           Dead Time   Address         Interface 131.108.2.1       1  EXCHANGE/-  00:00:46    131.108.1.2     Serial0/0 

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

Figure 9-37. Problem-Resolution Flowchart

graphics/09fig37.gif

Debugs and Verification

Example 9-97 shows the output of debug ip ospf adj. The debug shows that R2 keeps retrans-mitting the DBD packets every 5 seconds, which is a default, and is not receiving any reply. Also note that the length of this packet is 1274 and the flag value is 3; this means that R2 is a master. Recall from the previous problem that a flag of 3 means that the M and MS bits are set.

Example 9-97 debug ip ospf adj Command Output Shows the DBD Packet Transmission History
 R2#  debug ip ospf adj  OSPF: Send DBD to 131.108.2.1 on Serial0 seq 0x793 opt 0x2 flag 0x3 len 1274 OSPF:  Retransmitting DBD  to 131.108.2.1 on Serial0 OSPF: Send DBD to 131.108.2.1 on Serial0 seq 0x793 opt 0x2 flag 0x3 len 1274 OSPF:  Retransmitting DBD  to 131.108.2.1 on Serial0 OSPF: Send DBD to 131.108.2.1 on Serial0 seq 0x793 opt 0x2 flag 0x3 len 1274 OSPF:  Retransmitting DBD  to 131.108.2.1 on Serial0 OSPF: Send DBD to 131.108.2.1 on Serial0 seq 0x793 opt 0x2 flag 0x3 len 1274 OSPF:  Retransmitting DBD  to 131.108.2.1 on Serial0 

Example 9-98 shows the output of normal and extended pings from R1 to R2. When R1 pings R2 with an MTU equal to or greater than 1200, the ping never reaches the other side. This indicates a problem at Layer 2.

Example 9-98 Normal Ping Is Successful and Ping with 1,200 Fails
 R1#  ping 131.108.1.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.1.2, timeout is 2 seconds: !!!!!  Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms  R1# R1#  ping ip  Target IP address: 131.108.1.2 Repeat count [5]: Datagram size [100]:  1200  Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 1200-byte ICMP Echos to 131.108.1.2, timeout is 2 seconds: .....  Success rate is 0 percent (0/5)  R1# 
Solution

The problem is actually with Layer 2. R1 can ping R2 when using a 100-byte datagram, but the ping starts failing when the datagram size is greater than 1200 bytes.

To solve this problem, fix the Layer 2 issue. One way to narrow this problem is to connect the two devices directly instead of going through switches and so forth, to see whether the problem is with the Layer 2 devices or with the router itself. If connecting routers back to back doesn't fix the problem, there is a possibility of bad hardware. Most times, it turns out to be a problem in the middle ‚ for example, a LAN switch or a telco cloud.

Depending upon the media, there are several recommendations:

  • In the case of a LAN medium

    - Check the MTU size defined in the switch configuration for this medium.

    - Try using a different port.

  • In the case of a WAN medium

    - If you are the WAN cloud provider, check at which hop it fails.

    - If you are getting a circuit from a telco, request that the WAN cloud in the middle be checked to see where it fails.

OSPF Neighbor Stuck in EXSTART/EXCHANGE ‚ Cause: Unicast Connectivity Is Broken

When OSPF routers begin exchanging database information with each other, they send a unicast packet to each other in EXSTART/EXCHANGE state. This happens only if the network type is not a point-to-point link. In cases of a point-to-point link, OSPF sends all multicast packets. If unicast connectivity is broken, OSPF neighbor remains in EXSTART state.

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

Figure 9-38. Problem-Resolution Flowchart

graphics/09fig38.gif

Debugs and Verification

Example 9-99 shows the output of a ping from R1 to R2. The output shows that a ping packet with 100-byte datagrams fails.

Example 9-99 Ping Failure Shows That Unicast Connectivity Is Broken
  R1#  ping 131.108.1.2   Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.1.2, timeout is 2 seconds: .....  Success rate is 0 percent (0/5)  R1# 
Solutions

This ping failure could occur for several reasons, including the following:

  • The wrong DLCI or VPI/VCI mapping exists in a Frame Relay or ATM switch, respectively.

  • An access list is blocking the unicast.

  • NAT is translating the unicast.

Wrong DLCI or VPI/VCI Mapping

In cases of Frame Relay or ATM, this is a very common problem. The packet will be lost in the Frame Relay or ATM cloud. To further verify that this is the case, turn on debug ip packet detail with the access list on both routers.

Example 9-100 shows the output of debug ip packet detail on both R1 and R2, indicating that the ICMP packet is being sent into the Frame Relay cloud but nothing is coming back.

Example 9-100 debug ip packet detail Command Output Indicates Successful ICMP Packet Transmission but No Receipt
 R1#  show access-list 100  Extended IP access list 100     permit ip 131.108.1.0 0.0.0.255 131.108.1.0 0.0.0.255 (10 matches) R1#  debug ip packet detail 100  R1#  ping 131.108.1.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.1.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0), len 100,  sending   ICMP type=8  , code=0 IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0), len 100, sending     ICMP type=8, code=0 IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0), len 100, sending     ICMP type=8, code=0 IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0), len 100, sending     ICMP type=8, code=0 IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0), len 100, sending     ICMP type=8, code=0 R1# _____________________________________________________________________________________ R2#  show access-list 100  Extended IP access list 100     permit ip 131.108.1.0 0.0.0.255 131.108.1.0 0.0.0.255 (10 matches) R2#  debug ip packet detail 100  R2#  ping 131.108.1.1  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) IP: s=131.108.1.2 (local), d=131.108.1.1 (Serial0), len 100,  sending   ICMP type=8  , code=0 IP: s=131.108.1.2 (local), d=131.108.1.1 (Serial0), len 100, sending     ICMP type=8, code=0 IP: s=131.108.1.2 (local), d=131.108.1.1 (Serial0), len 100, sending     ICMP type=8, code=0 IP: s=131.108.1.2 (local), d=131.108.1.1 (Serial0), len 100, sending     ICMP type=8, code=0 IP: s=131.108.1.2 (local), d=131.108.1.1 (Serial0), len 100, sending     ICMP type=8, code=0 R2# 

To solve this problem, the telephone carrier should be contacted to determine whether any such thing has happened . There is a slight chance that the problem could be with the router itself and that it is dropping the packet. Any other problems will appear in the debug messages. Problems such as the wrong Frame Relay mapping within the router produce "encapsulation failure" messages in the debug output.

Access List Blocking the Unicast

If an access list is configured on a router, make sure that it's not blocking the unicast packet. Example 9-101 shows the output of debug ip packet detail 100 on R2, which shows that the unicast is being blocked. Access list 101 shows that only the multicast packets of OSPF are allowed and that unicast packets from the 131.108.1.0 address are denied because there is an implicit deny at the end of each access list.

Example 9-101 Revealing That the Unicast Connection Is Being Blocked
 R1#  show access-list 100  Extended IP access list 100     permit ip 131.108.1.0 0.0.0.255 131.108.1.0 0.0.0.255 R1#  show access-list 101  Extended IP access list 101     permit ip 141.108.10.0 0.0.0.255 any     permit ip 141.108.20.0 0.0.0.255 any     permit ip 141.108.30.0 0.0.0.255 any     permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5 R1#  debug ip packet 100 detail  IP packet debugging is on (detailed) for access list 100 R1# IP: s=131.108.1.2 (Serial0.2), d=131.108.1.1, len 100,  access denied  ICMP type=8, code=0 IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0.2), len 56, sending     ICMP type=3, code=13 R1# IP: s=131.108.1.2 (Serial0.2), d=131.108.1.1, len 100, access denied     ICMP type=8, code=0 IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0.2), len 56, sending     ICMP type=3, code=13 R1# IP: s=131.108.1.2 (Serial0.2), d=131.108.1.1, len 100, access denied     ICMP type=8, code=0 IP: s=131.108.1.1 (local), d=131.108.1.2 (Serial0.2), len 56, sending     ICMP type=3, code=13 R1# 

Example 9-101 clearly shows that the packet is being rejected because of the access list. All access lists have an implicit deny at the end of the list, so they also deny any packet not explicitly permitted (in this case, unicast packets). This causes OSPF to get stuck in the EXCHANGE state.

To solve this problem, modify access list 101 so it allows the unicast packets. Example 9-102 shows the modified access list that will solve the problem.

Example 9-102 Modifying an Access List to Permit Unicast Packets
 R1#  show access-list 101  Extended IP access list 101     permit ip 141.108.10.0 0.0.0.255 any     permit ip 141.108.20.0 0.0.0.255 any     permit ip 141.108.30.0 0.0.0.255 any     permit ip 131.108.1.0 0.0.0.255 host 224.0.0.5  permit ip 131.108.1.0 0.0.0.255 131.108.1.0 0.0.0.255  
NAT Is Translating the Unicast

This is another common problem that occurs when NAT is configured on the router. If NAT is misconfigured, it will start translating the unicast packet coming toward it, which will break the unicast connectivity. Example 9-103 shows that R1 is configured with NAT. The outside inter-face of R1 is Serial 0.2, which connects to R2. Figure 9-39 shows R1 and R2 connected to each other, with R1 running NAT.

Figure 9-39. Network in Which R1 Is Running NAT

graphics/09fig39.gif

When R2 sends a unicast packet to R1, R1 tries to translate that packet and R2 never receives the ping reply. The main thing to watch for is the access list in NAT. If the access list is permitting everything, this problem will occur. Example 9-98 shows the NAT configuration on R1.

Example 9-103 NAT Configuration Resulting in Unicast Packets Being Translated
 R1#  interface Ethernet 0   ip nat outside   !   ip nat inside source list 1 interface Serial0.2 overload   !   access-list 1 permit any  

To solve this problem, change access list 1 and permit only those IP address that require translation. Example 9-104 shows the correct access list that solves the problem. The access list could be different from network to network. The whole idea is that the access list permit statement should not cover the neighbor's IP address. In Example 9-104, only the inside network 10.0.0.0/8 is permitted. This means that R1 will no longer translate the packets belonging to the 131.108.1.0 network.

Example 9-104 Correcting the Access List to Solve the Unicast Connectivity Problem
 R1#  interface Ethernet 0   ip address 131.108.1.1 255.255.255.0   ip nat outside   !   ip nat inside source list 1 interface Serial0.2 overload   !   access-list 1 permit 10.0.0.0 0.255.255.255  

Example 9-105 shows the output of show ip ospf neighbor, which shows that OSPF neighbors are in the FULL state after fixing the unicast problem.

Example 9-105 Verifying That the Unicast Issue Has Been Resolved
 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/-    00:00:32   131.108.1.1   Ethernet0  

OSPF Neighbor Stuck in EXSTART/EXCHANGE ‚ Cause: Network Type Is Point-to-Point Between PRI and BRI/Dialer

The network type on a PRI interface is point-to-point. This causes OSPF to send multicast packets even after the 2-WAY state. If only one BRI comes up as an OSPF neighbor, it will work fine. However, when multiple BRIs try to form an adjacency with the PRI, the PRI will complain because its network type is point-to-point. Because all OSPF packets are sent as multicast on a point-to-point link, the PRI receives DBD packets from multiple BRI neighbors, and this causes all the neighbors to get into the EXSTART/EXCHANGE state.

Figure 9-40 shows a network setup that produces this problem. R1 has a PRI, and both R2 and R3 dial into this PRI. This creates a problem in OSPF because the network type is point-to-point.

Figure 9-40. PRI to BRI Setup with Network Type Point-to-Point

graphics/09fig40.gif

Example 9-106 shows the output of show ip ospf neighbor on R1. R2 and R3 both are stuck in the EXSTART state, with R1 on an ISDN link. If the output shows neighbors in the EXSTART state, for a long time, it is an indication of a problem.

Example 9-106 PRI Neighbors Are Stuck in EXSTART State
 R1#  show ip ospf neighbor  Neighbor ID     Pri   State           Dead Time   Address         Interface 131.108.1.2     1  EXSTART/-  00:00:38    131.108.1.2     Serial0/0:23 131.108.1.3     1  EXSTART/-  00:00:32    131.108.1.3     Serial0/0:23 

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

Figure 9-41. Problem-Resolution Flowchart

graphics/09fig41.gif

Debugs and Verification

Example 9-107 shows the output of show ip ospf interface bri0 on R2 indicating that the network type is point-to-point.

Example 9-107 Verifying the Network Type on R2's bri0 Interface
 R2#  show ip ospf interface bri0  BRI0 is up, line protocol is up (spoofing)    Internet Address 131.108.1.2/24, Area 2    Process ID 1, Router ID 131.108.1.2,  Network Type POINT_TO_POINT  , Cost: 1562    Transmit Delay is 1 sec, State POINT_TO_POINT,    Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5      Hello due in 00:00:06    index 1/1, flood queue length 0    Next 0x0(0)/0x0(0)    Last flood scan length is 1, maximum is 1    Last flood scan time is 0 msec, maximum is 0 msec    Neighbor Count is 1, Adjacent neighbor count is 0    Suppress hello for 0 neighbor(s) 

Example 9-108 shows the output of debug ip ospf adj on R2. The debug shows that R2 is receiving two different DBD packets on a point-to-point network type. The problem is that when R1 sends the DBD packets to R2 and R3, it sends them as multicasts because the network type is defined as point-to-point. In point-to-point networks, all OSPF packets are sent as multicast. This causes R2 to receive DBD packets destined for R3, and vice versa.

When R2 receives a DBD packet, it complains because the DBD packet's sequence number and the flags are different. This causes R2 to go back into the EXSTART state. This cycle keeps repeating.

Example 9-108 debug Output Showing That R2 Is Receiving R3's DBD Packets, Which Causes Problems
 R2#  debug ip ospf adj  Send DBD to 131.108.1.1 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 Rcv DBD from 131.108.1.1 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32  mtu 1500 state EXSTART First DBD and we are not SLAVE Rcv DBD from 131.108.1.1 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92  mtu 1500 state EXSTART NBR Negotiation Done. We are the MASTER Send DBD to 131.108.1.1 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 Database request to 131.108.1.1 sent LS REQ packet to 131.108.1.1, length 12 Rcv DBD from 131.108.1.1 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32  mtu 1500 state EXCHANGE  EXCHANGE - inconsistent in MASTER/SLAVE   Bad seq received from 131.108.1.1 on BRI0  Send DBD to 131.108.1.1 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 Rcv DBD from 131.108.1.1 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92  mtu 1500 state         EXSTART  Unrecognized dbd for EXSTART  Rcv DBD from 131.108.1.1 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32  mtu 1500 state         EXSTART  Unrecognized dbd for EXSTART  
Solution

To solve this problem, change the network type of PRI and BRI to point-to-multipoint. Example 9-109 shows the interface-level command to change the network type to point-to-multipoint, followed by the output of show ip ospf interface on R2.

Example 9-109 Verifying the Network Type on R2's bri0 Interface
 R2#  interface BRI0    ip ospf network point-to-multipoint   R2#  show ip ospf interface bri0  BRI0 is up, line protocol is up (spoofing)    Internet Address 131.108.1.2/24, Area 2    Process ID 1, Router ID 131.108.1.2,  Network Type POINT_TO_MULTIPOINT  , Cost: 1562    Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,    Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5      Hello due in 00:00:06    index 1/1, flood queue length 0    Next 0x0(0)/0x0(0)    Last flood scan length is 1, maximum is 1    Last flood scan time is 0 msec, maximum is 0 msec    Neighbor Count is 1, Adjacent neighbor count is 1    Suppress hello for 0 neighbor(s) 

This change must be made on all the routers connected to the ISDN cloud. Changing the net-work type to point-to-multipoint forces OSPF to send a unicast packet for DBDs instead of a multicast after 2-WAY state, so the packet destined for R3 never reaches R2.

‚  < ‚  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