MLAG dual-homed networks: a failure acceptance worksheet

Multi-chassis link aggregation lets a downstream device form one logical LACP bundle to two physical switches. Vendors use names such as MLAG, vPC, MC-LAG and VSX. The design can remove a spanning-tree blocked access link and maintain service through a member or switch failure. It also introduces a distributed state system whose unsafe failure modes are different from an ordinary stack or single-chassis port channel.

1. Draw the failure domains before configuring

Record the two peer switches, the inter-peer link, the separate keepalive or control path, downstream LACP members, upstream routing, management paths, orphan ports, power supplies and racks. If both peers use one UPS, one fiber route or one upstream switch, that shared component remains a single failure domain.

2. Separate LACP from multi-chassis state

IEEE 802.1AX defines link aggregation and LACP behavior between systems. MLAG extends the implementation so two physical switches act as one logical LACP partner toward the downstream device. A healthy LACP bundle therefore does not prove that the two peers agree on VLANs, forwarding state, gateway behavior or failure ownership.

Collect these views from both peers and the connected device:

• LACP actor and partner system IDs.
• Member state, collecting and distributing status.
• Port speed, MTU, native VLAN and allowed VLAN list.
• MLAG domain state and peer adjacency.
• Consistency-check results and suspended interfaces.
• MAC, ARP or neighbor entries learned locally and through the peer.

3. Size the peer link for degraded traffic

Under normal symmetric forwarding, much traffic may stay local to the peer that received it. During a member, uplink or node failure, traffic can cross the peer link before reaching the surviving path. Control, synchronization, broadcast, unknown-unicast and multicast traffic may also use it.

Do not simply add all access-port speeds. Estimate real concurrent traffic classes, then validate with counters while the intended failure is active. Include CCTV multicast, storage replication, Wi-Fi controller tunnels, server east-west traffic and gateway traffic where relevant. Record both aggregate utilization and per-member utilization because a hashing imbalance can overload one link while the bundle still appears to have spare capacity.

4. Test hashing with multiple flows

Link aggregation normally selects a member using a hash of packet fields. One long TCP flow commonly remains on one member to preserve order. A two-link bundle does not make one flow twice as fast. Validate distribution with many representative source and destination combinations instead of a single speed test.

There is no universal perfect balance. The objective is to identify whether the real traffic mix creates a persistent hot member and whether the surviving capacity meets the service requirement. Capture the configured hash policy and any platform restrictions before changing it.

5. Run controlled single failures

One downstream member

Remove one member using the approved administrative method. Confirm the bundle remains up, traffic reconverges within the agreed interval, no unexpected VLANs appear and the event is alarmed. Restore the member and confirm it rejoins without excessive loss or MAC movement.

One upstream path

Disable one peer's upstream link. Confirm affected flows use the alternate route or cross the peer link as designed. Watch for a healthy LACP access bundle with a blackholed upstream path. Validate route tracking, gateway state and any vendor feature that redirects traffic.

One peer switch

Use a controlled reload or protected-power interruption approved for the test environment. Confirm the downstream partner keeps the surviving member, critical traffic continues and management alarms identify the failed node. Record packet loss, application interruption and recovery time.

One peer-link member

If the peer link is itself a bundle, remove one member and measure remaining capacity. Check that the control relationship remains healthy and no application member is suspended unexpectedly.

6. Treat peer-link loss as a special test

A peer-link failure while both switches remain alive can create split-brain risk. The independent keepalive helps each peer determine that the other is still operating. Vendor safeguards may suspend selected interfaces on one peer, preserve primary-peer forwarding or apply recovery rules. Cisco vPC and Arista MLAG documentation describe platform-specific peer-link and peer-health behavior that must be reviewed before the test.

For an approved peer-link isolation test:

1. Confirm the keepalive is healthy and independently routed.
2. Start continuous traffic through dual-homed and orphan endpoints.
3. Save peer, LACP, MAC and gateway state from both switches.
4. Isolate the peer link without removing peer power.
5. Verify which ports remain forwarding and which are suspended.
6. Check for duplicate gateway replies, MAC flapping and broadcast multiplication.
7. Restore the peer link and observe resynchronization before clearing alarms.

7. Verify orphan-port behavior

An orphan endpoint is attached to only one peer. It may be a firewall, legacy server, management appliance, recorder or building controller. During peer-link or upstream failures, the endpoint can remain physically up while losing reachability to parts of the network.

For each critical orphan, document the dependency and test:

• Reachability to local and remote VLANs.
• Default-gateway and upstream access from both failure states.
• MAC learning and movement after recovery.
• Whether the port is intentionally shut or kept active during dual-active protection.
• Whether the endpoint can be converted to a dual-homed LACP design.

8. Measure recovery and stability

Use continuous probes, representative application sessions and switch telemetry. A single ping can miss microbursts, reordering or a short broadcast loop. Record packet loss, maximum consecutive loss, session survival, peer-link utilization, MAC moves, LACP transitions and convergence timestamps.

Do not declare success at the first returned ping. Confirm that both peers reach a consistent state, all intended bundle members rejoin, counters stop increasing abnormally and traffic no longer depends on a temporary recovery path.

9. Acceptance checklist

1. Physical and logical topology diagrams match the installed network.
2. Peer link and keepalive use documented independent paths.
3. MLAG domain, peer roles and software versions are recorded.
4. LACP actor and partner identities match the design.
5. VLAN, MTU, speed and bundle settings are consistent.
6. Consistency checks show no unexplained suspended interfaces.
7. Peer-link degraded capacity and headroom are calculated.
8. Traffic hashing is tested with multiple representative flows.
9. Single-member surviving capacity meets the requirement.
10. One downstream-member failure is tested and alarmed.
11. One upstream-path failure is tested for blackholing.
12. One peer-switch failure is tested and timed.
13. One peer-link member failure is tested under load.
14. Peer-link isolation behavior matches vendor documentation.
15. Critical orphan ports are inventoried and tested.
16. MAC flapping, duplicate forwarding and loop symptoms are absent.
17. Restored links rejoin without persistent imbalance or instability.
18. Configurations, logs, counters, timings and deviations are handed over.

10. Handover package

Include the topology, rack and patch-port map, MLAG and LACP identifiers, peer-link and keepalive routes, VLAN and MTU matrix, orphan-port register, configuration backups, software versions, capacity calculation, traffic-test method, failure timeline, event logs, counter snapshots, alarms, recovery observations and approved deviations. Keep the exact vendor commands used for health checks and rollback with the operations team.

Primary technical references

• IEEE 802.1AX revision project: Link Aggregation
• Cisco Nexus 9000: Configuring virtual port channels
• Arista EOS: Multi-chassis link aggregation