ExStart Stall and Silent Hellos on a Shared Metro VLAN
Three Nokia SR OS routers share VLAN 100 on a metro Ethernet switch: R1 (10.10.0.1/29), R2 (10.10.0.2/29) and R3 (10.10.0.3/29). All three sit in area 0.0.0.1 with hello 10, dead 40 and no authentication. R1 and R2 reach Full within seconds, but the R1-R3 and R2-R3 pairs have been stuck in ExStart for 40 minutes, and show router ospf neighbor shows the DBD sequence numbers never advancing. R1's VLAN 100 interface was set to MTU 9000 during a storage migration last month; R2 and R3 were left at 1500. Separately, R2 was recently rebuilt from an old configuration template and its OSPF interface still carries hello 30 / dead 120. R2 never appears in the neighbor tables of R1 or R3 at all, not even in Init. A colleague has proposed converting all three interfaces to point-to-point to remove DR election from the picture.
1. Why are R1 and R3 stuck specifically in ExStart rather than Exchange or Full, and what is the correct fix?
Read the worked answer
ExStart is reached only after a successful hello exchange, so area ID, hello/dead timers and authentication are all correct on that pair; the failure is inside the database description exchange. The DBD header carries the interface MTU, and RFC 2328 requires both sides to agree. R3 receives R1's DBD, compares 9000 against its own 1500, discards the packet, and R1 retransmits the same initial DBD forever. The state machine therefore never advances to Exchange, and because hellos keep arriving the neighbor never ages out - which is exactly the ExStart-forever signature. This also rules out filtering or an area mismatch: packets are flowing both ways. Check show router ospf interface detail on both sides for the interface MTU, then the VLAN SAP MTU and the metro switch jumbo configuration, since an IP MTU mismatch can also be introduced below OSPF. Make the MTU identical end to end; use 1500 unless jumbo is verified on every device in the path. OSPF does not renegotiate after the change, so reset the adjacency by bouncing the interface or restarting the OSPF process, then confirm Full.
2. R2 never appears in the neighbor tables at all. Explain the symptom and the remedy, and state why it differs from the R1-R3 case.
Read the worked answer
R2's interface still carries hello 30 / dead 120 from the old template. Hello validation compares the hello interval and the router dead interval carried in the received hello against the local values; a mismatch causes the packet to be discarded before any neighbor state is created. That is why R2 produces no neighbor entry at all, while the MTU fault produces a neighbor that is visible but frozen in ExStart - the two faults look similar on a status page but are distinguishable by whether anything appears in the neighbor table. Two traps are worth stating: the dead interval must be identical, not merely longer than the peer's, and both values must match in both directions. Verify with show router ospf interface on all three routers, then correct R2 to 10/40 to match the segment standard; the adjacency forms without touching R1 or R3. Note that a nonstandard timer only breaks the router that has it, but if the segment standard itself changes, all routers must change inside the same window.
3. Evaluate the proposal to convert all three VLAN 100 interfaces to point-to-point.
Read the worked answer
Reject it as stated. Point-to-point over Ethernet is supported on SR OS and is a good design when the subnet has exactly one peer: it removes DR/BDR election and the type 2 network LSA, and the link is advertised as a point-to-point link in the router LSA. On VLAN 100 with three routers that model breaks, because a point-to-point interface assumes a single neighbor and describes the subnet as a stub link with a host route to that peer; one router cannot correctly represent reachability to the other two on the same subnet, and next-hop resolution becomes ambiguous. It also fixes neither fault found here: the MTU mismatch would still block the DBD exchange, and the timer mismatch would still discard hellos before the neighbor table is populated. If DR churn is a real concern, the targeted remedies are OSPF priority 0 on routers that must never become DR, leaving two viable candidates, or a redesign in which each access router gets its own dedicated point-to-point VLAN to the hub.