I85PREP
⌘ K
Aruba Comware Advanced study materials
Aruba Comware Advanced study resources

OSPF Neighbor Flap After IRF Merge

Aruba Comware Advanced · Put your knowledge to work in context.

All case studies

OSPF Neighbor Flap After IRF Merge

A two-member IRF stack (Master 1, Standby 2) runs OSPF area 0 toward an upstream router over a 2x10G BAGG. During a firmware upgrade, member 2 reboots and rejoins; immediately OSPF adjacency with the upstream router drops and re-forms every ~40 seconds. display ospf peer shows the neighbor cycling Full -> Down. display irf topology shows the stack is stable. The BAGG uses LACP active with a 30s timeout. OSPF hello 10, dead 40. Interface cost on the BAGG is 10. The upstream router's logs show 'dead timer expired'. The stack's member 2 has the higher member ID and was previously the standby. Traffic is asymmetric: return path uses member 2's links.

1. Diagnose the most likely root cause of the OSPF flap and justify why IRF stability alone does not rule it out.

Read the worked answer

Root cause hypothesis: LACP forwarding-state churn on the BAGG after member 2 rejoins causes brief loss of hellos on the aggregate, so the upstream router's 40s dead timer expires. IRF topology being 'stable' only means the stack fabric is up; it says nothing about per-link LACP aggregation state or hash distribution.

Reasoning:

  • Hello 10 / dead 40 means four missed hellos kills the adjacency. A 30s LACP timeout with a rebooting member can produce a window where member 2's links are 'selected' but not forwarding, and the upstream's return path (asymmetric) is on those links.
  • If the upstream router sends hellos back over member 2's links while those links are still negotiating, hellos are dropped -> dead timer expires -> Full->Down->Full cycle.
  • The ~40s cycle matches the dead interval, not a config mismatch (which would stay Down).

Next checks: display link-aggregation verbose for selected/unselected and LACP state per member; display ospf interface for DR/BDR and timers; capture hellos on member 2 links during the window.

2. Recommend a remediation sequence that restores stability without changing OSPF timers, and state the trade-off.

Read the worked answer

Sequence:

  1. Pin the OSPF-facing BAGG to a single member during the upgrade window (or use link-aggregation selected-port maximum 1 temporarily) so hellos always traverse the same member.
  2. Ensure LACP is active on both sides and set a longer LACP timeout (long/90s) on the member-2 links to tolerate the rejoin.
  3. Verify asymmetric routing: if return traffic must use member 2, confirm member 2's links are forwarding before declaring the upgrade complete; consider making the return path symmetric via cost or a dedicated link.
  4. Only after LACP is stable, re-enable full aggregation.

Trade-off: Pinning to one member removes redundancy and halves the 20G aggregate during the window; acceptable for a maintenance window but not as a permanent state. Changing LACP timeout increases failure-detection latency, so a real link failure takes longer to converge. Avoid masking the problem by raising OSPF dead interval - that hides the LACP defect and slows all future convergence.