Mise à niveau du firmware des commutateurs sans interruption de service : stratégie de déploiement, vérifications et plan de repli

Un upgrade de firmware de switch sans interruption semble être une promesse qui échoue souvent sur des détails en pratique : un uplink unique sans LACP, un chemin STP mal configuré, un stack avec des modèles mélangés ou une image qui démarre mais active de nouveaux paramètres par défaut. Parallèlement, les mises à jour de firmware ne sont pas un « nice to have ». Elles comblent des vulnérabilités, corrigent des fuites mémoire, améliorent l’interopérabilité (p. ex. pour LACP, BGP/EVPN ou PoE) et stabilisent l’exploitation.

Cet article montre comment planifier et déployer des mises à jour de firmware de manière à ce que les utilisateurs et les systèmes, idéalement, n’en perçoivent rien. L’accent n’est pas mis sur les commandes spécifiques aux fabricants, mais sur la logique opérationnelle : quelle redondance est réellement nécessaire, quelles vérifications préalables sont indispensables, comment se déroule un déploiement par paliers sur Access/Distribution/Core et à quoi ressemble un plan de rollback robuste – y compris les embûches typiques et les points de monitoring.

Pourquoi « sans interruption » pour les switches est parfois vrai – et parfois non

« Sans interruption » signifie en réseau généralement : aucune interruption perceptible pour les services connectés. Techniquement, il peut néanmoins y avoir de courts événements : pertes de paquets isolées, une reconvergence de routage, un changement de topologie STP ou un link‑flap. Que cela soit considéré comme une downtime dépend de vos applications (VoIP, OT, Storage, VDI), des timeouts et de votre redondance.

Important : une mise à jour de firmware n’est pas automatiquement « hitless ». Les fabricants proposent des mécanismes tels que ISSU (In‑Service Software Upgrade, mise à jour en cours d’exploitation), « non-disruptive upgrade », « rolling upgrade » dans les stacks ou des chemins de mise à jour pour MLAG/vPC. Ces procédures ne fonctionnent que si certaines conditions sont réunies : révisions matérielles compatibles, combinaisons de jeux de fonctionnalités prises en charge, images identiques, versions de bootloader appropriées, architecture Dual‑Control‑Plane correcte ou partenaires LACP stables.

Conditions préalables pour un upgrade de firmware de switch sans interruption

La possibilité d’effectuer un upgrade sans interruption perceptible se joue en amont. Vérifiez ces points avant de télécharger la moindre image :

1) Redundanz ist kein Label, sondern ein Nachweis

« Dual‑homed » n’est fiable que si chaque liaison critique est redondante — et ce, jusqu’à la couche suivante (Distribution/Core) puis jusqu’aux routeurs passerelle. Modèles typiques :

• LACP (Link Aggregation Control Protocol) : regroupe plusieurs liaisons physiques en un port‑channel logique. Si une liaison tombe, le channel reste actif. Condition : algorithme de hachage correct, MTU identique, mêmes paramètres VLAN et STP sur tous les ports membres.
• MLAG/vPC : deux switches apparaissent en aval comme un partenaire LACP logique. Avantage : redondance sans blocage STP sur les uplinks d’accès. Risque : le design du peer‑link/keepalive et la protection contre le split‑brain doivent être correctement conçus.

Si un Access-Switch n’a qu’un seul uplink ou si un serveur n’utilise qu’une seule NIC sans bonding/teaming, « sans interruption » n’est pas atteignable. L’objectif est alors plutôt : minimiser et contrôler les temps d’arrêt.

2) Control Plane vs. Data Plane verstehen

Pour les exploitants, la séparation est cruciale : la Data Plane achemine les paquets (ASICs/forwarding), la Control Plane calcule les tables et les voisinages (STP, OSPF/BGP, ARP/ND). Une mise à niveau hitless tente de maintenir le forwarding stable le plus longtemps possible, tandis que la Control Plane redémarre ou bascule vers une seconde Supervisor/Route-Engine. Cela peut échouer si des fonctionnalités utilisées ne sont pas prises en charge pendant l’ISSU (par ex. certains modules de télémétrie, PBR, profils QoS spécifiques, MACsec, combinaisons VXLAN/EVPN selon la release).

3) Management-Zugang und Out-of-Band müssen stehen

Sans OOB-Management (Out-of-Band, réseau de gestion séparé), un rollout est risqué : si le réseau in-band vacille brièvement, vous perdez l’accès précisément au moment où vous en avez besoin. Au minimum requis : un AAA cohérent (RADIUS/TACACS), des comptes de secours locaux, des consoles serveur accessibles ou un processus Remote-Hands.

4) Konfigurations- und Zustandsdaten sichern

Une mise à jour du firmware ne modifie pas seulement le logiciel, mais parfois aussi : bootloader, valeurs par défaut, feature flags, formats de base de données pour la configuration ou les stores de certificats/clefs. Sauvegardez donc :

• Configuration en cours (running) et configuration de démarrage (startup)
• Jeu d’images actuel (incl. image secondaire/de sauvegarde, si disponible)
• Inventaire : modèle, numéro de série, révision matérielle, état PSU/ventilateur
• États opérationnels importants : STP-Root, état MLAG/vPC, adjacences de routage, état des Port-Channels

Rollout-Strategie: So planen Sie den Upgrade-Pfad über Access, Distribution und Core

La meilleure stratégie de mise à niveau s’articule autour des domaines de défaillance et des dépendances. Un principe simple et robuste en pratique : d’abord les périphéries, puis le centre – mais avec discernement.

Phase 0: Readiness-Check und Change-Plan

Élaborez un Change-Plan qui ne se contente pas de « effectuer la mise à niveau », mais qui contient des critères mesurables : Go/No-Go, seuils de monitoring, déclencheurs de rollback, voie de communication et calendrier. Si vous travaillez selon ITIL : un plan de backout est obligatoire, mais il doit être techniquement exécutable (voir ci‑dessous).

Phase 1: Lab/Canary – eine repräsentative Teilmenge

Commencez par un Canary : un commutateur ou une paire (MLAG/vPC) dans un segment représentatif (mêmes fonctionnalités, VLANs similaires, mêmes Optics/Transceivers) – mais exploitable d’un point de vue opérationnel. L’objectif n’est pas seulement qu’il « démarre », mais : qu’il fonctionne de manière stable sous votre charge et votre monitoring.

Phase 2: Mise à niveau progressive de la couche d’accès

Les commutateurs d’accès sont souvent nombreux, mais individuellement moins critiques. Si les terminaux sont dual-homed (p. ex. serveurs avec LACP vers deux commutateurs d’accès ou vers une paire MLAG), vous pouvez mettre à niveau les équipements d’accès l’un après l’autre. Si les terminaux sont single-homed, définissez explicitement que de courtes interruptions sont possibles – et planifiez-les dans une fenêtre de maintenance.

Phase 3: Distribution/Leaf – par paires et avec vérifications d’état

Dans la distribution (ou au niveau Leaf dans une architecture Spine-Leaf), les mécanismes MLAG/vPC/EVPN sont plus fréquents. Ici, la mise à niveau « sans downtime » devient réaliste si vous procédez par paires : d’abord le switch A, vérification de la stabilité, puis le switch B. Il est important que les peer-links et keepalives restent stables pendant l’opération.

Phase 4: Core/Spine – uniquement avec convergence de routage assurée

Au niveau Core ou Spine, l’impact est le plus important. Même si les chemins de données sont redondants, un redémarrage du control plane peut entraîner une reconstruction de BGP/OSPF. Planifiez ici de manière délibérée : évitez les changements de route-policy, ne modifiez pas les timers « on the fly », et vérifiez au préalable si vos applications tolèrent de courts événements de routage. Pour les réseaux de stockage (iSCSI/NFS) : adoptez une planification particulièrement conservatrice, car de courtes pertes de paquets peuvent déjà affecter les sessions.

Pièges typiques qui font échouer le « hitless » en pratique

De nombreuses pannes lors d’un déploiement de firmware ne sont pas des bugs mystérieux, mais des schémas récurrents :

• Redondance asymétrique : deux uplinks existent, mais un seul transporte les VLANs ou la MTU est différente. En cas de bascule, il y a du blackholing.
• Surprises liées à STP : Spanning Tree (prévention des boucles au niveau Layer 2) réagit aux événements de lien. Une mise à niveau peut déclencher des changements de topologie entraînant un blocage temporaire – particulièrement si le root est mal positionné ou si les paramètres PortFast/Edge sont incohérents.
• MLAG/vPC-Split-Brain : le peer-keepalive circule sur le même réseau que le peer-link ou est trop fragile. S’il disparaît, des situations dual-active peuvent survenir.
• Stacks avec générations mixtes : le rolling-upgrade est limité voire impossible. Un membre redémarre et entraîne l’état du stack.
• Compatibilité Transceiver/Optics : après la mise à niveau, les optics tiers peuvent être contrôlés plus strictement ou l’interprétation du DOM/EEPROM peut changer. Résultat : les liens restent down.
• Dépendances Bootloader/ROMMON : la nouvelle image peut exiger une mise à jour du bootloader. Si cette étape est sautée, le switch peut ne pas démarrer après le reboot.
• Feature-flags et valeurs par défaut : des fonctions de sécurité (p. ex. paramètres crypto SSH plus stricts, versions TLS, obligations SNMPv3) évoluent. Les outils de management perdent l’accès.

Vérifications préalables : liste de contrôle pour inventaire, compatibilité et risques

Les contrôles suivants sont formulés de manière à pouvoir être intégrés dans votre Runbook. Les commandes des constructeurs varient, la logique reste la même.

Inventaire et dépendances (obligatoire)

• Version de firmware actuelle et version cible prévue ; vérifier si une étape intermédiaire est nécessaire (chemin de mise à jour).
• Révisions matérielles, membres de stack, modules Supervisor/RE, état des PSU/ventilateurs.
• Fonctionnalités utilisées : MLAG/vPC, VXLAN/EVPN, MACsec, PBR, NetFlow/sFlow, télémétrie, DHCP Snooping, Dynamic ARP Inspection, 802.1X.
• Gestion : AAA, politiques SSH, SNMP (v2c/v3), Syslog, NTP, certificats.
• Systèmes dépendants : NAC, monitoring, sauvegarde de configuration, IPAM/DCIM, outils d’automatisation.

Validation de la redondance (preuve plutôt que présomption)

Testez le basculement avant la mise à jour. Le test doit être réaliste : pas seulement « tirer le lien », mais aussi vérifier si le trafic bascule réellement. Étapes recommandées :

1. Recueillir des valeurs de référence (latence, perte de paquets, compteurs d’erreurs d’interface, CPU/mémoire des switches).
2. Désactiver brièvement l’uplink A, observer : les sessions restent-elles stables, STP/routage converge-t-il, la perte de paquets augmente-t-elle ?
3. Réactiver l’uplink A, mêmes observations.
4. Idem pour l’uplink B.

Si le basculement n’est déjà pas propre en exploitation normale, une mise à jour de firmware ne résoudra pas le problème — elle ne fera que le rendre visible.

Préparation du monitoring et du logging

Pour une mise à jour sans downtime, vous avez besoin d’« yeux et oreilles » : SNMP/télémétrie en streaming, Syslog, éventuellement suivi des erreurs d’interface. Surveillez les compteurs susceptibles d’être affectés lors des mises à jour : CRC/Alignment Errors, Input Drops, STP TCNs (Topology Change Notifications), LACP-Flaps, BGP Neighbor Down/Up.

Exécution en production : plan par étapes incluant pré- et post-contrôles

Ci-dessous un plan par étapes neutre vis-à-vis des fournisseurs. Utilisez-le comme modèle pour votre Runbook ; complétez par les commandes CLI spécifiques à votre plateforme.

Étape 1 : pré-contrôles immédiatement avant la modification

• Gel des changements pour les modifications parallèles (Firewall, Routing, VLAN, Storage), afin de séparer les effets.
• Sauvegarde de configuration (automatisée + vérification manuelle que le fichier est lisible).
• Tester l’accès de management : OOB accessible, login OK, Privileged Mode OK.
• Check d’état : pas de liaisons qui flappent, pas de taux d’erreurs élevés, pas de voisins de routage instables.

Étape 2 : gestion des images et intégrité

Ne copiez pas d’images « n’importe où » sur le switch. Utilisez une source contrôlée (repo interne, téléchargements signés du fournisseur) et vérifiez l’intégrité (hash) et l’espace de stockage. Exemple de vérification de hash sur un hôte d’administration :

# Beispiel: SHA256-Hash einer Firmware-Datei prüfen
sha256sum switch-firmware.bin
# Erwarteten Hash aus Herstellerquelle/Release-Notes gegenprüfen

Pourquoi c’est important : des images corrompues entraînent des boucles de démarrage ou des erreurs d’exécution étranges qui ne se manifestent qu’après le redémarrage. La vérification d’intégrité par hachage est une protection simple et peu coûteuse.

Étape 3 : Mise à niveau progressive sur paires (MLAG/vPC) — principe

Sur une paire de switches, le principe est toujours similaire, quel que soit son nom : vous maintenez un nœud en service pendant que l’autre est mis à niveau et redémarre. Trois contrôles sont essentiels :

• Peer-Link/Interconnect stable : le nœud restant doit maintenir correctement l’état de la paire.
• Downstream-LACP stable : les serveurs/accès doivent poursuivre leurs agrégations de liens.
• Gateway/Anycast stable : si vous utilisez des Anycast-Gateways, le basculement doit être propre.

Concrètement : mettre à niveau le nœud A, attendre qu’il soit entièrement de retour dans le cluster, que l’état soit synchronisé, puis procéder au nœud B.

Étape 4 : Mise à niveau des Stacks — particularités

En stacking, les membres partagent souvent un plan de contrôle. Certaines plates-formes permettent un « hitless/rolling », d’autres redémarrent le stack en tant qu’entité. Vérifiez donc à l’avance :

• Un hitless/rolling upgrade est-il du tout pris en charge pour votre modèle de stack et votre version ?
• La topologie du stack est-elle redondante (anneau plutôt que chaîne), de sorte qu’un redémarrage d’un membre ne sépare pas le stack ?
• Quel rôle joue le Master (Active) et comment s’effectue un switchover ?

Si le rolling n’est pas pris en charge, l’« sans interruption » n’est possible que si les équipements en dehors du stack sont connectés de manière redondante (p. ex. dual-homing vers deux stacks distincts) — sinon il y aura une interruption perceptible.

Étape 5 : Vérifications postérieures — pas seulement « Ping geht »

Beaucoup d’équipes clôturent une modification après une connexion réussie. Pour la stabilité, il vous faut davantage :

• Port-Channel/LACP : tous les membres up, pas de « suspended », pas de rééquilibrage inhabituel.
• STP : Root-Bridge comme prévu, pas de changements de topologie inattendus, pas de ports dans un état incorrect.
• Routage (si L3) : voisins up, routes complètes, ECMP actif, pas de flaps.
• Erreurs d’interface : CRC/Input Errors/Drops sans augmentation.
• Management : SNMP/Telemetry fonctionne, le Syslog arrive, NTP synchronisé, AAA OK.

Ce n’est qu’une fois ces points stabilisés que l’on passe au switch suivant.

Plan de rollback : ce qui fonctionne réellement en cas d’incident

Un rollback n’est pas un « on remet l’ancienne image », mais une procédure mécanique qui fonctionne même sous stress. Planifiez le rollback de sorte qu’il puisse être exécuté dans votre fenêtre de perturbation maximale tolérée (RTO dans le jargon opérationnel : Recovery Time Objective).

Définir les déclencheurs de rollback (au préalable !)

Sans déclencheurs clairs, les équipes discutent trop longtemps. Déclencheurs typiques justifiant un rollback immédiat :

• Core/Distribution : instabilité de routage (flaps de voisins) qui ne se stabilise pas en quelques minutes
• MLAG/vPC : indicateurs de Dual-Active/Split-Brain, Peer-Link instable
• Erreurs massives d’interface après mise à niveau (CRC/Drops augmentent fortement)
• Perte de management : pas d’accès via OOB ni Inband, seulement Remote Hands
• Incompatibilité inattendue : optiques/PoE/802.1X cessent de fonctionner massivement

Mécanismes de rollback : image, configuration, variables de boot

En pratique, il existe trois niveaux de rollback :

1. Démarrage sur l’image secondaire/de secours : de nombreux switches peuvent conserver une seconde image. C’est la voie la plus rapide si la nouvelle image est fondamentalement le problème.
2. Installation de rétrogradation : réinstallation de la version précédente. Attention : certaines plateformes n’autorisent pas une rétrogradation directe entre certaines versions majeures.
3. Rollback de configuration : si l’image est OK, mais que les valeurs par défaut des fonctions ou des modifications de l’analyseur interprètent la configuration différemment, vous avez besoin d’une sauvegarde de configuration vérifiée et, le cas échéant, d’ajustements.

Planifiez explicitement quel niveau vous rétrograderez en premier. Et : maintenez l’ancienne firmware disponible localement (repo + voie de transfert accessible), pas seulement « sur Internet ».

Test de rollback en environnement canary obligatoire

L’erreur de rollback la plus fréquente : personne ne l’a exercée. Dans un environnement canary, vous devez donc au minimum jouer une fois le « démarrage sur l’image précédente » et la restauration d’une sauvegarde de configuration. Objectif : savoir combien de temps cela prend et quels états intermédiaires sont critiques (p. ex. synchronisation MLAG temporairement manquante).

Dépannage pendant et après la mise à niveau : chemins de diagnostic rapides

Si, après la mise à niveau, quelque chose semble « bizarre », un chemin de diagnostic court et standardisé est utile, plutôt que de se précipiter et d’agir dans toutes les directions.

Symptôme : les terminaux perdent brièvement la connexion

• Vérifier : flapping LACP/Port-Channel ? changements de topologie STP ? événements de liaison sur les uplinks ?
• Pourquoi : un lien membre redémarre, LACP renégocie, STP recalcule. Si Edge/PortFast est mal configuré, cela prend plus de temps.
• Mesure : configurer correctement STP-Edge, harmoniser les paramètres LACP, valider les chemins redondants.

Symptôme : voisins (OSPF/BGP) flapent, alors que les liens sont opérationnels

• Vérifier : pics CPU/mémoire après démarrage, timers/keepalive, MTU, ACLs/CoPP (Control Plane Policing).
• Pourquoi : le plan de contrôle met plus de temps à se stabiliser après la mise à niveau ; de nouveaux paramètres par défaut pour CoPP ou les politiques de routage peuvent s’appliquer.
• Mesure : attendre la stabilisation (délai défini), puis vérifier les déclencheurs de rollback ; comparer les politiques.

Symptôme : certains VLANs/services «disparaissent»

• Vérifier : listes de VLAN autorisés sur les trunks, VLAN natif, base de données VLAN, signalisation VTP/EVPN selon le design.
• Pourquoi : modifications de l’analyseur, nouveau comportement par défaut pour les trames non taggées, reprise incorrecte des templates.
• Mesure : diff de configuration par rapport à la sauvegarde, réapplication ciblée des sections critiques.

Automatisation et documentation : moins d’erreurs de frappe, meilleure traçabilité

Même si vous n’utilisez pas d’automatisation complète : une mise à niveau bénéficie de procédures standardisées. Deux éléments pragmatiques :

• Sauvegardes de configuration et diffs : sauvegarder automatiquement quotidiennement et créer avant la modification un « Golden Backup ». Les diffs aident à détecter les effets secondaires.
• Runbook en checklist : séquence d’étapes avec horodatages, responsables, points de contrôle, déclencheurs de rollback. Ça paraît bureaucratique, mais réduit les erreurs en situation de stress.

Si vous automatisez déjà les déploiements réseau : intégrez des contrôles pré/post en tant que tâches distinctes (p. ex. état des interfaces, voisinages, compteurs d’erreurs). Pour de nombreuses équipes, une approche déclarative de l’automatisation est un bon point d’entrée. À cet égard, une lecture approfondie du guide sur Automatisation réseau avec Ansible pour la config des switches, sauvegardes et rollbacks peut aider à rendre les runbooks de mise à niveau reproductibles.

Conclusion : les mises à niveau de firmware sans interruption sont une question d’architecture et de processus

Une mise à niveau du firmware d’un switch sans interruption de service est réalisable lorsque la redondance n’est pas seulement présente mais qu’elle fonctionne de manière vérifiable, et lorsque les mécanismes de mise à niveau (ISSU, Rolling, MLAG/vPC) correspondent à votre topologie. Décisives sont des vérifications préalables rigoureuses, un déploiement par paliers (Canary → Access → Distribution → Core) et un plan de rollback, éprouvé et doté de déclencheurs clairs. Ainsi, la mise à niveau du firmware passe de l’événement à risque au changement de routine contrôlé – avec des services stables et une exploitation traçable.

La mise à jour du firmware des switches et la mise à niveau du stacking sont également importantes pour ce sujet. Cet article situe ces aspects de manière claire et montre ce qui compte dans la pratique.