LACP Fallback: Keeping a Server Reachable Without LACP

A dynamic LAG refuses to forward until it receives LACP protocol data units from the peer. That is correct behaviour, and it becomes a problem in exactly two situations: a server whose NIC teaming is not enabled yet (during provisioning, or after a rebuild), and a server that deliberately runs a failover-only bonding mode rather than 802.3ad. In both cases the switch ports stay down, the server is unreachable, and somebody drives to the data centre. LACP fallback solves it by allowing the LAG members to act as ordinary non-bonded interfaces when no LACP partner is detected, then joining the LAG properly the moment LACP appears.

What fallback does, precisely

• With no LACP partner detected, the LAG member ports become individual forwarding interfaces instead of staying blocked.
• When LACP PDUs are received, the members transition from "individual" to collecting and distributing, and the peer's bonding mode moves from active-backup to IEEE 802.3ad.
• Traffic during the fallback period is not load-shared — each port forwards independently, so the server sees multiple links and must handle that itself.

That last point is the limitation: fallback assumes the server side is not aggregating, which is true when it has no teaming configured or is running a failover-only mode. If the server is configured for 802.3ad but its LACPDUs are missing, fallback will hold the link up in a state the server was not designed for — usually harmless, occasionally a source of duplicate packets. Use it intentionally, not as a blanket default.

Two variants, one platform

On ArubaOS-CX the feature exists in two forms, and using the wrong command is the most common mistake:

! standalone switch: dynamic LAG with fallback
switch(config)# interface lag 1
switch(config-lag-if)# no shutdown
switch(config-lag-if)# lacp mode active
switch(config-lag-if)# lacp fallback-static
switch(config-lag-if)# vlan trunk native 1 tag
switch(config-lag-if)# vlan trunk allowed all
switch(config-lag-if)# exit
switch(config)# interface 1/1/1
switch(config-if)# lag 1
switch(config-if)# no shutdown

! VSX pair: multi-chassis LAG with fallback
core01(config)# interface lag 10 multi-chassis
core01(config-lag-if)# lacp mode active
core01(config-lag-if)# lacp fallback
core01(config-lag-if)# no shutdown

Note that lacp fallback on a non-VSX LAG is ignored rather than rejected on some releases, so a configuration that looks correct simply does not take effect. Check the LAG type before choosing the command.

Verifying the state transition

show lacp interfaces lag 1
show lag 1
show running-config interface lag 1
show lacp aggregates

The field to watch is the LACP status of each member: individual during fallback, then collecting and distributing once the partner is detected. In the LAG summary, member interfaces should move into the aggregated list at the same moment. If ports stay individual after the server has booted with teaming enabled, the LACP PDUs are not arriving — usually because the server's bond is not activated, the mode is wrong, or the two ends disagree on rate (fast versus slow).

Design implications

Fallback is a provisioning and recovery aid, not a high-availability mechanism. Three design points keep it useful:

1. Pair it with the right server mode. On Linux, fallback matches mode=1 (active-backup) or no bonding at all; it does not match mode=4 (802.3ad) once LACP is up.
2. Keep it off trunks you do not control. On inter-switch links, a fallback that keeps links forwarding without LACP can create loops if the far end also forwards.
3. Alert on fallback state. A LAG that spends weeks in fallback is a configuration drift problem — somebody rebuilt a server without teaming and never noticed, because everything still worked.

The same reasoning applies to multi-chassis constructs on other platforms: the VSX pair that terminates the LAG is configured as in ArubaOS-CX VSX configuration, the equivalent MLAG design is covered in Arista EOS MLAG configuration, and the Dell counterpart in Dell OS10 VLT setup. In all three, the fallback behaviour is a property of the LAG, and the downstream device's expectations decide whether enabling it helps or hurts.

原文链接：https://airheads.hpe.com/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=e430569f-7278-4706-a859-01854be51f44&forceDialog=0