Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Provisionner un Virtual Chassis à l’aide du client phone-home

Le provisionnement téléphonique à domicile sur un Virtual Chassis est une forme de zero-touch provisioning (ZTP). Le client de réception (PHC) sur le Virtual Chassis reçoit les informations d’amorçage sur le réseau à partir d’un serveur de réception téléphonique (PHS) et provisionne le Virtual Chassis. La seule intervention de l’utilisateur requise côté client est de relier physiquement les membres du Virtual Chassis entre eux et de connecter n’importe quel port du Virtual Chassis au réseau.

Présentation du provisionnement téléphonique pour un Virtual Chassis

Avec le provisionnement à domicile, un client téléphonique (PHC) sur un appareil provisionne initialement l’équipement avec une image logicielle et une configuration à partir d’une source de données de gestion réseau centrale appelée serveur téléphonique (PHS), ce qui nécessite peu ou pas d’intervention de l’utilisateur sur le site distant.

Un Virtual Chassis est constitué d’un ensemble d’équipements interconnectés à l’aide de ports appelés ports Virtual Chassis (VCP). Vous configurez et gérez le Virtual Chassis comme un seul appareil. À partir de la version 20.3R1 de Junos OS, nous avons étendu le processus de provisionnement du téléphone à domicile pour un équipement autonome afin qu’il puisse également fonctionner sur un Virtual Chassis. Le PHC sur un Virtual Chassis nécessite des étapes supplémentaires pour coordonner et gérer l’amorçage des équipements membres.

Le PHS fait généralement partie d’un système de gestion de réseau (NMS) qui prend en charge le provisionnement téléphonique à domicile. Votre administrateur réseau saisit les données de provisionnement prévues qui indiquent comment les appareils et le Virtual Chassis sur les sites distants doivent être configurés. Votre organisation peut avoir plusieurs PHS pour la redondance.

Vous pouvez consulter l’Explorateur de fonctionnalités et rechercher phone-home les plates-formes Virtual Chassis qui prennent en charge le provisionnement de la téléphonie à domicile.

Avantages du provisionnement téléphonique à domicile sur un Virtual Chassis

  • Simplifie le provisionnement en lançant automatiquement le processus à partir du site distant, tout en obtenant en toute sécurité les informations d’amorçage à partir d’un système de gestion central (PHS) sur votre réseau ou dans le cloud.

  • Ne nécessite pas d’expérience approfondie avec le CLI Junos OS pour coordonner le provisionnement de plusieurs appareils composant un Virtual Chassis.

Présentation du processus de provisionnement téléphonique sur un Virtual Chassis

Sur un Virtual Chassis qui prend en charge le provisionnement téléphonique à domicile, pour que le processus fonctionne, vous devez configurer le Virtual Chassis conformément aux exigences décrites dans la section Activation du provisionnement téléphonique sur un réseau Virtual Chassis.

Lorsque le composant Virtual Chassis se forme initialement, le processus PHC démarre automatiquement sur le membre principal du Virtual Chassis et suit :

  1. Le PHC se connecte à un PHS.

    Le PHC envoie une demande de provisionnement à une URL de serveur de redirection par défaut, https://redirect.juniper.net, qui redirige la demande vers un PHS disponible contrôlé par votre administrateur réseau ou NMS. Cette étape est identique au provisionnement téléphonique sur un seul appareil.

  2. Le PHS répond à la demande de provisionnement PHC avec les informations d’amorçage, qui comprennent la topologie, l’image logicielle et la configuration prévues du Virtual Chassis.

  3. Le PHC provisionne le Virtual Chassis comme spécifié par le PHS.

    Le provisionnement comprend des étapes telles que :

    • Validez la topologie Virtual Chassis.

    • Mettez à niveau l’image logicielle séquentiellement sur tous les appareils membres si nécessaire.

    • Exécutez des scripts de préconfiguration ou de post-configuration.

    • Validez une nouvelle configuration sur le Virtual Chassis.

Le PHC envoie des notifications d’état au PHS pendant le processus d’amorçage, afin que l’administrateur réseau puisse vérifier que le processus s’est bien terminé.

Le PHC consigne également l’état localement dans les fichiers journaux système du Virtual Chassis. Si nécessaire, vous pouvez afficher les fichiers journaux dans le CLI Junos OS et utiliser les commandes Junos OS CLI pour voir l’état de la connexion Virtual Chassis et VCP.

Voir aussi

Comment activer le provisionnement téléphonique à domicile sur un Virtual Chassis

Sur un Virtual Chassis qui prend en charge le provisionnement phone-home, si vous configurez le Virtual Chassis selon les étapes répertoriées ici, un processus de client phone-home (PHC) démarre automatiquement sur le membre principal de Virtual Chassis.

Pour activer le provisionnement téléphonique à domicile sur un Virtual Chassis :

  1. Assurez-vous que tous les membres de Virtual Chassis ont la configuration d’usine par défaut et sont hors tension.

    Vous pouvez exécuter la request system zeroize commande CLI de Junos OS pour rétablir l’état d’usine d’un équipement.

    Remarque :

    Le Virtual Chassis ne peut pas être un Virtual Chassis en mode mixte, car le mode mixte n’est jamais défini dans la configuration d’usine par défaut.

  2. Interconnectez les membres de Virtual Chassis dans une topologie en anneau en utilisant uniquement des ports Virtual Chassis (VCP) dédiés ou configurés par défaut sur chaque périphérique membre.

    Gardez à l’esprit que le processus PHC ne fonctionne que si le Virtual Chassis est initialement formé avec des VCP qui n’ont pas besoin d’être explicitement configurés (VCP dédiés ou ports qui sont des VCP dans la configuration d’usine par défaut). Voir Options VCP par type de commutateur pour plus d’informations sur les ports dédiés et les VCP configurés par défaut sur différents périphériques prenant en charge Virtual Chassis. Consultez le guide matériel de l’appareil pour localiser ces ports sur l’appareil.

  3. Connectez l’interface de gestion Virtual Chassis (me0) ou tout port réseau de n’importe quel membre de Virtual Chassis au réseau.

    Une fois que le PHC démarre sur le Virtual Chassis, il utilise cette connexion pour accéder à un PHS sur le réseau et récupérer les informations d’amorçage de ce Virtual Chassis.

    Pour plus de détails sur le fonctionnement des interfaces de gestion sur un Virtual Chassis, voir Présentation de la gestion globale d’un Virtual Chassis.

  4. Mettez les membres du Virtual Chassis sous tension.

La figure 1 montre un exemple de topologie Virtual Chassis pouvant prendre en charge le provisionnement téléphonique à domicile : un Virtual Chassis EX4300 à quatre membres câblé dans une topologie en anneau à l’aide de VCP configurés par défaut (dans ce cas, deux des ports QSFP+ 40 Gigabit Ethernet de chaque appareil).

Figure 1 : Exemple de Virtual Chassis pouvant prendre en charge leRack-mounted server setup with multiple stacked units, labeled ports, connectors, power inputs, and orange lines showing connection paths. provisionnement téléphonique à domicile

Habituellement, vous n’avez rien d’autre à faire pour que le processus de provisionnement de la maison téléphonique se déroule et se termine correctement. Si vous ne voyez pas l’état d’achèvement réussi ou si le Virtual Chassis n’est pas opérationnel et ne fonctionne pas comme prévu à la fin du processus, lisez la suite pour en savoir plus sur le fonctionnement du PHC pour vous aider à résoudre les problèmes.

Voir aussi

Processus de téléphone à domicile sur un Virtual Chassis

Le provisionnement d’accueil téléphonique sur un Virtual Chassis est une extension de la prise en charge d’accueil téléphonique d’un appareil autonome décrite dans Obtention de configurations et d’une image Logiciels sans intervention de l’utilisateur à l’aide du client d’accueil téléphonique. Le PHC effectue des étapes supplémentaires pour gérer l’amorçage des périphériques membres qui composent le Virtual Chassis.

Sur un Virtual Chassis, le processus de calcul de santé primaire (PHC) requiert les mêmes outils logiciels et utilitaires que les appareils autonomes pour fonctionner. Par exemple, le processus de connexion téléphonique a besoin de la prise en charge du client DHCP pour faciliter la connexion réseau au PHS de la même manière que pour un seul appareil, et vérifie une image logicielle téléchargée à l’aide des mêmes utilitaires de somme de contrôle. Voir Prérequis pour une liste de ces exigences générales des SSP.

Le provisionnement de répertoire téléphonique démarre automatiquement sur un Virtual Chassis côté client une fois que vous avez effectué les tâches décrites dans Comment activer le provisionnement de répertoire téléphonique sur un Virtual Chassis et si le Virtual Chassis remplit les conditions décrites dans Exigences relatives au provisionnement de répertoire téléphonique pour fonctionner pour un Virtual Chassis.

Les étapes du processus de provisionnement sont regroupées dans les étapes décrites dans cette section.

Informations de démarrage et de provisionnement des demandes de PHS

Au démarrage et à l’étape de la demande :

  1. Le Virtual Chassis démarre à l’état d’usine par défaut ou à zéro en tant que Virtual Chassis non provisionné et élit les membres principaux et de secours initiaux. (Voir Présentation du mode d’élection du principal dans un Virtual Chassis.)
  2. Le PHC démarre sur le membre principal Virtual Chassis, se connecte au serveur de redirection par défaut (https://redirect.juniper.net) et envoie une requête d’amorçage pour le périphérique. Le serveur de redirection redirige le PHC vers un PHS disponible.
  3. Le PHC reçoit la réponse de PHS, commence à découvrir quels membres du Virtual Chassis sont connectés et se prépare à provisionner le Virtual Chassis. La réponse de PHS comprend :

    • Informations sur la topologie du Virtual Chassis : cette partie de la réponse indique au minimum que l’appareil est censé faire partie d’un Virtual Chassis ; sinon, le PHC ne prévoit que le membre principal en tant qu’appareil autonome.

      La réponse peut en outre contenir des informations de topologie complètes, qui incluent les ID de série de tous les membres que l’administrateur réseau s’attend à voir dans le Virtual Chassis.

    • Logiciels informations de mise à niveau de l’image : comprend un chemin d’accès à l’image logicielle prévue et aux détails de vérification de l’image.

    • Informations sur les scripts de préconfiguration et de postconfiguration : inclut tous les scripts de transfert que l’administrateur réseau doit exécuter au PHC avant ou après l’application de la nouvelle configuration.

    • Informations de configuration : inclut la configuration Virtual Chassis prévue et la méthode d’application de cette configuration.

    Le PHC doit recevoir les informations de topologie minimales requises pour reconnaître qu’il doit provisionner un Virtual Chassis. Sinon, le PHC provisionne par défaut uniquement le membre principal en tant que périphérique autonome.

    Les extensions PHC pour Virtual Chassis prennent en charge deux modes de provisionnement : le mode par défaut et un mode plus strict que PHS peut spécifier dans la réponse :

    • Par défaut, le PHC provisionne tous les membres qu’il détecte dans le VC au moment où il reçoit la réponse du PHS. Si le PHC rencontre une erreur lors de l’amorçage d’un membre particulier, il passe à l’amorçage du membre suivant ou passe à l’étape de provisionnement suivante.

    • Si le PHS spécifie l’option de mode strict dans la réponse, la réponse doit également inclure les informations complètes sur la topologie du Virtual Chassis. Le provisionnement ne réussit que si le PHC trouve et amorce avec succès tous les membres répertoriés dans la réponse PHS. Si le PHC ne détecte pas tous les membres prévus ou si le provisionnement échoue pour l’un d’entre eux, il redémarre le processus depuis le début pour renvoyer la demande de provisionnement à un autre PHS disponible.

    Remarque :

    Le PHS peut inclure les ID de série des membres du Virtual Chassis dans la réponse dans l’un ou l’autre mode. Toutefois, en mode par défaut, l’amorçage du Virtual Chassis peut réussir même si le PHC ne détecte pas tous les membres de la réponse PHS ou si la réponse PHS n’inclut pas du tout les détails des membres.

    Dans cette étape, si la réponse inclut des informations complètes sur la topologie du Virtual Chassis et indique d’utiliser le mode de provisionnement strict, le PHC valide ce qu’il trouve dans le Virtual Chassis localement par rapport aux informations du membre du Virtual Chassis de la réponse PHS.

    Le Tableau 1 résume les actions entreprises par le PHC à partir de cette étape en fonction du type d’informations de topologie qu’il reçoit dans la réponse PHS, du mode de provisionnement et des membres Virtual Chassis que le PHS détecte localement.

    Tableau 1 : Mesures prises par les PHC en fonction des informations topologiques dans la réponse PHS

    Informations sur la topologie Virtual Chassis à partir de PHS

    Actions du mode par défaut

    Actions en mode strict si PHS demande cette option

    Aucune information de topologie fournie

    Essayez de provisionner en tant qu’appareil autonome.

    S.O.

    (Ce mode ne peut être spécifié qu’avec des informations de topologie complètes)

    Informations de topologie minimales requises pour un Virtual Chassis

    Découvrez les membres et procédez au provisionnement de Virtual Chassis avec les membres trouvés.

    S.O.

    (Ce mode ne peut être spécifié qu’avec des informations de topologie complètes)

    Informations complètes sur la topologie d’un Virtual Chassis, y compris les ID de série de tous les membres Virtual Chassis prévus

    Découvrez les membres. Si la liste des membres ne correspond pas à la réponse PHS, continuez quand même à provisionner Virtual Chassis avec les membres trouvés.

    Bootstrap destiné aux membres de Virtual Chassis à partir de la réponse PHS. Détecter les membres ; Si tous les membres attendus sont présents et opérationnels, le provisionnement réussit.

    Sinon, réessayez d’amorcer et de détecter les membres qui ont échoué au processus.

    Après le délai de détection des membres avec incapacité de détection de tous les membres attendus, signaler une erreur et redémarrer le processus en contactant un autre PHS pour demander à nouveau le provisionnement.
  4. Si le PHC procède au provisionnement des périphériques dans le Virtual Chassis, à ce stade, il valide certaines modifications temporaires de la configuration du Virtual Chassis pour permettre un démarrage fluide de tous les membres du VC.

    Par exemple, le PHC s’assure que les rôles des membres principaux et de sauvegarde de Virtual Chassis ne changent pas pendant qu’il met à niveau l’image logicielle de tous les membres.

Membres de Bootstrap Virtual Chassis

À ce stade, le PHC démarre le Virtual Chassis, ce qui inclut l’installation de l’image logicielle et le redémarrage de tous les membres.

  1. Le PHC sur le membre principal compare les informations d’amorçage de la réponse PHS avec celles du Virtual Chassis pour voir s’il doit mettre à niveau l’image logicielle. Si les versions correspondent, le PHC ignore les étapes restantes de cette étape.
  2. Si le PHC doit mettre à niveau l’image logicielle, il utilise les informations d’amorçage de la réponse PHS (nom du fichier image et informations de somme de contrôle) pour télécharger et valider l’image.

    Si l’opération de transfert échoue, le PHC retente jusqu’à ce qu’il réussisse. (Ce comportement est le même pour le provisionnement d’appareils autonomes ou de téléphone à domicile Virtual Chassis.)

  3. Le PHC procède à l’installation et au redémarrage des membres de Virtual Chassis en fonction des rôles des membres, comme suit dans cet ordre :

    1. Membres de la carte de ligne : installe l’image sur les membres du rôle de carte de ligne de manière séquentielle (dans l’ordre de l’ID membre), puis les redémarre tous en même temps.

    2. Membre de sauvegarde : installe l’image sur le membre de sauvegarde et la redémarre.

    3. Membre principal : installe l’image sur le membre principal, synchronise l’état d’amorçage actuel de PHC Virtual Chassis avec le membre de sauvegarde et déclenche le redémarrage du membre principal.

    Lorsque les membres mis à niveau démarrent, le PHC vérifie qu’ils sont à nouveau opérationnels. Cette action est appelée détection de membre dans les messages de journal et les notifications d’état. Si le PHC ne parvient pas à détecter un membre dans un délai de détection de membre par défaut, il informe le PHS de l’erreur. Voir Informations de démarrage et de demande de provisionnement à PHS pour connaître les actions effectuées par défaut par PHC ou si le PHS a spécifié un provisionnement strict.

  4. Pendant le redémarrage de l’ancien membre principal, le membre principal d’origine n’est pas disponible, de sorte que le rôle principal de Virtual Chassis bascule vers le membre de secours. Le Virtual Chassis élit également un nouveau membre suppléant à ce moment-là.
  5. Le PHC démarre sur le nouveau membre principal (le membre de sauvegarde d’origine) et reprend la procédure d’amorçage Virtual Chassis à partir de l’état PHC hérité de l’ancien composant principal.

    Lorsque l’ancien principal termine le démarrage et rejoint le Virtual Chassis, il joue initialement le rôle de carte de ligne, puis assume le rôle de sauvegarde pour le nouveau membre principal.

  6. Lorsque le PHC détecte que ce dernier membre est opérationnel, le processus de provisionnement passe à l’étape suivante pour appliquer les scripts de préconfiguration ou de postconfiguration et la nouvelle configuration au Virtual Chassis.
    Remarque :

    Évitez de demander à des scripts de pré-configuration, de post-configuration ou à la nouvelle configuration d’apporter des modifications qui pourraient amener le Virtual Chassis à attribuer de nouveaux rôles de membre ou à élire de nouveaux membres principaux et suppléants pendant le processus de provisionnement. Sinon, le provisionnement risque d’échouer et d’obtenir des résultats imprévisibles.

Application de scripts et de nouvelles configurations sur le Virtual Chassis

La réponse du PHS peut inclure des scripts de préconfiguration et de postconfiguration dont l’administrateur réseau a besoin que le PHC s’exécute sur le Virtual Chassis avant ou après l’application de la nouvelle configuration. Le provisionnement à domicile prend en charge les scripts Python ou shell et uniquement le format XML pour la configuration.

La réponse PHS fournit également la configuration Junos OS pour que PHC valide sur les équipements membres du Virtual Chassis.

Un Virtual Chassis fonctionne comme s’il s’agissait d’un seul appareil, de sorte que le PHC effectue ces étapes sur le Virtual Chassis dans son ensemble :

  1. Exécute tous les scripts de préconfiguration spécifiés à partir de PHS.
  2. Applique et valide la nouvelle configuration à partir de PHS.
  3. Exécute tous les scripts de post-configuration spécifiés à partir de PHS.

Fin du processus de provisionnement

Pour terminer le processus de provisionnement téléphonique, le PHC consigne que le processus s’est terminé avec succès et envoie une notification d’achèvement d’amorçage au PHS.

Le PHC ne s’exécute pas à nouveau, sauf si vous renvoyez l’appareil ou le Virtual Chassis à l’état d’usine par défaut et que vous remplissez toutes les autres conditions requises pour déclencher le provisionnement du téléphone à domicile.

Pour plus d’informations, consultez Configuration requise pour le provisionnement téléphonique à domicile pour un Virtual Chassis .

Notifications d’état du provisionnement téléphonique à domicile

Le PHC consigne les informations d’état localement dans le journal système (/var/log/messages) sur le Virtual Chassis et envoie des notifications d’état au PHS pour signaler la progression du processus de provisionnement. Ces messages signalent lorsque le PHC termine les différentes étapes de provisionnement et vous aident à résoudre les problèmes si le processus ne se termine pas correctement. Voir Processus de téléphone à domicile sur un Virtual Chassis pour connaître les étapes que le PHC effectue à chaque étape du provisionnement Virtual Chassis.

Certains messages d’état PHC sont généraux et s’appliquent soit au provisionnement d’un seul appareil, soit au provisionnement Virtual Chassis.

Les messages de notification spécifiques à un membre Virtual Chassis particulier incluent :

  • L’ID de membre

  • Le numéro de série du membre

  • Rôle actuel du membre dans le Virtual Chassis (carte principale, de sauvegarde ou de ligne)

Les notifications spécifiques aux membres de Virtual Chassis ont le format suivant :

Par exemple :

Les notifications de processus de téléphone à domicile se composent d’un type de notification et d’un message. Le Tableau 2 répertorie les notifications spécifiques aux étapes de provisionnement téléphonique sur un Virtual Chassis. Les types de notification avec le mot-clé incluent des vc-member informations spécifiques aux membres de Virtual Chassis.

Tableau 2 : Notifications des CSP pour les étapes de provisionnement Virtual Chassis

Notification Type

Notification Message

vc-member-image-installed

  • Successfully installed downloaded image. Initiating image installation on next member.

  • Successfully installed downloaded image. Initiating member reboot.

vc-member-image-installation-failed

  • Image failed to install on the member. Giving up and trying a different phone-home-server.

vc-member-reboot-initiated

  • Reboot initiated for Line Card members. Waiting for the members to come back up.

vc-member-upgrade-success

  • No upgrade required.

  • Successfully upgraded.

  • Member detected and successfully upgraded.

vc-member-upgrade-failed

  • Upgrade failed !!!

  • Member detected but upgrade failed !!!

vc-member-detection-failed

  • Did not come up post image upgrade

    Remarque :

    Ce message signifie que le PHC a installé la nouvelle image et lancé un redémarrage du membre du Virtual Chassis, mais le PHC n’a pas détecté que le membre est réapparu dans un délai de détection de membre prescrit.

vc-bootstrap-failed

  • VC member bootstrap failure detected with Strict provisioning set.

    Remarque :

    Ce message signifie que le PHC a mis à niveau les membres du rôle de carte de ligne attendus avec succès, mais après les avoir redémarrés, PHC n’a pas détecté que tous les membres réapparaissaient dans le délai de détection des membres prescrit.

  • VC with detection failed members and Strict provisioning set.

    Remarque :

    Ce message signifie que le PHC n’a pas réussi à détecter un ou plusieurs membres après les avoir tous mis à niveau et redémarrés, et lors de la vérification à nouveau, constate qu’un ou plusieurs d’entre eux n’ont toujours pas pu apparaître.

    Avec un mode de provisionnement strict, PHC doit démarrer avec succès tous les membres prévus pour que le processus de provisionnement signale qu’il est terminé.

Vérifier l’état du Virtual Chassis après le provisionnement du téléphone à domicile

Objet

Vérifiez l’état d’exécution du Virtual Chassis après le provisionnement PHC.

Mesures à prendre

Entrez la show virtual-chassis commande à l’aide de la CLI de Junos OS.

Par exemple :

Résoudre les problèmes de provisionnement téléphonique à domicile

Pour résoudre les problèmes de CSP pendant le processus de provisionnement :

  • Utilisez des utilitaires spécifiques à votre système de gestion réseau du côté PHS pour vérifier l’état de l’équipement, du Virtual Chassis et de la connexion, ou afficher des notifications de processus de connexion téléphonique (voir Notifications d’état de provisionnement téléphonique à domicile).

  • Assurez-vous que l’interface réseau ou de gestion de Virtual Chassis est connectée au réseau et peut se connecter à un PHS.

  • Si le PHS a spécifié l’option de mode strict, vérifiez que les ID de série des membres de Virtual Chassis côté serveur de base correspondent aux périphériques membres que vous interconnectez côté client sur le site distant.

  • Recherchez les messages d’erreur et d’état dans le fichier syslog sur le Virtual Chassis.

    Par exemple, les messages d’état syslog peuvent indiquer que le client ZTP tente de provisionner l’équipement à la place ou en plus du PHC. Au démarrage avec la configuration d’usine par défaut sur un périphérique autonome ou un membre principal de Virtual Chassis, le PHC et le processus ZTP basé sur DHCP (voir Zero-Touch Provisioning) commencent à s’exécuter automatiquement. ZTP se poursuit si des options DHCP ZTP sont configurées, ce qui peut entraîner un comportement de provisionnement inattendu, car ZTP n’est pas pris en charge pour un Virtual Chassis. Pour déclencher uniquement le provisionnement téléphonique à domicile, votre administrateur système DHCP peut s’assurer que les options spécifiques à ZTP ne sont pas définies sur le serveur DHCP pour les périphériques destinés à se trouver dans un Virtual Chassis sous la gestion de PHS.

  • Vérifiez la configuration sur le Virtual Chassis après le provisionnement à l’aide de la show configuration commande CLI.

Documentation connexe