HPE Aruba Switching Expert (Written, HPE7-A06): OSPF Neighbor Stuck in EXSTART Across a VSX MC-LAG

OSPF Neighbor Stuck in EXSTART Across a VSX MC-LAG

A pair of Aruba CX 8360 switches (VSX) connects to a pair of core routers via MC-LAG. OSPF is configured on the VSX pair toward the core. After a change window, one OSPF adjacency on SW1 is stuck in EXSTART/EXCHANGE while the other side is FULL. The core routers report the same. MTU is 9000 on the VSX pair and 1500 on the core routers. The VSX pair uses ip mtu 9000 on the uplink SVIs, and the core routers use default 1500. No authentication mismatch is configured. show ip ospf neighbor on SW1 shows the neighbor in EXSTART with a lower router-id than SW1.

1. What is the most likely root cause of the EXSTART state, and how does MTU mismatch produce this specific symptom?

Read the worked answer

The most likely root cause is an MTU mismatch (9000 on the VSX SVIs vs 1500 on the core routers).

Why EXSTART specifically:

OSPF progresses INIT -> 2-WAY -> EXSTART -> EXCHANGE -> LOADING -> FULL.
In EXSTART, the routers exchange DBD (Database Description) packets to elect master/slave and agree on the initial sequence. DBD packets are small, but the MTU is carried in the DBD and, more importantly, once the exchange begins, larger DBD/LSU packets can exceed the path MTU.
With a 9000 MTU on one side and 1500 on the other, the larger packets are dropped silently (no fragmentation for OSPF), so the exchange never completes and the adjacency sticks in EXSTART/EXCHANGE.
The router-id detail (neighbor lower than SW1) is consistent with SW1 being master, but does not change the MTU diagnosis.

Judgement: EXSTART/EXCHANGE stuck with no auth mismatch and a known MTU delta is almost always MTU. Verify with show ip ospf interface and show interface MTU on both sides.

2. What would you check to confirm, and what is the correct fix given the VSX design?

Read the worked answer

Confirmation checks:

show ip ospf interface <vlan> on SW1/SW2 and the core routers - compare MTU values.
show interface <svi> - confirm ip mtu vs physical MTU.
show ip ospf neighbor - confirm state and that only the mismatched side is stuck.
Packet capture or show ip ospf statistics for DBD retransmissions/drops.
Confirm no ip ospf mtu-ignore is set (if it were, the symptom would differ).

Correct fix (choose one, consistently):

Preferred: Set the core routers and VSX SVIs to the same MTU - either 1500 everywhere (simplest, matches core) or 9000 everywhere if the core supports jumbo. Because the core is 1500, set the VSX SVIs to 1500 on the OSPF-facing interfaces.
If jumbo is required on the VSX side for other traffic, isolate OSPF to a dedicated SVI/subinterface at 1500.
As a temporary mitigation only, ip ospf mtu-ignore on both sides - but this hides the real problem and is not recommended as a permanent fix.

VSX-specific note: Apply the MTU change consistently on both VSX peers and confirm the MC-LAG member links and SVIs match, so the adjacency does not flap when the secondary takes over. After the change, clear the OSPF process (clear ip ospf process) and confirm FULL on both peers.