Une mise à niveau de pare-feu échoue rarement à cause de la commande de mise à niveau elle-même — elle échoue parce que quelque chose n'a pas été sauvegardé, que le paquet n'a pas été vérifié avant d'être chargé, ou qu'une paire à chaud a été mise à niveau dans le mauvais ordre. Voici la liste de sauvegarde, les étapes de vérification du paquet, la séquence isoler-mettre à niveau-vérifier-basculer pour une paire à chaud, le chemin de retour arrière, et la liste de contrôle à exécuter avant de clore le changement.
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
Presque toutes les mises à niveau qui échouent remontent à l'une de ces trois lacunes — quelque chose n'a pas été sauvegardé, le paquet n'a pas été vérifié avant d'être chargé, ou une paire à chaud a été mise à niveau dans le mauvais ordre.
La plupart des mises à niveau de pare-feu sont routinières, jusqu'à celle qui ne l'est pas — et à ce moment-là, il est trop tard pour revenir en arrière et sauvegarder la configuration que l'on vient d'écraser. Les consignes de maintenance de Huawei pour la plateforme HiSecEngine USG6000F, USG6000G et USG12000 traitent la sauvegarde comme une condition préalable à toute opération de maintenance sérieuse, pas comme une réflexion après coup : les données critiques du réseau sont nommées explicitement — topologie et inventaire des équipements, fichier de configuration, fichier de License, et fichiers du logiciel système et des correctifs — à sauvegarder avant que quoi que ce soit d'autre ne se produise.
Voici cette liste de sauvegarde, comment vérifier un paquet de mise à niveau avant de le charger, la séquence qui permet à une paire à chaud de continuer à faire transiter le trafic pendant toute la mise à niveau, le chemin de retour arrière si la nouvelle version ne convient pas, et la liste de contrôle à exécuter avant de considérer le changement comme terminé.
La documentation source désigne explicitement cette liste comme les données critiques du réseau — sauvegardez-la avant que quoi que ce soit d'autre ne se produise.
| Catégorie | Ce que ça couvre | Pourquoi c'est important |
|---|---|---|
| Topologie et inventaire des équipements | Modèles d'équipements, versions du logiciel et des correctifs, schéma de topologie | Sans un instantané de ce qui était connecté à quoi, une mauvaise mise à niveau passe de « revenir en arrière sur un équipement » à « reconstruire le réseau de mémoire ». |
| Fichier de configuration | vrpcfg.cfg / current-configuration | Chaque chemin de retour arrière suppose que vous l'avez encore, sous une forme comparable. |
| Fichier de License | Chargé indépendamment sur chaque équipement | Une paire à chaud ne partage pas de License — chaque équipement a besoin de la sienne, avec un ensemble de fonctionnalités et une expiration identiques. |
| Fichiers du logiciel système et des correctifs | Les paquets .cc actuellement en cours d'exécution, plus tout correctif chargé | Aussi bien la version vers laquelle vous migrez que celle dont vous partez — supprimer l'ancienne avant que la nouvelle ne soit vérifiée supprime votre chemin de retour arrière. |
| (Facultatif) Journaux et versions de la base de signatures | Versions des bases de fonctionnalités IPS / AV / URL | Confirme qu'il n'y a pas eu de régression silencieuse ; pas indispensable pour un simple retour arrière. |
La documentation source compare Console, FTP, TFTP, SFTP et SCP comme méthodes de transfert de fichiers : TFTP et le FTP en clair envoient les données et les identifiants de connexion en texte clair, tandis que SFTP et SCP chiffrent et protègent l'intégrité du transfert. Pour extraire une sauvegarde de configuration ou de License d'un équipement en production, préférez SFTP ou SCP à FTP ou TFTP.
Dix étapes, dans cet ordre — sautez l'étape d'isolement et une paire à chaud peut finir scindée ; sautez l'étape de vérification et vous transportez une hypothèse non vérifiée.
Les légendes du schéma restent en anglais pour la clarté technique.
Les étapes 1 à 5 s'exécutent sur un équipement d'une paire à chaud, isolé de son pair ; les étapes 6 à 10 répètent le même schéma isoler-mettre à niveau-vérifier sur l'autre équipement, après que le trafic a été basculé volontairement. Sur un pare-feu unique, non redondant, les étapes 3, 6 et 7 ne s'appliquent tout simplement pas — mais 1, 2, 4, 5, 9 et 10 s'appliquent toujours.
Une mise à niveau échouée n'est souvent pas un fichier défectueux — c'est un fichier non vérifié ; quelques vérifications suffisent à détecter la plupart des problèmes qui surgiraient sinon en cours de mise à niveau.
<HUAWEI> dir
Directory of flash:/
Idx Attr Size(Byte) Date Time(LMT) FileName
10 -rw- 25,841,428 Nov 17 2015 09:48:10 basicsoft.cc
12 -rw- 26,101,692 Dec 21 2015 11:44:52 devicesoft.cc
1,927,220 KB total ( 1,130,464 KB free )
<HUAWEI> display version
Huawei YunShan OS
Version 1.23.0.X (XXX)
// software version must match this device's type — not interchangeable across device types
<HUAWEI> check system-software upgrade.cc
Caution! Confirm to check startup file! Continue? [Y/N]:y
Info: Prepare to check system software cfcard:/upgrade.cc, please wait, XX% completed.
// look for: System software signature check passed! / ...check failed!
C:\Users\xxxx> certutil -hashfile "C:\upgrade\upgrade.cc" SHA256
<HUAWEI> check file-digest digest-algorithm sha256 <hash-from-certutil> upgrade.cc
Info: Verification completed. The digest value of cfcard:/upgrade.cc is the same as the input digest value.L'ordre importe plus que les commandes — isolez complètement un équipement, mettez-le à niveau seul, vérifiez-le, puis basculez le trafic délibérément.
HRP_M[sysname] hrp switch standby
// forces this active device to yield; peer takes over as active
HRP_S[sysname] hrp switch active
// forces this standby device to take over as active
<sysname> system-view
[sysname] hrp track interface 10GE 1/0/1
// raises this device's HRP fault metric on a Down interface, for a controlled switchover test without touching live business interfacesComparez les fichiers de configuration des deux équipements (un outil de comparaison fonctionne bien ici). Tout devrait correspondre sauf : le nom de l'équipement, le Router ID et les segments de route que chacun annonce, les adresses IP des interfaces, l'état d'adhésion de l'interface HRP, le délai de préemption, et — en mode de partage de charge uniquement — la plage de ports NAT. Toute autre différence mérite d'être examinée avant de faire confiance à la paire.
Le retour arrière n'est pas un réflexe de panique — c'est la même discipline que la mise à niveau, exécutée à l'envers, dans une fenêtre de changement.
[HUAWEI] diagnose
[HUAWEI-diagnose] display configuration commit changes
Building configuration
Commit changes of commitId 1000000002 2024-12-23 07:08:24 by root
#
- sysname 11
#
+ sysname HUAWEI
[HUAWEI-diagnose] display configuration changes start-time 2025/06/18,12:01:18Six vérifications, exécutées sur les deux équipements d'une paire — la différence entre « la mise à niveau est terminée » et « la mise à niveau a vraiment fonctionné ».
Même mise à niveau, mêmes commandes — voici ce qui piège vraiment les gens.
RISQUESur une paire à chaud, les deux équipements ne partagent pas de License ; des fonctionnalités comme IPS, AV ou le filtrage URL qui en dépendent sont licenciées et appliquées indépendamment sur chaque équipement, avec un ensemble de fonctionnalités, un nombre de ressources et une expiration correspondants.
PRATIQUE PLUS SÛRELors d'une mise à niveau ou d'un renouvellement, vérifiez display license sur les deux équipements, pas seulement celui sur lequel vous vous êtes connecté par hasard — une License expirée silencieusement sur le secondaire ne devient visible qu'au moment où il prend le relais en tant que primaire.
RISQUEUn équipement ne reprend pas le rôle primaire à l'instant où il termine son redémarrage. Il ne tente de préempter qu'une fois la configuration de sa carte principale restaurée, au moins un CPU en ligne, et au moins une carte d'interface portant le battement de cœur revenue — et seulement après une minute d'attente supplémentaire.
PRATIQUE PLUS SÛRESi un équipement fraîchement mis à niveau reste en secondaire plus longtemps que prévu, vérifiez si les trois conditions sont réellement remplies — en particulier la carte d'interface de battement de cœur — avant de supposer que la mise à niveau a échoué.
RISQUEArrêter les interfaces métier pour isoler un équipement en vue de la mise à niveau est correct ; mal gérer l'interface de battement de cœur, sa zone de sécurité, ou la politique qui laisse passer ses paquets de battement laisse les deux équipements croire qu'ils sont primaires une fois que l'équipement isolé redémarre.
PRATIQUE PLUS SÛREdisplay hrp state affichant Local role: Active, Peer role: Unknown sur les deux équipements est la signature d'une paire scindée — vérifiez display hrp interface pour un état de battement de cœur down, invalid ou negotiation failed avant de déclarer la mise à niveau terminée.
RISQUEcheck system-software signalant un échec de vérification de signature est traité par réflexe comme « retélécharger le fichier », ce qui fait perdre du temps si la vraie panne est un transfert partiel ou interrompu plutôt qu'un fichier source réellement défectueux.
PRATIQUE PLUS SÛREComparez une somme de contrôle — SHA256 ou MD5, obtenue avec certutil -hashfile sur le PC source et check file-digest sur l'équipement — avant de conclure que le fichier source lui-même est défectueux et de retourner en chercher une copie fraîche.
RISQUEdelete /unreserved est documenté comme irrécupérable — l'utiliser sur l'ancien paquet logiciel dès que l'espace flash se fait rare supprime silencieusement la seule chose dont dépend un retour arrière.
PRATIQUE PLUS SÛRELibérez d'abord de l'espace par un nettoyage courant des fichiers réellement inutilisés, et conservez au moins un ancien paquet logiciel connu comme fonctionnel jusqu'à ce que la nouvelle version ait réussi la liste de contrôle complète.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Ce n'est que brièvement, pendant la fenêtre de mise à niveau elle-même, qu'ils sont intentionnellement dépareillés. L'exigence minimale pour que la paire fonctionne correctement est que le modèle de produit, la version logicielle, la version de correctif, l'ensemble de fonctionnalités et la version de la base de signatures correspondent tous — prévoyez donc de terminer les deux côtés dans la même fenêtre de maintenance plutôt que de laisser la mise à niveau à moitié faite.
hrp switch est un déclencheur délibéré et contrôlé plutôt qu'une panne non planifiée. La même vérification demandée par la documentation source — arrêter une interface métier, débrancher un câble, et un redémarrage complet — doit à chaque fois déplacer le trafic vers l'autre équipement sans une interruption qu'un utilisateur remarquerait ; testez ce déclencheur avant le vrai changement avec hrp track interface sur une interface déjà down plutôt que de supposer que cela fonctionnera simplement le jour venu.
Pas nécessairement. Un échec de vérification de signature peut aussi signifier que le transfert lui-même était incomplet ou interrompu. Comparez un hachage SHA256 ou MD5 entre le fichier source et le fichier téléversé avant de conclure que la source est défectueuse et de retourner en chercher une copie fraîche.
La documentation source ne donne pas de nombre de jours fixe ; la réponse pratique est : jusqu'à ce que la liste de contrôle de vérification ci-dessus ait réussi sur les deux équipements et que la paire ait subi au moins un test de basculement planifié sur la nouvelle version. Conservez — ne faites pas /unreserved — supprimez-le avant cela.
Pas nécessairement — voir le deuxième piège ci-dessus. Vérifiez si la configuration de la carte principale a fini de se restaurer, si au moins un CPU est en ligne, et si la carte d'interface portant le battement de cœur est revenue, et laissez la minute d'attente supplémentaire avant de considérer cela comme une panne.
Cette note s'appuie sur le matériel de cas du manuel de maintenance HiSecEngine USG6000F, USG6000G et USG12000 V600 concernant la discipline de sauvegarde, la vérification des paquets de mise à niveau et les bonnes pratiques de haute disponibilité, recoupé avec le manuel USG6000E/USG9500 de la même famille de plateforme où le mécanisme HRP sous-jacent et le comportement de licence par équipement sont partagés. La synchronisation précise de préemption au redémarrage et les règles de licence décrites sont propres à cette plateforme ; une implémentation HA d'un autre fournisseur utilisera des commandes et des compteurs différents, même si l'ordre sauvegarde-vérification-isolement-basculement se transpose conceptuellement. Elle ne couvre pas en profondeur le remplacement de cartes au niveau châssis pendant une mise à niveau, ni la répartition de License multi-vsys.
Indiquez-nous le modèle de l'équipement, la version logicielle actuelle et cible, et s'il s'agit d'une paire à chaud — nous vous aiderons à vérifier le plan avant de toucher à la commande de mise à niveau.