Description
This article demonstrates troubleshooting steps for OSPF neighbors stuck in Exstart/Exchange state.
Scope
FortiGate.
Solution
When an OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent to its neighbor. Those states are defined in RFC 2328 section 10.1.
The states are: Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, and Full.
OSPF is only fully functional when the neighbor state is FULL.
The most common reason for the neighbors to be stuck in Exstart/Exchange state is an MTU mismatch on the OSPF-enabled interfaces between the two neighbors.
See one of the following articles if an OSPF neighbour is stuck in one of the other states:
- Troubleshooting Tip: OSPF – Neighbor stuck at loading.
- Technical Tip: Why multiple OSPF neighbors on FortiGate are stuck in 2-Way state?
- Troubleshooting Note: OSPF Neighbor stuck in INIT state.
Expectations, requirements:
The OSPF neighbor states can be verified as follows:
FGT_A # get router info ospf neighbor
OSPF process 0:
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 ExStart/ - 00:00:36 10.100.100.2 OSPF_TEST
Verify the MTU configuration on both interfaces using CLI as mentioned below:
FGT_A # get router info ospf interface
OSPF_TEST is up, line protocol is up
Internet Address 10.100.100.1/32, Area 0.0.0.0, MTU 1440
Process ID 0, Router ID 0.0.0.1, Network Type POINTOPOINT, Cost: 100
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
Neighbor Count is 1, Adjacent neighbor count is 0
Crypt Sequence Number is 1644581
Hello received 15 sent 15, DD received 27 sent 29
LS-Req received 0 sent 0, LS-Upd received 0 sent 0
LS-Ack received 0 sent 0, Discarded 0
FWF60D4614-----1 # get router info ospf interface
Test_1 is up, line protocol is up
Internet Address 10.100.100.2/32, Area 0.0.0.0, MTU 1436
Process ID 0, Router ID 2.2.2.2, Network Type POINTOPOINT, Cost: 100
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:09
Neighbor Count is 1, Adjacent neighbor count is 0
Crypt Sequence Number is 1122298
Hello received 49869 sent 49915, DD received 3888 sent 2847
LS-Req received 769 sent 770, LS-Upd received 2977 sent 3019
LS-Ack received 1743 sent 2413, Discarded 39
Configuration:
The issue can be resolved by either configuring the same MTU on both OSPF interfaces or enabling mtu-ignore on the OSPF interface. However, in some cases, MTU-ignore does not solve the issue because the actual size of the OSPF DPD or LSR packet is larger than the receiving side MTU size. In this case, it is necessary to make sure that MTU matches in OSPF adjacent interfaces.
1) Configure MTU on the OSPF Interface to match the neighbor OSPF interface:
# config router ospf
# config ospf-interface
edit OSPF1
set mtu 1436
end
end
2) Enable mtu-ignore on the OSPF interface:
# config router ospf
# config ospf-interface
edit OSPF1
set mtu-ignore enable
end
end
Verification:
Verify the OSPF neighborship state again and the neighbor state should be FULL.
FGT_A # get router info ospf neighbor
OSPF process 0:
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 Full/ - 00:00:36 10.100.100.2 OSPF_TEST
3) IPsec interface MTU value:
IPsec interfaces may calculate a different MTU value after upgrading from 6.2. This change might cause an OSPF neighbor to not be established after upgrading. The workaround is to set mtu-ignore to enable the OSPF interface's configuration:
# config router ospf
# config ospf-interface
edit "ipsce-vpnx"
set mtu-ignore enable
next
end
end
