MLAG Host Dual-Homing on a Leaf Pair
A two-tier leaf-spine fabric uses MLAG on every leaf pair. A storage cluster of 24 nodes is dual-homed to leaf-01 and leaf-02, which are MLAG peers with a peer-link on Ethernet49/50 and a peer-keepalive over a routed management path. After a leaf-02 reload, operators notice the 24 storage nodes re-ARPed and saw 6-9 seconds of packet loss. show mlag on leaf-01 reports the peer as Active but the peer-link as down during the window. The team wants to know whether to widen the peer-keepalive heartbeat, move keepalive to a dedicated link, or change something else. Traffic is active/active; STP is not in the forwarding path for these hosts.
1. During the reload, why did the dual-homed storage nodes lose forwarding even though leaf-01 stayed up and its peer relationship eventually recovered?
Read the worked answer
The loss is explained by MLAG's failure handling, not by a single keepalive timer. When leaf-02 reloads, the peer-link drops. With the peer-link down, the surviving peer (leaf-01) must not keep forwarding for ports that were active on the failed peer, because the two peers can no longer coordinate MAC and ARP state. EOS therefore places the MLAG ports in an error-disabled or inactive state (or restricts them) until the peer-link is restored. That is the 6-9 seconds: it is the time for leaf-02 to boot, bring up the peer-link, and re-synchronize MLAG state, not the keepalive interval. Widening the heartbeat does not shorten this window, and moving keepalive to a dedicated link only changes the detection path for a peer that is alive but unreachable.
Key judgement: the observed peer-link down during the window is the causal signal. The fix is to reduce peer-link recovery time (faster boot, pre-provisioned config, port-fast on peer-link where appropriate) and to design host dual-homing so a single leaf reboot does not strand both uplinks. Keepalive tuning is not the lever here.
2. The team proposes putting the peer-keepalive on a dedicated 1G link between the two leaves. Evaluate whether this addresses the observed symptom and state what it does and does not fix.
Read the worked answer
It does not address the observed symptom. The symptom is tied to the peer-link being down while leaf-02 reloads; the keepalive link is a liveness check that prevents a split-brain when the peer-link fails but the peer is still alive. A dedicated keepalive link improves detection of a silent peer-link failure (for example, a bad optic or a link that stays up but drops traffic), which is a real risk on a shared peer-link. It does not accelerate leaf-02's boot or MLAG resynchronization, so the 6-9 second outage persists.
What it fixes: split-brain risk and false-positive peer-down detection when the peer-link is impaired but the peer is healthy. What it does not fix: reboot recovery time, MAC/ARP re-learning, and the fact that a dual-homed host loses both paths when one leaf is down and the peer-link is not yet up. A better combined plan is a dedicated keepalive plus reducing leaf boot time and validating that hosts have a fast reconvergence path (for example, LACP with fast timers and a second independent leaf pair for critical storage).
3. A junior engineer suggests disabling MLAG on the storage leaves and using active/standby bonding with STP. Give a reasoned recommendation.
Read the worked answer
Reject it for this design. Active/standby bonding reintroduces STP as the convergence mechanism, which is slower and less predictable than MLAG's active/active forwarding, and it wastes half the uplink capacity on 24 storage nodes. It also does not eliminate the failure window; it moves it to STP reconvergence, which is typically longer than MLAG resync.
A defensible alternative is to keep MLAG but harden it: dedicated keepalive, faster boot, and LACP fast timers on the host bonds. If the storage SLA truly cannot tolerate a single-leaf reboot, the architectural answer is to dual-home each node to two independent leaf pairs (or use a routed/multipath host design), not to fall back to STP. The judgement is to fix the recovery path and the topology, not to trade a known short window for a longer, less deterministic one.