Aruba ACSP: The Backup Link That Never Came Up

The Backup Link That Never Came Up

An 8360 at HQ is the ABR between area 0 (core) and area 1 (branches). One branch 6300 has two uplinks in area 1: primary 1G fiber (cost 10) and a backup LTE path through a carrier CPE handing off Ethernet with a 1400-byte MTU (cost 100). Both interfaces are /30 and up/up, default timers, normal (non-stub) area. The fiber neighbor reaches FULL; the LTE neighbor has sat in EXSTART for three days. Last week the fiber was cut and the branch lost all HQ connectivity for 40 minutes even though the LTE interface was up. The branch also redistributes a static default toward the LTE CPE. OSPF router IDs are derived from loopbacks.

1. Why is the LTE neighbor stuck in EXSTART, and what fix would you apply?

Read the worked answer

EXSTART/EXCHANGE stalls are almost always a DBD exchange problem.

In EXSTART the routers negotiate a master/slave relationship and a starting sequence number, then exchange database descriptions. If the DBD packets are larger than the path MTU, they are dropped silently, the sequence never advances, and the adjacency hangs in EXSTART or EXCHANGE indefinitely. The symptom set here fits: the LTE interface is up, hellos are exchanged (so it is not a reachability or authentication problem), and only the large DBDs fail because the CPE path is 1400 bytes while the 6300 interface defaults to 1500.

Confirm before changing: show ip ospf neighbors for state and retransmit/DbSummary counters, show ip interface for MTU on both ends, and a DF-bit ping at 1500 versus 1400 bytes.

Fix:

Set ip mtu 1400 on the 6300 LTE interface so the OSPF MTU check and the actual link agree, and clamp transit TCP with ip tcp adjust-mss (about 1360) so user traffic does not blackhole on large packets either.
ip ospf mtu-ignore also brings the adjacency up, but it only disables the check. Full-size LSAs and user packets over 1400 still drop silently, converting a visible control-plane symptom into an invisible data-plane one.
Separately confirm router IDs are unique; a duplicate ID produces a similar stall and is ruled out here by loopback-derived IDs.

2. After the adjacency forms, how would you prove the failover path actually works, and what would you tell management about the 40-minute outage?

Read the worked answer

Prove it with a controlled test, not by reading config.

With both neighbors FULL, show ip route 10.20.0.0/24 (or the relevant prefix) should show the fiber next hop and cost 10. Note the exact metric and next hop.
In a window, administratively shut the fiber interface. Confirm the LTE neighbor stays FULL, the route reappears with cost 100, and a traceroute from HQ to a branch host follows the LTE path.
Time the reconvergence. Default dead interval is 40 seconds, so a few seconds of loss plus the dead timer is expected - not 40 minutes.
Restore the fiber and confirm the route prefers cost 10 again without flapping.

Message to management: the 40 minutes was not slow OSPF convergence. OSPF never had a working backup adjacency, so when the fiber failed there was no alternate path at all and the branch waited for a human. Default timers cost about 40 seconds; the remaining 39 minutes were detection and response.

The corrective actions are the MTU fix, the proof test above, and a monitoring alert on any OSPF neighbor not FULL for more than five minutes, so a silent stuck adjacency never ages for three days again.

3. Should BFD be added, and how do you weigh that against other options?

Read the worked answer

BFD is the right second step, but it must be tuned for the LTE link.

BFD on the fiber gives sub-second detection where the path is clean, which is exactly where fast failover matters.
On LTE, latency and jitter are high and variable. Aggressive timers (for example 3 x 100 ms) will declare false failures during congestion and cause flapping, which is worse than a slow failover. Use a longer interval and multiplier on that neighbor, or disable echo mode, so BFD only fires on genuine loss.
BFD adds a control-plane dependency: if the CPU is loaded or the neighbor is restarted, the session can drop and take OSPF down unnecessarily. Verify with show bfd or equivalent neighbor detail after enabling, and test with the shutdown exercise above.

Alternatives and how they compare:

Floating static plus an IP SLA style probe can replace the LTE OSPF session entirely, but you lose dynamic redistribution and topology information, and you add a second failure-detection mechanism.
Tuning OSPF hello/dead timers is simpler but burns CPU on every link and is not recommended on a jittery carrier path.

The ordering is: fix the MTU, prove the failover, then add BFD on the fiber and a conservatively tuned BFD on LTE.