Mise à jour des équipements

La mise à jour des équipements réseau dans Avalon permet de téléverser et d'activer des images NOS (Network Operating System) sur vos équipements de manière centralisée et contrôlée. Avalon gère l'ensemble du processus : vérification de l'espace disque, transfert de l'image, validation du checksum et activation selon les procédures spécifiques à chaque constructeur.

Prérequis

Avant de pouvoir mettre à jour un équipement, vous devez avoir téléversé les images NOS dans Avalon et les avoir associées à une device family. Une fois cette association effectuée, l'image devient disponible pour tous les équipements dont le modèle est rattaché à cette device family.

Pour plus de détails sur le téléversement des images, consultez la page Device images.

Méthodes d'accès

Avalon offre trois points d'entrée, et ils ne se comportent pas pareil : les deux premiers nomment une image, le troisième énonce une intention.

• Depuis la carte du site : sélectionnez un ou plusieurs équipements, clic droit, puis un service de la catégorie NosImages. L'image est choisie dans une liste. Voir la page Travailler avec la carte d'un site.

• Depuis le planificateur (Schedule) : programmez une mise à jour pour une exécution différée. L'image est choisie dans la même liste.

• Depuis une règle d'ingénierie : la règle ne nomme aucune image. Chaque équipement reçoit l'image cible déclarée sur son propre modèle, dans Inventory puis Device Models. Une seule règle couvre donc un parc mixte, et un modèle sans cible déclarée est simplement écarté au lieu de faire échouer la règle. Voir la page Ingénierie.

Pourquoi la troisième existe

Écrite comme une campagne, une mise à jour nomme une image et doit être relancée pour chaque modèle. Écrite comme une règle, elle dit « chaque équipement tourne sur l'image décidée pour son modèle », et la décision vit dans le catalogue, là où elle se prend une fois. Le seuil d'échec, la date butoir et l'ordre par criticité sont disponibles sur les trois.

Services disponibles

uploadnosimage

Effectue un upload simple de l'image vers l'équipement sans l'activer. Utile pour pré-positionner une image avant une fenêtre de maintenance.

Option	Description
Image	L'image NOS à transférer
auto_cleanup	Nettoie automatiquement le disque si l'espace est insuffisant. Supporté sur les équipements Cisco en INSTALL MODE et en BUNDLE MODE.
VRF	La VRF à utiliser pour récupérer l'image en TFTP depuis Avalon

activatenosimage

Active une image qui a été préalablement téléversée par Avalon.

Option	Description
Image	L'image NOS à activer
minimize_disruption	Active un processus de mise à jour sans coupure (ex. ISSU chez Cisco)
VRF	La VRF à utiliser pour récupérer l'image en TFTP depuis Avalon

Ce que la liste d'images propose

Depuis la carte et depuis le planificateur, la liste ne propose que la dernière image transférée avec succès par Avalon, et seulement si elle diffère de celle actuellement active. Une image déposée par un autre moyen n'est pas proposée.

Une règle d'ingénierie ne passe pas par cette liste : elle nomme la cible déclarée sur le modèle d'équipement, quel que soit ce qui a déposé le fichier. Avant de redémarrer, Avalon vérifie alors que l'image est sur le disque, qu'elle figure dans son propre catalogue, et que son empreinte correspond. L'un des trois qui échoue arrête l'opération sans toucher à l'équipement.

upgradevice

Effectue l'upload et l'activation en une seule opération. C'est le service le plus couramment utilisé pour une mise à jour complète.

Option	Description
Image	L'image NOS à déployer
minimize_disruption	Active un processus de mise à jour sans coupure (ex. ISSU chez Cisco)
auto_cleanup	Nettoie automatiquement le disque si l'espace est insuffisant. Supporté sur les équipements Cisco en INSTALL MODE et en BUNDLE MODE.
VRF	La VRF à utiliser pour récupérer l'image en TFTP depuis Avalon

Vérifications effectuées sur Cisco IOS et IOS XE

Les deux schémas ci-dessous décrivent le déroulé Cisco, et lui seul. Les modes de démarrage install et bundle, le registre de configuration, l'ISSU et la validation d'une installation en deux temps sont des notions Cisco sans équivalent ailleurs : Aruba OS-CX travaille avec deux banques d'images, primaire et secondaire, et suit la procédure décrite dans sa propre section plus bas.

Au sein de Cisco, le déroulé ne dépend pas du point de lancement : la carte, une planification et une règle d'ingénierie empruntent exactement ces étapes. Chaque refus arrive avant toute écriture sur l'équipement.

Phase de transfert

De la demande à l'image posée sur le disque. uploadnosimage s'arrête ici ; upgradevice enchaîne directement sur le schéma suivant.

graph TD
    Start[Upload demandé] --> FS{Système de fichiers<br/>lisible ?}
    FS -->|Non| Stop[Arrêt<br/>rien n'est écrit sur l'équipement]
    FS -->|Oui| Present{Image déjà<br/>sur le disque ?}
    Present -->|Oui, empreinte différente| Stop
    Present -->|Oui, empreinte conforme| Ready[Image en place<br/>proposée à l'activation]
    Present -->|Non| Space{Espace suffisant,<br/>ou auto_cleanup ?}
    Space -->|Non| Stop
    Space -->|Oui| Register{Registre correct,<br/>là où il est requis ?}
    Register -->|Impossible à poser| Stop
    Register -->|Oui| Transfer[Transfert en TFTP<br/>progression suivie en direct]
    Transfer --> Sum{Empreinte conforme<br/>au catalogue ?}
    Sum -->|Non| Stop
    Sum -->|Oui| Ready

Phase d'activation

De la demande à un équipement qui tourne sur la nouvelle version. activatenosimage démarre ici, sur une image déjà présente sur le disque.

graph TD
    Act[Activation demandée] --> Same{Tourne déjà sur<br/>la version cible ?}
    Same -->|Oui| Done[Succès, sans redémarrage]
    Same -->|Non| Asked{minimize_disruption<br/>demandé ?}
    Asked -->|Oui| Eligible{Modèle, redondance,<br/>chemin de version,<br/>prérequis ?}
    Eligible -->|Non| Stop[Arrêt<br/>rien n'est modifié, pas de redémarrage]
    Eligible -->|Oui| ISSU[ISSU<br/>environ 1s de perturbation]
    Asked -->|Non| Checks{Sur le disque, au catalogue,<br/>empreinte conforme ?}
    Checks -->|Non| Stop
    Checks -->|Oui| Mode{Mode de démarrage ?}
    Mode -->|Bundle| Boot[Nouvelle image en premier<br/>l'actuelle en second comme recours]
    Mode -->|Install| Reload[Redémarrage complet]
    Boot --> Reload
    ISSU --> Verify{Version en cours<br/>conforme à la cible ?}
    Reload --> Verify
    Verify -->|Non, ou illisible| Failed[Échec<br/>revenu sur la version précédente]
    Verify -->|Oui| Commit{Installation en deux temps<br/>à valider ?}
    Commit -->|Commit refusé| Failed
    Commit -->|Non, ou validé| Saved[Configuration sauvegardée<br/>mise à jour terminée]

Ce que le schéma ne montre pas

L'image déjà sur le disque. Rien n'est transféré, et c'est le seul cas que rien d'autre ne vérifie : le fichier a été déposé par une tentative précédente, par une autre exécution ou à la main, et son empreinte est la seule chose qui dise s'il s'agit bien de l'image demandée.

Cela compte quand même comme un upload réussi, et ce n'est pas un détail : la carte et le planificateur proposent à l'activation la dernière image transférée avec succès par Avalon, donc une image trouvée en place et vérifiée devient celle qu'ils proposent. Sans cela, un transfert qui n'avait rien à faire laisserait l'image non sélectionnable et imposerait un retransfert inutile.

Le recours dans l'ordre de démarrage. En mode bundle, l'image actuellement active est inscrite en seconde position, donc un équipement qui ne parvient pas à démarrer sur la nouvelle revient sur celle qu'il exécutait. Avalon rapporte alors un échec : le redémarrage a eu lieu, la mise à jour non.

L'installation en deux temps. Quand l'équipement répond que le paquet est déjà ajouté, l'activation n'est validée qu'après le redémarrage. Sans cette validation il revient de lui-même à sa version précédente au bout d'un délai, sans rien annoncer, donc un commit refusé est un échec même si l'équipement tourne sur la nouvelle version à cet instant.

Qui décide de quoi. En mode install, l'équipement valide le paquet et refuse un paquet incomplet, Avalon n'ajoute rien. En mode bundle, il démarre sur ce qu'on lui désigne sans rien contrôler, et c'est pourquoi les trois vérifications n'existent que sur ce chemin.

Et rien de tout ceci ne s'applique à Aruba. Là-bas, activer veut dire désigner une banque de démarrage, l'équipement porte deux images en permanence, et le retour arrière est l'autre banque plutôt qu'un ordre de démarrage. Voir la section Aruba plus bas.

Aruba OS-CX : le déroulé

Rien de ce qui précède ne s'applique ici. Un commutateur CX porte deux banques d'images, primaire et secondaire, et il les garde toujours toutes les deux : activer veut dire désigner celle sur laquelle démarrer, et se remettre d'une mauvaise image veut dire démarrer sur l'autre. Il n'y a pas d'ordre de démarrage à écrire, pas de registre de configuration, pas d'ISSU, et pas de retour arrière à armer, puisque l'autre banque est le retour arrière.

graph TD
    Start[Upload demandé] --> Disk{Image déjà<br/>sur une banque ?}
    Disk -->|Illisible| Stop[Arrêt<br/>rien n'est écrit sur l'équipement]
    Disk -->|Oui| Ready[Rien à transférer]
    Disk -->|Non| Bank{Quelle banque<br/>est active ?}
    Bank -->|Illisible| Stop
    Bank -->|Connue| Target[La cible est l'AUTRE banque<br/>celle qui tourne n'est jamais touchée]
    Target --> Copy[Copie dans cette banque<br/>par la VRF choisie]
    Copy --> Timeout{Transfert terminé<br/>dans le délai ?}
    Timeout -->|Non| Stop
    Timeout -->|Oui| Sum{Empreinte de la banque<br/>conforme ?}
    Sum -->|Non| Stop
    Sum -->|Oui| Ready

graph TD
    Act[Activation demandée] --> Which{Quelle banque PORTE<br/>l'image demandée ?}
    Which -->|Aucune| Stop[Arrêt<br/>transférez-la d'abord]
    Which -->|Celle qui est active| Done[Succès, sans redémarrage<br/>elle tourne déjà dessus]
    Which -->|L'autre| Boot[Démarrage sur cette banque]
    Boot --> Accepted{Commande<br/>acceptée ?}
    Accepted -->|Non| Stop
    Accepted -->|Oui| Down{L'équipement est-il<br/>vraiment tombé ?}
    Down -->|Jamais tombé| Failed[Échec<br/>la commande est passée mais rien n'a redémarré]
    Down -->|Oui| Up{Revenu en ligne,<br/>et joignable en SSH ?}
    Up -->|Non| Failed
    Up -->|Oui| Verify{Version en cours<br/>conforme à l'image ?}
    Verify -->|Non| Failed
    Verify -->|Oui| Saved[Mise à jour terminée]

La banque est choisie d'après ce que les banques contiennent, jamais en basculant l'active. Demander l'activation d'une image que l'équipement exécute déjà se termine donc en succès sans redémarrage, et la version lue dans la banque cible est réécrite dans Avalon, ce qui réaligne un inventaire qui avait perdu le fil.

Le VSX est refusé quand les deux châssis ne démarrent pas sur la même banque, et Avalon le vérifie avant de transférer quoi que ce soit : la paire serait sinon laissée dans un état incohérent. La commande d'orchestration VSX elle-même n'est volontairement pas employée ici.

En VSF, la pile synchronise l'image vers ses membres toute seule, et boot system redémarre la pile entière. Avalon n'attend pas la fin de cette synchronisation, et c'est précisément pourquoi redémarrer un membre en pleine synchronisation est le seul moyen de l'empêcher de rejoindre la pile.

Pas de retour arrière automatique sur Aruba OS-CX

Contrairement à Cisco en mode bundle, où l'image précédemment active est inscrite en seconde position dans l'ordre de démarrage et où l'équipement y revient de lui-même, AOS-CX n'offre rien d'équivalent. L'autre banque reste intacte, donc l'image précédente est toujours là, mais redémarrer dessus est une opération manuelle qui demande quelqu'un sur site ou une console. Dimensionnez la fenêtre de maintenance en conséquence : un équipement qui ne revient pas ne se rétablira pas tout seul.

Ce qu'Avalon traite, par constructeur et par modèle

Deux questions décident de tout : le modèle est-il pris en charge, et quel mode de démarrage l'équipement exécute-t-il. Le mode n'est pas une propriété du modèle mais de l'équipement : Avalon le lit dans l'image en cours, packages.conf signifiant le mode install et tout le reste le mode bundle. Un modèle qui sait faire les deux apparaît donc dans les deux colonnes.

Cisco IOS et IOS XE

Modèle	Pris en charge	Install	Bundle	ISSU	Remarques
C9400, C9500	oui	oui	oui	oui	L'ISSU exige un Stackwise Virtual ou un double superviseur
C9200, C9300	oui	oui	oui	non	Les plateformes habituelles en mode install
C3850, C3650 (C38)	oui	oui	oui	non
C3560 (C356)	oui	non	oui	non	IOS classique
C2960C, C2960X	oui	non	oui	non	IOS classique, aucun contrôle de registre nécessaire
C9600	non				Couvert par les règles de registre et de disques mais absent de la liste des modèles pris en charge : la mise à jour est refusée avant de commencer
Catalyst 4500, 4500-X (C45)	oui	non	oui	non	Le registre de configuration est lu et posé avant le transfert
Cisco IOL	oui	non	oui	non	Plateforme de lab EVE-NG, système de fichiers unix:
ISR 4000, ASR 1000, C1100	non				Absents de la liste : la mise à jour est refusée avant de commencer
Tout autre Cisco IOS	non				Idem, et le système de fichiers ne peut pas être déterminé non plus

Piles et redondance

Une paire Stackwise Virtual ou VSS avec double superviseur est refusée, volontairement : la procédure diffère et n'est pas implémentée. Une pile Stackwise simple est prise en charge, et le contrôle d'espace disque comme le nettoyage automatique s'exécutent sur tous les membres.

Aruba OS-CX

Modèle	Pris en charge	Procédure	Remarques
CX autonome	oui	Deux banques d'images, primaire et secondaire	Pas de retour arrière automatique. L'autre banque reste intacte, donc une mauvaise image se récupère en redémarrant dessus, ce qui demande quelqu'un sur site ou une console
CX en VSX	oui	Les deux châssis doivent démarrer sur la même banque	Avalon le vérifie avant de transférer quoi que ce soit et refuse sinon
CX en VSF	oui

Autres constructeurs

Constructeur	Transfert et activation d'image
Cisco NX-OS	non implémenté, et déclaré comme tel
HP Comware, HP ProCurve	non implémenté
Huawei VRP	non implémenté
Arista EOS	non implémenté
Palo Alto PAN-OS, Stormshield	non implémenté, déclaré explicitement sur le pilote

Ce que « non implémenté » veut dire

Le service n'est pas absent par accident : le pilote déclare la méthode comme indisponible, donc demander une mise à jour sur ces plateformes rend un refus clair au lieu d'échouer à mi-parcours. Le reste de ce qu'Avalon y fait, inventaire, connectivité, sauvegarde de configuration quand elle existe, n'est pas affecté.

Formats d'image acceptés

Deux seulement, toute autre extension étant refusée au téléversement : .bin pour Cisco, .swi pour Aruba OS-CX. Une archive .tar doit être décompressée au préalable, Avalon inscrivant un chemin de démarrage vers le fichier qu'il a transféré plutôt que de passer par la procédure d'extraction d'archive de l'équipement.

Procédures spécifiques

Cisco

Auto Cleanup

Le nettoyage automatique du disque (auto_cleanup) est supporté sur les équipements Cisco IOS / IOS XE dans les deux modes de boot :

Install mode :

• Avalon exécute la commande de nettoyage native de la plateforme pour supprimer les paquets inactifs.

Bundle mode :

• Avalon scanne tous les disques de l'équipement, y compris ceux des membres secondaires dans un Stackwise ou un stack.
• Pour chaque disque, la recherche s'effectue à la racine et dans les sous-dossiers.
• Seules deux images sont conservées : l'image en cours d'exécution et l'image cible (celle qui va être téléversée). Tous les autres fichiers .bin sont supprimés.

ISSU (In-Service Software Upgrade)

L'ISSU est une méthode de mise à jour qui minimise l'interruption de service. Contrairement à un upgrade standard qui provoque un reload complet (~10 minutes de downtime), l'ISSU exploite la redondance matérielle d'un équipement dual-supervisor pour effectuer la mise à jour "à chaud" avec environ 1 seconde de perturbation du trafic. La durée totale du processus est d'environ 20 minutes.

L'ISSU est déclenché en activant l'option minimize_disruption dans les services upgradevice ou activatenosimage. Si l'équipement remplit tous les critères d'éligibilité, Avalon utilise la procédure ISSU. Sinon l'opération échoue et l'équipement n'est pas touché : aucune bascule silencieuse vers un upgrade standard. Demander minimize_disruption, c'est accepter une seconde de perturbation, pas dix minutes de coupure, donc Avalon refuse plutôt que de substituer une procédure que vous n'avez pas demandée.

Plateformes supportées

L'ISSU est actuellement supporté sur Cisco IOS XE uniquement, pour les modèles suivants :

• Catalyst 9500 (C95) : en topologie Stackwise Virtual
• Catalyst 9400 (C94) : en topologie Stackwise Virtual ou en configuration dual-superviseur (SSO sans SVL)

Critères d'éligibilité

Toutes les conditions suivantes doivent être réunies pour que l'ISSU puisse s'exécuter :

Critère	C9500 (Stackwise Virtual)	C9400 (dual-superviseur)
Modèle	Catalyst 9500 (C95)	Catalyst 9400 (C94)
Technologie	Stackwise Virtual	Dual-superviseur (SSO)
Version minimale	IOS XE 16.9.2	IOS XE 16.9.2
Mode de boot	Install mode (packages.conf)	Install mode (packages.conf)
Redondance	SSO (Stateful Switchover) actif	SSO (Stateful Switchover) actif
Topologie	2 switches SVL en état Ready	Chassis avec 2 superviseurs en état Ready
Autoboot	manual_boot = no sur Active ET Standby	manual_boot = no sur Active ET Standby
État ISSU	Enabled, aucune opération en cours	Enabled, aucune opération en cours
Paquets	Tous en état Committed	Tous en état Committed
Espace disque	Espace suffisant sur bootflash: ET stby-bootflash:	Espace suffisant sur bootflash: ET stby-bootflash:

Si un critère n'est pas rempli, Avalon nomme lequel dans la transaction et arrête l'opération. Les quatre contrôles, le modèle, la redondance, le chemin de version et les prérequis, aboutissent au même résultat : un échec avant toute écriture. Pour partir quand même, relancez sans minimize_disruption, ce qui est un choix explicite.

Commandes incompatibles

Certaines commandes de configuration sont incompatibles avec l'ISSU. Avalon les détecte et les supprime automatiquement de la running-config avant de lancer la procédure. La configuration est ensuite sauvegardée pour que la suppression soit effective.

Commandes identifiées à ce jour (documentation Cisco + retours terrain) :

• snmp-server enable traps license
• ip http banner
• snmp enable traps energywise

Info

Cette liste est susceptible d'évoluer avec les futures versions d'IOS XE.

Chemins d'upgrade valides

L'ISSU ne supporte pas les sauts de version arbitraires. Les règles suivantes s'appliquent :

• IOS XE 16.x : upgrade dans le même mineur (ex. 16.9.x vers 16.9.y) ou de 16.9.x vers 16.12.x uniquement
• IOS XE 17.x : upgrade entre versions Extended Maintenance (17.3, 17.6, 17.9, 17.12, 17.15, 17.18) ou dans le même mineur
• Pas de downgrade supporté
• Pas de saut de branche majeure (16.x vers 17.x est interdit via ISSU)
• Version source minimale : 16.9.2. Tout ce qui est antérieur est refusé

IOS XE 26.x et au-delà

Les chemins ci-dessus couvrent 16.x et 17.x. Un équipement sur une branche plus récente, 26.x notamment, voit l'ISSU refusé avec un message explicite, ISSU validation not defined for version 26.x, et l'opération s'arrête là, sans bascule. La validation des chemins ISSU de cette branche est en cours : d'ici là, une mise à jour d'un équipement en 26.x doit être lancée sans minimize_disruption.

Fonctionnement

Lorsque l'ISSU est déclenché, Avalon effectue les étapes suivantes :

1. Vérifications préalables : Avalon valide tous les critères d'éligibilité listés ci-dessus
2. Activation ISSU : Avalon lance la procédure ISSU sur l'équipement
3. Monitoring actif : Avalon surveille la progression de l'ISSU en continu (timeout : 40 minutes)
4. Switchover : Le supervisor standby est mis à jour en premier, puis prend le rôle d'active. L'ancien supervisor active est ensuite mis à jour et devient standby. La perturbation du trafic est d'environ 1 seconde lors du switchover
5. Reconnexion : Après le switchover, Avalon se reconnecte à l'équipement
6. Validation post-upgrade : Avalon vérifie que la nouvelle version est bien active et que l'état de l'équipement est propre
7. Sauvegarde de la configuration : La running configuration est sauvegardée

ISSU vs Upgrade standard

Aspect	Upgrade standard	ISSU
Downtime	~10 min (reload complet)	~1 seconde
Durée totale	~10-15 min	~20 min
Prérequis matériels	Minimal	Dual supervisor SSO (+ SVL pour C9500)
Modèles supportés	C2960X, C38, C45, C92-95	C94 (SVL ou dual-sup), C95 (SVL)
Rollback automatique en cas d'échec	Non	Oui

Rollback

En cas d'échec pendant le processus, Avalon tente automatiquement d'annuler l'opération et de restaurer l'équipement dans un état connu.

Aruba

CX en VSX

Pour les équipements Aruba CX configurés en VSX (Virtual Switching Extension), des règles spécifiques s'appliquent :

• Toutes les opérations doivent être lancées sur le membre primary
• Il n'est pas possible de lancer un upload ou une activation directement sur le membre secondary
• Avalon pilote la procédure d'upgrade depuis le membre primary et monitore l'état global du processus
• Lorsque le primary redémarre, Avalon perd temporairement la connexion SSH puis monitore le retour du primary pour se reconnecter et vérifier que le processus est complété avec la bonne version

Roadmap

Nous sommes ouverts à l'implémentation de procédures spécifiques pour d'autres constructeurs ou modèles. Contactez-nous pour discuter de vos besoins.