OSPFv3 Neighbor Stuck in ExStart After a Security Change
Two SR OS PE routers, PE1 and PE2, are connected by a 10 Gb/s link that traverses a third-party Layer 2 metro network. PE1's physical port is configured with MTU 9000; PE2's port is on an older line card with MTU 1500. OSPFv3 is enabled on both routers with a single area 0.0.0.0, interface-type point-to-point, and identical hello and dead intervals. IPv6 addresses are on the same /64. The neighbor has remained in ExStart for 25 minutes. show router ospf3 neighbor on PE1 shows state ExStart, and show router ospf3 interface "to-PE2" detail shows MTU 9000 on PE1 and 1500 on PE2. The team recently enabled IPsec AH authentication for OSPFv3 on PE1 only, intending to add PE2 the next night. No log entry reports authentication failure. They ask whether the authentication mismatch is causing the ExStart state.
1. Identify the actual cause of the ExStart state and explain why the IPsec mismatch is not the explanation.
Read the worked answer
ExStart is the master/slave negotiation phase of the OSPF database exchange. OSPFv3 Database Description packets carry the interface MTU, and the two routers must agree on the MTU for the exchange to proceed to Exchange and Loading. PE1 has MTU 9000 and PE2 has MTU 1500, so the DBD negotiation cannot complete. The neighbor stays in ExStart even though hellos are exchanged and both routers see each other.
An IPsec authentication mismatch behaves differently. OSPFv3 IPsec AH is applied at the IP layer, so a missing or wrong security association causes the receiving router to drop the hellos before OSPFv3 processes them. The symptom would normally be no neighbor, or a neighbor stuck in Init/Attempt, not ExStart. The fact that PE1 reports ExStart means authenticated or unauthenticated hellos are still being accepted enough to build a neighbor state; the MTU is the blocker.
The fix is to make the MTU consistent on the link, or to enable MTU ignore on both OSPFv3 interfaces if the platform and design allow it. Changing the line card or adjusting the port MTU is preferable to hiding the mismatch, because a 9000-byte frame can still be dropped by the metro network even if OSPF forms.
2. What show commands confirm the diagnosis, and what would you check after correcting the MTU?
Read the worked answer
On PE1, show router ospf3 neighbor shows the neighbor state and the router IDs; show router ospf3 interface "to-PE2" detail shows the local MTU and the hello/dead timers. On PE2, the same commands show its MTU and state. Because the mismatch is directional in the display but bidirectional in effect, compare both sides. Also check show router ospf3 interface for the interface type and area ID, and confirm that both interfaces are point-to-point; a broadcast-to-point-to-point mismatch can produce different but equally confusing states.
After correcting the MTU, watch the neighbor move from ExStart to Exchange, then Loading, then Full. Use show router ospf3 database and show router ospf3 routes to confirm that LSAs are exchanged and routes are installed. If the neighbor moves to Exchange but stalls, check for an inconsistent DBD or an MTU problem on a different interface. If it moves to Full but no routes appear, check area mismatches and prefix configuration.
3. How should the team roll out OSPFv3 IPsec AH on both routers without causing a second outage?
Read the worked answer
Treat the IPsec change as a separate maintenance step after the MTU is fixed and the adjacency is stable. Configure a matching IPsec AH security association on both routers, including the same SPI, algorithm, and key, before enabling enforcement on either side. If SR OS supports a key rollover or multiple security associations, stage the new key while the old key is still valid, then remove the old key after both sides have converged.
Verify with show router ospf3 interface and the IPsec statistics before and after enabling enforcement. Confirm that hellos are still received and that the neighbor remains Full. Do not enable AH on PE1 only while PE2 is unprotected; an inbound policy that requires AH will drop PE2's hellos, and the adjacency will fall. If the platform allows it, use a maintenance window and a rollback plan that restores the previous OSPFv3 configuration if the adjacency does not return to Full within the expected dead interval.