\nIt doesn’t always distribute bandwidth evenly.<\/strong>Dynamic load-balance<\/h2>\n\n\n\n Some devices support dynamic<\/strong> mode, which monitors the instantaneous load of each member and reallocates flows between links<\/strong> that are underutilized or overloaded.<\/p>\n\n\n\n\nMaintains flow order,<\/li>\n\n\n\n Corrects situations where the hash alone would leave one link “full” and another idle,<\/li>\n\n\n\n It is more efficient in scenarios with few heavy flows.<\/li>\n<\/ul>\n\n\n\nOne device that uses this type of balancing is Datacom’s switches.<\/p>\n\n\n\n
And what can the chips use for hashing?<\/h2>\n\n\n\n Hardly anyone talks about this point, but it’s crucial.<\/p>\n\n\n\n
Depending on the ASIC, the router may look:<\/p>\n\n\n\n
\nonly layer 2 + layer 3<\/strong> (MAC + IP + ports),<\/li>\n\n\n\nand\/or MPLS labels<\/strong>.<\/li>\n<\/ul>\n\n\n\nIn the case of MPLS:<\/p>\n\n\n\n
\nSome ASICs can only read the first label of<\/strong> the stack.<\/li>\n\n\n\nOthers can read the first 3 labels<\/strong>.<\/li>\n\n\n\nMore modern ASICs (recent NPs\/NPUs) read up to the 7th label<\/strong> to generate entropy in the hash.<\/li>\n<\/ul>\n\n\n\nThis matters because:<\/p>\n\n\n\n
\nIn MPLS tunnels, when everyone uses the same top label, the hash loses entropy.<\/li>\n\n\n\n When the ASIC does not read deeply into the MPLS stack, several flows can fall on the same<\/strong> LAG link<\/strong>.<\/li>\n\n\n\nMore modern hardware can see internal labels (VPN, PW, etc.), giving the hash much more diversity.<\/li>\n<\/ul>\n\n\n\nPractical examples:<\/p>\n\n\n\n
\nVPLS\/PWE3 \u2192 use the PW label<\/strong> as entropy (if the chip is deep enough).<\/li>\n\n\n\nL3VPN \u2192 use the VPN label<\/strong>.<\/li>\n\n\n\nSimple LDP traffic \u2192 almost always hash poor, as many flows share the same transport label.<\/li>\n\n\n\n Use other techniques, such as flow-labeling <\/strong>in services.<\/li>\n<\/ul>\n\n\n\n\n In a nutshell:<\/p>\nThe greater the MPLS depth that the ASIC sees, the better the distribution of MPLS flows in the LAG.<\/cite><\/blockquote>\n\n\n\nWhat LACP does<\/h2>\n\n\n\n LACP<\/strong> (Link Aggregation Control Protocol, IEEE 802.3ad) is the guy who:<\/p>\n\n\n\n\nNegotiates<\/strong> whether or not a set of interfaces can form a LAG;<\/li>\n\n\n\nDecides which<\/strong> interfaces in the group will be active<\/strong> and which will be backed up<\/strong>;<\/li>\n\n\n\nMaintains LAG status: if a link goes down, it can activate another link that was on standby;<\/li>\n\n\n\n Detects configuration\/mismatch problems (speed, duplex, mode, etc.) and avoids aggregating incompatible links.<\/li>\n<\/ul>\n\n\n\nAt Huawei, when Eth-Trunk is in static LACP<\/strong>, the member interfaces:<\/p>\n\n\n\n\nBy exchanging LACPDUs<\/strong>, they report:\n\nSystem priority<\/strong> (device priority),<\/li>\n\n\n\nSystem ID<\/strong> (usually the system MAC),<\/li>\n\n\n\nInterface priority<\/strong>,<\/li>\n\n\n\nInterface number<\/strong>,<\/li>\n\n\n\nKey<\/strong> (logical identifier of the LAG).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\nThe side with the highest system priority<\/strong> (lowest numerical value) becomes the Actor<\/strong>. From there: <\/p>\n\n\n\n\nThe Actor decides which ports will be active<\/strong> (based on priority and policies \/ thresholds);<\/li>\n\n\n\nThe other side follows this decision to maintain consistency.<\/li>\n<\/ul>\n\n\n\nWhat needs to be “OK” for LAG to rise properly<\/h2>\n\n\n\n For an Eth-Trunk with LACP to work as expected, certain points need to be aligned between the two sides:<\/p>\n\n\n\n
\nSame idea as LAG\/Key<\/strong> (the doors that will form the same Eth-Trunk on each side);<\/li>\n\n\n\nSame speed<\/strong> and duplex<\/strong> on the physical ports;<\/li>\n\n\n\nSame type of LACP mode<\/strong> (static LACP on both sides);<\/li>\n\n\n\nCoherent limits of:\n\nminimum number of active links (lower threshold),<\/li>\n\n\n\n maximum number of active links (upper threshold), if used;<\/li>\n<\/ul>\n<\/li>\n\n\n\n Minimum compatibility in LACP timers (fast\/slow) and active\/passive<\/strong> mode (the two sides in passive do not negotiate).<\/li>\n<\/ul>\n\n\n\nWhat LACP does is use system priority + system ID + interface priority + interface number<\/strong> to:<\/p>\n\n\n\n\nDecide who the actor<\/strong> is;<\/li>\n\n\n\nChoose which ports are active<\/strong> and which are backed up<\/strong>.<\/li>\n<\/ul>\n\n\n\nEntering MC-LAG<\/h2>\n\n\n\n So far we’ve been talking about “normal” LAG, i.e. between two devices<\/strong> only.<\/p>\n\n\n\nMC-LAG<\/strong> (Multi-Chassis LAG) comes in when you want it:<\/p>\n\n\n\n\nA single LAG from the customer’s point of view (CE)<\/strong>,<\/li>\n\n\n\nBut actually terminating in two different devices<\/strong> (for example, two PEs\/edge routers).<\/li>\n<\/ul>\n\n\n\nThe idea is simple:<\/p>\n\n\n\n
\nOn the EC<\/strong> side, you can see a single Eth-Trunk<\/strong> with several doors;<\/li>\n\n\n\nPhysically, these ports go to two different PEs<\/strong>;<\/li>\n\n\n\nOn the operator’s side, these two PEs “combine” to look like a single device in terms of LACP.<\/li>\n<\/ul>\n\n\n\nMC-LAG’s main objective:<\/p>\n\n\n\n
\nIf an entire PE<\/strong> dies (equipment failure, reload, etc.),<\/li>\n\n\n\nThe other PE<\/strong> takes over and the CE continues with the same LAG, without changing IP, MAC, gateway etc.<\/li>\n<\/ul>\n\n\n\nIt’s basically taking the idea of redundancy from the port\/link level to the device<\/strong> level.<\/p>\n\n\n\n
Active\/active vs active\/backup<\/h2>\n\n\n\n In many vendors you can find MC-LAG in two flavors:<\/p>\n\n\n\n
\nActive\/active<\/strong>: both devices forward traffic at the same time;<\/li>\n\n\n\nActive\/backup<\/strong>: only one device is the “owner” of the LAG at any given time; the other is backed up.<\/li>\n<\/ul>\n\n\n\nAt Huawei<\/strong>, for this specific scenario with E-Trunk\/mLACP, the behavior is active\/backup<\/strong>:<\/p>\n\n\n\n\nOne side is the master<\/strong> (active),<\/li>\n\n\n\nThe other side is backup<\/strong> (the links are logical down from the EC’s point of view),<\/li>\n\n\n\nOn failure, there is a switchover<\/strong> from the master role to the other device.<\/li>\n<\/ul>\n\n\n\nMC-LAG at Huawei: E-Trunk vs mLACP<\/h2>\n\n\n\n In Huawei, there are two main ways of implementing MC-LAG:<\/p>\n\n\n\n
\nE-Trunk (Enhanced Trunk)<\/strong><\/li>\n\n\n\nmLACP (Multi-chassis LACP)<\/strong><\/li>\n<\/ol>\n\n\n\n\n\nBoth have the same goal:<\/p>\n“Trick” the CE into thinking it’s talking to just one<\/strong> device, even though there are two PEs behind it.<\/cite><\/blockquote>\n<\/blockquote>\n\n\n\nThe difference lies in the control mechanism<\/strong> between the PEs:<\/p>\n\n\n\n\nE-Trunk<\/strong>\n\nIt uses its own channel (UDP) between the PEs, with Hello<\/strong> and timeout<\/strong>;<\/li>\n\n\n\nExchanges status information of the Eth-Trunks participating in that E-Trunk;<\/li>\n\n\n\n Defines who is master<\/strong> and who is backup<\/strong> based on E-Trunk priority<\/strong> (lowest value = highest priority);<\/li>\n\n\n\nControls whether the local Eth-Trunk is up<\/strong> or down<\/strong> according to the role (master\/backup) and status of the peer.<\/li>\n<\/ul>\n<\/li>\n\n\n\nmLACP<\/strong>\n\nIt uses ICCP<\/strong> running over LDP<\/strong> between the PEs (RG – Redundancy Group);<\/li>\n\n\n\nSynchronizes LACP configuration and status<\/strong> via ICCP;<\/li>\n\n\n\nDefine master\/backup using mLACP system priority<\/strong>, system ID<\/strong> and port priority<\/strong>;<\/li>\n\n\n\nIt integrates in a more “SP standard” way with other ICCP functions (VRRP, redundant VPNs, etc.).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\nIn this article, we’ll focus on E-Trunk<\/strong>, which is the “classic<\/strong>” form of MC-LAG in many PE-CE scenarios.<\/p>\n\n\n\nHow E-Trunk works<\/h2>\n\n\n\n Don’t confuse E-Trunk (the sync technology between chassis) with Eth-Trunk (the link-aggregation itself).<\/p>\n\n\n\n
Consider the following scenario:<\/p>\n\n\n\n
\nCE dual-homed in two PEs (PE1 and PE2);<\/li>\n\n\n\n In the EC, you create a single Eth-Trunk<\/strong>, with the doors going to both PEs;<\/li>\n\n\n\nIn the EPs:\n\nYou create the same Eth-Trunk ID<\/strong> on PE1 and PE2;<\/li>\n\n\n\nPlace the corresponding physical interfaces on each Eth-Trunk;<\/li>\n\n\n\n Add this Eth-Trunk to an E-Trunk<\/strong> with the same E-Trunk ID<\/strong> on both sides.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\nThe PEs then:<\/p>\n\n\n\n
\nThey create an E-Trunk (UDP) channel between themselves (using loopback IPs, usually);<\/li>\n\n\n\n They exchange E-Trunk messages with:\n\nE-Trunk ID<\/strong>,<\/li>\n\n\n\nE-Trunk priority<\/strong>,<\/li>\n\n\n\nInformation on Eth-Trunks members and their status;<\/li>\n<\/ul>\n<\/li>\n\n\n\n They define who is master<\/strong> and who is backup<\/strong>:\n
![\"\"](\"https:\/\/made4it.com.br\/wp-content\/uploads\/2025\/11\/eth-trunk.png\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/made4it.com.br\/wp-content\/uploads\/2025\/11\/eth-trunk-2.png\")
<\/figure><\/div>\n\n\n