VSX Pair Recovering From an Uplink Failure
Two Aruba CX 8325 switches form a VSX pair (SW1 primary, SW2 secondary) at a distribution layer. Each has a 2x100G ISL and a 2x40G MC-LAG uplink to a pair of core routers running OSPF. The access layer is dual-homed into the VSX pair with active-active MC-LAGs. During a maintenance window, the entire ISL bundle on SW1 is accidentally shut down for 90 seconds while the inter-switch keepalive (over an out-of-band management path) stays up. Observers report that access hosts connected to SW2 lost their default gateway for roughly 20 seconds, then recovered. After the ISL is restored, the network team notices that some flows take a suboptimal path through the core and that OSPF adjacencies on SW1 briefly flapped. The core routers run default OSPF timers.
1. Explain why access hosts on SW2 lost their gateway, and what VSX feature and timer determine whether the secondary keeps forwarding during an ISL outage.
Read the worked answer
When the ISL goes down but the keepalive is still up, each VSX peer can no longer confirm the other is alive over the data path. The secondary (SW2) must decide whether to keep its MC-LAG member ports forwarding. The relevant mechanism is **VSX split-brain protection with the server-role / vsx-sync and the keepalive plus the split-detect behavior governed by the vsx split-recovery timer - more precisely, the secondary stays forwarding only while it continues to receive keepalives.
Key reasoning:
- If keepalives continue, the secondary knows the primary is alive and keeps forwarding (no gateway loss).
- If keepalives are lost too (true split-brain), the secondary disables its VSX member ports after the configured split-recovery / keepalive timeout to prevent duplicate gateway MAC/IP and asymmetric forwarding.
- The observed ~20 s outage means the keepalive path was disturbed (or the keepalive timeout was short) and the secondary briefly entered split-brain protection, disabling its MC-LAG ports until the ISL came back.
Judgement: verify keepalive is on a truly independent path with a timeout longer than the expected ISL maintenance, and confirm which side is primary so the surviving side retains forwarding.
2. After ISL restoration, why might flows take a suboptimal path and OSPF adjacencies flap on SW1? What would you check and change?
Read the worked answer
Two interacting effects:
OSPF flap on SW1: When the ISL dropped, SW1's MC-LAG uplinks and the VSX topology changed, which can cause the OSPF interface/adjacency on SW1 to reset (interface down/up, or the router-id/DR election churn). With default timers (10 s hello / 40 s dead), a brief interface bounce produces a full adjacency reset and SPF run.
Suboptimal path: After recovery, the MC-LAG hashing and OSPF cost may leave some flows pinned to the core router that is not the closest exit. Because MC-LAG is active-active, the return path can differ from the forward path, and OSPF will only re-optimize on the next SPF event.
Checks and changes:
- Confirm the ISL came back cleanly (
show vsx status,show vsx brief,show lacp aggregates). - Verify keepalive health and that split-brain did not persist.
- Consider OSPF BFD or tuned hello/dead timers so a sub-second blip does not tear down the adjacency.
- Review OSPF cost/bandwidth on the 40G uplinks so both core exits are symmetric; confirm ECMP is actually installed (
show ip ospf route). - Validate that MC-LAG hash (L3/L4) is consistent so forward/reverse flows select the same egress.