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 d’une mise à niveau logicielle en service

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

Consultez la section Comportement de mise à niveau logicielle en service spécifique à la plate-forme pour obtenir des remarques relatives à votre plate-forme.

La mise à niveau logicielle en service (ISSU) permet une mise à niveau logicielle d’une version de Junos OS vers une version ultérieure de Junos OS avec un temps d’arrêt minimal. Pour plus d’informations, consultez les rubriques suivantes :

Comprendre l’ISSU d’un cluster de châssis

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

La fonctionnalité ISSU du cluster de châssis permet de mettre à niveau les deux équipements d’un cluster à partir des versions prises en charge de Junos OS avec un minimum d’interruption du trafic et sans interruption de service.

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 de nouvelles fonctionnalités

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 pendant le 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 version qui prend en charge à la fois IPv4 et IPv6, le trafic IPv4 et IPv6 continue de fonctionner pendant le processus de mise à niveau. Junos OS version 10.2 et ultérieures prennent en charge le traitement basé sur les flux pour le trafic IPv6.

  • Au cours d’une ISSIS, vous ne pouvez pas mettre en ligne des PIC. Vous ne pouvez pas effectuer d’opérations telles que la validation, le redémarrage ou l’arrêt.

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

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

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

Le processus suivant se produit lors d’un ISSU pour les équipements d’un cluster de châssis. Les séquences données ci-dessous s’appliquent lorsque RG-0 est le noeud 0 (noeud primaire). Notez que vous devez initier un ISSU à partir du RG-0 principal. Si vous lancez la mise à niveau sur le nœud 1 (secondaire RG-0), un message d’erreur s’affiche.

  1. Au début d’un ISSU de cluster de châssis, le système bascule automatiquement tous les groupes de redondance RG-1+ qui ne sont pas principaux sur le nœud à partir duquel l’ISSU est lancé. Cette action permet de s’assurer que tous les groupes de redondance sont actifs uniquement sur le noeud principal RG-0.

    Le basculement automatique de tous les groupes de redondance RG-1+ est disponible à partir de la version 12.1 ou ultérieure de Junos OS. Si vous utilisez Junos OS version 11.4 ou antérieure, avant de démarrer l’ISSU, assurez-vous que tous les groupes de redondance sont tous actifs sur le nœud principal RG-0 uniquement.

    Une fois que le système a basculé tous les groupes de redondance RG-1+, il définit le bit de basculement manuel et définit toutes les priorités de nœud principal RG-1+ sur 255, que le groupe de redondance ait basculé ou non vers le nœud principal RG-0.

  2. Le nœud principal (nœud 0) valide la configuration de l’équipement pour s’assurer qu’elle peut être validée à l’aide de la nouvelle version du logiciel. Des vérifications sont effectuées pour vérifier la disponibilité de l’espace disque pour le système de fichiers /var sur les deux nœuds, les configurations non prises en charge et les cartes d’interface physique (PIC) non prises en charge.

    Si l’espace disque disponible sur l’un ou l’autre des moteurs de routage est insuffisant, le processus ISSU échoue et renvoie un message d’erreur. Toutefois, les PIC non pris en charge n’empêchent pas l’ISSU. Le logiciel émet un avertissement pour indiquer que ces PIC vont redémarrer pendant la mise à niveau. De même, une configuration de protocole non prise en charge n’empêche pas l’ISSU. Toutefois, le logiciel émet un avertissement indiquant que des pertes de paquets peuvent se produire pour le protocole pendant la mise à niveau.

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

  4. Le noeud 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 d’autres processus logiciels pour lSSU. Lorsque tous les processus sont prêts, chassisd envoie un message aux PIC installés dans l’appareil.

  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 (unified-ISSU ready) au châssis.

  7. Après avoir reçu le message (unified-ISSU ready) d’un moteur de transfert de paquets, le châssis 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 du FPC et une liaison interne haut débit est établie avec le nœud 1 exécutant le nouveau logiciel. Le châssis est également rétabli avec le noeud 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 a lieu et le nœud 1 devient le nouveau nœud principal (jusqu’à présent le nœud secondaire 1).

  10. Le nouveau noeud secondaire (jusqu’ici noeud principal 0) est maintenant mis à niveau vers la nouvelle image logicielle.

Lorsque les deux nœuds sont correctement mis à niveau, l’ISSU est terminé.

Lors de la mise à niveau d’un cluster de versions qui ne prend pas en charge le chiffrement vers une version qui prend en charge le chiffrement, mettez à niveau le premier nœud vers la nouvelle version. Si le chiffrement n’est pas configuré et activé, deux nœuds de versions différentes peuvent toujours communiquer entre eux et le service n’est pas interrompu. Après avoir mis à niveau le premier nœud, mettez à niveau le deuxième nœud vers la nouvelle version. Une fois la mise à niveau terminée, les utilisateurs peuvent décider d’activer ou non la fonctionnalité de chiffrement. Le chiffrement doit être désactivé avant de passer à une version qui ne prend pas en charge le chiffrement. Cela garantit que la communication entre un nœud de version compatible avec le chiffrement et un nœud rétrogradé n’est pas interrompue, car les deux ne sont plus chiffrés.

Note:

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 des stratégies sont modifiées et qu’elles 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 remarqueriez que les stratégies de sécurité ne sont pas synchronisées après une mise à niveau.

Configuration 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 terminal doit exécuter une version de Junos OS qui prend en charge ISSU pour la plate-forme spécifique. Voir le tableau 1 pour connaître la prise en charge de la plate-forme.

Tableau 1 : 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

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

Pour plus d’informations sur la prise en charge et les limitations d’ISSU , reportez-vous à la section Limitations de mise à niveau ISSU/ICU sur les équipements SRX Series.

Notez les limitations suivantes liées à une ISSU :

  • Le processus ISSU est terminé si la version de Junos OS spécifiée pour l’installation est antérieure à celle actuellement en cours d’exécution sur le périphérique.

  • Le processus ISSU est arrêté si la mise à niveau spécifiée entre en conflit avec la configuration actuelle, les composants pris en charge, etc.

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

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

  • ISSU tombe parfois en panne en cas de charge importante sur le processeur.

Pour rétrograder d’une version compatible ISSU vers une version antérieure (compatible ISSU ou non), utilisez la request system software add commande. Contrairement à une mise à niveau à l’aide du processus ISSU , une rétrogradation à l’aide de la request system software add commande peut entraîner des perturbations du réseau et des pertes de données.

Nous vous recommandons vivement de réaliser l’ISSU dans les conditions suivantes :

  • Lorsque les noeuds primaire et secondaire sont sains

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

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

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

Dans les cas où ISSU n’est pas pris en charge ou recommandé, alors que les temps d’arrêt lors de la mise à niveau du système doivent être minimisés, la procédure de temps d’arrêt minimal peut être utilisée (voir l’articleKB17947 de la base de connaissances.

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

Avant de commencer l’ISSU pour la mise à niveau des deux périphériques, tenez compte des instructions suivantes :

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

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

    • Tous les groupes de redondance sont d’état primaire ou secondaire

    • Il y a suffisamment d’espace disponible (deux fois plus d’espace que la taille de l’image) dans le fichier /var/tmp

    • L’utilisation du processeur est inférieure à 80 % dans les 5 secondes

    Si les conditions de pré-vérification ne sont pas remplies, ISSU prendra fin au début.

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

  • Si vous utilisez Junos OS version 11.4 ou 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 de cluster de châssis.

    Si vous utilisez Junos OS version 12.1 ou ultérieure, Junos OS bascule automatiquement tous les RG vers le RG0 principal.

  • Nous vous recommandons d’activer le redémarrage gracieux pour les protocoles de routage avant de démarrer un ISSU.

Sur tous les pare-feu SRX Series pris en charge, le premier ISSU recommandé est Junos OS version 10.4R4.

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

Pour effectuer un ISSU à partir de l’interface de ligne de commande 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 noeud 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 noeud à 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 en cours d’exécution 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 de 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 périphériques 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 noeud 0 comme noeud 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 définir la priorité du groupe de redondance de manière à ce que le nœud 0 soit principal et activer l’option preempt . Notez que cette méthode fonctionne pour tous les groupes de redondance, à l’exception du groupe de redondance 0. Vous devez définir manuellement le basculement pour le groupe de redondance 0.

Pour définir la priorité du groupe de redondance et activer l’option, reportez-vous à la preempt section Exemple : Configuration des groupes de redondance de clusters 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 de cluster de châssis.

Au cours de la mise à niveau, les deux équipements peuvent rencontrer des basculements de groupe redondants, mais le trafic n’est pas interrompu. Chaque équipement valide le package et vérifie la compatibilité des versions avant de commencer la mise à niveau. Si le système constate que la nouvelle version du package n’est pas compatible avec la version actuellement installée, l’équipement refuse la mise à niveau ou vous invite à prendre des mesures correctives. Il peut arriver qu’une seule fonctionnalité ne soit pas compatible, auquel cas le logiciel de mise à niveau vous invite soit à mettre fin à la mise à niveau, soit à désactiver la fonctionnalité avant de commencer la mise à niveau.

Si vous souhaitez réutiliser le pare-feu SRX Series en tant qu’appareil autonome ou supprimer un nœud d’un cluster de châssis, assurez-vous d’avoir terminé la procédure ISSU sur les deux nœuds (au cas où une procédure ISSU serait lancée)

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

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

Voir aussi

Restauration d’équipements dans un cluster de châssis après un ISSU

Si un ISSU ne se termine pas et qu’un seul périphérique du cluster est mis à niveau, vous pouvez revenir à la configuration précédente sur le périphérique mis à niveau uniquement en émettant l’une des commandes suivantes sur le périphérique mis à niveau :

  • request chassis cluster in-service-upgrade abort

  • request system software rollback node node-id reboot

  • request system reboot

Activation d’une restauration automatique du nœud du 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 définir la priorité du groupe de redondance de manière à ce que le nœud 0 soit principal et activer l’option preempt . Notez que cette méthode fonctionne pour tous les groupes de redondance, à l’exception du groupe de redondance 0. Vous devez définir manuellement le basculement pour un groupe de redondance 0. Pour définir la priorité du groupe de redondance et activer l’option, reportez-vous à la preempt section Exemple : Configuration des groupes de redondance de clusters 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 de cluster de châssis.

Pour mettre à niveau le nœud 0 et le rendre disponible dans le cluster de châssis, redémarrez manuellement le nœud 0. Le nœud 0 ne redémarre pas automatiquement.

Consigner les messages d’erreur utilisés pour résoudre les problèmes liés à ISSU

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

Erreurs de processus Chassisd

Problème

Description

Erreurs liées au châssis.

Solution

Utilisez les messages d’erreur pour comprendre les problèmes liés au châssis.

Au démarrage d’ISSU , une requête est envoyée à chassisd pour vérifier s’il y a 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éé.

Comprendre la gestion des erreurs courantes pour ISSU

Problème

Description

Vous pourriez rencontrer des problèmes au cours d’une ISSI. Cette section fournit des détails sur la façon de les traiter.

Solution

Toute erreur rencontrée au cours d’un ISSU entraîne la création de messages de journal, qui continuent de fonctionner sans impact sur le trafic. S’il est nécessaire de revenir aux versions précédentes, l’événement est soit consigné, soit l’ISSU est arrêté, afin de ne pas créer de versions incompatibles sur les deux nœuds du cluster de châssis. Le Tableau 2 présente certaines des conditions d’erreur courantes et les solutions de contournement. Les exemples de messages utilisés dans le Tableau 2 proviennent du périphérique SRX1500 et s’appliquent également à tous les pare-feu SRX Series pris en charge.

Tableau 2 : Erreurs et solutions liées à l’ISSU

Conditions d’erreur

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 en cours et relancer l’ISSU à l’aide de la request chassis cluster in-service-upgrade abort commande.

Échec du redémarrage sur le noeud secondaire

Aucun temps d’arrêt de service ne se produit, car le nœud principal continue de fournir les services requis. Des messages détaillés s’affichent sur la console, vous demandant d’effacer manuellement les états ISSU existants et de restaurer le cluster du 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

À partir de Junos OS version 17.4R1, le délai de mise en attente pour le redémarrage initial du nœud secondaire pendant le processus ISSU est étendu de 15 minutes (900 secondes) à 45 minutes (2700 secondes) dans les clusters de châssis sur les périphériques SRX1500, SRX4100, SRX4200 et SRX4600.

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

Le noeud principal expire si le noeud secondaire ne parvient pas à terminer la synchronisation à froid. Des messages détaillés s’affichent sur la console vous indiquant que vous effacez manuellement les états ISSU existants et que vous restaurez le cluster du 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 du serveur secondaire récemment mis à niveau

Aucun temps d’arrêt de service ne se produit, car le nœud principal continue de fournir les services requis. Des messages détaillés s’affichent sur la console, vous demandant d’effacer manuellement les états ISSU existants et de restaurer le cluster du 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 serveur principal

Aucun temps d’arrêt de service 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 noeud principal, les périphériques étant hors de la configuration ISSU , aucun message d’erreur lié à ISSU ne s’affiche. Si une autre défaillance est détectée, le message d’erreur de redémarrage suivant s’affiche :

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

Description

L’échec de l’installation se produit en raison d’un logiciel et d’une configuration de fonctionnalités non pris en charge.

Solution

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

La validation initiale vérifie l’échec

Problème

Description

Les vérifications de validation initiales échouent.

Solution

Les contrôles de validation échouent si l’image n’est pas présente ou si le fichier image est endommagé. 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é :

Lorsque l’image n’est pas présente

Lorsque le fichier image est corrompu

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

Le nœud principal valide la configuration de l’équipement 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

Description

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

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. Il peut s’agir d’un fichier local ou d’un fichier distant. Si le fichier n’existe pas ou si le site distant est inaccessible, une erreur est signalée.

Erreurs de basculement de groupe de redondance

Problème

Description

Problème de défaillance du groupe de redondance automatique (RG).

Solution

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

Erreurs de synchronisation de l’état du noyau

Problème

Description

Erreurs liées à ksyncd.

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 noeud secondaire (noeud 1) et affiche le message d’erreur s’il y a des problèmes et abandonne la mise à niveau.

Comportement de mise à niveau logicielle en service spécifique à la plate-forme

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

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

Plateforme

Différence

SRX Series

  • Les pare-feu SRX1500, SRX4100 et SRX4200 permettent la mise à niveau de Junos OS 17.4 vers des versions 17.4 successives mais ne peuvent pas effectuer de mise à niveau vers la version 17.4 à partir des versions Junos OS précédentes.

  • Les pare-feu SRX5400, SRX5600 et SRX5800 prennent en charge la mise à niveau de Junos OS 17.3 vers les versions 17.3 successives et ne peuvent pas effectuer de mise à niveau vers la version 17.3 et les versions ultérieures à partir des versions Junos OS.

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

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

Documentation connexe

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libérer
Description
17.4R1
À partir de Junos OS version 17.4R1, SRX4600 appareils prennent en charge ISSU.
17.4R1
À partir de Junos OS version 17.4R1, le délai de mise en attente pour le redémarrage initial du nœud secondaire pendant le processus ISSU est étendu de 15 minutes (900 secondes) à 45 minutes (2700 secondes) dans les clusters de châssis sur les périphériques SRX1500, SRX4100, SRX4200 et SRX4600.
15.1X49-D80
À partir de Junos OS version 15.1X49-D80, les équipements SRX4100 et SRX4200 prennent en charge ISSU.
15.1X49-D70
À partir de Junos OS version 15.1X49-D70, SRX1500 appareils prennent en charge ISSU.