Neighbor Stuck in Exstart Exchange State

OSPF neighbors that are in the exstart or exchange state are trying to exchange DD packets. The adjacency should continue past this state. If it does not, there is a problem with the DD exchange, such as a maximum transmission unit (MTU) mismatch or the receipt of an unexpected DD sequence number.

Although OSPF neighbors transition through the exstart/exchange states during the normal OSPF adjacency-building process, it is not normal for OSPF neighbors to be stuck in this state.

The problem occurs when the MTU settings for neighboring router interfaces do not match. The problem occurs most frequently when attempting to run OSPF between a Cisco router and another vendor's router. If the router with the higher MTU sends a packet larger than the MTU set on the neighboring router, the neighboring router ignores the packet. When this problem occurs, the show ip ospf neighbor command displays output similar to that shown in Figure 3-34.

152 Chapter 3: OSPF Communication

Figure 3-34 MTU Mismatch

Router 6

S0.6

S2.7

170.170.11.0/24

Routers 6 and 7 in the topology in Figure 3-34 are connected via frame relay, and Router 6 has been configured with 204 static routes redistributed into OSPF. The serial interface on Router 6 has the default MTU of 1500, while the serial interface on Router 7 has an MTU of 1450. Example 3-16 shows each router's configuration (only the necessary configuration information is shown):

Example 3-16 Configurations for Routers 6 and 7 in Figure 3-34

Router 6 Configuration

Router 7 Configuration

interface Serial2

!

no ip address

interface Serial0

no ip directed-broadcast

mtu 1450

encapsulation frame-

relay

no ip address

no ip mroute-cache

no ip directed-broadcast

frame-relay lmi-type

ansi

encapsulation frame-relay

!

frame-relay lmi-type ANSI

interface Serial2.7

point-to-point

ip address 170.170.11.6 255.255.255.0

!

no ip directed-broadcast

interface Serial0.6 point-to-point

frame-relay interface-dlci 101

ip address 170.170.11.7 255.255.255.0

no ip directed-broadcast

router ospf 7

frame-relay interface-dlci 110

redistribute static

subnets

network 170.170.11.0

0.0.0.255 area

0

router ospf 7

network 170.170.11.0 0.0.0.255 area 0

ip route 192.79.34.0

255.255.255.0

Null0

ip route 192.79.35.0

255.255.255.0

Null0

ip route 192.79.36.0

255.255.255.0

Null0

204 total static

routes

Example 3-17 shows the output of the show ip ospf neighbor command for each router. Example 3-17 Output of the show ip ospf neighbor Command for Routers 6 and 7

router-6#show

ip ospf

neighbor

Neighbor ID

Pri

State

Dead Time

Address

Interface

170.170.11.7

1

EXCHANGE/ -

00:00:36

170.170

11.7

Serial2.7

router-7#show

ip ospf

neighbor

Neighbor ID

Pri

State

Dead Time

Address

Interface

170.170.11.6

1

EXSTART/ -

00:00:33

170.170

11.6

Serial0.6

The problem occurs when Router 6 sends an OSPF DD packet larger than 1450 bytes (Router 7's MTU) while in the exchange state. Using the debug ip packet and debug ip ospf adjacency commands on each router, you can see the OSPF adjacency process as it takes place. Table 3-4 documents the output following Routers 6 and 7 from Steps 1 through 14.

Table 3-4 Output from the debug ip packet and debug ip ospf adjacency Command on Routers 6 and 7

Router 6 Debug Output

Router 7 Debug Output

***ROUTER6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN 00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on Serial2.7 is dead 00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on Serial2.7 is dead, state DOWN

OSPF NOT ENABLED ON ROUTER7 YET

***ROUTER6 SENDING HELLOS

00:03:53: IP: s=170.170.11.6 (local), d=224.0.0.5 (Serial2.7), len 64, sending broad/multicast, proto=89 00:04:03: IP: s=170.170.11.6 (local), d=224.0.0.5 (Serial2.7), Len 64, sending broad/multicast, proto=89

OSPF NOT ENABLED ON ROUTER7 YET

***RECEIVE HELLO FROM ROUTER7

00:04:04: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, Len 64, rcvd 0, proto=89 00:04:04: OSPF: Rcv hello from 170.170.11.7 area 0 from Serial2.7 170.170.11.7

00:04:04: OSPF: End of hello processing

***OSPF ENABLED ON ROUTER7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA

00:17:44: IP: s=170.170.11.7 (local), d=224.0.0.5 (Serial0.6), Len 64, sending broad/multicast, proto=89 00:17:44: OSPF: Build router LSA for area 0, router ID 170.170.11.7, seq 0x80000001

***ROUTER6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET

00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 (Serial2.7), Len 68, sending broad/multicast, proto=89

***ROUTER7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY

00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:17:53: OSPF: Rcv hello from 170.170.11.6 area 0 from Serial0.6 170.170.11.6 00:17:53: OSPF: 2 Way Communication to 170.170.11.6 on Serial0.6, state 2WAY

154 Chapter 3: OSPF Communication

Table 3-4 Output from the debug ip packet and debug ip ospf adjacency Command on Routers 6 and 7 (Continued)

Router 6 Debug Output

Router 7 Debug Output

***ROUTER6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY

00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:13: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT 00:04:13: OSPF: 2 Way Communication to 170.170.11.7 on Serial2.7, state 2WAY

***ROUTER7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD

00:17:53: OSPF: Send DBD to 170.170.11.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32

00:17:53: IP: s=170.170.11.7 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:17:53: OSPF: End of hello processing

***ROUTER6 SENDS DBD PACKET TO ROUTER7 (MASTER/SLAVE NEGOTIATION - ROUTER6 IS SLAVE) 00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 seq 0xE44 opt 0x2 flag 0x7 Len 32

00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 (Serial2.7), Len 52, sending broad/multicast, proto=89 00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE

***RECEIVE ROUTER6'S INITIAL DBD

PACKET(MTU MISMATCH IS RECOGNIZED)

00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:17:53: OSPF: Rcv DBD from 170.170.11.6 on Serial0.6 seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART 00:17:53: OSPF: Nbr 170.170.11.6 has larger interface MTU (MTU MISMATCH RECOGNIZED)

***SINCE ROUTER6 IS SLAVE SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER7'S DBD. (NOTE SIZE OF PKT)

00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 seq 0x13FD opt 0x2 flag 0x2 Len 1472

00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 (Serial2.7), Len 1492, sending broad/multicast, proto=89

***NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT

00:17:54: IP: s=170.170.11.7 (local), d=224.0.0.5 (Serial0.6), Len 68, sending broad/multicast, proto=89 00:17:58: OSPF: Retransmitting DBD to 170.170.11.6 on Serial0.6 00:17:58: OSPF: Send DBD to 170.170.11.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32

AT THIS POINT ROUTER6 KEEPS TRYING TO ACK THE INITIAL DBD PACKET FROM ROUTER7

ROUTER7 NEVER GETS ACK FROM ROUTER6 BECAUSE DBD PACKET FROM ROUTER7 IS TOO BIG FOR ROUTER7'S MTU. ROUTER7 KEEPS RETRANSMITTING DBD PACKET.

Table 3-4 Output from the debug ip packet and debug ip ospf adjacency Command on Routers 6 and 7 (Continued)

Router 6 Debug Output

00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:04:13: OSPF: Rcv hello from 170.170.11.7 area 0 from Serial2.7 170.170.11.7

00:04:13: OSPF: End of hello processing

00:04:18: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:18: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 170.170.11.7 on Serial2.7 seq 0x13FD opt 0x2 flag 0x2 Len 1472

00:04:18: IP: s=170.170.11.6 (local), d=224.0.0.5 (Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.6 (local), d=224.0.0.5 (Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, Len 52, rcvd 0, proto=89 00:04:23: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

ROUTERS REMAIN IN THIS RETRANSMIT SESSION INDEFINITELY

Router 7 Debug Output

0:17:58: IP: s=170.170.11.7 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:18:03: OSPF: Retransmitting DBD to 170.170.11.6 on Serial0.6 00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32

00:18:03: IP: s=170.170.11.7 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 00:18:03: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, Len 68, rcvd 0, proto=89 00:18:03: OSPF: Rcv hello from 170.170.11.6 area 0 from Serial0.6 170.170.11.6 00:18:03: OSPF: End of hello processing

00:18:04: IP: s=170.170.11.7 (local), d=224.0.0.5 (Serial0.6), Len 68, sending broad/multicast, proto=89 00:18:08: OSPF: Retransmitting DBD to 170.170.11.6 on Serial0.6 00:18:08: OSPF: Send DBD to 170.170.11.6 on Serial0.6 seq 0x13FD opt 0x2 flag 0x7 Len 32

00:18:08: IP: s=170.170.11.7 (local), d=224.0.0.5 (Serial0.6), Len 52, sending broad/multicast, proto=89 router-7#

In Step 9 of Table 3-4, Router 7 sends its first DBD packet with flag 0x7 set. This indicates that Router 7 is the master.

In Step 10, Router 6 receives Router 7's initial DBD packet and transitions its state to 2-way.

Step 11 shows Router 6 sending its initial DBD packet with flag 0x7 set, indicating that it is the master (this is part of the master—slave negotiation).

156 Chapter 3: OSPF Communication

In Step 12, Router 7 receives Router 6's initial DBD packet and recognizes an MTU mismatch. (Router 7 can recognize an MTU mismatch because Router 6 includes its interface MTU in the interface MTU field of the DBD packet.) Router 6's initial DBD is rejected by Router 7. Router 7 retransmits the initial DBD packet.

Step 13 shows Router 6, as slave, adopting Router 7's sequence number and sending its second DBD packet containing the headers of its LSAs; this increases the size of the packet. However, Router 7 never receives this DBD packet because it is larger than Router 7's MTU.

After Step 13, Router 7 continues to retransmit the initial DBD packet to Router 6, while Router 6 continues to send DBD packets that follow the master sequence number. This loop continues indefinitely, preventing either router from making the transition out of the exstart/ exchange state.

Was this article helpful?

0 -2

Responses

  • Elizabeth Thompson
    Why ospf stuck in exstart state?
    1 year ago
  • HABEN MUHAMMED
    Why mismatch MTU cause ospf stuck?
    11 months ago

Post a comment