Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Mise à niveau d’un cluster de châssis à l’aide de la mise à niveau de logiciels en service

Cette rubrique explique que la mise à niveau Logiciels en service (ISSU) permet de mettre à niveau un logiciel d’une version Junos OS vers une version Junos OS ultérieure tout en minimisant les temps d’arrêt.

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.

Consultez la section Comportement de mise à niveau des logiciels en service spécifique à la plate-forme pour les notes relatives à votre plate-forme.

Voir la section Informations supplémentaires sur la plate-forme pour plus d’informations.

Comprendre l’ISSU pour un cluster de châssis

La mise à niveau logicielle en service (ISSU) permet une mise à niveau d’une version de Junos OS vers une version ultérieure de Junos OS avec peu ou pas de temps d’arrêt. La ISSU est réalisée uniquement lorsque les équipements fonctionnent en mode cluster de châssis.

Les temps d’arrêt observés lors d’un basculement peuvent varier en fonction de l’environnement de déploiement et de plusieurs facteurs externes, notamment :

  • La vitesse à laquelle les appareils connectés traitent et répondent aux mises à jour ARP gratuites (GARP).
  • Réapprentissage des adresses MAC et mises à jour de la table de transfert sur les commutateurs en amont et en aval.
  • Le comportement des applications et les protocoles utilisés (par exemple, les sessions TCP peuvent récupérer différemment du trafic UDP).

La fonctionnalité ISSU de cluster de châssis permet de mettre à niveau les deux équipements d’un cluster à partir des versions de Junos OS prises en charge avec un minimum d’interruption du trafic et sans interruption des services, en coordonnant le processus de mise à niveau entre les nœuds de cluster.

L’ISSU offre les avantages suivants :

  • Élimine les temps d’arrêt du réseau lors de la mise à niveau des images logicielles

  • Réduit les coûts d’exploitation tout en offrant des niveaux de service plus élevés

  • Permet une mise en œuvre rapide des nouvelles fonctionnalités

L’ISSU présente les limitations suivantes :

  • ISSU est disponible uniquement pour Junos OS version 10.4R4 ou ultérieure.

  • ISSU ne prend pas en charge les rétrogradations logicielles.

  • Si vous effectuez une mise à niveau d’une version de Junos OS qui prend uniquement en charge IPv4 vers une version qui prend en charge à la fois IPv4 et IPv6, le trafic IPv4 continue de fonctionner normalement tout au long du processus de mise à niveau. Si vous effectuez une mise à niveau d’une version de Junos OS qui prend en charge à la fois IPv4 et IPv6 vers une autre version qui prend également en charge les deux protocoles, le trafic IPv4 et IPv6 continue de fonctionner pendant la mise à niveau. Les plates-formes prises en charge par Junos OS prennent en charge le traitement basé sur les flux pour le trafic IPv6.

  • Pendant un ISSU, vous ne pouvez pas mettre les PIC en ligne. Vous ne pouvez pas effectuer d’opérations telles que la validation, le redémarrage ou l’arrêt.

  • Lors d’une ISSU, les opérations telles que la surveillance de la structure, la récupération des liaisons de contrôle et la préemption RGX sont suspendues.

  • Lors d’un ISSU, vous ne pouvez valider aucune configuration.

Pour plus de détails sur l’état de la prise en charge d’ISSU , consultez l’article KB17946 de la base de connaissances.

La séquence suivante décrit le comportement d’un ISSU pour les périphériques fonctionnant dans un cluster de châssis. La séquence s’applique lorsque RG-0 est hébergé sur le nœud 0, qui est le nœud principal. Vous devez lancer l’ISSU à partir du nœud principal RG-0. Si vous essayez de démarrer l’ISSU à partir du nœud 1 (le nœud secondaire RG-0), le système affiche un message d’erreur et la mise à niveau ne se poursuit pas.

  1. Basculement du groupe de redondance initiale

    Au début d’un ISSU de cluster de châssis, le système bascule automatiquement sur tous les groupes de redondance RG-1 et supérieurs (RG-1+) qui ne sont pas déjà principaux sur le nœud à partir duquel l’ISSU est lancé. Cette action garantit que tous les groupes de redondance deviennent actifs sur le nœud principal RG-0 avant le début de la mise à niveau logicielle.

    Le basculement automatique de tous les groupes de redondance RG-1+ est effectué par le système. Si vous utilisez Junos OS version 18.1R1 ou une version antérieure, vous devez vérifier manuellement (avant de démarrer l’ISSU) que tous les groupes de redondance RG-1+ sont actifs sur le nœud principal RG-0.

    Une fois que tous les groupes de redondance RG-1+ ont été basculés, le système définit le bit de basculement manuel, empêchant ainsi le déplacement des groupes redondants pendant la mise à niveau. Le système modifie la priorité du nœud principal de tous les groupes de redondance RG-1+ à 255, qu’ils aient ou non basculé vers le nœud principal RG-0 au cours de cette étape.

  2. Lors d’un ISSU, le nœud principal (nœud 0) valide la configuration de l’équipement pour s’assurer qu’elle peut être validée avec succès à l’aide de la nouvelle version de Junos OS. Dans le cadre de ce processus de validation, le système effectue les vérifications suivantes sur les deux nœuds :

    • Espace disque disponible sur le système de fichiers /var

    • Instructions de configuration non prises en charge

    • Cartes d’interface physique (PIC) non prises en charge

    Si l’espace disque disponible sur le système de fichiers de l’un /var ou l’autre des moteurs de routage est insuffisant, le processus ISSU échoue et renvoie un message d’erreur, et la mise à niveau ne se poursuit pas.

    Les PIC non pris en charge n’empêchent pas l’ISSU de continuer. Toutefois, le logiciel génère un avertissement indiquant que ces PIC vont redémarrer pendant la mise à niveau.

    De même, la présence d’une configuration de protocole non prise en charge ne bloque pas l’ISSU. Dans ce cas, le logiciel émet un avertissement indiquant que le protocole affecté peut perdre des paquets pendant le processus de mise à niveau.

  3. Lorsque la validation réussit, le démon de synchronisation de l’état du noyau (ksyncd) synchronise le noyau du nœud secondaire (nœud 1) avec le nœud 0.

  4. Le nœud 1 est mis à niveau avec la nouvelle image logicielle. Avant d’être mis à niveau, le nœud 1 récupère le fichier de configuration du nœud 0 et valide la configuration pour s’assurer qu’elle peut être validée à l’aide de la nouvelle version du logiciel. Après avoir été mis à niveau, il est resynchronisé avec le nœud 0.

  5. Le processus de cluster de châssis (chassisd) sur le nœud 0 prépare les autres processus logiciels pour lSSU. Lorsque tous les processus sont prêts, chassisd envoie un message aux PIC installés sur le périphérique.

  6. Le moteur de transfert de paquets de chaque concentrateur PIC flexible (FPC) enregistre son état et télécharge la nouvelle image logicielle à partir du nœud 1. Ensuite, chaque moteur de transfert de paquets envoie un message (prêt pour ISSU unifié) au chassisd.

  7. Après avoir reçu le message (prêt pour unified-ISSU ) d’un moteur de transfert de paquets, le chassisd envoie un message de redémarrage au FPC sur lequel réside le moteur de transfert de paquets. Le FPC redémarre avec la nouvelle image logicielle. Une fois le FPC redémarré, le moteur de transfert de paquets restaure l’état FPC et une liaison interne à haut débit est établie avec le nœud 1 exécutant le nouveau logiciel. Le chassisd est également rétabli avec le nœud 0.

  8. Une fois que tous les moteurs de transfert de paquets ont envoyé un message prêt à l’aide du châssis sur le nœud 0, d’autres processus logiciels sont préparés pour un basculement de nœud. À ce stade, le système est prêt pour un basculement.

  9. Le basculement de nœud se produit et le nœud 1 devient le nouveau nœud principal (jusqu’alors nœud secondaire 1).

  10. Le nouveau nœud secondaire (jusqu’à présent nœud principal 0) est maintenant mis à niveau vers la nouvelle image logicielle.

Lorsque les deux nœuds sont mis à niveau avec succès, l’ISSU est terminé.

Lors de la mise à niveau d’un cluster de châssis d’une version de Junos OS qui ne prend pas en charge le chiffrement vers une version qui prend en charge le chiffrement, effectuez la mise à niveau un nœud à la fois :

  1. Mettez à niveau le premier nœud vers la nouvelle version de Junos OS.

    Si le chiffrement n’est pas configuré et activé, la communication de cluster entre les deux nœuds reste intacte, même s’ils exécutent des versions logicielles différentes, et les services se poursuivent sans interruption.

  2. Mettez à niveau le deuxième nœud vers la même nouvelle version de Junos OS.

Une fois les deux nœuds mis à niveau avec succès, vous pouvez choisir de configurer et d’activer le chiffrement selon vos besoins.

Pour les rétrogradations vers une version de Junos OS qui ne prend pas en charge le chiffrement, assurez-vous que le chiffrement est désactivé avant de lancer la rétrogradation. La désactivation du chiffrement avant la rétrogradation permet d’éviter les échecs de communication entre :

  • un nœud exécutant encore une version de Junos OS compatible avec le chiffrement, et
  • un nœud qui a été rétrogradé vers une version sans prise en charge du chiffrement.

En veillant à ce que le chiffrement soit désactivé sur les deux nœuds, la communication du cluster reste non chiffrée et opérationnelle tout au long du processus de rétrogradation.

Les stratégies du moteur de routage et du moteur de transfert de paquets doivent être synchronisées pour que la configuration soit validée. Lorsque les configurations de stratégie sont modifiées et que les stratégies ne sont pas synchronisées, le système affiche un message d’erreur.

Pour contourner ce problème, vous devez utiliser la commande request security policies resync pour synchroniser la configuration des stratégies de sécurité dans le moteur de routage et le moteur de transfert de paquets, au cas où vous constateriez que les stratégies de sécurité ne sont pas synchronisées après une mise à niveau.

Configuration système requise pour ISSU

Vous pouvez utiliser ISSU pour effectuer une mise à niveau d’une version logicielle compatible ISSU vers une version ultérieure.

Pour effectuer un ISSU, votre équipement doit exécuter une version de Junos OS qui prend en charge ISSU pour la plate-forme spécifique.

Pour plus d’informations, reportez-vous à la section Comprendre l’ISSU pour un cluster de châssis .

Pour plus de détails sur la prise en charge et les limitations d’ISSU ( Limitations de mise à niveau ISSU/ICU sur les équipements SRX Series).

Voici les limites lors de l’exécution d’un ISSU :

  • Le processus ISSU est interrompu si la version de Junos OS spécifiée pour l’installation est antérieure à la version actuellement en cours d’exécution sur l’équipement.

  • ISSU est arrêté si la mise à niveau spécifiée entre en conflit avec :

    • La configuration actuelle des appareils

    • Composants matériels pris en charge

    • Autres dépendances logicielles ou de plate-forme

  • ISSU ne prend pas en charge les packages d’application d’extension développés à l’aide du SDK de Junos OS.

  • ISSU ne prend pas en charge la rétrogradation de version sur tous les pare-feu.

  • L’ISSU peut échouer sous une charge CPU importante, et il est recommandé de s’assurer que les ressources système sont suffisantes avant de lancer la mise à niveau.

Pour passer d’une version de Junos OS compatible ISSU à une version antérieure (compatible ISSU ou non), utilisez la request system software add commande.

Contrairement à une mise à niveau d’ISSU par exemple, une rétrogradation peut entraîner des perturbations du réseau.

Il existe également un risque de perte de données pendant le processus de rétrogradation.

Planifiez soigneusement les rétrogradations et assurez-vous que les sauvegardes appropriées sont effectuées avant de continuer.

Nous vous recommandons fortement d’effectuer l’ISSU dans les conditions suivantes :

  • Lorsque les nœuds principal et secondaire sont sains

  • Pendant la période de maintenance du système

  • Pendant la période de trafic le plus faible possible

  • Lorsque l’utilisation du processeur du moteur de routage est inférieure à 40 %

Dans les scénarios où ISSU n’est pas pris en charge ou n’est pas recommandé, mais que les temps d’arrêt de la mise à niveau du système doivent encore être minimisés, la procédure de mise à niveau à temps d’arrêt minimal peut être utilisée, voir l’article KB17947 de la base de connaissances correspondant.

Mettez à niveau les deux équipements d’un cluster de châssis à l’aide d’ISSU

Avant de commencer l’ISSU pour la mise à niveau des deux appareils, notez les instructions suivantes :

  • Assurez-vous que les exigences de pré-vérification ISSU suivantes sont remplies :

    • La priorité de tous les groupes de redondance est supérieure à 0

    • Tous les groupes de redondance sont primaires ou secondaires dans l’état

    • Il existe suffisamment d’espace (deux fois la taille de l’image) disponible dans le /var/tmp

    • L’utilisation du processeur est inférieure à 80 % sur une période de 5 secondes

    Si les exigences de vérification préalable ne sont pas remplies, l’ISSU prendra fin au début.

  • Sauvegardez le logiciel à l’aide de la request system snapshot commande de chaque moteur de routage pour sauvegarder le logiciel système sur le disque dur de l’équipement.

  • Si vous utilisez Junos OS version 18.1R1 ou une version antérieure, avant de démarrer l’ISSU, définissez le basculement pour tous les groupes de redondance afin qu’ils soient tous actifs sur un seul nœud (principal). Reportez-vous à la section Lancement d’un basculement manuel de groupe de redondance d’un cluster de châssis.

    Si vous utilisez Junos OS version 18.1 ou ultérieure, le système bascule automatiquement tous les groupes de groupes vers le GR0 principal.

  • Nous vous recommandons d’activer le redémarrage progressif pour tous les protocoles de routage avant de lancer un ISSU afin de minimiser les perturbations du trafic.

Sur tous les pare-feu pris en charge, le premier ISSU recommandé à partir de la version est Junos OS version 18.1R1.

La fonctionnalité ISSU de cluster de châssis permet de mettre à niveau les deux équipements d’un cluster à partir de versions de Junos OS prises en charge avec un impact sur le trafic comparable à celui des basculements de groupe de redondance.

Pour réaliser un ISSU à partir de la CLI sur Routing Engine2 :

  1. Téléchargez le progiciel à partir du site Web d’assistance Juniper Networks : https://www.juniper.net/support/downloads/
  2. Copiez le package sur le nœud principal du cluster. Nous vous recommandons de copier le package dans le répertoire /var/tmp , qui est un système de fichiers volumineux sur le disque dur. Notez que le nœud à partir duquel vous lancez l’ISSU doit avoir l’image logicielle.

    user@host>file copy ftp://username:prompt@ftp.hostname.net/filename /var/tmp/filename

  3. Vérifiez la version actuelle du logiciel qui s’exécute sur les deux nœuds en exécutant la show version commande sur le nœud principal.
  4. Démarrez l’ISSU à partir du nœud principal pour tous les groupes de redondance en entrant la commande suivante :

    Attendez que les deux nœuds terminent la mise à niveau (après quoi vous êtes déconnecté de l’appareil).

  5. Attendez quelques minutes, puis reconnectez-vous à l’appareil. Vérifiez à l’aide de la show version commande que les deux équipements du cluster exécutent la nouvelle version de Junos OS.
  6. Vérifiez que l’ensemble des stratégies, zones, groupes de redondance et autres objets temps réel (RTO) reviennent à leur état correct.
  7. Redéfinissez le nœud 0 comme nœud principal en exécutant la request chassis cluster failover node node-number redundancy-group group-number commande.

Si vous souhaitez que les groupes de redondance reviennent automatiquement au nœud 0 en tant que nœud principal après une mise à niveau logicielle en service (ISSU), vous devez configurer les priorités des groupes de redondance afin que le nœud 0 ait la priorité la plus élevée et activer l’option preempt .

Cette approche s’applique à tous les groupes de redondance, à l’exception du groupe de redondance 0 (RG0). Pour le RG0, le basculement doit être effectué manuellement.

Pour définir la priorité du groupe de redondance et activer l’option, reportez-vous à Exemple preempt : Configuration des groupes de redondance de cluster de châssis.

Pour définir manuellement le basculement d’un groupe de redondance, reportez-vous à la section Lancement d’un basculement manuel de groupe de redondance d’un cluster de châssis.

Pendant la mise à niveau, les deux appareils peuvent rencontrer des basculements de groupe de redondance ; Cependant, la circulation n’est pas perturbée. Avant de lancer la mise à niveau, chaque appareil valide le package de mise à niveau et vérifie la compatibilité des versions. Si le système détecte que la nouvelle version du package est incompatible avec la version actuellement installée, la mise à niveau est rejetée ou vous êtes invité à prendre des mesures correctives. Dans certains cas, une fonctionnalité spécifique peut être incompatible, dans de telles situations, le logiciel de mise à niveau vous invite à mettre fin à la mise à niveau ou à désactiver la fonctionnalité incompatible avant de continuer.

Si vous prévoyez d’utiliser le pare-feu en tant que périphérique autonome ou de supprimer un nœud d’un cluster de châssis, assurez-vous que la procédure ISSU a été complètement terminée sur les deux nœuds (si un ISSU a été initié).

Pour démarrer le processus ISSU sur les équipements SRX5K avec Routing Engine3 et sur les équipements SRX1600, SRX2300, SRX4120 et SRX4300 :

  1. Exécutez la commande suivante pour démarrer ISSU :

Voir aussi

Restaurer des périphériques dans un cluster de châssis après un ISSU

Si un ISSU échoue et qu’un seul appareil du cluster est mis à niveau, vous pouvez revenir à la configuration précédente sur l’appareil mis à niveau uniquement en exécutant l’une des commandes suivantes sur l’appareil mis à niveau :

  • request chassis cluster in-service-upgrade abort

  • request system software rollback node node-id reboot

  • request system reboot

Activer la restauration automatique d’un nœud de cluster de châssis après un ISSU

Si vous souhaitez que les groupes de redondance reviennent automatiquement au nœud 0 en tant que nœud principal après une mise à niveau logicielle en service (ISSU), vous devez configurer la priorité du groupe de redondance afin que le nœud 0 ait la priorité la plus élevée et activer l’option preempt .

Ce mécanisme s’applique à tous les groupes de redondance, à l’exception du groupe de redondance 0. Le groupe de redondance 0 ne prend pas en charge la préemption automatique et doit être basculé manuellement.

Pour définir les priorités des groupes de redondance et activer preempt l’option, reportez-vous à Exemple : Configuration des groupes de redondance de cluster de châssis. Pour lancer manuellement un basculement de groupe de redondance, reportez-vous à la section Lancement d’un basculement manuel de groupe de redondance d’un cluster de châssis.

Pour terminer la mise à niveau et rendre le nœud 0 disponible dans le cluster de châssis après ISSU, vous devez redémarrer manuellement le nœud 0. Le nœud 0 ne redémarre pas automatiquement dans le cadre du processus ISSU

Consignez les messages d’erreur utilisés pour dépanner les problèmes liés à ISSU

Les problèmes suivants peuvent survenir lors d’une mise à niveau d’ISSU : Vous pouvez identifier les erreurs à l’aide des détails des journaux. Pour plus d’informations sur des messages spécifiques du journal système, voir Explorateur du journal système.

Erreurs de processus Chassisd

Problème

Descriptif

Erreurs liées à chassisd.

La solution

Utilisez les messages d’erreur pour comprendre les problèmes liés à chassisd.

Au démarrage de l’ISSU , une requête est envoyée à chassisd pour vérifier s’il existe des problèmes liés à l’ISSU du point de vue du châssis. En cas de problème, un message de journal est créé.

Gestion des erreurs courantes pour ISSU

Problème

Descriptif

Vous pourriez rencontrer des problèmes au cours d’un ISSU. Cette section fournit des détails sur la façon de les gérer.

La solution

Toute erreur rencontrée lors d’un ISSU génère des messages de journal, et le processus ISSU se poursuit sans impact sur le trafic. Si un retour à une version précédente de Junos OS est nécessaire, l’événement est consigné ou le processus ISSU est arrêté pour éviter les incompatibilités de version entre les nœuds du cluster de châssis. Le Tableau 1 présente certaines des conditions d’erreur courantes et les solutions de contournement correspondantes. Les exemples de messages de journal présentés dans le tableau 1 proviennent du périphérique SRX1500, mais ils s’appliquent également à tous les pare-feu pris en charge.

Tableau 1 : Erreurs et solutions liées à ISSU

Conditions d’erreur

Nos solutions

Tentative de lancement d’un ISSU alors qu’une instance précédente d’un ISSU est déjà en cours

Le message suivant s’affiche :

warning: ISSU in progress

Vous pouvez abandonner le processus ISSU actuel et relancer l’ISSU à l’aide de la request chassis cluster in-service-upgrade abort commande.

Échec du redémarrage sur le nœud secondaire

Aucun temps d’arrêt ne se produit, car le nœud principal continue de fournir les services requis. Des messages de console détaillés s’affichent pour vous demander d’effacer manuellement les états ISSU existants et de restaurer le cluster de châssis.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

Le nœud secondaire n’a pas réussi à terminer la synchronisation à froid

Le nœud principal expire si le nœud secondaire ne parvient pas à terminer la synchronisation à froid. Des messages de console détaillés s’affichent indiquant que vous effacez manuellement les états ISSU existants et restaurez le cluster de châssis. Aucun temps d’arrêt de service ne se produit dans ce scénario.

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node

Échec du basculement d’une société secondaire nouvellement mise à niveau

Aucun temps d’arrêt ne se produit, car le nœud principal continue de fournir les services requis. Des messages de console détaillés s’affichent pour vous demander d’effacer manuellement les états ISSU existants et de restaurer le cluster de châssis.

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Échec de la mise à niveau sur le réseau principal

Aucun temps d’arrêt ne se produit, car le nœud secondaire bascule en tant que nœud principal et continue de fournir les services requis.

Échec du redémarrage sur le nœud principal

Avant le redémarrage du nœud principal, les périphériques étant hors de la configuration ISSU , aucun message d’erreur lié à ISSU n’est affiché. Le message d’erreur de redémarrage suivant s’affiche si un autre échec est détecté :

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

Erreurs liées au support ISSU

Problème

Descriptif

L’installation échoue en raison d’un logiciel non pris en charge et d’une configuration de fonctionnalités non prise en charge.

La solution

Utilisez les messages d’erreur suivants pour comprendre les problèmes liés à la compatibilité :

Échec des vérifications de validation initiale

Problème

Descriptif

Les vérifications de validation initiales échouent.

La solution

Les contrôles de validation échouent si l’image n’est pas présente ou si le fichier image est corrompu. Les messages d’erreur suivants s’affichent lorsque les vérifications de validation initiales échouent lorsque l’image n’est pas présente et que l’ISSU est abandonné :

En l’absence d’image

Lorsque le fichier image est corrompu

Si le fichier image est corrompu, la sortie suivante s’affiche :

Le nœud principal valide la configuration de l’appareil pour s’assurer qu’elle peut être validée à l’aide de la nouvelle version du logiciel. En cas de problème, l’ISSU abandonne et des messages d’erreur s’affichent.

Erreurs liées à l’installation

Problème

Descriptif

Le fichier image d’installation n’existe pas ou le site distant est inaccessible.

La solution

Utilisez les messages d’erreur suivants pour comprendre les problèmes liés à l’installation :

ISSU télécharge l’image d’installation comme spécifié dans la commande ISSU en tant qu’argument. Le fichier image peut être un fichier local ou situé sur un site distant. Si le fichier n’existe pas ou si le site distant est inaccessible, une erreur est signalée.

Erreurs de basculement du groupe de redondance

Problème

Descriptif

Problème avec l’échec du groupe de redondance automatique (RG).

La solution

Utilisez les messages d’erreur suivants pour comprendre le problème :

Erreurs de synchronisation de l’état du noyau

Problème

Descriptif

Erreurs liées à ksyncd.

La solution

Utilisez les messages d’erreur suivants pour comprendre les problèmes liés à ksyncd :

ISSU vérifie s’il y a des erreurs ksyncd sur le nœud secondaire (nœud 1) et affiche le message d’erreur en cas de problème et interrompt la mise à niveau.

Comportement de mise à niveau des logiciels en service spécifiques à la plate-forme

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.

Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.

Plate-forme

Différence

SRX Series

  • Prise en charge des pare-feu SRX1500, SRX4100 et SRX4200 pour la mise à niveau de Junos OS 17.4 vers les versions 17.4 successives et ne peuvent pas être mises à niveau vers les versions 17.4 à partir des versions précédentes de Junos OS.

  • Prise en charge des pare-feu SRX5400, SRX5600 et SRX5800 pour la mise à niveau de Junos OS 17.3 vers les versions 17.3 successives et ne peuvent pas être mises à niveau vers les versions 17.3 et supérieures à partir de versions antérieures de Junos OS.

  • SRX1500, SRX1600, SRX2300, SRX4120, SRX4100, SRX4200, SRX4300 et SRX4600, les pare-feu ne prennent pas en charge cette request system snapshot commande.

  • Les pare-feu SRX1500, SRX4100 et SRX4200 qui prennent en charge ISSU vous permettent de supprimer le fichier image d’origine. Inclure unlink à la user@host> request system software in-service-upgrade image-name-with-full-path unlink commande.

Informations supplémentaires sur la plate-forme

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.

D’autres plateformes peuvent être prises en charge.

Tableau 2 : Prise en charge de la plate-forme ISSU

Appareil

Version de Junos OS

SRX5800 et SRX5600

10.4R4 ou version ultérieure

SRX5400

12.1X46-D20 ou version ultérieure

SRX1500

15.1X49-D70 ou version ultérieure

SRX1600 et SRX2300, SRX4120

23.4R1 ou version ultérieure

SRX4100 et SRX4200

15.1X49-D80 ou version ultérieure

SRX4300

24.2R1 ou version ultérieure

SRX4600

17.4R1 ou version ultérieure

Documentation connexe