# OSPF adjacency failure modes What to compare across the two ends of a link, and the exact line of output that settles each case. Ordered roughly by how often they turn up. Read the neighbor state first. It narrows the list fast. | Neighbor state | What it means | Look at | |---|---|---| | Neighbor absent entirely | Hellos are not being accepted by one or both ends | Everything below the "hello is rejected" heading | | Stuck in INIT | One side hears the other, the other does not hear back | One-way traffic: ACL, one-sided auth, unicast/multicast filtering | | Stuck in 2-WAY | Normal on a broadcast segment between two DROTHERs | Not a fault. Check priorities before chasing it | | Stuck in EXSTART or EXCHANGE | Adjacency forms then fails to sync the database | MTU mismatch, almost always | | Stuck in LOADING | Database exchange stalls | Rare. Look for a corrupt or oversized LSA | | FULL then drops, repeatedly | Flap, not a hard fault | Interface errors, CPU, or a timer that is too aggressive | ## The one command to start with Verified against a live lab 2026-08-15. This single command per end returns almost everything the hello-rejection cases below depend on: ``` show ip ospf interface | include Internet|Timer|Network Type|authentication ``` Sample output from a real mask mismatch, R2 first and R3 second: ``` Internet Address 10.1.23.2/24, Interface ID 3, Area 0 Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Internet Address 10.1.23.3/25, Interface ID 2, Area 0 Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 10 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 ``` Three lines per end. Mask, area, network type, timers, and router ID all visible, and the absence of an authentication line rules authentication out. Reading down the two blocks, everything matches except the prefix length. That is the diagnosis, and it took two commands total. Use the per-fault sections below when the two blocks look identical and you need to go deeper. ## When the hello is rejected These are the faults where the neighbor never appears at all. Every one of them is a disagreement, so every one needs both ends. ### Timer mismatch Both ends must agree on hello and dead intervals. ``` show ip ospf interface | include Timer Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 ``` Compare the Hello and Dead numbers on each end. Any difference kills it. Note that changing the hello interval changes the dead interval automatically unless it was set explicitly, so a single command produces two differences. **Fix:** match them, usually by removing the non-default one: `no ip ospf hello-interval`. ### Subnet mask mismatch On broadcast segments the hello carries the network mask. ``` show ip ospf interface | include Internet Internet Address 10.1.23.3/25, Interface ID 2, Area 0 ``` Compare the prefix length on each end. The addresses can look nearly identical and still be on different networks. This is the one people misdiagnose as a timer problem, because the symptom is identical and the timers are the first thing everyone checks. **Fix:** correct whichever end is wrong. Check which one matches the rest of the design before assuming. ### Area mismatch Same output line as the mask check: ``` Internet Address 10.1.23.3/24, Interface ID 2, Area 0 ``` Both ends must be in the same area. A router can be in several areas; the *interfaces* facing each other must agree. ### Authentication mismatch Either type or key. ``` show ip ospf interface | include authentication|digest Cryptographic authentication enabled ``` Empty output on one end and a line on the other means one-sided authentication. Both ends configured but with different keys shows the same symptom, so compare the key IDs too: ``` show running-config interface | include message-digest ``` Note the log lies here. It reports "Dead timer expired", which is true and useless: the timer expired because the hellos were being discarded. Do not stop at the log. **Fix:** either add the matching key or remove the authentication. Which one is correct is a policy question, not a CLI question. Say so. ### Network type mismatch ``` show ip ospf interface | include Network Type Network Type BROADCAST, Cost: 10 ``` Broadcast facing point-to-point sometimes forms and sometimes does not, depending on the pairing, and the failures are confusing. Also check the hello timers, which change with the network type default. ### Duplicate router ID Two routers claiming the same ID produce adjacency churn and log noise rather than a clean down state. ``` show ip ospf | include Router ID show logging | include DUPLICATE|ADJCHG ``` ### The interface itself Before any protocol reasoning, confirm the link is actually up and OSPF is actually enabled on it: ``` show ip interface brief show ip ospf interface brief ``` An interface missing from `show ip ospf interface brief` is not running OSPF at all: either the `network` statement does not cover its address, or `ip ospf area ` is absent, or someone set `passive-interface`. A passive interface stays in the routing process and never forms an adjacency, which reads as a protocol fault if you do not check for it. ``` show running-config | section router ospf ``` ## When the adjacency forms then stalls ### MTU mismatch (EXSTART / EXCHANGE) The classic. Database description packets are dropped because the two ends disagree on how big a packet may be. ``` show interface | include MTU show ip ospf interface | include MTU ``` **Fix:** match the MTU. `ip ospf mtu-ignore` makes the symptom disappear without fixing the mismatch; if you use it, say plainly that it is a workaround, because a real MTU mismatch will bite something else later. ## Ruling things out is the job State what you eliminated and how, not just what you found. "Timers match on both ends, addresses are both /24 in area 0, no authentication on either side, MTU 1500 both ends, so the remaining candidate is X" is a real diagnosis. "It is probably the MTU" is a guess wearing a diagnosis costume.