Home / Notes / M-LAG Troubleshooting

NOTES · M-LAG TROUBLESHOOTING

M-LAG Faults: Split-Brain, Sync Failures and the Cases That Cause Them

Two devices acting as one is only as good as the heartbeat and the sync between them. This is the diagnostic order for M-LAG faults — DFS pairing and peer-link state, why access-side traffic loops through the peer-link, why an overloaded peer-link causes packet loss during failover, why active-standby election never completes, and the DHCP Snooping binding-table case that only shows up after the primary device fails.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Why Two Devices Acting as One Keeps Breaking the Same Way

M-LAG makes two switches look like one Eth-Trunk peer to everything downstream — which means the fault is rarely in what's downstream at all.

M-LAG exists to let a server or an upstream switch dual-home across two independent chassis without running Spanning Tree, treating the two members as if they were ports on one logical device. That illusion is exactly what makes M-LAG faults confusing: a device can show its M-LAG interface as Up while the two chassis have quietly drifted out of sync on gateway configuration, or the peer-link can be carrying every bit of traffic that a failed access port should have dropped, silently exhausting its own bandwidth. The fastest way through any of it is to verify the pairing and the peer-link state first, then match the symptom to the specific case it resembles, rather than assuming the downstream device is the one at fault.

What follows is an M-LAG topology to place the fault on, the order to verify DFS pairing and peer-link state before touching anything else, the access-side gateway-MAC case that loops traffic through the peer-link, the peer-link bandwidth-exhaustion case that shows up during failover, the missing ARP L2-proxy case that blocks active-standby election, the DHCP Snooping binding-table sync failure that only shows up after the primary device fails, five recurring root causes, and field-tested FAQ answers.

See the Pairing Before You Read a Single Interface Counter

DFS-Group, peer-link, Master and Backup roles, member ports paired one-to-one across the two chassis — everything downstream just sees one logical switch.

Every case below assumes this shape: two CloudEngine switches in the same DFS-Group, joined by a dedicated peer-link (typically an Eth-Trunk of its own), each holding half of every M-LAG member Eth-Trunk that faces a dual-homed server or an upstream network, with a heartbeat running over the peer-link to detect whether the other chassis is actually alive.

Diagram labels are kept in English for engineering clarity.

These same Device A/Device B pairs are exactly the Server Leaf pairs that dual-home hosts under a VXLAN fabric — see our VXLAN Overlay Troubleshooting note for what happens one layer above this one. The consistency-check feature is what keeps the two chassis' configuration from silently drifting apart; almost every case below traces back to either the peer-link, the heartbeat, or a piece of configuration that consistency-check either caught or missed.

Working Through State Verification, Then the Specific Case

Four different investigations, four different sets of commands — and the discipline of confirming the pairing itself before assuming any one of them applies.

Confirm DFS Pairing and Peer-Link State First

The Causation field in display dfs-group m-lag brief tells you directly why a member port isn't in the state you expect — read that before touching the downstream device.

Check display dfs-group m-lag brief on both chassis. If Causation isn't a dash, it's naming the exact reason the M-LAG member isn't fully up — not a placeholder to ignore.
Check display dfs-group peer-link to confirm the peer-link interface itself, and the heartbeat carried over it, are both Up.
Check display error-down recovery — an M-LAG member port that Error-Downed and hasn't recovered looks identical to a cable fault from the downstream device's side.
Check display eth-trunk for the M-LAG member Eth-Trunk on both chassis to confirm the same member ports are actually Up on each side, not just configured.

<DeviceA> display dfs-group m-lag brief
 M-LAG ID  Interface        Local-State  Peer-State  Causation
 1         Eth-Trunk10      up           up          -
 2         Eth-Trunk20      down         up          Peer-link fault
// Causation names the reason directly -- not a placeholder

<DeviceA> display dfs-group peer-link
 Peer-link interface : Eth-Trunk1
 State                : up
 Heartbeat            : up

<DeviceA> display error-down recovery
 Interface        Error-down reason     Recovery time left
 GigabitEthernet0/0/3  m-lag-mad          disabled
// port stuck in error-down with no recovery timer set -- will not come back on its own

Case: Access-Side Gateway MAC Mismatch Loops Traffic Through the Peer-Link

Both chassis show the M-LAG interface as Up — the mismatch is one layer deeper, in the gateway configuration itself.

Symptom: traffic forwarded through an M-LAG interface behaves abnormally — intermittent loss, or traffic that appears to loop between the two chassis over the peer-link.
Root cause: the access-side gateway configuration (for example, the VBDIF or VLANIF interface's MAC address) differs between Device A and Device B, so return traffic gets forwarded across the peer-link instead of out the correct local member port.
Enable consistency-check in strict mode so a real configuration mismatch raises an alarm instead of silently forwarding incorrectly, then compare the flagged interface's configuration side by side on both chassis.
Fix: make the gateway configuration identical on both chassis — same MAC, same VLAN/BD binding — then confirm the consistency-check alarm clears.

[DeviceA] m-lag consistency-check port-mode strict
[DeviceA] m-lag consistency-check type1 vlanif

<DeviceA> display m-lag consistency-check inconsistent-configuration
 Interface   Config Item        DeviceA           DeviceB
 Vlanif100   MAC address        5489-98aa-0001    5489-98aa-0002
// gateway MAC differs between the two chassis -- return traffic loops via peer-link

[DeviceB] interface vlanif 100
[DeviceB-Vlanif100] mac-address 5489-98aa-0001
// align the gateway MAC on both chassis

Case: An Overloaded Peer-Link Causes Persistent Packet Loss During Failover

The peer-link isn't just for heartbeat and sync traffic — during a member-port failure, it also carries every packet that would otherwise have gone out the failed local port.

Symptom: after one M-LAG member interface fails, traffic through the fabric shows continuous packet loss rather than a brief, one-time hit.
Root cause: when a local M-LAG member port is down, its share of the traffic has to cross the peer-link to reach the surviving member on the other chassis; if the peer-link's own bandwidth was sized only for heartbeat and table-sync traffic, it can't absorb that extra load.
Check display interface for the peer-link Eth-Trunk and compare the traffic rate against its configured bandwidth during the failure window.
Fix: size the peer-link for worst-case failover load, not just steady-state sync traffic — add member links to the peer-link Eth-Trunk, or move some M-LAG member traffic to reduce what a single failure would push across it.

<DeviceA> display interface Eth-Trunk1
Eth-Trunk1 current state : UP
 Last 300 seconds input rate  9.8 Gbps, output rate 9.9 Gbps
 Bandwidth utilization      : 98%
// peer-link near saturation during the failover window -- undersized for this load

[DeviceA] interface eth-trunk 1
[DeviceA-Eth-Trunk1] trunkport GigabitEthernet0/0/23
// add another member link to the peer-link trunk to absorb failover traffic

Case: DHCP Snooping Binding Table Fails to Sync Across the M-LAG Pair

This one is invisible until the primary device that built the binding table actually fails — then the backup's DHCP Snooping simply does not protect anything.

Symptom: Device A and Device B form an M-LAG pair with DHCP Snooping enabled; Device A generates the Snooping binding table as clients come online, but Device B does not build a matching table of its own.
Consequence: if Device A then fails, Device B takes over forwarding but its DHCP Snooping has no binding entries — anti-spoofing protection silently stops working exactly when the network needs it most.
Check display dhcp configuration and display dhcp snooping configuration on both chassis, including on ports that aren't M-LAG member ports — a single differing DHCP-related setting is enough to break the sync.
Check display dfs-group m-lag brief for a non-dash Causation value, and check display clock on both chassis — inconsistent configuration or unsynchronized clocks between the two M-LAG nodes are the two most common reasons the binding table doesn't replicate.
Fix: make the DHCP Snooping-related configuration identical on every port of both chassis, including non-M-LAG ports, and synchronize the clocks between the two nodes (for example, via NTP).

<DeviceA> display dhcp snooping configuration
 DHCP snooping is enabled globally
 GigabitEthernet0/0/1 : trusted
<DeviceB> display dhcp snooping configuration
 DHCP snooping is enabled globally
 GigabitEthernet0/0/1 : untrusted
// same physical role, different trust setting -- breaks binding-table sync

<DeviceA> display clock
2026-07-19 09:14:02
<DeviceB> display clock
2026-07-19 09:11:47
// clocks not synchronized -- configure NTP on both chassis

5 Root Causes That Show Up Again and Again

Once the checks above have told you which of the four investigations applies, these five account for most of what's actually wrong.

1. A Member Port Sits in Error-Down With No Recovery Timer

SYMPTOMAn M-LAG member interface stays down on one chassis while the peer chassis shows its own side as up, and the port never comes back on its own.

CAUSEThe port was placed into Error-Down (commonly by m-lag-mad, the multi-active detection mechanism) and no automatic recovery time was configured for that error-down reason, so the port waits indefinitely for manual intervention.

FIXCheck display error-down recovery for the reason and recovery-time-left; either configure an automatic recovery interval for that reason, or manually restore the interface once the underlying cause is confirmed resolved.

[DeviceA] error-down auto-recovery cause m-lag-mad interval 300

2. Access-Side Gateway Configuration Differs Between the Two Chassis

SYMPTOMTraffic through an M-LAG interface is intermittent, or appears to loop between the two chassis over the peer-link.

CAUSEThe gateway interface's MAC address (or other gateway configuration) is different on Device A and Device B, so return traffic addressed to the gateway is forwarded across the peer-link instead of straight out the correct local port.

FIXEnable consistency-check in strict mode so this class of mismatch raises an alarm, compare the flagged configuration item side by side, then make it identical on both chassis.

3. Peer-Link Bandwidth Wasn't Sized for Failover Load

SYMPTOMAfter one M-LAG member interface fails, packet loss through the fabric continues rather than recovering after a brief switchover.

CAUSEThe failed port's share of traffic now has to cross the peer-link to reach the surviving member on the other chassis; a peer-link sized only for heartbeat and table-sync traffic saturates under that extra load.

FIXCheck display interface for the peer-link's utilization during the failure window, then add member links to the peer-link Eth-Trunk or rebalance traffic so a single port failure doesn't overload it.

4. Active-Standby Election Never Completes Without ARP L2-Proxy

SYMPTOMAn M-LAG interface configured for active-standby (rather than active-active) member selection never settles on a single active port — both sides behave as if they're forwarding.

CAUSEActive-standby election relies on ARP, ND, IGMP, DHCP or MLD packets being visible across both chassis to decide which member port should be active; without arp l2-proxy enable, the election-relevant packets don't reach the peer chassis and the two sides never agree.

FIXEnable arp l2-proxy on the M-LAG interface so the election-relevant packets are visible to both chassis, then confirm a single active member port is elected.

[DeviceA] interface eth-trunk 20
[DeviceA-Eth-Trunk20] arp l2-proxy enable

5. DHCP Snooping Binding Table Doesn't Sync Across the M-LAG Pair

SYMPTOMDHCP Snooping is enabled on both M-LAG chassis, but only the device that actually processed the client's DHCP exchange builds a binding entry — the peer chassis' table stays empty for that client.

CAUSEBinding-table synchronization between the two M-LAG nodes depends on identical DHCP-related configuration on every port of both chassis (including non-M-LAG ports) and on the two chassis' clocks being synchronized; either mismatch is enough to silently break the sync.

FIXCompare display dhcp snooping configuration port by port on both chassis, check display clock for drift, and align both before assuming the feature itself is broken.

Five Questions Worth Having an Answer Ready For

Pulled straight from the field — the ones worth having an answer ready for.

How do I stop specific ports on the backup chassis from Error-Down every time the peer-link fails?

By default, when the peer-link goes down, the backup chassis puts its M-LAG member ports into Error-Down to avoid a dual-active condition — which is the safe default, but it can be more aggressive than a given deployment wants. m-lag unpaired-port suspend lets you designate specific ports that should stay up and keep forwarding even without a paired peer-link, for cases where a brief risk of duplicate forwarding is preferable to a full outage on those ports.

Does a consistency-check mismatch alarm actually affect traffic, or is it just a warning?

It depends on which type triggered it. A Type 1 inconsistency covers configuration that affects forwarding correctness (like the gateway MAC case above) — left unresolved, it can cause real traffic problems, and restarting the M-LAG primary device while a Type 1 mismatch is outstanding can trigger a dual-active event. A Type 2 inconsistency covers configuration that doesn't affect forwarding directly; it's worth fixing for consistency's sake, but it won't by itself break traffic. Check which type raised the alarm before deciding how urgently to act.

display dfs-group m-lag shows a Causation value that isn't a dash — what should I check first?

Read the Causation text itself before checking anything else — it directly names the reason (peer-link fault, DFS pairing not yet complete, a just-restarted device still synchronizing, or a configuration inconsistency blocking the member from coming fully up). Match that reason to display dfs-group peer-link and display m-lag consistency-check inconsistent-configuration rather than guessing at the downstream cabling.

The peer-link just went down, but the heartbeat still looked fine right up until it did — what happens to my M-LAG ports now?

Once the peer-link itself is confirmed down, the backup chassis assumes it may no longer be safe to keep forwarding independently and Error-Downs its M-LAG member ports by default, to avoid both chassis actively forwarding the same traffic without a way to coordinate. Any port you've explicitly excluded with m-lag unpaired-port suspend is the exception. This is why peer-link redundancy (a trunk with more than one physical member) matters as much as its bandwidth.

We found a Type 1 consistency-check mismatch and I'm about to restart the M-LAG primary device to force a resync — is that safe?

Not yet. Restarting the primary while a Type 1 mismatch is still outstanding is exactly the scenario that can trigger a dual-active (split-brain) event, because the backup may come up believing it should take over active forwarding while the primary is also still trying to. Resolve the flagged configuration mismatch first, confirm display m-lag consistency-check inconsistent-configuration comes back clean, and only then plan the restart.

Honest Limits of This Note

Honest Limits of This Note

This note is built around the Huawei CloudEngine 16800/9800/8800/6800 series V300 maintenance manual's DFS-Group M-LAG model — display dfs-group m-lag / peer-link, error-down recovery, consistency-check, and the field cases behind them, including the DHCP Snooping binding-table sync case. If your platform uses a different MC-LAG or vPC implementation, the exact commands change, but the diagnostic order — pairing state, peer-link health, then the specific traffic or sync symptom — carries over directly. It doesn't cover VXLAN-over-M-LAG dual-active gateway interactions in depth; see our VXLAN Overlay Troubleshooting note for the layer above this one.

Stuck on a specific M-LAG pair?

Tell us what display dfs-group m-lag brief and display m-lag consistency-check inconsistent-configuration show, plus which of these cases it matches, and we'll help you read it.

WhatsApp an engineer →