Upgrading an M-LAG member doesn't have to cost a single packet — but only if the traffic leaves before the software update starts, and comes back only after the tables have resynced. This is the route-cost-and-downlink-down sequence that shifts traffic off the member being upgraded, the verification gate at each stage, and the rollback point if the traffic switch never actually completes.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
M-LAG lossless upgrade doesn't make the upgrading switch invisible to traffic — it moves the traffic somewhere else first, upgrades the empty seat, then moves it back.
M-LAG lossless upgrade is the practice of switching traffic onto the backup link before the M-LAG member being upgraded goes down, so the business doesn't feel the software update at all. In a typical pair, Leaf1 and Leaf2 form the M-LAG, both reach the rest of the network over a dynamic routing protocol, and servers dual-home to the pair. The sequencing adjusts Leaf1's route cost and advertisement priority and sets its downlink interface Down, waits for the traffic to actually move to Leaf2, upgrades Leaf1, then reverses all three settings once Leaf1 is healthy again — and repeats the same sequence for Leaf2.
None of this works if the pair isn't healthy to begin with. Before scheduling this upgrade, confirm the M-LAG's peer-link state and DFS pairing the same way you would when diagnosing an M-LAG fault — the diagnostic order in our M-LAG troubleshooting note is worth running as a pre-upgrade gate, not just a post-failure one.
Each phase exists to make sure traffic only ever moves once it's confirmed to have somewhere safe to go — and only moves back once the member it's returning to is confirmed healthy.
Diagram labels are kept in English for engineering clarity.
The templates named UpLinkSwitch, DownLinkSwitch, DownLinkSwitchDelete and UpLinkSwitchDelete are what actually perform each half of this shift — applying and removing them in the wrong order is what turns this into a lossy upgrade instead of a lossless one.
Six conditions, straight from the source procedure — the License, dual-homing, the supported protocols, and the two traffic patterns this sequence can't fully protect.
| Requirement | Detail | Why It Matters |
|---|---|---|
| License | CE-LIC-LU must be loaded and enabled; it is off by default on new devices. | Without it, the lossless upgrade feature itself isn't available, no matter how carefully the sequence below is followed. |
| Dual-homing | Servers, firewalls and load balancers must dual-home to the M-LAG group over LACP, with server NICs in mode4 bond. | Any single-homed device downstream has nowhere for its traffic to shift to when its member goes down for upgrade. |
| Routing protocol | OSPF, OSPFv3, BGP or BGP4+. | Other protocols aren't covered by the route-cost and advertisement-priority mechanism this sequence relies on. |
| Multicast | Not supported. | Multicast traffic doesn't follow the same route-cost-driven switch and will drop regardless of how well the rest of the sequence is executed. |
| East-west traffic | L2/L3 traffic between servers under the same M-LAG group cannot reach 0 packet loss during the switch. | Set expectations before the maintenance window: “zero-loss” describes the routed north-south path, not this specific east-west pattern. |
| PE / BorderLeaf escape link | When PE and BorderLeaf connect in a square topology, an escape link between the PE groups is mandatory. | Without it, a BorderLeaf being upgraded has nowhere to send its traffic, and this sequencing has nothing to switch onto. |
Source: AI data center network solution maintenance documentation, switch M-LAG lossless upgrade procedure.
Four controller-delivered templates, applied through Network Element Management > Device-Specific Programming, do the actual work of shifting and restoring traffic.
| Template | Applied To | Effect |
|---|---|---|
| UpLinkSwitch | Leaf being taken out for upgrade | Adjusts route cost and route advertisement priority so upstream traffic prefers the peer. |
| DownLinkSwitch | Same Leaf, after route convergence is confirmed | Sets the downlink Eth-Trunk member port joined to M-LAG Down. |
| DownLinkSwitchDelete | Same Leaf, post-upgrade | Restores the downlink Eth-Trunk member port to Up, once M-LAG member-port ARP/ND/MAC entries have resynced. |
| UpLinkSwitchDelete | Same Leaf, post-upgrade | Restores route cost and advertisement priority, switching routed traffic back to this Leaf. |
<HUAWEI> display ip routing-table vpn-instance vpn-name
Route Flags: R - relay, D - download to fib, T - to vpn-instance
Destination/Mask Proto Pre Cost Flags NextHop Interface
<HUAWEI> display interface brief
PHY: Physical
*down: administratively down
Interface PHY Protocol InUti OutUti inErrors outErrors
<HUAWEI> display ip routing-table vpn-instance vpn-name
<HUAWEI> display interface briefSource: AI data center network solution maintenance documentation — the same two commands verify both the switch-out and the switch-back.
Same sequence as above — here's what happens when a gate gets skipped, and what to check instead.
RISKThe source documentation excludes multicast services from this mechanism entirely — multicast doesn't follow the route-cost-and-advertisement-priority shift, so it drops when the member goes down, regardless of how carefully the rest of the sequence is executed.
SAFER PRACTICEIdentify any multicast services riding on this M-LAG pair before scheduling the window, and set separate expectations for them — this sequence protects the routed unicast path, not multicast.
RISKThe source documentation is explicit: east-west L2/L3 traffic between servers dual-homed to the same M-LAG group cannot reach 0 packet loss during the switchover, no matter how correctly the sequence runs.
SAFER PRACTICECommunicate this limitation to application owners before the window — “zero-loss” in this context means the routed north-south traffic, and east-west flows between co-located servers are the one pattern this sequencing was never meant to fully cover.
RISKCE-LIC-LU controls this feature, and the source documentation notes it is not enabled by default on newly purchased devices even when the hardware supports it — attempting the sequence without it means the templates either aren't available or don't behave as expected.
SAFER PRACTICEConfirm CE-LIC-LU is loaded and enabled on both Leaf devices while you're still building the maintenance plan, not while the window is already open.
RISKThe sequence applies UpLinkSwitch first, then waits for confirmed route convergence, and only then applies DownLinkSwitch. Reversing that order — or skipping the wait — brings the downlink down while traffic is still routed through the Leaf about to be upgraded.
SAFER PRACTICETreat the routing-table and interface checks after UpLinkSwitch as a hard gate, not a formality — don't apply DownLinkSwitch until display ip routing-table confirms convergence and traffic has actually moved.
RISKDownLinkSwitchDelete brings the downlink back Up, but if the switch-back to route traffic happens before M-LAG member-port ARP, ND and MAC entries have resynced, the return path carries stale forwarding state and drops packets.
SAFER PRACTICEAfter restoring the interface Up, verify the synced entries have recovered before applying UpLinkSwitchDelete — the entry resync is the gate for the route switchback, not the other way around.
Confirm CE-LIC-LU is enabled and the M-LAG pair's peer-link is healthy before you start — if a dual-homed firewall or load balancer sits on this same pair, its own upgrade sequencing follows a similar isolate-verify-switchover discipline, worth cross-checking against our firewall upgrade maintenance note if both devices are due in the same window.
Pulled straight from the field — the ones worth having an answer ready for.
No — the source documentation is explicit that east-west L2/L3 traffic between servers dual-homed to the same M-LAG group cannot reach 0 packet loss during the switchover. “Zero-loss” describes the routed north-south traffic that the route-cost, advertisement-priority and downlink-down templates redirect away before the member being upgraded goes down.
No. The source documentation explicitly excludes multicast services from lossless upgrade support — plan for multicast traffic to be affected regardless of how carefully this sequence is followed.
OSPF, OSPFv3, BGP or BGP4+, per the source documentation. Other routing protocols aren't covered by the route-cost and advertisement-priority mechanism this sequence depends on.
Yes — CE-LIC-LU, the M-LAG lossless upgrade license control item. It's off by default on newly purchased devices, even when the hardware technically supports the feature, so confirm it's loaded before scheduling the window.
Then this sequencing can't fully protect BorderLeaf upgrades in a square (PE-BorderLeaf loop) topology — the source documentation requires an escape link between PE groups specifically so traffic has somewhere to go while one BorderLeaf is being upgraded.
No — skipping the route-side and interface-down templates, or not waiting for the convergence check between them, means Leaf1 goes down for upgrade while still carrying live traffic, producing exactly the loss this sequencing exists to avoid.
This note follows the switch M-LAG lossless upgrade procedure from the AI data center network solution's maintenance documentation, orchestrated through iMaster NCE-Fabric's Southbound Open Services templates shown here. It assumes OSPF, OSPFv3, BGP or BGP4+ as the routing protocol, and explicitly does not cover multicast traffic or make any zero-loss claim for east-west traffic between servers on the same M-LAG group — both are called out as exceptions in the source documentation itself, not gaps in this summary.
Send us the peer-link and DFS pairing state, whether CE-LIC-LU is loaded, and which routing protocol you're running, and we'll help you confirm this sequence will hold before you schedule the window.