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 de la segmentation de nœud Junos

Segmentation de nœud Junos mise à niveau implique la mise à niveau du gestionnaire de périphériques Juniper (JDM), des fonctions réseau invitées (GNF) et du système de base (BSYS).

Mise à niveau de la segmentation de nœud Junos

La segmentation de nœud Junos comprend trois types de composants logiciels :

  • Progiciel Juniper Device Manager (JDM)

  • Image de Junos OS pour les fonctions réseau invitées (GNF)

  • Progiciel Junos OS pour système de base (BSYS)

Vous pouvez mettre à niveau chacun de ces composants indépendamment, à condition qu’ils se trouvent dans la plage de versions logicielles autorisée (voir Présentation de l’interopérabilité multiversion Logiciels pour plus de détails). Vous pouvez également tous les mettre à niveau ensemble.

Remarque :

  • Avant de commencer le processus de mise à niveau, enregistrez les configurations JDM, GNF VM et BSYS pour référence.

  • Si vous souhaitez exécuter la mise à niveau du BIOS sur une carte de ligne, vous devez vous assurer que le routeur est en mode autonome, en désactivant la configuration de la segmentation de nœud Junos.

Mise à niveau de JDM pour le modèle de serveur externe

  1. Mettez à niveau le JDM en effectuant les tâches suivantes sur les deux serveurs :

    1. Copiez le nouveau package JDM (RPM ou Ubuntu) dans un répertoire de l’hôte (par exemple, /var/tmp).

    2. Arrêtez le JDM à l’aide de la commande suivante :

    3. Exécutez la commande upgrade pour mettre à niveau le package JDM :

      Si vous mettez à niveau le package JDM RHEL, utilisez la commande suivante :

      Si vous mettez à niveau le package JDM Ubuntu, utilisez la commande suivante :

      Remarque :

      • Une mise à niveau JDM n’affecte aucun des GNF en cours d’exécution.

      • Avant de mettre à niveau JDM, assurez-vous que les deux déploiements JDM sont synchronisés. Cela signifie que :

        • Junos exécuté sur un GNF donné doit prendre en charge la même version de SMBIOS sur les deux serveurs.

        • Avant la mise à niveau, assurez-vous que tous les GNF existent sur les deux serveurs.

      • Après avoir mis à niveau les deux serveurs JDM, vous devez exécuter commit synchronize avant de configurer un nouveau GNF. Si vous n’exécutez commit synchronize pas et ne créez pas de GNF sur server1, vous ne pourrez pas faire commit synchronize plus tard de server0 à server1.

      • Vous devez mettre à niveau les deux JDM.

      Voir aussi :

Mise à niveau de JDM pour prendre en charge le déploiement basé sur Podman (23.2R1)

À partir de la version 23.2R1 de Junos OS, la segmentation de nœud Junos basée sur un serveur externe prend en charge le déploiement de Juniper Device Manager (JDM) à l’aide de l’outil Pod Manager (podman). Seuls les serveurs exécutant Red Hat® Enterprise Linux® (RHEL) 9 ou versions ultérieures prennent en charge podman.

Dans les versions de Junos antérieures à 23.2R1, la segmentation de nœud Junos basée sur un serveur externe prenait en charge RHEL 7.3, ce qui fournissait le pilote lxc de libvirt (libvirt-lxc) pour déployer des JDM.

Remarque :

Si vous devez sauvegarder votre configuration JDM pendant la mise à niveau de JDM, vous devez d’abord installer Junos version 23.1R1 ou ultérieure sur votre équipement. Par conséquent, les commandes permettant de sauvegarder et de restaurer les configurations JDM (request system save state path et request system restore state path) ne sont disponibles que dans Junos version 23.1R1 ou ultérieure.

Pour mettre à niveau votre JDM basé sur libvirt-lxc vers une version basée sur podman, suivez les étapes ci-dessous sur les deux serveurs :

  1. Vérifiez si les préfixes MAC aléatoires générés par le JDM sur les deux serveurs sont identiques.

  2. Sauvegardez votre configuration JDM dans le dossier /host/tmp/.

    Cette étape sauvegarde la configuration JDM et la valeur du préfixe mac aléatoire. Le préfixe MAC fait partie des adresses MAC associées à la fonction de réseau invité (GNF) sans licence.

  3. Désinstallez le JDM sur chaque serveur. Pour plus d’informations, reportez-vous à la section Gestion de la segmentation de nœud Junos.

  4. Mettez à niveau le système d’exploitation hôte vers RHEL 9.

  5. Installez le JDM basé sur podman. Il s’agit d’un processus d’installation régulier. Pour installer JDM, suivez les étapes indiquées dans Installation du package RPM JDM sur des serveurs x86 exécutant RHEL (modèle de serveur externe).

  6. Restaurez la sauvegarde JDM.

  7. Après avoir effectué les étapes ci-dessus sur les deux serveurs, vérifiez si les préfixes MAC aléatoires générés par le JDM sur les deux serveurs sont identiques.

Remarque :

Vous ne pouvez pas sauvegarder les GNF avant de mettre à niveau JDM d’une version basée sur libvirt-lxc vers une version basée sur podman. Vous devez reconfigurer les GNF après la mise à niveau de JDM.

Mise à niveau de JDM pour le modèle in-chassis

  1. Mettez à niveau le JDM en effectuant les tâches suivantes sur l’instance BSYS des deux moteurs de routage :

    1. Copiez le nouveau package RPM JDM dans un répertoire (par exemple, /var/tmp).

    2. Arrêtez le JDM en exécutant la commande suivante :

    3. Installez le package RPM JDM pour la segmentation de nœud Junos dans le châssis à l’aide de la commande indiquée dans l’exemple suivant :

      Remarque :

      Une mise à niveau JDM n’affecte aucun des GNF en cours d’exécution.
Remarque :

Pour mettre à niveau JDM pour le modèle dans le châssis, vous n’avez pas besoin de désinstaller le logiciel JDM existant. La désinstallation du JDM existant peut avoir un impact sur les fonctions réseau invitées (GNF).

Mise à niveau du GNF et du BSYS

Les packages GNF et BSYS peuvent être mis à niveau de la même manière que vous mettriez à niveau Junos OS sur un routeur MX Series autonome.

Assurez-vous que tous les GNF sont en ligne lorsque vous effectuez une mise à niveau. En effet, les processus de mise à niveau GNF et BSYS déclenchent tous deux des vérifications multiversions (abordées plus loin dans ce guide) et tous les GNF doivent être en ligne pendant la phase de vérification multiversion, faute de quoi la mise à niveau sera interrompue. Si un GNF reste fermé, vous devez désactiver sa configuration à partir de BSYS CLI, ce qui entraînera l’ignorance des vérifications de multiversion pour ce GNF particulier.

Remarque :

Une force option est également disponible, grâce à laquelle vous pouvez remplacer une image GNF existante par une nouvelle à l’aide de la commande request virtual-network-functions vnf-name add-image new-image-name forceJDM CLI . Cela peut être utile dans une situation rare où l’image GNF ne démarre pas. Vous pouvez également utiliser l’option force pour effectuer un nettoyage si, par exemple, vous avez brusquement mis fin à une opération précédente add-image en cours, en appuyant sur Ctrl-C (exemple : request virtual-network-functions vnf-name delete-image image-name force).

Mise à niveau de JDM pour prendre en charge WRL 9 Hôte de machine virtuelle - Modèle in-chassis

Si le moteur de routage doit exécuter Junos OS 19.3R1 ou version ultérieure, vous devez mettre à niveau JDM vers 19.3R1 ou version ultérieure.

Remarque :

Les versions de Junos OS publiées avant 19.3R1 utilisent la version WRL6 du logiciel hôte de la machine virtuelle. Junos OS 19.3R1 intègre la version WRL9 du logiciel hôte de machine virtuelle. Pour vérifier la version de l’hôte de la machine virtuelle, sur la machine virtuelle BSYS, utilisez la commande show vmhost versionJunos CLI .

Suivez les étapes suivantes pour mettre à niveau le JDM.

  1. Pour chacun des GNF, attribuez un rôle principal aux GNF de secours qui s’exécutent sur le moteur de routage 1 (re1).

  2. À re0, arrêtez d’abord les GNF du JDM, puis arrêtez le JDM lui-même de BSYS.

  3. Assurez-vous que la version de l’hôte de la machine virtuelle re0 est Junos OS 19.3R1 ou ultérieure. Pour vérifier la version de l’hôte de la machine virtuelle, utilisez la commande show vmhost versionJunos CLI .

    Vous pouvez utiliser les CLI Junos suivantes pour mettre à niveau le logiciel de l’hôte VM :

    Pour plus d’informations, consultez Installation, mise à niveau, sauvegarde et récupération de l’hôte de machine virtuelle.

  4. Lorsque re0 est sauvegardé après le redémarrage, copiez le nouveau package RPM JDM (19.3R1 ou version ultérieure) dans un répertoire (par exemple, /var/tmp).

  5. Installez le nouveau package RPM JDM sur re0, puis démarrez le JDM.

    Les GNF sur re0 démarrent automatiquement après cette étape.

  6. Répétez les étapes 1 à 5 sur le moteur de routage 1 (r1).

  7. Exécutez la request server authenticate-peer-server commande sur le JDM sur les deux moteurs de routage.

  8. Configurez set system commit synchronize puis appliquez commit sur re0 JDM.

Remarque :

La version 19.3R1 du logiciel JDM peut s’exécuter sur la version 19.3R1 de Junos OS ainsi que sur les versions de Junos OS antérieures à 19.3R1.

Voir aussi

Rétrogradation de JDM pour le modèle de serveur externe

Remarque :

Vous ne pouvez pas rétrograder Juniper Device Manager (JDM) installé dans une configuration de segmentation de nœud Junos basée sur un serveur unique.

Pour rétrograder JDM, procédez comme suit :

  1. Attribuez un rôle principal aux GNF de sauvegarde exécutés sur server1.
  2. Sur server0, arrêtez tous les GNF et supprimez la commit synchronize configuration.
  3. Sur server0, arrêtez et désinstallez JDM.
    Remarque :

    Si vous utilisez Ubuntu, utilisez la commande dpkg --purge jns-jdm pour désinstaller JDM.
  4. Sur server0, installez la version cible de JDM.
  5. Configurez JDM avec l’authentification racine ou les interfaces, et les options de routage.
  6. Sur server0 JDM, ajoutez une version d’image GNF compatible avec la version JDM.

    Si la version GNF est incompatible avec la version JDM, le message d’erreur suivant s’affiche :

  7. Attendez que le GNF apparaisse sur server0 JDM.
  8. Effectuez une synchronisation de validation à partir du moteur de routage principal (qui est le GNF exécuté sur server1).
  9. Attribuez un rôle principal au GNF qui s’exécute sur server0 JDM.
  10. Sur le serveur 1, répétez les étapes 2 à 5.
  11. Exécutez la request server authenticate-peer-server commande sur les deux serveurs.
  12. Postulez show server connections all-servers et assurez-vous qu’aucun problème n’est détecté.
  13. Configurez set system commit synchronize , puis appliquez commit sur server0 JDM.
  14. Utilisez la commande show virtual-network-functions all-servers pour voir si les GNF arrivent.

Rétrogradation de JDM pour un modèle intégré au châssis

Remarque :

Vous ne pouvez pas rétrograder Juniper Device Manager (JDM) installé dans une configuration de segmentation de nœud Junos unique basée sur un moteur de routage.

Pour rétrograder JDM, procédez comme suit :

  1. Attribuez un rôle principal aux GNF de sauvegarde s’exécutant sur le moteur de routage 1 (re1).
  2. Sur re0, arrêtez tous les GNF et supprimez la commit synchronize configuration.
  3. Sur re0, désinstallez JDM (sur BSYS principal).
  4. Sur re0, installez la version cible (exemple : 18.3R1) de JDM.
  5. Sur re0, déployez la même version de GNF qui s’exécute sur server1.

    Si la version GNF est incompatible avec la version JDM, le message d’erreur suivant s’affiche :

    Vous pouvez utiliser la commande suivante pour vérifier la version GNF.

  6. Sur re1, répétez les étapes 1 à 5.
  7. Exécutez la request server authenticate-peer-server commande sur les deux moteurs de routage.
  8. Effectuez une synchronisation de validation à partir du moteur de routage principal (qui est le GNF exécuté sur server1).
  9. Configurez set system commit synchronize puis appliquez commit sur re0 JDM.

JDM est maintenant disponible avec Junos OS version 18.3R1.

Prise en charge unifiée d’ISSU

La segmentation de nœud Junos prend également en charge la mise à niveau logicielle en service unifiée (ISSU), ce qui vous permet d’effectuer une mise à niveau entre deux versions différentes de Junos OS sans interruption sur le plan de contrôle et avec une interruption minimale du trafic. Vous pouvez effectuer un ISSU unifié sur BSYS et GNF séparément. De plus, vous pouvez exécuter un ISSU unifié sur chaque GNF indépendamment sans affecter les autres GNF. Voir aussi Comprendre l’ISSU unifiée.

Remarque :

  • Les restrictions de support logiciel multiversion (telles que les limites d’écart de version) s’appliquent également à la mise à niveau unifiée d’ISSU .

  • À partir de la version 21.4R1 de Junos OS, la MPC11E avec SLC (cartes de sous-ligne) prend en charge ISSU en mode sans perte de paquets. Si vous utilisez une version antérieure de Junos OS, n’essayez pas d’effectuer un ISSU sur une configuration de segmentation de nœud Junos qui comporte des SLC.

Gestion de l’interopérabilité des logiciels multiversions

La segmentation de nœud Junos prend en charge l’interopérabilité logicielle multiversion. Toutefois, en cas d’incompatibilités entre les versions logicielles, des messages d’alerte s’affichent pendant le processus de mise à niveau logicielle ou lorsqu’un GNF ou une FRU est activé. Lorsque des incompatibilités mineures se produisent, vous pouvez choisir de les accepter et de continuer. En cas d’incompatibilité majeure, vous devez soit mettre fin au processus, soit utiliser l’option force pour accepter l’incompatibilité et continuer.

Remarque :

En cas de mise à niveau du logiciel vmhost, l’option n’est force pas disponible. Par conséquent, si un GNF est hors ligne ou incompatible avec le logiciel en cours d’installation et entraîne l’arrêt des vérifications multiversions, vous devez désactiver ce GNF pendant la mise à niveau logicielle, puis le réactiver une fois la mise à niveau terminée.

Voici des exemples de messages qui s’affichent si des incompatibilités sont détectées lors de la mise à niveau du logiciel :

Sample alert message indicating a minor incompatibility:

Sample alert message indicating a major incompatibility:

Sample output showing how to use the 'force' option to proceed with an upgrade:

Affichage des alarmes d’incompatibilité des logiciels

Après la mise à jour logicielle d’un GNF ou d’un BSYS, s’il existe des incompatibilités logicielles entre le GNF et le BSYS, elles sont déclenchées sous forme d’alarme de châssis. Vous pouvez afficher les informations d’alarme d’incompatibilité à l’aide de la show chassis alarms commande. Vous pouvez afficher plus en détail les incompatibilités à l’aide de la show system anomalies commande. Pour plus de détails, voir Affichage des incompatibilités entre les versions de Logiciels.

Les alarmes n’apparaissent que sur les GNF, même si la mise à niveau est effectuée sur le BSYS. Les types d’alarme suivants peuvent se produire :

  • Incompatibilité du système avec BSYS : il s’agit d’une alarme majeure. Elle apparaît lorsque des incompatibilités entre les versions logicielles BSYS et GNF entraînent la mise hors ligne du GNF.

  • Incompatibilité des fonctionnalités avec BSYS : il s’agit d’une alarme mineure. Cela indique une incompatibilité mineure entre les versions logicielles BSYS et GNF. Cela n’entraîne pas la déconnexion du GNF.

Affichage des incompatibilités entre les versions des Logiciels

Pour afficher les incompatibilités logicielles à partir du BSYS, utilisez la CLI comme indiqué dans l’exemple suivant :

Pour afficher les incompatibilités logicielles d’un GNF, utilisez la CLI comme indiqué dans l’exemple suivant :

Remarque :

  • Comme indiqué dans la CLI, n’oubliez pas de spécifier l’ID GNF lors de l’affichage des incompatibilités à partir de BSYS.

  • Les exemples précédents montrent des incompatibilités au niveau du système. Utilisez les options ou config pour afficher les fru incompatibilités au niveau des FRU ou des fonctionnalités.

Redémarrage des serveurs externes

Les activités de maintenance des serveurs, telles que la mise à niveau du matériel ou du système d’exploitation hôte et l’isolation des pannes, peuvent nécessiter le redémarrage des serveurs externes utilisés pour la segmentation de nœud Junos. Utilisez la procédure suivante pour redémarrer les serveurs :

  1. Arrêtez tous les GNF.

    Si vous redémarrez les deux serveurs, choisissez l’option all-servers tout en arrêtant chaque GNF comme indiqué dans l’exemple suivant :

    Si vous redémarrez un serveur particulier, arrêtez les GNF sur ce serveur en spécifiant l’ID serveur comme indiqué dans l’exemple suivant :

  2. Vérifiez que les GNF ont été arrêtés.
    Remarque :

    Si vous souhaitez afficher l’état des GNF sur les deux serveurs, choisissez l’option all-servers . Exemple : show virtual-network-functions all-servers).
  3. À partir du shell hôte Linux, arrêtez le JDM à l’aide de la commande suivante :
  4. À partir du shell hôte Linux, vérifiez que l’état JDM s’affiche comme arrêté.
  5. Après le redémarrage, vérifiez que l’état JDM s’affiche maintenant comme étant en cours d’exécution.

Après un redémarrage du serveur, le JDM et les GNF configurés commenceront automatiquement à s’exécuter.

Si vous remplacez les serveurs, assurez-vous que la paire de serveurs d’exploitation continue d’avoir une configuration matérielle similaire ou identique. Si la paire de serveurs devait devenir temporairement différente pendant le remplacement (cela peut être le cas lors du remplacement séquentiel des serveurs), il est recommandé de désactiver GRES et NSR pendant cette période, et de les réactiver uniquement lorsque les deux serveurs sont à nouveau similaires.

Mise à jour du système d’exploitation hôte sur les serveurs externes

Avant de mettre à jour le système d’exploitation hôte sur un serveur externe, vous devez d’abord arrêter les GNF et JDM sur ce serveur comme décrit dans la section Redémarrage des serveurs externes.

Après la mise à jour du système d’exploitation hôte, si vous utilisez des cartes réseau Intel X710, assurez-vous que la version du pilote NIC X710 utilisée continue d’être la version la plus récente, comme décrit dans Mise à jour du pilote Intel X710 NIC pour les serveurs x86 .

Application des mises à jour de sécurité au système d’exploitation hôte

Le système d’exploitation hôte nécessite des mises à jour de sécurité de temps à autre. Cette section met en évidence les étapes à suivre pour appliquer les mises à jour de sécurité au système d’exploitation hôte à l’aide du système d’exploitation Red Hat (RHEL).

La segmentation de nœud Junos prend en charge RHEL 7.3.

Avant d’effectuer des mises à jour sur le système d’exploitation hôte, assurez-vous que Red Hat Subscription Manager est défini sur la version 7.3 et que le service d’abonnement Red Hat inclut un support de mise à jour étendu (EUS).

Vous pouvez utiliser la commande subscription-manager release --show pour confirmer que la version est définie sur 7.3. Si ce n’est pas le cas, vous pouvez utiliser la commande subscription-manager release --set=7.3 pour définir la version sur 7.3.

Remarque :

Vous devez vous assurer que Red Hat Subscription Manager est défini sur la version 7.3. Sinon, les mises à jour de RHEL tenteront d’effectuer une mise à niveau vers la dernière version mineure. Par exemple, RHEL 7.3 peut devenir RHEL 7.4 (ou une version ultérieure) avec une mise à jour générale yum , ou une yum mise à jour de sécurité peut extraire un nouveau noyau au-delà de RHEL 7.3.

La prise en charge étendue des mises à jour de Red Hat permet d'appliquer des correctifs et des mises à jour de sécurité dans la version spécifiée. L'utilisation autorisée du support de mise à jour étendue de RHEL est une fonction du contrat de support RHEL et dépasse le champ d'application de cette section. Vous pouvez vérifier si votre abonnement RHEL inclut la prise en charge étendue des mises à jour (EUS), à l’aide de la commande subscription-manager repos --list | grep rhel-7-server-eus-rpms. La prise en charge d’EUS n’est pas activée par défaut. EUS peut être activé à l’aide de la commande subscription-manager repos --enable rhel-7-server-eus-rpms.

Étapes d’application des mises à jour de sécurité du système d’exploitation hôte

L’application de mises à jour de sécurité au système d’exploitation hôte vous obligera probablement à redémarrer les serveurs x86 externes. Voir la rubrique Mise à jour du système d’exploitation hôte sur la rubrique Serveurs externes .

Il est également possible qu’une mise à jour de sécurité du système d’exploitation hôte apporte une nouvelle version du noyau. La mise à jour du noyau du système d’exploitation hôte peut également écraser le pilote Intel i40e pour en importer une version qui ne répond pas aux exigences de version minimale du pilote i40e. Si c’est le cas, vous devez mettre à jour le pilote i40e pour répondre à la configuration minimale requise. Pour plus de détails, consultez Mise à jour du pilote Intel X710 NIC pour les serveurs x86.

Avant de redémarrer les serveurs x86 externes, vous devez arrêter toutes les machines virtuelles GNF et JDM sur ce serveur. Étant donné que nous avons deux serveurs x86 externes, les mises à jour de sécurité du système d’exploitation hôte peuvent être effectuées sans interrompre le transfert GNF, en mettant à jour un serveur à la fois. Un basculement du moteur de routage principal GRES/NSR est nécessaire pour éloigner le moteur de routage principal du serveur concerné.

Nous commençons par le comportement par défaut du moteur de routage 1 (re1) en tant que moteur de routage de secours pour chaque GNF où re1 pour chaque GNF est en cours d’exécution sur le serveur x86 externe1.

  1. Sauvegardez toutes les configurations.

  2. Rassemblez une vue des versions du noyau et des packages du système d’exploitation hôte sur les serveurs x86 externes avant la mise à jour de sécurité du système d’exploitation hôte. Vérifiez également que le pilote i40e et le micrologiciel Intel X710 répondent aux exigences minimales (version : 2.4.10 et version : 18.5.17).

  3. Assurez-vous que RedHat Subscription Manager est défini sur RHEL 7.3 et que le référentiel EUS est activé.

  4. Assurez-vous que tous les GNF utilisent le RE principal le server0. Le moteur de routage de secours est re1 activé server1. Effectuez d’abord des mises à jour de sécurité du système d’exploitation hôte sur le serveur qui contient les moteurs de routage de secours.

    Exécutez cette commande sur tous les GNF pour confirmer que tous les GNF ont leur moteur de routage principal sur server0.

  5. Arrêtez toutes les machines virtuelles GNF dans l’interface de ligne de commande JDM via request stop on server1 uniquement. server1 contient les moteurs de routage de sauvegarde pour tous les GNF. N’utilisez pas cette all-servers option. Exemple :

  6. Arrêtez JDM sur le serveur affecté à partir du système d’exploitation hôte.

  7. Faites la mise à jour de yum sécurité et redémarrez le serveur.

  8. Rechargez ou compilez le pilote i40e. Consultez la page d’assistance Intel pour obtenir des instructions sur la mise à jour du pilote.

    À ce stade, la mise à jour de sécurité du server1 système d’exploitation hôte est terminée. Notez que les machines virtuelles GNF démarrent au redémarrage du serveur.

  9. Une fois les mises à jour de sécurité terminées, le serveur redémarré et les GNF restaurés, répétez l’opération sur l’autre serveur.

Application de correctifs de sécurité pour le conteneur Ubuntu

Des correctifs de sécurité doivent être appliqués de temps à autre au conteneur Ubuntu sur lequel repose Juniper Device Manager (JDM).

Remarque :

JDM doit pouvoir accéder à Internet et doit être name-server configuré. Appliquez l’instruction de configuration JDM CLI suivante pour spécifier le name-server:

root@jdm# set system name-server address

Procédez comme suit pour appliquer des mises à jour de sécurité aux composants de conteneur Ubuntu de JDM :

  1. Si vous utilisez le modèle de serveur externe, à partir du système d’exploitation hôte, utilisez la console JDM pour entrer JDM comme root.

    root@server# jdm console

    Ou, à partir du CLI JDM, entrez dans l’interpréteur de commandes JDM à l’aide de la commande :

    root@jdm> start shell user root

    Si vous utilisez la segmentation de nœud Junos dans le châssis, utilisez la commande suivante sur la machine virtuelle BSYS pour entrer dans JDM :

    root@routeur> request vmhost jdm login

  2. À partir de l’interpréteur de commandes JDM, utilisez la commande apt-get update pour télécharger des informations sur les nouveaux packages ou les dernières versions des packages actuellement installés.

    JDM-SRv1 :~# sudo apt-get update

  3. À partir de l’interpréteur de commandes JDM, utilisez la commande apt-get upgrade.

    JDM-SRv1 :~# sudo apt-get upgrade

    Une liste de mises à niveau s’affiche et vous êtes invité à continuer. Répondez Y par oui et appuyez sur Entrée.

  4. À partir de l’interpréteur de commandes JDM, utilisez la commande apt-get dist-upgrade pour effectuer la mise à niveau.

    JDM-SRv1 :~# sudo apt-get dist-upgrade

    Répondez Y lorsque vous êtes invité à continuer et attendez la fin des mises à niveau.

  5. Si vous utilisez le modèle de serveur externe, à partir du système d’exploitation hôte, redémarrez le JDM.

    user@server# sudo jdm restart

    Si vous utilisez la segmentation de nœud Junos dans le châssis, utilisez les commandes suivantes sur la machine virtuelle BSYS pour redémarrer le JDM :

    root@routeur> request vmhost jdm stop

    root@routeur> request vmhost jdm start

Documentation connexe