Troubleshooting OSPF Adjacency Issues - Part 2
Are
you not seeing any output or neighbors under "Show ip ospf neighbors"
command? This blog guides you in Troubleshooting OSPF Adjacency Issues -
Part 2.
If OSPF neighborship is stuck in ATTEMPT State. Attempt state is seen when the OSPF neighborship is configured b/w two routers connected via a Frame-Relay (NBMA) type of link. In NBMA type of network, OSPF neighborship is configured manually using command "neighbor x.x.x.x" under OSPF router config mode. The possible cause for neighborship to not come up are :
- Frame-Relay PVC is down due to the wrong configuration.
- Neighbor statement configured incorrectly i.e. with a wrong IP address of the neighbor.
If OSPF neighborship is stuck in INIT state, the possible causes are(few are also discussed in Troubleshooting OSPF Adjacency Issues - Part 1):
- Authentication issue b/w peers
- OSPF Hellos are blocked using the ACL on either side or due to some issue at L2 level i.e. Hellos not reaching the other side.
- 'Broadcast' keyword is missing on either/both sides, while you establish the frame-relay map/dialer map statement when you configure the PVC over FR links.
If OSPF neighborship is stuck TWO-WAY State, the possible reasons are the neighbors are configured with "priority 0". DR/BDRs cannot be elected if the neighbors are configured with priority 0 (IP OSPF priority 0 or neighbor x.x.x.x priority 0 configured at both ends in NBMA setup) command and remain stuck in Two-Way state. Remove the "priority 0" command from the interface level or router config level fix the problem.
If OSPF neighborship is stuck in EXSTART State, there will be issues in the Master/Slave election b/w the peers. The possible reason is:
- IP MTU (L3) mismatch b/w OSPF peers.
- Same Router-ID configured on both peers.
Use "debug ip ospf adj" to figure out MTU mismatch issues. You can also use the command "show ip int f0/0 | i MTU"
If OSPF neighborship remains stuck in EXCHANGE State, the possible reason is:
- L2 MTU issue b/w peers.
- Unicast ping not working b/w the peers due to a blocking ACL.
- Unicast ping not working b/w the peers due to incorrect NAT ACL.
Below are more details:
Issue pinging the OSPF peer above a certain MTU size (L2 MTU). You can check the L2 MTU using the "show interface f0/0 | i MTU" command. The correct MTU can be figured out by extended ping command with DF bit set by trying multiple MTU sizes. Once you figured out the maximum supported MTU on the link, configure the same L2 MTU at both ends of the interfaces. The MTU issue could be due to MTU support at L2 provider devices which can be figured out using extend ping and DF bit.
The OSPF exchange DBD packets in Exchange state using Unicast communication. If you are not able to ping between two peers, the peers could remain stuck in the Exchange state. Check if any ACL is configured on any of the peers that are blocking the unicast ping communication. Use 'debug ip icmp' or debug ip packet detail 121 (ACL number)).
Unicast communication can also be blocked if a NAT is configured on any of the peers that are translating the packets due to which unicast ping is not working.
If OSPF peers are stuck in LOADING State, the possible causes are :
- Mismatch in L2 Interface MTU.
- Corrupted link-state request packet. Which could lead to re-transmissions? (use 'debug ip ospf adj')
LSU packets can get corrupted due to L2 issues (faulty LAN cable/switch or switch/hub/port/transceiver) on the link or any L2 device connected between two peers. This could corrupt the LSU packet making difference in Checksum of OSPF packet header. The peers will drop the OSPF LSU due mismatch in the checksum, leading to frequent transmissions of LSU packets. Neighbors remain stuck in the Loading state unless the LSUs are successfully exchanged between two peers.
