This Tech Note explains an issue with the formation of OSPF adjacency when the dialer interfaces are configured as point-to-point links.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
The OSPF network-type on Primary Rate Interface (PRI), Basic Rate Interface (BRI), and dialer interfaces is point-to-point, which means that an interface can't form adjacency with more than one neighbor. A common problem when a PRI, BRI, or dialer interfaces try to form an OSPF adjacency is the neighbor gets stuck in the exstart/exchange process. Let's look at an example.
Using the show ip ospf neighbor command, we can see the neighbor state is stuck in "EXSTART".
RTR-A# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 126.96.36.199 1 EXSTART/ - 00:00:37 188.8.131.52 Serial6/0:23 184.108.40.206 1 EXSTART/ - 00:00:39 220.127.116.11 Serial6/0:23 RTR-B# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 18.104.22.168 1 EXSTART/ - 00:00:36 22.214.171.124 BRI0 RTR-C# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 126.96.36.199 1 EXSTART/ - 00:00:35 188.8.131.52 BRI0
RTR-Bs configuration shows the network-type is point-to-point:
RTR-B# show ip ospf interface bri0 BRI0 is up, line protocol is up (spoofing) Internet Address 184.108.40.206/24, Area 2 Process ID 1, Router ID 220.127.116.11, 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)
We can debug this situation using the debug ip ospf adj command. Let's look at some sample output taken while running this command on RTR-B in the figure above:
1: Send DBD to 18.104.22.168 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 2: Rcv DBD from 22.214.171.124 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART 3: First DBD and we are not SLAVE 4: Rcv DBD from 126.96.36.199 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu 1500 state EXSTART 5: NBR Negotiation Done. We are the MASTER 6: Send DBD to 188.8.131.52 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 7: Database request to 184.108.40.206 8: sent LS REQ packet to 220.127.116.11, length 12 9: Rcv DBD from 18.104.22.168 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32 mtu 1500 state EXCHANGE 10: EXCHANGE - inconsistent in MASTER/SLAVE 11: Bad seq received from 22.214.171.124 on BRI0 12: Send DBD to 126.96.36.199 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 13: Rcv DBD from 188.8.131.52 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92 mtu 1500 state EXSTART 14: Unrecognized dbd for EXSTART 15: Rcv DBD from 184.108.40.206 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32 mtu 1500 state EXSTART 16: Unrecognized dbd for EXSTART
Lines 1 - 3: RTR-B sends the first DBD to 220.127.116.11 (RTR-A) with seq 0xB41 and receives the first DBD from 18.104.22.168 (RTR-A) with seq# 0x1D06. Neighbor negotiation is still not complete.
Lines 4 - 6: RTR-B receives a reply from 22.214.171.124 (RTR-A) indicating that RTR-A received RTR-B's first DBD. Since RTR-B has the higher router ID, RTR-A elects itself slave. After receiving the acknowledgement from RTR-A, RTR-B declares itself master and sends the first DBD with data in it. Note the sequence number, which is 0xB42. Since RTR-B is the master, only it can increment the sequence number.
Line 7: RTR-B requests data from RTR-A since RTR-A indicated it has more data to send (flag set to 0x2 in last DBD received from RTR-A).
Line 8: RTR-B sends a link-state request packet to 126.96.36.199 (RTR-A). This is an OSPF packet type 3. This packet is usually sent to the neighbor's IP address. In this case, the neighbor's IP address is its router ID.
Lines 9 - 11: RTR-B receives a reply from slave (RTR-A) with a completely different sequence number and a flag of 0x7, which is the init flag. This DBD was intended for another router (most likely RTR-C), but RTR-B incorrectly received it. RTR-B declares there is a discrepancy because a flag of 0x7 means the slave has changed its status to master by setting the MS (Master/Slave) bit during the adjacency exchange. RTR-B also complains about the sequence number because it's out of order. The slave should always follow the master's sequence number.
Line 12: RTR-B re-initializes the adjacency by sending the first DBD to 188.8.131.52 to re-elect master and slave.
Lines 13 - 14: RTR-B receives a DBD from 184.108.40.206 (RTR-A), indicating that it's a slave, without recognizing RTR-B's sequence number. RTR-B declares that it doesn't recognize this DBD since the master and slave negotiation is not complete yet. This DBD packet was intended for another router.
Line 15: RTR-B receives a reply from 220.127.116.11 (RTR-A) for the old DBD, but it's too late because RTR-B has already re-initialized the adjacency process.
Line 16: RTR-B fails to recognize this DBD because it is for an "old" adjacency, which RTR-B has already torn down.
This process will repeat endlessly.
According to section 8.1 of RFC 2328 , OSPF sends a multicast packet for a point-to-point network-type even after the interface achieves the 2-way state. Since RTR-A is trying to form adjacencies with both RTR-B and RTR-C, RTR-B receives DBD packets meant for RTR-C and RTR-C receives DBD packets meant for RTR-B.
To solve this problem, change the network type on all routers to point-to-multipoint. This changes the behavior of OSPF to send unicast packets after the 2-way state. Now RTR-B receives only packets destined for itself and RTR-C receives packets destined for itself. Changing the network-type in this way ensures that the OSPF router will form adjacency on a PRI, BRI, or dialer interface.
To change the network-type, enter the following configuration commands, ending each line by pressing ENTER. We'll change RTR-B as an example.
RTR-B# configure terminal RTR-B(config)# int bri 0 RTR-B(config-if)# ip ospf network point-to-multipoint RTR-B(config-if)# end
Now if we look at the show commands for RTR-B, we can verify that the network-type is point-to-multipoint and the state is full.
RTR-B# show ip ospf interface bri0 BRI0 is up, line protocol is up (spoofing) Internet Address 18.104.22.168/24, Area 2 Process ID 1, Router ID 22.214.171.124, 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:16 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 Adjacent with neighbor 172.16.141.10 Suppress hello for 0 neighbor(s) RTR-B# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 172.16.141.10 1 FULL/ - 00:01:36 126.96.36.199 BRI0
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.