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 nud Junos

La mise à niveau de la segmentation de nœud Junos implique la mise à niveau de Juniper Device Manager (JDM), des fonctions réseau invitées (GNF) et du système de base (BSYS).

Mise à niveau de la segmentation de nud Junos

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

  • Package Juniper Device Manager (JDM)

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

  • Package 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é logicielle multiversion pour plus de détails). Vous pouvez également les mettre à niveau tous ensemble.

Note:

  • 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 :

      Note:

      • 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 s’exécutant 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 nouveaux GNF sur server1, vous ne pourrez pas passer commit synchronize ultérieurement 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 Junos OS version 23.2R1, 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 des 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 les JDM.

Note:

Si vous devez sauvegarder votre configuration JDM lors de la mise à niveau de JDM, vous devez d’abord installer Junos version 23.1R1 ou ultérieure sur votre équipement. En effet, les commandes de sauvegarde et de restauration des 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 random-mac-prefix. Le préfixe MAC fait partie des adresses MAC associées à la fonction GNF (Guest Network Function) sans licence.

  3. Désinstallez le JDM sur chaque serveur. Pour plus d’informations, reportez-vous à la section Gestion de la segmentation de nud 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 la procédure décrite dans Installation du package JDM RPM 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.

Note:

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 JDM RPM dans un répertoire (par exemple, /var/tmp).

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

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

      Note:

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

Pour mettre à niveau JDM pour le modèle intégré au 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 du réseau invité (GNF).

Mise à niveau de GNF et 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 autonome MX Series.

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 des vérifications multiversions (abordées plus loin dans ce guide), et toutes les GNF doivent être en ligne pendant la phase de vérification multiversion, faute de quoi la mise à niveau sera terminée. Dans le cas où un GNF reste arrêté, vous devez désactiver sa configuration à partir de la CLI BSYS, ce qui entraînera l’omission des vérifications multiversions pour ce GNF particulier.

Note:

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 forceCLI JDM . Cela peut être utile dans les rares cas 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 à un précédent 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 l’hôte de machine virtuelle basé sur WRL 9 - Modèle dans le châssis

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

Note:

Les versions de Junos OS antérieures à la version 19.3R1 utilisent la version WRL6 du logiciel VM Host. Junos OS 19.3R1 intègre la version WRL9 du logiciel VM Host. Pour vérifier la version de l’hôte de la machine virtuelle, sur la machine virtuelle BSYS, utilisez la commande show vmhost versionCLI Junos .

Procédez comme suit pour mettre à niveau JDM.

  1. Pour chacun des GNF, attribuez un rôle principal aux GNF de sauvegarde s’exécutant sur le moteur de routage1 (re1).

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

  3. Assurez-vous que la version de re0 VM Host 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 versionCLI Junos .

    Vous pouvez utiliser les CLI Junos suivantes pour mettre à niveau le logiciel VM Host :

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

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

  5. Installez le nouveau package JDM RPM 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 du moteur de routage 1 (r1).

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

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

Note:

La version 19.3R1 du logiciel JDM est compatible avec Junos OS version 19.3R1 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

Note:

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

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

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

    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 des interfaces, et des options de routage.
  6. Sur server0 JDM, ajoutez une version d’image GNF compatible avec la version JDM.

    Dans le cas où la version GNF est incompatible avec la version JDM, le message d’erreur suivant s’affiche :

  7. Patientez jusqu’à ce que le GNF apparaisse sur le JDM server0.
  8. Effectuez une synchronisation de validation à partir du moteur de routage principal (qui est le GNF exécuté sur le serveur1).
  9. Attribuez un rôle principal au GNF qui s’exécute sur le JDM server0.
  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 le JDM server0.
  14. Utilisez la commande show virtual-network-functions all-servers pour voir si les GNF sont activés.

Rétrogradation de JDM pour le modèle In-Chassis

Note:

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

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

  1. Attribuez un rôle principal aux GNF de sauvegarde exécutés 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 que celle qui s’exécute sur le serveur1.

    Dans le cas où 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 le serveur1).
  9. Configurez set system commit synchronize puis appliquez commit sur re0 JDM.

Maintenant, JDM est en place 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 unifiée en service (ISSU), ce qui vous permet de passer de deux versions de Junos OS différentes sans interruption du plan de contrôle et avec une perturbation minimale du trafic. Vous pouvez effectuer un ISSU unifié sur BSYS et GNF séparément. En outre, vous pouvez exécuter ISSU unifié sur chaque GNF indépendamment sans affecter les autres GNF. Voir aussi Comprendre le processus ISSU unifié.

Note:

  • Les restrictions de prise en charge logicielle multiversion (telles que les limites d’écart de version) s’appliquent également à la mise à niveau unifiée d’ISSU

  • Depuis Junos OS version 21.4R1, le MPC11E avec SLC (cartes de sous-ligne) prend en charge ISSU en mode zéro perte de paquets. Si vous exécutez une version antérieure de Junos OS, n’essayez pas d’exécuter ISSU sur une configuration de segmentation de nœud Junos comportant 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 du logiciel, des messages d’alerte s’affichent pendant le processus de mise à niveau du logiciel ou lorsqu’un GNF ou une FRU est activé. Lorsque des incompatibilités mineures surviennent, 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 permettant d’accepter l’incompatibilité et de continuer.

Note:

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 qu’il entraîne l’arrêt des vérifications multiversions, vous devez désactiver ce GNF pendant la mise à niveau du logiciel, 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é logicielle

Après une mise à jour logicielle d’un GNF ou d’un BSYS, s’il existe des incompatibilités logicielles entre le GNF et le BSYS, elles seront déclenchées en tant qu’alarme de châssis. Vous pouvez afficher les informations d’alarme d’incompatibilité à l’aide de la show chassis alarms commande. Vous pouvez afficher les détails des incompatibilités à l’aide de la show system anomalies commande. Pour plus d’informations, reportez-vous à la section Affichage des incompatibilités entre les versions logicielles.

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. Il 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 des logiciels BSYS et GNF. Cela n’entraîne pas la mise hors ligne du GNF.

Affichage des incompatibilités entre les versions logicielles

Pour afficher les incompatibilités logicielles à partir de BSYS, utilisez l’interface de ligne de commande comme illustré dans l’exemple suivant :

Pour afficher les incompatibilités logicielles d’un GNF, utilisez l’interface de ligne de commande comme illustré dans l’exemple suivant :

Note:

  • 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 FRU ou au niveau des fonctionnalités.

Redémarrage de serveurs externes

Les activités de maintenance du serveur, 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 dans 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 lors de l’arrêt all-servers de 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 de serveur comme indiqué dans l’exemple suivant :

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

    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 de l’interpréteur de commandes hôte Linux, arrêtez le JDM à l’aide de la commande suivante :
  4. À partir de l’interpréteur de commandes hôte Linux, vérifiez que l’état JDM est 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 recommencent 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 pourrait ê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 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 de la carte réseau X710 utilisée continue d’être la dernière version, comme décrit dans Mise à jour du pilote de carte réseau Intel X710 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 décrit 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 toute mise à jour du 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 la prise en charge étendue des mises à jour (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.

Note:

Vous devez vous assurer que Red Hat Subscription Manager est défini sur la version 7.3. Dans le cas contraire, 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 intégrer 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 de la prise en charge des mises à jour étendues de RHEL est une fonction du contrat d'assistance RHEL et dépasse le cadre 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 pour appliquer les 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 nécessitera probablement le redémarrage des serveurs x86 externes. Reportez-vous à la rubrique Mise à jour du système d’exploitation hôte dans 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 remplacer le pilote Intel i40e pour introduire une version de celui-ci qui ne répond pas aux exigences minimales de version du pilote i40e. Si c’est le cas, vous devez mettre à jour le pilote i40e pour répondre à la configuration minimale requise. Pour plus d’informations, reportez-vous à la section Mise à jour du pilote de carte réseau Intel X710 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 requis pour éloigner le moteur de routage principal du serveur affecté.

Nous commençons avec 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. Collectez 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 l’énergie renouvelable principale sur server0. Le moteur de routage de sauvegarde est re1 activé server1. Effectuez d’abord les mises à jour de sécurité du système d’exploitation hôte sur le serveur qui contient les moteurs de routage de sauvegarde.

    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 une requête stop activée server1 uniquement. server1 contient les moteurs de routage de sauvegarde pour tous les GNF. N’utilisez pas l’option all-servers . Exemple:

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

  7. Effectuez la yum mise à jour de 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 système d’exploitation server1 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 sauvegardé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 pour le conteneur Ubuntu, sur lequel est basé Juniper Device Manager (JDM).

Note:

JDM doit être en mesure d’accéder à Internet et doit avoir name-server configuré. Appliquez l’instruction de configuration CLI JDM suivante pour spécifier les name-serveréléments suivants :

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 en tant que root.

    root@server# jdm console

    Ou, à partir de l’interface de ligne de commande JDM, entrez 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 JDM :

    root@router> 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 l’affirmative 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@router> request vmhost jdm stop

    root@router> request vmhost jdm start

Documentation connexe