Link Aggregation Explained: LACP, IEEE 802.1AX, MLAG and Failure Modes

Link aggregation bundles several parallel Ethernet links into one logical link, so a switch, server or router can use them together for more total bandwidth and for survival when a cable or port fails. IEEE 802.1AX defines it, and LACP is the protocol that negotiates the bundle. A single flow still rides one member link, so four 10G links never give one TCP connection 40G.

This post goes one level deeper than our Ethernet switching explainer and our VXLAN and EVPN explainer. It covers how the standard moved from 802.3ad to 802.1AX, what is inside every LACP frame, how hashing picks a member link, multi-chassis designs and EVPN multihoming, split brain, the failure modes and security gaps that bite real networks, and a Linux bond built three ways and checked in /proc/net/bonding.

Key takeaways

• Link aggregation joins parallel, full duplex, point to point links into one Link Aggregation Group (LAG) that the layers above treat as a single link. The IEEE 802.1AX-2020 abstract says it "allows parallel point-to-point links to be used as if they were a single link."
• The work started as IEEE 802.3ad, approved at the March 2000 IEEE Standards Board meeting. It moved to the 802.1 working group as IEEE 802.1AX-2008 (approved 26 September 2008, published 3 November 2008), was revised in 2014 and again in 2020, and gained a YANG amendment, 802.1AXdz, published 17 October 2025.
• LACP sends a 110 byte LACPDU to the reserved multicast address 01-80-C2-00-00-02 using the Slow Protocols EtherType 0x8809. Each LACPDU carries what the sender knows about itself (the actor) and about the far end (the partner): system priority and MAC, key, port priority, port number and an eight bit state field.
• Fast rate asks the partner for one LACPDU per second and times out after 3 seconds. Slow rate asks for one every 30 seconds and times out after 90 seconds. Slow is the Linux default.
• Every frame of a conversation goes over one member so that frames stay in order. A hash over addresses and ports picks the member, which is why one elephant flow cannot go faster than one member and why several large flows can collide on the same member while others sit idle.
• Multi-chassis link aggregation (MLAG) makes two switches answer LACP as one system, so a server can bundle links to both. Vendor MLAG designs depend on a peer link and a keepalive; when both fail, both switches can act alone and the network splits. EVPN multihoming (RFC 7432) does the same job with BGP instead of a peer link.
• LACP has no authentication. The Linux kernel documentation warns that hosts on the same layer 2 domain can spoof LACPDUs and, in theory, join another machine's aggregate. Static LAGs have no protocol at all, so a miscabled static LAG can loop or blackhole traffic without any warning.

What is link aggregation?

A link aggregation group is a set of physical links between the same two devices that both ends agree to treat as one. Above the LAG, the bridge or IP stack sees one interface with one MAC address. Spanning tree sees one port. Routing sees one adjacency. Below the LAG, a distributor decides which member carries each outgoing frame and a collector accepts frames from every member and passes them up.

You get two things from that arrangement. The first is capacity: a 4 x 10G bundle can carry up to 40 Gb/s in each direction when traffic is spread across many conversations. The second is resilience: when a member fails, the remaining members keep the logical link up, and the layers above do not have to reconverge. Spanning tree does not recompute and a routing protocol does not drop its neighbour, because the logical interface never went down.

The 2008 edition of the standard describes the result as "N parallel instances of full duplex point-to-point links operating at the same data rate." Each part of that phrase matters in practice:

• Parallel. All members run between the same pair of systems. Standard LACP will not bundle a port to switch A with a port to switch B unless those two switches pretend to be one system, which is exactly what MLAG and EVPN multihoming do.
• Full duplex point to point. Half duplex links and shared media cannot join an aggregate. The Linux driver encodes duplex into the port key and keeps half duplex ports out of aggregates.
• Same data rate. Mixing a 10G and a 25G port in one LAG does not work in standard LACP. Linux puts the speed into the port key, so ports of different speeds get different keys and end up in different aggregators.

Why do four 10G links not give one flow 40G?

Because the standard requires frames of one conversation to arrive in order, and the simplest way to keep order is to send a whole conversation down one member. The Linux bonding documentation states it plainly for its layer3+4 policy: traffic to one peer can span several members, "although a single connection will not span multiple slaves." The kernel even notes that a policy which stripes one conversation across members risks breaking "the packet mis-ordering requirements of section 43.2.4 of the 802.3ad standard."

So a 4 x 10G LAG behaves like four 10G lanes with a dispatcher at the entrance. A file copy over one TCP connection gets one lane, at most 10 Gb/s. Forty file copies over forty connections can, on average, fill all four lanes. The only Linux mode that stripes a single connection over several links is balance-rr (round robin), and the kernel documentation warns that it "generally results in peer systems receiving packets out of order," which triggers TCP congestion control and retransmissions. That mode is not LACP and is not what a switch expects on a standard LAG.

Worked example 1: four flows on four links

Suppose four large flows enter a 4 x 10G LAG and the hash spreads flows uniformly at random. The chance that each flow lands on a different member is 4! divided by 4^4, which is 24 out of 256, or about 9.4 percent. In the other 90.6 percent of cases at least two flows share a member. The expected number of members left completely idle is 4 x (3/4)^4, about 1.27 links. With only a handful of big flows, a LAG is usually lopsided. Uniform spreading needs many flows, which is why aggregation works well for a busy server talking to hundreds of clients and badly for a single replication stream between two storage nodes.

Worked example 2: an elephant among mice

Now put one 9 Gb/s backup flow and forty small flows of 0.5 Gb/s each onto the same 4 x 10G LAG. Offered load is 29 Gb/s against 40 Gb/s of capacity, so the bundle looks healthy on an aggregate graph. On average each member gets ten of the small flows, 5 Gb/s. The member that also carries the backup flow is offered 14 Gb/s on a 10 Gb/s port, so about 4 Gb/s is queued or dropped, while the other three members sit at about half load. The fix is not a bigger bundle. It is a hash that includes ports, more parallel streams in the application, or a faster single link.

From 802.3ad to 802.1AX: the timeline

Link aggregation was first standardised by the IEEE 802.3 (Ethernet) working group as 802.3ad, which became clause 43 of IEEE 802.3. The 802.3ad task force page records that its work was "complete with the approval of IEEE 802.3ad-2000 at the March 2000 IEEE Standards Board meeting." Because aggregation does not depend on the details of any one MAC, the work moved to the 802.1 working group, which handles bridging and architecture, and became IEEE 802.1AX. The 2008 abstract says the standard "defines the MAC independent Link Aggregation capability." This is why the Linux driver still calls its LACP mode "802.3ad" and why Linux and many switch command sets still say 802.3ad more than a decade after the name changed.

Two small notes on that table. The IEEE 802.1 working group page says the 2020 revision was "Approved by the IEEE Standards Association Standards Board on January 30, 2020," while the IEEE SA record lists board approval as 2020-01-31. We show both. And the IEEE SA pages for the 2014 and 2020 editions say the PDFs are available at no cost through the IEEE GET program, so you can read the actual state machines rather than relying on summaries.

What changed between editions

The 2008 abstract describes only the classic case: one system bundling links to one other system. The 2014 abstract adds a new sentence, that link aggregation "also supports the use of multiple links as a resilient load sharing interconnect between multiple nodes in two separately administered networks." That is the Distributed Resilient Network Interconnect, usually shortened to DRNI, the IEEE's own multi-chassis design. (The working group's revision page also spells it out as Distributed Resilient Network Interface.) The 802.1 working group summary of the 2020 edition describes it as an interconnect among "one to three nodes in a network and one to three nodes in another, separately administered, network," with a means to ensure that frames of a given service use the same physical path in both directions.

The 2020 revision folded in the 2017 corrigendum and, in the words of its project description, set out to "correct and clarify Link Aggregation specifications and in particular the Distributed Resilient Network Interface specifications, in the light of implementation experience." The contributions listed on the working group page during that revision cover the LACP mux machine, Conversation Sensitive Collection and Distribution (CSCD), a wait to restore timer and DRNI state synchronisation. The 2025 amendment adds a UML model and YANG modules "for Link Aggregation configuration and status reporting," which matters for anyone who automates switches through NETCONF or RESTCONF rather than a command line.

What does LACP actually exchange?

LACP, the Link Aggregation Control Protocol, is how two systems discover that they share parallel links and agree which ones to bundle. Each end sends LACPDUs on every member port. An LACPDU is small and fixed in shape. The Linux kernel's struct lacpdu in include/net/bond_3ad.h lays it out field by field.

Add those up and the LACPDU body is 110 bytes. It travels in an Ethernet frame addressed to 01-80-C2-00-00-02 with EtherType 0x8809. The Linux header describes 0x8809 as "Slow Protocol. See 802.3ad 43B," and the bonding driver checks that incoming LACPDUs are addressed to that multicast address. The kernel documentation notes that these frames are "destined to link local mac addresses (which switches/bridges are not supposed to forward)." That keeps LACP confined to a single physical link, which is what you want: each LACPDU describes exactly one wire.

Actor and partner, system ID and keys

The most useful idea in LACP is that each end tells the other what it has heard. The actor fields say "this is me." The partner fields say "this is who I think you are." When both ends see their own values echoed back correctly, both know the link works in both directions and that it reaches the system they expected.

The system ID is the pair of system priority and system MAC. Two ports can join the same aggregate only if they reach the same partner system ID. That one rule is what lets LACP catch miscabling: if one cable goes to switch B and the other to switch C, the partner system IDs differ, and LACP puts the ports into different aggregates instead of treating them as one link.

The key groups ports that are allowed to bundle. Two ports with different keys never share an aggregate, even to the same partner. Switches normally derive the key from the port channel number you configure. Linux builds it from the link: the bonding documentation says the port key has three parts, bit 0 for duplex, bits 1 to 5 for speed and bits 6 to 15 for a user defined value. In the kernel source, actor_admin_port_key is set to the user key shifted left by 6, then OR'd with the speed code shifted left by 1 and the duplex bit.

Here is that worked through. The kernel's speed enumeration starts at 1 for 1 Mb/s and counts up, so 10 Gb/s is code 7. A 10G full duplex port with no user key has key (7 x 2) + 1 = 15. With ad_user_port_key set to 5, the key becomes (5 x 64) + 15 = 335. A 25G port is code 10, so its key would be 21. That is why a mix of 10G and 25G members ends up in two aggregators on Linux.

The state byte

Each LACPDU carries one state byte for the actor and one for the partner. The Linux UAPI header if_bonding.h defines the bits:

You will see these as decimals in /proc/net/bonding. A healthy active port at fast rate reads 63 (0x3F: activity, timeout, aggregation, synchronization, collecting, distributing). The same port at slow rate reads 61 (0x3D, timeout bit clear). A port stuck with Defaulted or Expired set, such as 71 or 199, has not heard from a working partner.

Timers

The Linux driver's constants in bond_3ad.c match the standard's defaults:

A subtle point: the rate in your own configuration is a request to the other side. The Linux documentation describes lacp_rate as "the rate in which we'll ask our link partner to transmit LACPDU packets." Setting fast on the server makes the switch send every second, which lets the server detect a dead switch port within 3 seconds. Detection in the other direction depends on the switch's own setting.

The Marker protocol

LACPDUs share the Slow Protocols EtherType with the Marker protocol, subtype 0x02. A marker lets a distributor confirm that frames sent down one member have arrived before it moves that conversation to another member, so rebalancing does not reorder frames.

How does hashing pick a member link?

The distributor must send every frame of a conversation down the same member, and it must decide fast, in hardware on a switch and per packet in the kernel on a host. So it hashes header fields and takes the result modulo the number of active members. Which fields go into the hash is the single most important tuning choice in a LAG.

The Linux bonding documentation publishes its formulas, which makes it a good teaching reference. Switch silicon uses its own hash functions with a similar choice of inputs.

The layer2 formula is hash = source MAC[5] XOR destination MAC[5] XOR packet type ID, then member number equals hash modulo member count. The layer3+4 formula starts with the source and destination ports, XORs in both IP addresses, folds the result by shifting right 16 and then 8 bits, shifts right once more, then reduces it modulo the member count.

Worked example 3: why layer2 hashing pins a server to one link

A server with MAC ending in 0x1a sends all its internet traffic through a default gateway whose MAC ends in 0x2b. With the layer2 policy, and taking the packet type ID as the IPv4 EtherType 0x0800 for illustration, the hash is 0x1a XOR 0x2b XOR 0x0800. 0x1a XOR 0x2b is 0x31, and XOR 0x0800 gives 0x0831, which is 2097 in decimal. 2097 modulo 4 is 1. Every flow to every internet host goes to the gateway's MAC, so every flow hashes to member 1. The other three members carry nothing outbound. This is the most common reason a new LAG "does nothing": the server sends almost everything to one next hop MAC, and layer2 hashing cannot tell those flows apart.

The fix on Linux is xmit_hash_policy layer3+4 or layer2+3. The kernel docs say layer2+3 is "intended to provide a more balanced distribution of traffic than layer2 alone, especially in environments where a layer3 gateway device is required to reach most destinations." Layer3+4 spreads further, per connection, at the cost of the small compliance caveat above.

Each end hashes on its own

A LAG has two distributors, one at each end, and they hash independently. Frames from the server to the switch might use member 1 while replies from the switch to the server use member 3. For plain forwarding that is fine, because the collector at each end accepts frames from any member. It matters when something in the path keeps state per direction, such as a firewall cluster that is split across members, a tap that captures only one member, or a monitoring tool that expects both directions on one port. For those cases operators choose symmetric hashing, a hash whose inputs are ordered (for example, always placing the lower IP address first) so that A to B and B to A produce the same value. Symmetric hashing is a feature of the hashing function, so check what your switch or host actually offers rather than assuming it.

Elephant flows, polarisation and rebalancing

Hashing is a statistical bet, and it pays off only with many flows of similar size. Three patterns break it:

• Few large flows. Worked examples 1 and 2 above show how quickly a handful of elephants collide.
• Polarisation. If two tiers of switches use the same hash function with the same inputs, the first tier sends a set of flows to one uplink and the next tier, seeing only that set, sends all of them to one of its own uplinks too. Varying the hash seed or inputs per tier avoids it.
• Member count changes. Modulo hashing reshuffles flows when a member fails or returns, because hash modulo 4 and hash modulo 3 give different answers. Brief reordering during that shuffle is normal; repeated flapping makes it constant.

LACP itself does not measure load. Some host implementations add rebalancing outside the standard; Open vSwitch, for example, documents that in its SLB mode "every 10 seconds, vswitchd rebalances the bond members" based on traffic statistics. Inside standard LACP, the hash is the whole story.

Static LAG, active and passive LACP, fast and slow rate, and min-links

These terms describe how the bundle comes up and how quickly it notices trouble.

Static LAG. Some platforms call this "mode on". Each side simply hashes across the configured ports. There is no exchange that confirms the far side is the same device, so it works only when cabling and configuration are perfect on both ends. The Linux equivalent is balance-xor mode, which uses the same hash policies but sends no LACPDUs.

Active and passive. In Linux the knob is lacp_active. The kernel docs describe off as "speak when spoken to" and on as sending LACPDUs periodically, with on as the default. At least one end must be active. Many teams set both ends active to avoid depending on which side starts.

Fast and slow. The Linux default is slow, and systemd-networkd's LACPTransmitRate= also defaults to slow. Slow rate is the reason many "LACP did not notice the link was broken" stories take a minute and a half to recover.

Worked example 4: what a slow timeout costs

A fibre in a 4 x 10G bundle loses one strand so frames from the switch stop reaching the server but the server's frames still reach the switch. The physical link may stay up on one side. With slow rate, the server keeps sending into the dead direction until it misses three LACPDUs from the switch: 3 x 30 = 90 seconds. About a quarter of the flows hash onto that member. At 10 Gb/s, 90 seconds is 900 gigabits, or 112.5 gigabytes of capacity during which traffic for those flows is lost. At fast rate the same failure is detected in 3 seconds, or 3.75 gigabytes of capacity. Fast rate is cheap insurance on links where you cannot rely on the physical layer to report a one way fault.

Min-links. The Linux min_links option sets "the minimum number of links that must be active before asserting carrier." Its default is 0, which the docs explain behaves exactly like 1. Setting it to 2 on a four member bundle means the logical interface goes down if only one member survives, so routing or a first hop redundancy protocol such as VRRP can steer traffic to a healthier path instead of squeezing 40G of demand through one 10G member. Our VRRP explainer covers that next layer.

Fallback when LACP fails. Recent kernel documentation describes a lacp_strict option. With its default of off, when no member reaches the Collecting_Distributing state but at least min_links members have carrier, "one interface of the bond is selected to be active, in order to facilitate communication with peer devices that do not implement LACP." With it on, members are active only after a successful LACP negotiation. Open vSwitch documents a similar idea, lacp-fallback-ab, which falls back to active-backup until the physical switch's LACP configuration is complete, and notes that many switches "block all traffic for ports that are configured to use LACP, until LACP is negotiated." Fallback helps first boot and network installs; it also means a broken negotiation can look like a working link. Decide on purpose which behaviour you want.

Aggregator selection. If ports on one host reach two different partners, Linux can form more than one aggregator but uses only one at a time. The ad_select option chooses it: stable (the default) picks the largest aggregate bandwidth and reselects only when the active aggregator has no working members; bandwidth and count reselect whenever membership changes. On a host cabled to two switches without MLAG, this is why only half the links carry traffic.

What is multi-chassis link aggregation?

Standard LACP bundles links between two systems. A server cabled to one switch has a single point of failure in that switch. Multi-chassis link aggregation (MLAG, also called MC-LAG) removes it: two switches cooperate so that both present the same LACP system ID to the server. The server sees one partner, puts both links into one aggregate and hashes across them. If either switch fails, the server keeps the bundle up on the surviving member.

The server needs nothing special; a normal Linux bond in 802.3ad mode works. All the complexity sits between the two switches, and in most vendor designs that complexity looks like this:

• A shared system ID. Both switches advertise the same actor system priority and MAC in their LACPDUs, and use consistent keys, so the server cannot tell them apart.
• A peer link. A high bandwidth link, often itself a LAG, between the two switches. It carries state synchronisation and any traffic that arrives on the "wrong" switch, such as a frame for a host that is attached only to the other switch.
• Table synchronisation. MAC addresses learned on one switch are shared with the other, so both forward to the bundle consistently.
• A peer keepalive. A separate heartbeat, ideally over a different path such as the management network, so each switch can tell "my peer is dead" apart from "my peer link is dead."
• Loop prevention across the peer link. A frame flooded onto the peer link must not go back out to a host that is dual attached, because that host already received it from the first switch.

Each vendor implements this differently, with its own names (virtual port channel and multi-chassis trunking are two common ones), its own synchronisation protocol and its own failure rules. These designs are not interoperable: both switches in a pair must run the same vendor's software. Check your network operating system's documentation for the exact behaviour; the rest of this section describes the general mechanisms. Our switch build explainer covers the ASIC and software layers that implement them.

DRNI: the standard version

IEEE 802.1AX-2014 added DRNI, a standard way for a "portal" of up to three systems to act as one end of an aggregation. The systems in a portal connect through intra-portal links and run a distributed relay that decides which system handles each conversation, with the stated aim that a given service uses the same physical path in both directions. DRNI exists so that multi-chassis aggregation can interoperate in principle; in practice, check whether your platforms actually implement it before relying on it.

How split brain happens

Split brain is the state where both MLAG peers believe they are in charge, each acting on its own copy of the tables. It follows from the design: two independent control planes pretending to be one.

1. Peer link fails, keepalive works. The switches can no longer synchronise, but each knows the other is alive. Typical designs pick a winner by role or priority, and the secondary disables its MLAG member ports. Servers lose half their links but stay up through the primary. Single attached hosts on the secondary (often called orphan ports) can be cut off if their traffic needs the peer link.
2. Peer link and keepalive both fail, both switches alive. Neither switch can tell whether the other is dead. If both carry on, both keep answering LACP with the shared system ID, so servers keep both members bundled. Each switch now learns MAC addresses on its own, floods unknown unicast on its own and may answer for the same gateway address. The symptoms are duplicated broadcasts, MAC flapping upstream, intermittent reachability and asymmetric paths that defeat stateful devices.
3. Peer reboots and rejoins too early. A recovering switch that brings its member ports up before its tables are synchronised can attract traffic it cannot forward correctly, blackholing flows for seconds. Most designs add a restore delay for this reason, an idea that also appears in the 802.1AX revision work on a wait to restore timer.

Defences are design choices: run the keepalive on a path physically separate from the peer link, build the peer link from members on different line cards or ASICs, keep single attached hosts off MLAG pairs where you can, and test the failure cases in a maintenance window instead of learning them during an outage.

What is EVPN multihoming?

EVPN multihoming, defined in RFC 7432 and adapted to VXLAN style overlays in RFC 8365, solves the same problem without a peer link. The switches attached to a host (provider edge devices, or PEs, in RFC language) advertise the host's links over BGP, and the rest of the fabric learns that it can reach the host through any of them.

The core terms:

• Ethernet segment (ES). RFC 7432 says that when a site connects to one or more PEs through a set of Ethernet links, "this set of Ethernet links constitutes an 'Ethernet segment'." Each multihomed segment gets a 10 octet Ethernet Segment Identifier (ESI). ESI 0 means single homed, and all 0xFF is reserved.
• ESI from LACP. RFC 7432 type 1 ESIs are generated from LACP: the customer device's LACP system MAC (6 octets), then its LACP port key (2 octets), then a zero octet. As RFC 7432 puts it, the device "would treat the multiple PEs that it is connected to as the same switch," which is the same trick MLAG plays, carried in BGP instead of a vendor protocol.
• All-active and single-active. In all-active mode every PE forwards unicast to and from the segment and the host hashes across its links as a LAG. In single-active mode only one PE forwards for a given VLAN.
• Designated forwarder (DF). Only one PE per segment and VLAN sends broadcast, unknown unicast and multicast (BUM) traffic to the host, so the host does not receive duplicates.
• Split horizon. When a non-DF PE floods a BUM frame it received from the host into the fabric, the DF on the same segment "MUST drop the packet and not forward back" to that host. With MPLS, an ESI label marks the segment of origin. RFC 8365 notes that VXLAN carries no ESI label and recommends "Local Bias": each switch filters frames from peers it shares segments with, based on the tunnel source IP.
• Aliasing and mass withdraw. Remote switches can load balance toward a host through every PE on the segment, even PEs that have not learned the host's MAC. When a PE loses its link to a segment it withdraws its per segment routes, and the rest of the fabric moves all MACs on that segment at once instead of one by one.

Worked example 5: DF election by modulo

RFC 7432's default DF election, called service carving, waits for a timer (default 3 seconds) to collect routes from the other PEs on the segment, sorts their IP addresses in increasing order and gives each an ordinal starting at 0. With N PEs, the PE with ordinal i is the DF for VLAN V when V mod N equals i.

Take two PEs, 192.0.2.1 (ordinal 0) and 192.0.2.2 (ordinal 1), sharing one segment. VLAN 100 mod 2 is 0, so the first PE is DF for VLAN 100. VLAN 101 mod 2 is 1, so the second PE is DF for VLAN 101. That spreads nicely. Now suppose the operator numbers VLANs in steps of two: 100, 102, 104, 106. Every one of them is even, so every one lands on the first PE, and the second PE does no BUM forwarding at all for that segment. When a PE joins or leaves, N changes and most VLANs move. RFC 8584 defines an alternative, the Highest Random Weight algorithm, and lets DF election take the state of the attachment circuit into account. It updates RFC 7432.

Split brain in EVPN

EVPN has no peer link to cut, but it has its own version of the problem. A PE that loses all its uplinks into the fabric while its access link to the host stays up is isolated: the host keeps hashing traffic toward it, and that PE has nowhere to send it. Implementations address this by tracking uplink state and bringing access links down (or stopping LACP on them) when the PE is cut off from the core. Two PEs on the same segment that disagree about who is DF during convergence can also, briefly, both forward BUM traffic; RFC 7432 recommends split horizon filtering even in single-active mode because it "prevents transient loops at the time of failure or recovery," for example "when two PEs think that both are DFs." If you run EVPN multihoming, the isolation behaviour is the first thing to test.

Comparison: static LAG, LACP, MLAG and EVPN multihoming

Failure modes and security issues

Link aggregation is unglamorous until it fails, and its failures are often silent because the logical interface stays up. These are the ones that recur.

Misconfigured static LAGs and loops

A static LAG has no way to discover that its far ends do not belong together. Picture switch A with ports 1 and 2 configured as a static bundle, and the cables actually landing on switches B and C, which are connected to each other. Switch A believes it has one link; B and C each believe they have a separate link to A. Spanning tree on A treats the bundle as one port, but B and C see two ports and a triangle. A broadcast from B reaches A over one member, while C can deliver the same frame back to A over the other. MAC addresses flap between members, broadcasts multiply, and spanning tree on A cannot block what it sees as one port. LACP would have refused to bundle the two ports, because the partner system IDs from B and C differ. The general rule: if a protocol is available, use LACP rather than static bundling. Our spanning tree explainer covers the loop protection features that should sit beside it.

The opposite mismatch, a LAG on one end and independent ports on the other, causes blackholes instead of loops. A host bonded in balance-xor toward a switch whose ports are independent will see the switch learn its MAC on whichever port spoke last, and return traffic will flip between ports.

Unidirectional links

Fibre links can fail in one direction: a broken strand, a dirty connector or a failing transmitter. If the receiving side still reports link up, a static LAG keeps sending into the void. LACP catches this because the partner information stops arriving or stops echoing correctly, but only after the timeout. Hardware link fault signalling in modern Ethernet helps at higher speeds; where you cannot rely on it, use fast rate, and consider RFC 7130 micro BFD, which runs "an independent Asynchronous mode BFD session on every LAG member link" and "provides a shorter detection time than what LACP offers." Micro BFD uses UDP destination port 6784 and the dedicated MAC address 01-00-5E-90-00-01. Some platforms also offer vendor specific unidirectional link detection protocols.

LACP spoofing from a host

LACPDUs carry no authentication field; the structure above has none. The Linux bonding documentation is unusually candid about the consequence. Most LACPDU values "are easily predictable or are simply the machine's MAC address," so other machines in the same layer 2 domain "can spoof LACPDU packets from other hosts to the switch and potentially cause mayhem by joining (from the point of view of the switch) another machine's aggregate," receiving part of that host's traffic. The same documentation adds that this is "not a likely scenario." The mechanism matters more than the likelihood: a switch trusts whatever LACPDUs arrive on a port that is allowed to run LACP.

Defences, from the host and switch sides:

• On Linux, set ad_actor_system to a random locally administered MAC, randomise ad_actor_sys_prio, and set a user portion in ad_user_port_key. The kernel docs recommend exactly these three, so the values another host would have to forge are no longer guessable.
• On the switch, enable LACP only on ports that should bundle, pin each port to the port channel it belongs to, and configure host facing ports so a stray LACPDU cannot create a new aggregate.
• Rate limit control plane traffic so a flood of slow protocol frames cannot starve the switch CPU.
• Use port based access control such as 802.1X on access ports; see our 802.1X and EAP explainer. MACsec authenticates frames on a link; whether LACPDUs on a given platform are protected depends on where the device places MACsec relative to link aggregation, so check the platform documentation. Our MACsec explainer covers the protocol.

Unauthenticated control frames in general

LACP joins other layer 2 control protocols that trust the wire, such as spanning tree, LLDP and ARP and IPv6 Neighbor Discovery. The defence is the same: limit which ports may speak each protocol and treat access ports as untrusted. LACPDUs also leak a little: the system MAC, priority and keys describe the device at the other end.

Flapping, churn and hash reshuffles

A member that keeps going up and down forces a rehash each time, causing reordering across the bundle. Linux shows "Actor Churn State" and "Partner Churn State" per port in /proc/net/bonding. A damaged cable or optic is the usual cause; updelay and downdelay damp brief glitches at the cost of slower reaction.

Multicast and gateway behaviour after failover

After a failover, multicast can stall until the switch learns the new path; Linux resend_igmp resends IGMP membership reports for the modes where that matters. On MLAG pairs, both switches must agree on gateway MAC handling, or hosts can lose their default route during a peer failure.

Software and firmware in the path

Every one of these protocols is code: the kernel bonding driver and NetworkManager on hosts, and the LACP, MLAG and EVPN daemons in network operating systems. State machine and parser bugs get fixed in updates, so keep them current and track which builds carry which versions.

Step by step: build a Linux bond with LACP and verify it

The examples below create bond0 in 802.3ad mode from two ports, eno1 and eno2, with fast rate, layer3+4 hashing, MII monitoring every 100 ms and min-links of 1. The switch side must have a matching LACP port channel on the two switch ports.

Warning: changing the interfaces that carry your SSH session can cut you off. Work from a console, an out of band management interface or a lab VM, and confirm the interface names first.

Step 0: identify the right ports

# list interfaces, link state and MAC addresses
ip -br link show

# confirm speed and duplex match on both members
ethtool eno1 | grep -E 'Speed|Duplex|Link detected'
ethtool eno2 | grep -E 'Speed|Duplex|Link detected'

# confirm neither port carries the address you are logged in through
ip -br addr show eno1
ip -br addr show eno2

If the speeds differ, the members will get different LACP keys and will not join the same aggregator.

Option A: iproute2 (temporary, good for testing)

sudo modprobe bonding

sudo ip link add bond0 type bond mode 802.3ad \
    miimon 100 lacp_rate fast xmit_hash_policy layer3+4 min_links 1

sudo ip link set eno1 down
sudo ip link set eno2 down
sudo ip link set eno1 master bond0
sudo ip link set eno2 master bond0

sudo ip link set bond0 up
sudo ip addr add 192.0.2.10/24 dev bond0

The option names come from iproute2's bond support, which accepts mode, miimon, lacp_rate, lacp_active, xmit_hash_policy, min_links, ad_select, ad_user_port_key, ad_actor_sys_prio and ad_actor_system among others. Members must be down before they are enslaved. This configuration disappears at reboot.

To apply the anti spoofing settings from the kernel documentation, add them when you create the bond:

sudo ip link add bond0 type bond mode 802.3ad miimon 100 lacp_rate fast \
    xmit_hash_policy layer3+4 \
    ad_actor_system 02:5e:3a:91:c4:17 ad_actor_sys_prio 41023 ad_user_port_key 517

Generate your own random values; do not copy these. The MAC must not be multicast or all zeros, and the kernel docs prefer the locally administered bit set (second lowest bit of the first byte, as in 0x02).

Option B: systemd-networkd (persistent)

Three small files. The [Bond] keys are documented in systemd.netdev(5); MinLinks= and the Ad* keys are available in current releases.

# /etc/systemd/network/25-bond0.netdev
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer3+4
LACPTransmitRate=fast
MIIMonitorSec=100ms
MinLinks=1

# /etc/systemd/network/30-bond0-members.network
[Match]
Name=eno1 eno2

[Network]
Bond=bond0

# /etc/systemd/network/40-bond0.network
[Match]
Name=bond0

[Network]
Address=192.0.2.10/24
Gateway=192.0.2.1

Then:

sudo networkctl reload
networkctl status bond0

The systemd.netdev manual lists LACPTransmitRate= with values slow and fast, and "the default value is slow." Its own example bond uses Mode=802.3ad, TransmitHashPolicy=layer3+4, MIIMonitorSec=1s and LACPTransmitRate=fast.

Option C: NetworkManager with nmcli (persistent)

NetworkManager's documented example adds a bond controller and two port profiles. For LACP, set the mode and options through bond.options, which takes key and value pairs:

sudo nmcli con add type bond ifname bond0 con-name bond0 \
    bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4,min_links=1"

sudo nmcli con add type ethernet ifname eno1 con-name bond0-port1 controller bond0
sudo nmcli con add type ethernet ifname eno2 con-name bond0-port2 controller bond0

sudo nmcli con mod bond0 ipv4.method manual ipv4.addresses 192.0.2.10/24 ipv4.gateway 192.0.2.1
sudo nmcli con up bond0

Older NetworkManager releases use master instead of controller for the port profiles. If an existing profile already manages eno1 or eno2, deactivate it first so the two do not fight over the port.

Step 4: read /proc/net/bonding/bond0

cat /proc/net/bonding/bond0

The field names come from the kernel's bond_procfs.c. A healthy two member bond to a switch at fast rate looks like this (values illustrative):

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP active: on
LACP rate: fast
Min links: 1
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: 3c:ec:ef:10:20:30
Active Aggregator Info:
	Aggregator ID: 1
	Number of ports: 2
	Actor Key: 15
	Partner Key: 10
	Partner Mac Address: 00:1c:73:aa:bb:cc

Slave Interface: eno1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
details actor lacp pdu:
    system priority: 65535
    port key: 15
    port state: 63
details partner lacp pdu:
    system priority: 32768
    oper key: 10
    port state: 63

What to check, line by line:

Step 5: watch the LACPDUs

sudo tcpdump -i eno1 -nn -e -v ether proto 0x8809

At fast rate you should see one LACPDU per second in each direction. The verbose output decodes actor and partner fields, so you can confirm the switch is echoing your system MAC and key back to you.

Step 6: test failover deliberately

# in one terminal, keep traffic flowing
ping 192.0.2.1

# in another, take one member down and back up
sudo ip link set eno2 down
cat /proc/net/bonding/bond0 | grep -E 'Number of ports|Slave Interface|MII Status'
sudo ip link set eno2 up

The ping should continue with at most a brief gap. A better test is pulling a cable or, on the switch, shutting one port, because that exercises the LACP path rather than local carrier. If the bond stays down when a member disappears, check min_links.

Common mistakes

• Leaving the default layer2 hash on a routed server. Everything goes to the gateway's MAC, so one member carries all outbound traffic. Use layer3+4 or layer2+3.
• Expecting one flow to go faster. A LAG raises total capacity, not single stream throughput. Benchmark with many parallel streams, or fix the application.
• Static bundling when LACP is available. Static LAGs cannot detect miscabling or one way failures. Use LACP active on both ends.
• Passive on both ends. Two passive ends wait for each other forever. At least one side must be active.
• Slow rate on links that matter. A 90 second timeout is a long outage for a quarter of your flows. Use fast rate, plus micro BFD where supported.
• Mixing speeds or duplex settings. Different speeds mean different keys and separate aggregators, and ad_select stable will use only one.
• Cabling a host to two switches without MLAG or EVPN. The partner system IDs differ, so you get two aggregators and only one is used.
• Running the MLAG keepalive over the peer link. Then one failure removes both, and the pair cannot tell a dead peer from a dead link.
• Forgetting min-links. A four member bundle that degrades to one member keeps attracting full traffic.
• Trusting fallback without monitoring it. Fallback modes keep a host reachable when LACP fails, which also hides the failure. Alert on aggregator membership, not just link state.
• Ignoring control plane exposure. Allowing LACP on every access port lets anything plugged in try to form an aggregate.

FAQ

What is the difference between LACP and link aggregation?

Link aggregation is the capability: treating several links as one. LACP is the control protocol, defined in the same IEEE 802.1AX standard, that lets two systems negotiate which links join the bundle and detect when one stops working. You can aggregate without LACP (a static LAG), but you then lose miscabling and one way failure detection.

Is IEEE 802.3ad the same as IEEE 802.1AX?

They describe the same mechanism. Link aggregation was first published as IEEE 802.3ad-2000, approved in March 2000, and became clause 43 of IEEE 802.3. It moved to the 802.1 working group as IEEE 802.1AX-2008, and the current edition is IEEE 802.1AX-2020 with the 802.1AXdz-2025 YANG amendment. Linux and many switch command sets still use the old name.

Does a 2 x 10G LAG give me 20G?

It gives you up to 20 Gb/s in total across many flows. Any single TCP or UDP flow is limited to one member, 10 Gb/s, because the hash sends every frame of a flow over the same link to keep them in order.

Should I use LACP fast or slow rate?

Fast rate detects a dead or one way link in 3 seconds instead of 90, for one small frame per second per link. Most operators choose fast on server and inter switch links. Check that both ends support it and remember each side's setting controls how often the other side sends.

What is the difference between active and passive LACP?

An active port sends LACPDUs on its own. A passive port sends only after it hears one. Active and passive together form a bundle; two passive ends never do. Setting both ends active is the simplest choice.

What is MLAG and do I need it?

MLAG lets two switches present themselves as one LACP partner, so a server can bundle links to both and survive a switch failure. You need it, or EVPN multihoming, when a single top of rack switch is an unacceptable single point of failure. It adds a peer link, a keepalive and vendor specific behaviour you have to test.

What is split brain in MLAG?

Split brain is when both MLAG switches lose contact with each other, usually because the peer link and the keepalive fail together, and both keep acting as the primary. Servers keep both links bundled while the switches forward independently, which causes duplicate broadcasts, MAC flapping and intermittent loss. Separate keepalive paths and tested failure rules prevent it.

Is LACP secure?

LACP has no authentication. The Linux kernel documentation describes how a host on the same layer 2 domain could spoof LACPDUs to join another host's aggregate, while calling it "not a likely scenario." Randomise the Linux actor system MAC, priority and user key, restrict LACP to the switch ports that need it and rate limit control plane traffic.

How do I check if my Linux bond is working?

Run cat /proc/net/bonding/bond0. Check that the mode is IEEE 802.3ad Dynamic link aggregation, that "Number of ports" matches your cables, that every member shows the same Aggregator ID, that the Partner Mac Address is not all zeros, and that the port state is 63 at fast rate or 61 at slow rate.

What is the difference between MLAG and EVPN multihoming?

Both let a host bundle links to two or more switches. MLAG uses a vendor specific peer link between a pair of switches. EVPN multihoming (RFC 7432, RFC 8365) advertises the host's Ethernet segment over BGP and needs no peer link, but requires an EVPN fabric.

Where Safeguard fits

Safeguard does not configure switches, monitor LACP sessions, analyse network operating system firmware or detect split brain; those jobs belong to your network operating system, your monitoring and your change process. The honest connection is the software around the network. Bonding and teaming daemons, NetworkManager and systemd on hosts, open source routing suites packaged as container images, and the Python or Go tooling that teams write to template and push switch configuration are all software with open source dependencies. Safeguard scans repositories, container images and SBOM files for those dependencies, matches them against vulnerability data, shows which projects carry a given component version and can open fix pull requests (switched off by default) when a safe version exists.

The same discipline that keeps a LAG healthy, knowing exactly what runs where, applies to the code that builds and configures your network. Network automation repositories and the images that run routing or monitoring daemons pull open source packages like any other project, so a vulnerable dependency there can reach every switch you manage.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and remediation workflows, not switch configuration or LACP monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a network automation repository or a container image that runs a routing or monitoring daemon, the same scan lists the open source packages inside and their known vulnerabilities, so you know which builds to update.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow fits a dependency bump in the tooling that templates and pushes your bond and port channel configuration, where you want to see every change before it runs.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, for example a library your network automation depends on, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEEE SA: IEEE 802.1AX-2020, Link Aggregation
• IEEE SA: IEEE 802.1AX-2014, Link Aggregation
• IEEE SA: IEEE 802.1AX-2008, Link Aggregation
• IEEE SA: IEEE 802.1AXbk-2012, Amendment 1: Protocol Addressing
• IEEE SA: IEEE 802.1AXdz-2025, Amendment 1: YANG for Link Aggregation
• IEEE 802.1 Working Group: 802.1AX-2020, Link Aggregation
• IEEE 802.3ad Link Aggregation Task Force
• Linux kernel documentation: Linux Ethernet Bonding Driver HOWTO
• Linux kernel source: include/net/bond_3ad.h (LACPDU structure)
• Linux kernel source: drivers/net/bonding/bond_3ad.c (timers, port key, LACPDU address)
• Linux kernel source: include/uapi/linux/if_bonding.h (LACP state bits)
• Linux kernel source: include/uapi/linux/if_ether.h (ETH_P_SLOW)
• Linux kernel source: drivers/net/bonding/bond_procfs.c (/proc/net/bonding fields)
• iproute2 source: ip/iplink_bond.c (bond options)
• ip-link(8) manual page
• systemd.netdev(5): Bond section options
• NetworkManager: nmcli examples
• NetworkManager: nm-settings-nmcli, bond.options
• Open vSwitch documentation: Bonding
• RFC 7432: BGP MPLS-Based Ethernet VPN, February 2015
• RFC 8365: A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN), March 2018
• RFC 8584: Framework for EVPN Designated Forwarder Election Extensibility, April 2019
• RFC 7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces, February 2014

Last reviewed: 24 October 2026. IEEE 802.1AX gained a YANG amendment in October 2025 and Linux bonding options change between kernel releases; check the pages above for the versions you actually run.