LAG Split: Why It Happens and How to Fix It

1. A Single Member Link Drops—The Most Common Cause

The most frequent reason a LAG splits is basic: one of the member links goes down. Not the whole bundle, just one cable or port. What's actually happening here is that the LAG protocol—LACP or static—sees the link state change on one end and assumes the other side is still trying to send traffic over that dead path. The switch or server then removes that link from the bundle, but the other side might not get the memo fast enough, leaving the group in a split-brain state where each side thinks it's in control of a different set of links.

Here's the fix that works 90% of the time:

1. Check the physical layer first. Look at the port LEDs on both ends. If one is dark or blinking amber, that's your culprit. Reseat the cable. Swap it with a known-good cable. Test the patch panel if there's one in between.
2. Run show lacp counters (Cisco) or show lldp neighbors to see if the neighbor is even reachable. If you see LACPDUs dropped or no neighbor info, the link is flapping or dead.
3. If the link is up but the LAG is still split, you might have a duplex mismatch. Force both ends to full duplex and 1000 or 10000—don't rely on autonegotiation across different vendors. I've seen this cause split LAGs on HP ProCurve to Cisco stacks more times than I'd like to admit.

The reason step 3 works is that LACP uses a state machine that expects consistent link parameters. If one side sees half-duplex and the other sees full, the LACP negotiation fails silently, and the link gets excluded from the bundle even though it's physically connected.

2. LACP Configuration Mismatch—The Silent Killer

This one is trickier because both links might be up, but the LAG still splits. The root cause is almost always a mismatch in LACP parameters between the two ends. The most common offenders:

• Mode mismatch: One side is set to active, the other to passive or on (static). If one side is passive, it won't send LACPDUs, so the passive side never hears back and never forms the LAG. Fix: set both sides to active or one to active and the other to passive—never static on one side and LACP on the other unless you know exactly what you're doing.
• Timeout mismatch: LACP has short and long timeouts. Short (1 second) is used for fast failover, long (30 seconds) for stability. If one side is set to short and the other to long, the side with the short timeout will keep dropping the link because it doesn't get LACPDUs fast enough. Run show lacp internal and check the timeout column—make them match.
• Key mismatch: LACP uses a system key and port key to identify which ports belong to which LAG. If you copy a config from one switch to another without changing the keys, you'll get a split. The fix is to delete the LAG and re-create it with unique keys per event.

A real-world scenario I debugged: a VMware host connected to a Cisco switch with a LAG of four 10GbE links. The host was set to active/active (not LACP), and the switch was set to active LACP. The switch saw LACPDUs from the host? No, because the host wasn't sending any. The switch waited, then dropped all but one link from the bundle. The fix was setting the host side to active LACP as well. Traffic resumed in under a second.

3. Duplicate System ID or MAC Conflict

Less common but maddening when it happens. Every LACP system has a system ID (usually derived from the switch's MAC address) and a system priority. If two switches in the same broadcast domain share the same system ID—because someone cloned a config or the MAC-based ID isn't unique—the LACP negotiation breaks. What's actually happening is that each switch thinks it's talking to itself, so it rejects the partner's LACPDUs and the group stays down.

How to spot it:

• show lacp neighbor shows the same system ID on both sides, but with different port roles.
• You see LAG is down, partner information is invalid in logs.
• No traffic passes even though all links are up and the config looks right.

Fix it by changing the system priority on one of the switches. On Cisco: lacp system-priority 32768—make it lower (higher priority) on the primary switch. On Juniper: set lacp system-priority 127. The reason this works is that LACP uses the system priority as a tiebreaker. When both sides have the same system ID, the lower priority wins, and the higher priority switch accepts the other as the partner. If that doesn't help, change the system ID explicitly—on some platforms you can set a MAC address for the LAG system ID. Only do this if you're sure the MAC is unique.

Quick-Reference Summary Table

Remember: a LAG split is almost never a single root cause—it's a negotiation failure between two ends that don't agree on the parameters. Always check both sides of every link. And don't forget to run clear lacp counters after making changes—old counters can mislead you.