Mettre à niveau un membre M-LAG ne coûte pas forcément un seul paquet — mais uniquement si le trafic part avant le début de la mise à jour logicielle, et ne revient qu'une fois les tables resynchronisées. Voici le séquencement par coût de route et mise à Down du lien descendant qui déplace le trafic hors du membre en cours de mise à niveau, la porte de vérification à chaque étape, et le point de retour arrière si la bascule de trafic n'aboutit jamais.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
La mise à niveau sans perte M-LAG ne rend pas le commutateur en cours de mise à niveau invisible au trafic — elle déplace d'abord le trafic ailleurs, met à niveau le siège vide, puis le ramène.
La mise à niveau sans perte M-LAG consiste à basculer le trafic sur le lien de secours avant que le membre M-LAG en cours de mise à niveau ne soit mis hors ligne, de sorte que l'activité ne ressente absolument pas la mise à jour logicielle. Dans une paire typique, Leaf1 et Leaf2 forment le M-LAG, tous deux atteignent le reste du réseau via un protocole de routage dynamique, et les serveurs sont doublement rattachés à la paire. Le séquencement ajuste le coût de route et la priorité d'annonce de Leaf1 et met son interface descendante à Down, attend que le trafic bascule réellement vers Leaf2, met à niveau Leaf1, puis inverse les trois réglages une fois Leaf1 de nouveau sain — et répète la même séquence pour Leaf2.
Rien de tout cela ne fonctionne si la paire n'est pas saine au départ. Avant de planifier cette mise à niveau, vérifiez l'état du peer-link et le pairage DFS du M-LAG de la même manière que pour diagnostiquer une panne M-LAG — l'ordre de diagnostic de notre note de dépannage M-LAG mérite d'être exécuté comme une porte avant mise à niveau, pas seulement après une panne.
Chaque phase existe pour s'assurer que le trafic ne se déplace que lorsqu'il est confirmé qu'il a un endroit sûr où aller — et ne revient que lorsque le membre vers lequel il retourne est confirmé sain.
Les libellés du schéma sont conservés en anglais pour plus de clarté technique.
Les modèles nommés UpLinkSwitch, DownLinkSwitch, DownLinkSwitchDelete et UpLinkSwitchDelete sont ce qui exécute réellement chaque moitié de ce basculement — les appliquer et les retirer dans le mauvais ordre est ce qui transforme cette mise à niveau sans perte en mise à niveau avec perte.
Six conditions, directement issues de la procédure source — la License, le double rattachement, les protocoles pris en charge, et les deux schémas de trafic que ce séquencement ne peut pas entièrement protéger.
| Exigence | Détail | Pourquoi c'est important |
|---|---|---|
| License | CE-LIC-LU doit être chargé et activé ; il est désactivé par défaut sur les nouveaux équipements. | Sans lui, la fonctionnalité de mise à niveau sans perte elle-même n'est pas disponible, quelle que soit la rigueur avec laquelle la séquence ci-dessous est suivie. |
| Double rattachement | Les serveurs, pare-feux et répartiteurs de charge doivent être doublement rattachés au groupe M-LAG via LACP, avec les cartes réseau des serveurs en agrégation mode4. | Tout équipement en aval à rattachement simple n'a nulle part où faire basculer son trafic quand son membre est mis hors ligne pour la mise à niveau. |
| Protocole de routage | OSPF, OSPFv3, BGP ou BGP4+. | Les autres protocoles ne sont pas couverts par le mécanisme de coût de route et de priorité d'annonce sur lequel repose cette séquence. |
| Multidiffusion | Non pris en charge. | Le trafic multidiffusion ne suit pas le même basculement piloté par le coût de route et sera perdu quelle que soit la qualité d'exécution du reste de la séquence. |
| Trafic est-ouest | Le trafic L2/L3 entre serveurs sous le même groupe M-LAG ne peut pas atteindre 0 perte de paquets pendant le basculement. | Fixez les attentes avant la fenêtre de maintenance : « sans perte » décrit le chemin routé nord-sud, pas ce schéma est-ouest spécifique. |
| Lien d'échappement PE / BorderLeaf | Quand PE et BorderLeaf se connectent selon une topologie carrée, un lien d'échappement entre les groupes PE est obligatoire. | Sans lui, un BorderLeaf en cours de mise à niveau n'a nulle part où envoyer son trafic, et ce séquencement n'a rien vers quoi basculer. |
Source : documentation de maintenance de la solution de réseau de centre de données IA, procédure de mise à niveau sans perte M-LAG du commutateur.
Quatre modèles délivrés par le contrôleur, appliqués via Gestion des éléments réseau > Programmation spécifique à l'équipement, effectuent le travail réel de basculement et de restauration du trafic.
| Modèle | Appliqué à | Effet |
|---|---|---|
| UpLinkSwitch | Leaf mis hors service pour la mise à niveau | Ajuste le coût de route et la priorité d'annonce de route pour que le trafic amont préfère le pair. |
| DownLinkSwitch | Même Leaf, après confirmation de la convergence de route | Met à Down le port membre Eth-Trunk descendant rattaché au M-LAG. |
| DownLinkSwitchDelete | Même Leaf, après la mise à niveau | Restaure à Up le port membre Eth-Trunk descendant, une fois que les entrées ARP/ND/MAC du port membre M-LAG se sont resynchronisées. |
| UpLinkSwitchDelete | Même Leaf, après la mise à niveau | Restaure le coût de route et la priorité d'annonce, faisant revenir le trafic routé vers ce 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 : documentation de maintenance de la solution de réseau de centre de données IA — les deux mêmes commandes vérifient à la fois le basculement sortant et le basculement retour.
Même séquence que ci-dessus — voici ce qui se passe quand une porte est sautée, et ce qu'il faut vérifier à la place.
RISQUELa documentation source exclut entièrement les services de multidiffusion de ce mécanisme — la multidiffusion ne suit pas le basculement par coût de route et priorité d'annonce, donc elle est perdue quand le membre est mis hors ligne, quelle que soit la rigueur avec laquelle le reste de la séquence est exécuté.
PRATIQUE PLUS SÛREIdentifiez tous les services de multidiffusion portés par cette paire M-LAG avant de planifier la fenêtre, et fixez des attentes séparées pour eux — cette séquence protège le chemin unicast routé, pas la multidiffusion.
RISQUELa documentation source est explicite : le trafic L2/L3 est-ouest entre serveurs doublement rattachés au même groupe M-LAG ne peut pas atteindre 0 perte de paquets pendant le basculement, quelle que soit la justesse d'exécution de la séquence.
PRATIQUE PLUS SÛRECommuniquez cette limitation aux propriétaires d'applications avant la fenêtre — « sans perte » dans ce contexte signifie le trafic nord-sud routé, et les flux est-ouest entre serveurs co-localisés sont le seul schéma que ce séquencement n'a jamais été conçu pour couvrir entièrement.
RISQUECE-LIC-LU contrôle cette fonctionnalité, et la documentation source note qu'elle n'est pas activée par défaut sur les équipements nouvellement achetés même quand le matériel la prend en charge — tenter la séquence sans elle signifie que les modèles ne sont pas disponibles ou ne se comportent pas comme prévu.
PRATIQUE PLUS SÛREConfirmez que CE-LIC-LU est chargé et activé sur les deux boîtiers Leaf pendant que vous élaborez encore le plan de maintenance, pas une fois la fenêtre déjà ouverte.
RISQUELa séquence applique d'abord UpLinkSwitch, attend ensuite la confirmation de la convergence de route, et applique seulement alors DownLinkSwitch. Inverser cet ordre — ou sauter l'attente — met le lien descendant à Down alors que le trafic est encore routé via le Leaf sur le point d'être mis à niveau.
PRATIQUE PLUS SÛRETraitez les vérifications de la table de routage et de l'interface après UpLinkSwitch comme une porte stricte, pas une formalité — n'appliquez pas DownLinkSwitch tant que display ip routing-table n'a pas confirmé la convergence et que le trafic n'a pas réellement basculé.
RISQUEDownLinkSwitchDelete remet le lien descendant à Up, mais si le basculement retour du trafic routé se produit avant que les entrées ARP, ND et MAC du port membre M-LAG ne se soient resynchronisées, le chemin de retour porte un état de transfert obsolète et perd des paquets.
PRATIQUE PLUS SÛREAprès avoir restauré l'interface à Up, vérifiez que les entrées synchronisées se sont rétablies avant d'appliquer UpLinkSwitchDelete — la resynchronisation des entrées est la porte du basculement retour de route, pas l'inverse.
Confirmez que CE-LIC-LU est activé et que le peer-link de la paire M-LAG est sain avant de commencer — si un pare-feu ou un répartiteur de charge doublement rattaché se trouve sur cette même paire, son propre séquencement de mise à niveau suit une discipline similaire d'isolement-vérification-bascule, qu'il vaut la peine de recouper avec notre note de maintenance de mise à niveau de pare-feu si les deux équipements sont prévus dans la même fenêtre.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Non — la documentation source précise explicitement que le trafic L2/L3 est-ouest entre serveurs doublement rattachés au même groupe M-LAG ne peut pas atteindre 0 perte de paquets pendant le basculement. « Sans perte » décrit le trafic nord-sud routé que les modèles de coût de route, de priorité d'annonce et de mise à Down du lien descendant redirigent avant que le membre en cours de mise à niveau ne soit mis hors ligne.
Non. La documentation source exclut explicitement les services de multidiffusion de la prise en charge de la mise à niveau sans perte — prévoyez que le trafic multidiffusion sera affecté, quelle que soit la rigueur avec laquelle cette séquence est suivie.
OSPF, OSPFv3, BGP ou BGP4+, selon la documentation source. Les autres protocoles de routage ne sont pas couverts par le mécanisme de coût de route et de priorité d'annonce dont dépend cette séquence.
Oui — CE-LIC-LU, l'élément de contrôle de License de mise à niveau sans perte M-LAG. Il est désactivé par défaut sur les équipements nouvellement achetés, même quand le matériel prend techniquement en charge la fonctionnalité, alors confirmez qu'il est chargé avant de planifier la fenêtre.
Alors ce séquencement ne peut pas entièrement protéger les mises à niveau de BorderLeaf dans une topologie carrée (boucle PE-BorderLeaf) — la documentation source exige un lien d'échappement entre les groupes PE précisément pour que le trafic ait un endroit où aller pendant qu'un BorderLeaf est mis à niveau.
Non — sauter les modèles côté route et de mise à Down de l'interface, ou ne pas attendre la vérification de convergence entre eux, signifie que Leaf1 est mis hors ligne pour la mise à niveau alors qu'il transporte encore du trafic en direct, produisant exactement la perte que ce séquencement existe pour éviter.
Cette note suit la procédure de mise à niveau sans perte M-LAG du commutateur issue de la documentation de maintenance de la solution de réseau de centre de données IA, orchestrée via les modèles Southbound Open Services d'iMaster NCE-Fabric présentés ici. Elle suppose OSPF, OSPFv3, BGP ou BGP4+ comme protocole de routage, et ne couvre explicitement pas le trafic multidiffusion ni ne fait d'affirmation sans perte pour le trafic est-ouest entre serveurs du même groupe M-LAG — les deux sont signalés comme exceptions dans la documentation source elle-même, pas comme des lacunes de ce résumé.
Envoyez-nous l'état du peer-link et du pairage DFS, si CE-LIC-LU est chargé, et le protocole de routage que vous utilisez, et nous vous aiderons à confirmer que cette séquence tiendra avant de planifier la fenêtre.