Troubleshooting OSPF Neighbor Stuck in INIT State

[MD Irshad Ansari]

Hi Cisco Community,

I faced a situation where OSPF neighbors were stuck in INIT state and not forming fully. Usual checks like hello/dead timer mismatches or interface types can cause this.

My questions are:

1. What are the first things you check when OSPF neighbors get stuck?
2. Do you prefer using broadcast or point-to-point network types in enterprise links?
3. Any common mistakes you’ve seen that trigger OSPF adjacency problems?

Thanks

[Giuseppe Larosa]

Hello @MD Irshad Ansari ,

the best tool for troubleshooting OSPF neighborships issues is:

debug ip ospf adj

1)  In addition to checking the OSPF timers it is important to verify that there is a shared IP subnet, unique IP address for each interface/device and that these IP addresses are associated to primary IP addresses ( OSPF neighorships on secondary IP addresses are not supported).   Then comes Area ID and Area Type that must match also. If used also authentication method and keys and passwords have to match

2)  if you are sure the link is between only two devices it is better to use ip ospf network point-to-point to avoid DR/BDR election and creation of a Network type 2 LSA. This is considered best practice now.

3) Addresses that are not in the same subnet or a mismatch in network mask/prefix length. There are some special cases for example when using an EoMPLS service where multicast is not supported in that case changing network type and using neighbor commands under router ospf is a workaround. In some cases a mismatch in network type does not block the OSPF adjacency but then LSAs from neighbor are not installed in IP routing table

Hope to help

Giuseppe

[Joseph W. Doherty]

2) if you are sure the link is between only two devices it is better to use ip ospf network point-to-point to avoid DR/BDR election and creation of a Network type 2 LSA. This is considered best practice now.

Laugh, so I've been ahead of the curve, for decades, if it's only now considered a best practice.

Hmm, might explain another poster being so surprised for my suggesting using OSPF p2p even on Ethernet when it's only a logical p2p.

You wouldn't happen to have a reference to it being so recommended as a best practice?  (It could be useful, when needed, to show that it's not just I who thinks it's a worthwhile approach.)

[balaji.bandi]

I cross-check and compare values between the peers.

Check the troubleshooting document.

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html#toc-hId-356727834

https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13702-7.html#intro

Do you prefer using broadcast or point-to-point network types in enterprise links?

Broadcast - I use LAN with Multiple Routers - DR and BDR

P2P Two directly connected routers (only one neighbour)

It all depends on the use case.

Any common mistakes you’ve seen that trigger OSPF adjacency problems?

First, I see a misconfiguration, and the rest need to look above at the troubleshooting guides.

[paul driver]

Hello

• ospf network types 
• any access-list prevent ospf hellos 224.0.0.5 ( ie: encapsulation failure)
•  L2 issues in between the ospf rtrs resulting in loss of hellos
• Authentication enabled (maybe just on one side either at process or interface level)

sh ip access-list
debug ip ospf hello
debug ip ospf adj
access-list 100 permit ip host  x.x.x.x host 224.0.0.5
debug ip packet 100 detail

[srimal99]

In addition to above mention points you may check the MTU sizes too. As mention above debug comes handy.