OSPF Adjacency Flapping Across a LAG
Two ArubaOS-CX 8320 core switches form an OSPF area 0 adjacency over a 2-member LAG (VLAN 99, /30 subnet). The LAG uses LACP active on both sides. Since a firmware upgrade on one switch, the OSPF neighbor repeatedly goes Full → Down → Full every few minutes. Interface counters show no CRC errors, but show lacp interfaces shows one member as "individual" intermittently. The LAG is also the only path between the two cores for several downstream subnets, so when OSPF drops, those subnets are unreachable for 40-60 seconds. A junior engineer proposes converting the link to a single 40G port to "remove the LAG variable."
1. Diagnose the flapping. Why would an OSPF adjacency drop when a LAG member goes individual?
Read the worked answer
The root cause is LACP member instability, not OSPF itself.
When a LAG member transitions to individual, LACP has stopped aggregating that port. The consequences cascade:
- The port-channel's effective bandwidth drops and, more importantly, the port-channel may briefly go down or renegotiate, causing the VLAN 99 SVI to lose link.
- OSPF on that interface sees the link go down, tears down the adjacency, and must re-form (Down → Init → 2-Way → ExStart → Exchange → Loading → Full). Full re-formation plus SPF takes tens of seconds - matching the 40-60s outage.
- A member going individual intermittently points to a physical or negotiation problem: a faulty DAC/optics, a speed/duplex mismatch after firmware, or an LACP timer/key mismatch between the two ends introduced by the upgrade.
Confirm by checking show lacp interfaces on both sides for matching keys, system priority, and timer (short vs long), and by reviewing interface error counters and transceiver diagnostics (show interface transceiver) on the individual member. Also check whether the firmware changed default LACP behavior or interface settings on that member.
2. Evaluate the proposal to replace the LAG with a single 40G port. What would you do instead, and how do you protect the OSPF path?
Read the worked answer
The single-40G proposal removes redundancy to hide a fault - it makes the outage worse if that one port fails, and it does not address the underlying LACP instability (which could recur on any aggregated link).
Do instead:
- Isolate the individual member: check transceiver diagnostics and swap the DAC/optic and port to confirm hardware vs. configuration. If firmware changed LACP defaults, align keys/timers/priorities on both ends.
- If the member is genuinely faulty, run on the remaining member while replacing hardware; do not abandon LAGs.
Protect the OSPF path regardless:
- Enable BFD on the OSPF interface so failures are detected in sub-second time rather than waiting for OSPF dead timers - this shortens the outage even when a member flaps.
- Tune OSPF hello/dead timers only if BFD is not available; BFD is preferred.
- Consider a second path (a direct link or a path through a downstream switch) so the two cores are not singly connected; OSPF can then reconverge without a full outage.
- Add LACP member-state alerting so an "individual" transition pages someone before OSPF drops.
Only after hardware and configuration are validated should you consider topology changes - and a redundant design, not a single link.