LAG split detected: fix it before your network falls apart

Quick answer for advanced users

Disable and re-enable LACP on both ends, or manually remove and re-add the member ports in the LAG. This forcibly re-synchronizes the group. If that doesn't work, check that both sides have the same port speeds and duplex settings.

Why this happens and what split detection really means

You've got a switch or a server that's using link aggregation—usually LACP (802.3ad). You bundle two or four ports into one bigger pipe. Nice, right? But sometimes the switch or the other end loses sync. One side thinks the port's still in the group, the other side thinks it's gone. That's a split. Traffic starts going to the wrong ports or just drops dead. Last month I had a client whose whole SAN slowed to a crawl because a LAG split on a Dell PowerConnect switch. Their backup jobs kept failing silently for two days before someone noticed.

This happens most often when someone replaces a cable, swaps a switch, or there's a brief power glitch. The LACP negotiation times out on one side but not the other. The switch doesn't know the link is down until the link state changes, but the other side still sees it as up. So you get half the traffic going through one port and half going nowhere.

Fix steps — do these in order, don't skip

Step 1: Check both ends for the same LAG config

Log into your switch and the device on the other end. Look at the LAG number, the ports assigned, and whether they're in active or passive mode. Both sides need to be in active mode, or one active and one passive. If both are passive, they'll never start talking.

Step 2: Re-sync the LAG by disabling and re-enabling LACP

On the switch side, go to the LAG interface and run:

interface port-channel 1
no lacp
lacp

Or if you're on a Cisco-style CLI:

interface port-channel 1
shutdown
no shutdown

Wait 10 seconds, then check the status with:

show lacp neighbor

If you see State: Active on both sides, you're good.

Step 3: Remove and re-add the member ports

If the LACP restart didn't work, take the ports out of the LAG one by one:

interface gigabitethernet 1/0/1
no channel-group 1 mode active

Then add them back:

interface gigabitethernet 1/0/1
channel-group 1 mode active

Do this for all ports in the group. It forces a fresh negotiation.

Step 4: Verify physical layer — cable and port settings

I can't tell you how many times a split was caused by one cable being bad or one port running at 100Mbps while the others are at 1Gbps. Check the link speed and duplex on every port in the LAG. They must match. If you see auto-negotiation on some ports and fixed speed on others, that's your problem. Set them all to the same speed, or set them all to auto-negotiate. Don't mix.

Alternative fixes if the main steps don't work

If you've done steps 1-4 and the LAG still shows split, try these:

• Reboot the switch. I hate doing this, but sometimes the LACP state machine gets stuck in a loop. A cold restart clears it. If you can't reboot the whole switch, try a power cycle of the ports using power-off on each port in the LAG, then power-on.
• Check for a firmware bug. Some older HP ProCurve switches had a known bug where LACP would split if you had more than 8 LAGs. Update firmware if possible.
• Temporarily use a static LAG. If you're desperate and need traffic now, disable LACP on both ends and use static link aggregation (also called manual trunking). Set all ports to the same VLAN and add them to the LAG without negotiation. It's less resilient but it works. Just remember to switch back later.
• Check the keepalive timer. On some switches, the LACP timeout is configurable. If one side has a short timeout and the other has a long one, they can lose sync. Set them both to short (1 second) for faster detection.

Prevention tips — avoid this mess from the start

• Use the same switch model on both ends if possible. Different vendors implement LACP slightly differently. I've seen splits happen between Cisco and Netgear switches because one uses a different hash algorithm for load balancing.
• Monitor LACP state regularly. Set up SNMP traps for LACP changes. Most managed switches can send an alert when a port leaves a LAG. That way you catch a split before it takes down the network.
• Label your cables. Sounds dumb, but when someone pulls the wrong cable during maintenance, they can break a LAG without knowing. Use different colored cables for LAG members or put a label on each one with the LAG number.
• Test failover scenarios. Once a quarter, unplug one cable from a LAG and watch the traffic. If it doesn't fail over smoothly, your LAG config is wrong. Had a client who tested this and found one port was in a different VLAN—split waiting to happen.

That's it. Most of the time, re-syncing LACP or fixing a speed mismatch will get you back online in 5 minutes. If you're still stuck after these steps, you might have a hardware issue—bad switch port or bad cable. Swap the cable first, it's cheaper. Good luck.