Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Zero Touch Provisioning

Le Zero-Touch Provisioning installe ou met à niveau le logiciel automatiquement sur vos nouveaux équipements Juniper Networks avec un minimum d’intervention manuelle.

Présentation du Zero-Touch Provisioning

Le Zero-Touch Provisioning (ZTP) vous permet de provisionner automatiquement les nouveaux appareils Juniper Networks dans votre réseau, avec un minimum d’intervention manuelle. Vous pouvez utiliser des ports de gestion ou des ports réseau, en fonction de votre appareil, pour vous connecter au réseau. Lorsque vous connectez physiquement un appareil au réseau et que vous le démarrez avec une configuration d’usine par défaut, l’appareil met à niveau (ou rétrograde) la version logicielle et installe automatiquement un fichier de configuration à partir du réseau. Le fichier de configuration peut être une configuration ou un script. À l’aide de scripts, vous pouvez créer des fichiers de configuration spécifiques à un appareil et effectuer des opérations de requête HTTP vers des serveurs Web pour télécharger des fichiers de configuration ou des versions logicielles spécifiques.

Pour localiser l’image logicielle et les fichiers de configuration nécessaires sur le réseau, l’équipement utilise les informations que vous avez configurées sur un serveur DHCP (Dynamic Host Configuration Protocol). Si vous ne configurez pas le serveur DHCP pour fournir ces informations, l’appareil démarre avec le logiciel préinstallé et la configuration d’usine par défaut.

Pour certains commutateurs, vous pouvez utiliser le client de connexion téléphonique (PHC) pour provisionner le logiciel du commutateur. Au démarrage du commutateur, si des options DHCP ont été reçues du serveur DHCP pour ZTP, le ZTP reprend. Si les options DHCP ne sont pas présentes, PHC est tenté. Pour plus d’informations sur PHC, consultez Provisionner un Virtual Chassis à l’aide du client Phone-Home.

Remarque :

Pour voir quelles plates-formes prennent en charge le ZTP, accédez à l’explorateur de fonctionnalités dans un navigateur. Dans la section Explorer les entités de la page Explorateur d’entités, sélectionnez Toutes les entités. Dans la zone Fonctionnalités regroupées par famille de fonctionnalités , sélectionnez Provisionnement sans intervention. Vous pouvez également saisir le nom de l’entité dans la zone d’édition Rechercher des entités . Consultez le tableau Historique des versions à la fin de cette rubrique pour plus de détails sur l’évolution de la prise en charge de ZTP.

ZTP Workflow

Lorsqu’un appareil démarre avec la configuration par défaut, les événements suivants se produisent :

  1. Le client DHCP s’exécute sur les interfaces prises en charge.

  2. Le serveur DHCP provisionne une adresse IP et inclut plusieurs options DHCP dans la réponse relative au processus ZTP.

  3. L’équipement traite les options DHCP et localise les fichiers de configuration, exécute des scripts et met à niveau et/ou rétrograde le logiciel.

  4. Si l’image et les fichiers de configuration sont présents, l’image est installée et la configuration est appliquée.

  5. Si seul le fichier image est présent, l’image est installée sur l’appareil.

  6. Si l’image est identique à l’image déjà installée sur l’appareil, ZTP continue et ignore l’étape d’installation.

  7. Si l’image n’a pas pu être récupérée par l’appareil, ZTP essaiera à nouveau de récupérer l’image.

  8. Si l’image est corrompue, l’installation échoue.

    Si l’installation échoue pour une raison quelconque, ZTP redémarrera.

  9. Si seul le fichier de configuration est présent, la configuration est téléchargée.

    Si la première ligne du fichier se compose du # ! suivis d’un chemin d’interpréteur, alors le fichier est considéré comme un script et le script est exécuté par l’interpréteur. Si le script renvoie une erreur, la machine d’état ZTP récupère le script et tente de l’exécuter à nouveau.

    Si le fichier de configuration ne peut pas être téléchargé, le processus ZTP essaiera de le télécharger à nouveau.

    Si le fichier de configuration est endommagé, contient des erreurs de syntaxe ou inclut des commandes qui ne sont pas prises en charge par l’appareil, l’appareil ne pourra pas valider et le mécanisme de nouvelle tentative redémarrera.

  10. S’il n’y a pas d’image ou de fichier de configuration, le processus ZTP recommence.

  11. S’il n’y a pas d’informations sur le serveur de fichiers, le processus ZTP recommence.

  12. Une fois la configuration validée, le processus ZTP est considéré comme réussi et se termine.

Provisionner un appareil à l’aide d’un script

Pendant le processus ZTP, lorsque vous connectez et démarrez un nouvel équipement réseau, l’équipement demande une adresse IP au serveur DHCP. Le serveur fournit l’adresse IP et, s’il est configuré, les noms de fichiers et les emplacements de l’image logicielle et du fichier de configuration de l’appareil. Le fichier de configuration peut être une configuration ou un script.

Si un fichier de configuration est fourni, le système d’exploitation détermine s’il s’agit d’un script en fonction de la première ligne du fichier. Si la première ligne contient les caractères #! suivis d’un chemin d’interpréteur, le système d’exploitation traite le fichier comme un script et l’exécute avec l’interpréteur spécifié.

Si le script renvoie une erreur (c’est-à-dire une valeur différente de zéro), la machine d’état ZTP récupère le script et tente de l’exécuter à nouveau. Cela continue jusqu’à ce que le script s’exécute correctement.

Le Tableau 1 présente les types de script pris en charge, le chemin d’interprétation correspondant et les plates-formes qui prennent en charge ce type de script pendant le processus ZTP.

Tableau 1 : scripts pris en charge pendant le ZTP

Script Type

Chemin de l’interprète

Assistance pour la plate-forme

Script shell

#!/bin/sh

Tous les appareils

Script SLAX

#!/usr/libexec/ui/cscript

Tous les appareils

Script Python

#!/usr/bin/python

Équipements exécutant Junos OS avec une automatisation améliorée

Équipements exécutant Junos OS Evolved
Remarque :

Pour des raisons de sécurité, Junos OS impose des exigences strictes pour l’exécution de scripts Python non signés sur les équipements exécutant Junos OS. Seuls les équipements exécutant Junos OS avec une automatisation améliorée et les équipements exécutant Junos OS Evolved prennent en charge l’utilisation de scripts Python non signés dans DHCP, option 43, sous-option 01.

Si le système d’exploitation ne trouve pas les caractères #! suivis d’un chemin d’interprétation, il traite le fichier comme une configuration au format texte et charge la configuration sur le périphérique.

Zero-Touch Provisioning Déclencheurs du processus de redémarrage

Le ZTP redémarre lorsque l’un des événements suivants se produit :

  • La demande de fichier de configuration, de fichier script ou de fichier image échoue.

  • Le fichier de configuration est incorrect et la validation échoue.

  • Aucun fichier de configuration et aucun fichier image n’est disponible.

  • Le fichier image est corrompu et l’installation échoue.

  • Aucune information sur le serveur de fichiers n’est disponible.

  • Aucun paramètre ZTP valide n’est configuré sur le serveur DHCP.

  • Lorsqu’aucune des interfaces client DHCP n’atteint l’état lié.

  • La transaction ZTP échoue après six tentatives de récupération du fichier de configuration ou du fichier image.

Lorsque l’un de ces événements se produit, ZTP réinitialise la machine d’état du client DHCP sur toutes les interfaces configurées par le client DHCP (gestion et réseau), puis redémarre la machine d’état. Le redémarrage de la machine d’état permet au client DHCP d’obtenir les derniers paramètres configurés par le serveur DHCP.

Avant le redémarrage de ZTP, environ 15 à 30 secondes doivent s’écouler pour laisser suffisamment de temps pour établir la liste des interfaces client DHCP liées et non liées.

La liste des interfaces client DHCP liées et non liées peut contenir :

  • Pas d’entrées.

  • Plusieurs interfaces client DHCP.

    La priorité est donnée aux interfaces client DHCP qui ont reçu tous les paramètres ZTP (fichier image logiciel, fichier de configuration et informations sur le serveur de fichiers) du serveur DHCP.

Une fois que les listes d’interfaces client liées et non liées sont créées et qu’un client DHCP est sélectionné pour l’activité ZTP, toute route par défaut existante est supprimée et l’interface client DHCP sélectionnée ajoute une nouvelle route par défaut. Pour ajouter une nouvelle route par défaut, une seule instance ZTP peut être active.

Après le redémarrage de ZTP, le client DHCP tente de récupérer les fichiers du serveur DHCP jusqu’à six fois, avec dix à quinze secondes s’écoulant entre les tentatives. Chaque tentative, qu’elle réussisse ou non, est enregistrée et peut être consultée sur la console.

En cas d’échec ou si le nombre de tentatives dépasse la limite, le ZTP s’arrête. ZTP efface ensuite les liaisons du client DHCP et redémarre la machine d’état sur les interfaces configurées par DHCP.

Le processus de redémarrage du ZTP se poursuit jusqu’à ce qu’une mise à niveau logicielle réussisse ou qu’un opérateur valide manuellement une configuration utilisateur et la supprime.

Mises en garde relatives au ZTP

Il existe deux limitations de mise à niveau vers une version antérieure pour les commutateurs EX Series :

  • Si vous passez à une version antérieure à la version 12.2 de Junos OS, dans laquelle ZTP n’est pas pris en charge, la phase d’installation automatique du fichier de configuration du processus de Zero-Touch Provisioning n’a pas lieu.

  • Pour revenir à une version logicielle qui ne prend pas en charge les partitions doubles résilientes (Junos OS version 10.4R2 ou antérieure), vous devez effectuer un travail manuel sur l’équipement. Pour plus d’informations, consultez Configuration de partitions à double racine.

Voici les mises en garde concernant les commutateurs QFX Series :

  • Sur les commutateurs QFX3500 et QFX3600 exécutant la CLI d’origine, vous ne pouvez pas utiliser ZTP pour effectuer une mise à niveau de Junos OS version 12.2 ou ultérieure vers Junos OS version 13.2X51-D15 ou ultérieure.

  • Les commutateurs QFX5200 fonctionnent uniquement avec HTTP dans 15.1X53-D30. Les protocoles FTP et TFTP ne sont pas pris en charge.

  • Si vous effectuez un provisionnement sans intervention (ZTP) avec une image Junos OS contenant une automatisation améliorée pour le commutateur QFX5100, configurez l’authentification racine et le nom du fournisseur, le type de licence et la portée du déploiement pour Chef et Puppet dans la [edit system] hiérarchie du fichier de configuration récupéré sur le serveur :

  • Dans Junos OS version 18.1R1, si vous mettez à niveau le logiciel, vous devez effectuer une mise à niveau logicielle complète. Une mise à niveau complète comprend la mise à niveau du logiciel Junos OS et des packages logiciels hôtes.

Zero-Touch Provisioning via les interfaces WAN des routeurs PTX1000

Le Zero-Touch Provisioning (ZTP) vous permet de provisionner automatiquement votre routeur dans votre réseau, avec un minimum d’intervention manuelle. À partir de la version 19.3R1 de Junos OS, vous pouvez utiliser des interfaces WAN ou des interfaces de gestion pour télécharger et installer automatiquement le logiciel approprié et le fichier de configuration sur votre routeur pendant le processus d’amorçage ZTP.

Lorsque vous connectez le routeur au réseau pour la première fois, vous pouvez choisir n’importe quel port WAN disponible sur le routeur pour connecter les modules optiques. Le ZTP configure automatiquement les interfaces WAN en fonction du type d’optique, puis connecte votre appareil au serveur DHCP (Dynamic Host Configuration Protocol) pour effectuer le processus d’amorçage.

Les interfaces WAN créées en fonction du type d’optique que vous avez connecté à l’appareil et la vitesse de l’interface WAN passent automatiquement d’une vitesse de port à l’autre jusqu’à ce que le ZTP soit terminé avec succès. La transition automatique de la vitesse garantit l’établissement d’un lien physique entre le port WAN et les modules optiques connectés et la connectivité de l’appareil final pair au serveur DHCP.

Le Guide matériel du routeur de transport de paquets PTX1000 indique les combinaisons disponibles pour les ports des routeurs PTX1000.

Zero-Touch Provisioning via DHCP

Le Zero-Touch Provisioning (ZTP) permet de provisionner automatiquement les périphériques Juniper Network que vous ajoutez à votre réseau. Vous pouvez provisionner n’importe quel périphérique pris en charge à l’aide d’un script à exécuter ou d’un fichier de configuration à charger. Vous devrez également configurer un serveur DHCP avec les informations requises, fournies dans cette procédure, pour utiliser ZTP.

Vous pouvez également configurer un serveur proxy HTTP pour le serveur phone-home ou le serveur de redirection. Lorsque le client phone-home reçoit des informations concernant le serveur proxy HTTP via l’option DHCP 43 sous-option 8, il crée un tunnel transparent HTTPS avec le serveur proxy. Une fois le tunnel établi, le client de réception utilise le tunnel comme proxy pour le serveur de réception ou le serveur de redirection. Le client télécharge l’image logicielle et le fichier de configuration via le tunnel sur l’appareil. Une fois l’amorçage terminé, l’appareil redémarre et le tunnel se ferme.

Le ZTP nécessite que votre appareil soit dans un état d’usine par défaut. L’appareil de l’usine démarre avec le logiciel préinstallé et la configuration par défaut. Sur un appareil qui n’a pas actuellement la configuration d’usine par défaut, vous pouvez émettre la request system zeroize commande.

Remarque :

La request system zeroize commande n’est pas prise en charge sur les appareils PTX1000, PTX10001-20C, QFX10002-60C, PTX10002-60C. Vous devez exécuter la commande (au lieu de request system zeroize) pour la configuration d’usine request vmhost zeroize par défaut sur les routeurs PTX1000.
Remarque :

Sur les appareils PTX10001-20C, après avoir lancé la request vmhost zeroize commande, le message suivant s’affiche deux fois : VMHost Zeroization : Erase all data, including configuration and log files ? [yes,no] (no) yes warning: Vmhost will reboot and may not boot without configuration Erase all data, including configuration and log files? [yes,no] (no) yes

Avant de commencer :

  • Assurez-vous que l’appareil a accès aux ressources réseau suivantes :

    • Serveur DHCP qui fournit l’emplacement de l’image logicielle et des fichiers de configuration sur le réseau

      Reportez-vous à la documentation de votre serveur DHCP pour obtenir des instructions de configuration.

    • Le serveur File Transfer Protocol (anonymous FTP), Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS) ou Trivial File Transfer Protocol (TFTP) sur lequel l’image logicielle et les fichiers de configuration sont stockés

      Remarque :

      Bien que TFTP soit pris en charge, nous vous recommandons d’utiliser FTP ou HTTP à la place, car ces protocoles de transport sont plus fiables.
      MISE EN GARDE :

      Les URL HTTP sont limitées à 256 caractères.

    • Un serveur DNS (Domain Name System) pour effectuer une recherche DNS inversée (non pris en charge).

    • (Facultatif) Un serveur NTP pour synchroniser l’heure sur le réseau

    • (Facultatif) Serveur de journal système (syslog) pour gérer les messages et les alertes du journal système.

      Les messages syslog seront transférés à ce serveur syslog pendant le ZTP.

  • (Facultatif) Un serveur proxy HTTP pour le serveur d’accueil ou le serveur de redirection.

  • Localisez et enregistrez l’adresse MAC de votre appareil.

    Sur les appareils PTX10008, les adresses MAC de gestion sont situées sur les moteurs de routage.

MISE EN GARDE :

Vous ne pouvez pas valider une configuration pendant que l’appareil effectue le processus de mise à jour logicielle. Si vous validez une configuration pendant que l’appareil effectue le processus d’installation automatique du fichier de configuration, le processus s’arrête et le fichier de configuration n’est pas téléchargé à partir du réseau.

Pour activer le Zero-Touch Provisioning d’un appareil à l’aide des options DHCP :

  1. Démarrez l’appareil.
  2. Assurez-vous que la configuration d’usine par défaut est installée sur l’appareil.

    Exécutez la request system zeroize commande sur l’appareil que vous souhaitez provisionner.

    Remarque :

    Cette request system zeroize commande n’est pas prise en charge sur les appareils PTX1000. Vous devez exécuter la commande (au lieu de request system zeroize) pour la configuration d’usine request vmhost zeroize sur les équipements PTX1000.

    Nous vous recommandons de provisionner le serveur DHCP et d’enregistrer le logiciel et le fichier de configuration dans le chemin d’accès spécifié au serveur DHCP sur le serveur de fichiers.

  3. Téléchargez le fichier image du logiciel et/ou le fichier de configuration sur le serveur FTP, HTTP ou TFTP à partir duquel l’appareil téléchargera ces fichiers.
    Remarque :

    Si vous effectuez un provisionnement sans contact avec une image Junos OS qui contient une automatisation améliorée pour l’équipement QFX5100, configurez l’authentification racine et le nom du fournisseur, le type de licence et la portée du déploiement pour Chef et Puppet dans la [edit system] hiérarchie du fichier de configuration récupéré à partir du serveur :
  4. Configurez le serveur DHCP pour fournir les informations nécessaires à l’appareil.

    Configurez l’attribution des adresses IP.

    Vous pouvez configurer l’attribution dynamique ou statique d’adresses IP pour l’adresse de gestion de l’appareil.

    Pour déterminer l’adresse MAC de gestion pour le mappage d’adresses IP statiques, ajoutez 1 au dernier octet de l’adresse MAC du périphérique, comme vous l’avez noté avant de commencer cette procédure.

    Remarque :

    Cette adresse peut être n’importe quelle adresse du pool.
  5. Définissez le format des informations spécifiques au fournisseur pour l’option DHCP 43 dans le fichier dhcpd.conf.

    Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

    Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    Remarque :

    À partir de la version 18.2R1 de Junos OS, une nouvelle option DHCP est introduite pour définir la valeur du délai d’attente pour les téléchargements de fichiers via FTP. Si le transfer-mode est défini sur FTP, la valeur par défaut du délai d’expiration est automatiquement définie sur 120 minutes, c’est-à-dire que si la session FTP est interrompue en raison d’une perte de connectivité au milieu d’un transfert de fichiers, elle expirera après 120 minutes et ZTP tentera de réessayer le processus de récupération de fichiers. Cette valeur peut être remplacée à l’aide de l’option DHCP suivante :

    Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

    Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    Définition :

    Affectation :

    où “val” est la valeur de délai d’expiration configurable par l’utilisateur en secondes et doit être fournie entre guillemets (par exemple, « val »).
  6. Configurez les sous-options DHCP 43 suivantes :

    • Sous-option 00 : Le nom du fichier image du logiciel à installer.

      Remarque :

      Lorsque le serveur DHCP ne peut pas utiliser la sous-option 00, configurez le nom du fichier image du logiciel à l’aide de la sous-option 04. Si la sous-option 00 et la sous-option 04 sont définies, la sous-option 04 est ignorée.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    • Sous-option 01 : Nom du script ou du fichier de configuration à installer.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :
      Remarque :

      ZTP détermine si le fichier est un fichier script en fonction de la première ligne du fichier. Si la première ligne contient les caractères #! suivis d’un chemin d’interpréteur, ZTP traite le fichier comme un script et l’exécute avec le chemin d’interprétation spécifié. Pour qu’un script s’exécute, le fichier script doit permettre de récupérer et de charger un fichier de configuration valide sur l’appareil pendant le processus ZTP.

      La liste suivante indique les types de scripts et les chemins d’interprétation qui leur sont associés :

      • Chemin de l’interpréteur de script shell : #!/bin/sh

      • Chemin de l’interpréteur de script SLAX : #!/usr/libexec/ui/cscript

      • Chemin de l’interpréteur de script Python : #!/usr/bin/python

        Pour des raisons de sécurité, Junos OS impose des exigences strictes pour l’exécution de scripts Python non signés sur les équipements exécutant Junos OS. Seuls les équipements exécutant Junos OS avec une automatisation améliorée et les équipements exécutant Junos OS Evolved prennent en charge l’exécution de scripts Python non signés dans le cadre du processus ZTP.

      Si le fichier ne contient pas de caractères spéciaux (#!) , ZTP détermine qu’il s’agit d’un fichier de configuration et charge le fichier de configuration.
      Remarque :

      À partir de la version 21.1R1 de Junos OS, les scripts Python ZTP récupérés à partir du serveur ZTP doivent être migrés vers Python 3, car Python 2.7 n’est plus pris en charge. En d’autres termes, la ligne de directive de l’interpréteur doit pointer vers Python 3 et le code du script doit également être migré vers Python 3.

    • Sous-option 02 : Le lien symbolique vers le fichier image du logiciel à installer.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

      Remarque :

      Si vous ne spécifiez pas la sous-option 2, le processus ZTP gère le nom de fichier image comme un nom de fichier et non comme un lien symbolique.

    • Sous-option 03 : Mode de transfert utilisé par l’appareil pour accéder au serveur TFTP, FTP, HTTP ou HTTPS. Si vous sélectionnez FTP comme mode de transfert, Junos OS utilise la connexion FTP anonyme pour télécharger des fichiers à partir du serveur FTP.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    • Sous-option 04 : Le nom du fichier image du logiciel à installer.

      Remarque :

      Si le serveur DHCP ne prend pas en charge la sous-option 00, configurez le fichier image à l’aide de la sous-option 04. Si la sous-option 00 et la sous-option 4 sont définies, la sous-option 04 est ignorée.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    • Sous-option 05 : Port HTTP que l’appareil utilise pour télécharger l’image ou le fichier de configuration, ou les deux, au lieu du port HTTP par défaut.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    • Sous-option 08 : Informations sur le serveur proxy HTTP transmises du serveur DHCP au client DHCP. Ceci est utile lorsque l’appareil doit accéder au serveur d’accueil téléphonique ou au serveur de redirection via un serveur proxy.

      Remarque :

      Lorsque vous configurez le serveur DHCP et le serveur proxy HTTP, assurez-vous d’utiliser le bon numéro de port pour permettre au trafic de circuler dans le tunnel sécurisé. Assurez-vous également que le nom d’hôte ou l’adresse IP du serveur proxy HTTP et le numéro de port sont séparés par un signe deux-points : par exemple, 192.168.10.10:8080. Si vous n’utilisez pas de deux-points, le port 1080 est utilisé.

      Lorsque le client DHCP reçoit les informations du serveur proxy HTTP, celles-ci sont enregistrées dans le fichier /var/etc/phc_vendor_specific_info.xml (INET).

      Si le client DHCP ne reçoit pas les informations du serveur proxy HTTP, rien n’est enregistré dans le fichier /var/etc/phc_vendor_specific_info.xml (INET) et le client DHCP passe à l’état lié.

      Vous pouvez renouveler les informations du serveur proxy HTTP en exécutant la request dhcp client renew interface commande. Le client DHCP récupère les informations valides du serveur proxy HTTP à partir du serveur DHCP. L’utilisation de la commande est plus simple que de devoir redémarrer le processus de provisionnement Lorsque le serveur proxy HTTP est renouvelé ou que les informations du serveur proxy HTTP sont modifiées ou supprimées, jdhcp réécrit le fichier /var/etc/phc_vendor_specific_info.xml avec les dernières informations reçues de la sous-option 8.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

      Voici le format de cette option :

      Fichier dhcpd.conf du serveur ISC DHCP 4.2 :

      Serveur Kea DHCP 2.4.1 Fichier kea-dhcp4.conf :

      Voici un exemple de format utilisant un nom de proxy fictif :

      Fichier dhcpd.conf du serveur ISC DHCP 4.2 :

      Serveur Kea DHCP 2.4.1 Fichier kea-dhcp4.conf :

  7. (Obligatoire) Configurez l’option 150 ou l’option 66.
    Remarque :

    Vous devez configurer l’option 150 ou l’option 66. Si vous configurez à la fois l’option 150 et l’option 66, l’option 150 est prioritaire et l’option 66 est ignorée. Assurez-vous également de spécifier une adresse IP, et non un nom d’hôte, car la résolution de nom n’est pas prise en charge.

    • Configurez l’option DHCP 150 pour spécifier l’adresse IP du serveur FTP, HTTP, HTTPS ou TFTP.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

      Définition :

      Affectation :

    • Configurez l’option DHCP 66 pour spécifier l’adresse IP du serveur FTP, HTTP, HTTPS ou TFTP.

      Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

      Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

      Définition :

      Affectation :

  8. (Facultatif) Configurez l’option DHCP 7 pour spécifier un ou plusieurs serveurs de journaux système (syslog).

    Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

    Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    Définition :

    Affectation :

  9. (Facultatif) Configurez l’option DHCP 42 pour spécifier un ou plusieurs serveurs NTP.

    Répertorie chaque serveur NTP séparé par un espace.

    Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

    Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    Définition :

    Affectation :

  10. (Facultatif) Configurez l’option DHCP 12 pour spécifier le nom d’hôte du périphérique.

    Par exemple :

    La configuration suivante montre un exemple des options DHCP que vous venez de configurer dans cette procédure :

    Voici un exemple de fichier dhcpd.conf de serveur ISC DHCP 4.2 :

    Voici un exemple de fichier kea-dhcp4.conf du serveur Kea DHCP 2.4.1 :

    En fonction des options DHCP configurées dans cet exemple, les éléments suivants sont ajoutés à la [edit system] hiérarchie :

    Les équipements Juniper exécutant Junos OS envoient des options DHCP supplémentaires au serveur DHCP dans le paquet Discover during Zero-Touch Provisioning (ZTP). Les options suivantes permettent au serveur DHCP d’identifier des périphériques spécifiques en fonction de paramètres tels que le fournisseur, le nom du modèle et le numéro de série, qui peuvent varier selon les plates-formes Juniper.

    Numéro d’option DHCP

    Nom de l’option DHCP

    Option 12

    Nom d’hôte

    Option 60

    Vendor Class Identifier (VCI)

    Modèle

    Option DHCP 12 (nom d’hôte)

    DHCP Option 60 (VCI)

    EX4400-24MP

    <serial-number>

    Juniper-ex4400-24mp-<serial-number>

    MX10-T

    <serial-number>

    Juniper-mx10-t-<serial-number>

    SRX320

    Option non envoyée

    Juniper-srx320

    Voici un exemple illustrant la classification d’un appareil en fonction de son numéro de série spécifique et l’attribution d’un ensemble unique d’options DHCP au traitement ZTP.

    Fichier dhcpd.conf du serveur ISC DHCP 4.2 :

    Serveur Kea DHCP 2.4.1 Fichier kea-dhcp4.conf :

    Remarque :

    Dans les exemples ci-dessus, la substring fonction extrait 12 caractères à partir de la position 14e caractère (indexation à partir de zéro). Vous trouverez ci-dessous quelques alternatives de chaîne de test supplémentaires utiles pour la configuration DHCP de Kea.

    • "test": "split(option[60].hex, '-', 4) == 'ZG4723350182'"
    • "test": "option[12].hex == 'ZG4723350182'"
    • "test": "split(option[60].hex, '-', 2) == 'ex4400'"
    • "test": "substring(option[60].hex,0,7) == 'Juniper'"
    • "test": "substring(option[60].hex,0,14) == 'Juniper-ex4400'"
  11. Connectez l’équipement au réseau qui comprend le serveur DHCP et le serveur FTP, HTTP, HTTPS ou TFTP.
  12. Mettez l’appareil sous tension.
  13. Surveillez le processus ZTP en regardant la console.

Zero-Touch Provisioning via DHCPv6

Remarque :

Le Zero-Touch Provisioning (ZTP) utilisant les options DHCPv6 n’est pas pris en charge sur les images Junos OS Flex. Une image Flex a le mot « flex » dans le nom de fichier. Voici un exemple de nom de fichier d’une image Flex : jinstall-host-qfx-5e-flex-x86-64-20.4R3.8-secure-signed.tgz.

Le protocole DHCPv6 n’a pas d’option de sous-réseau permettant au IA_NA (association d’identité pour les adresses non temporaires) d’apprendre et d’installer les routes de sous-réseau. Au lieu de cela, la route de sous-réseau est installée via le protocole Neighbor Discovery Protocol.

Dans IPv6, les appareils annoncent régulièrement les préfixes IPv6 ainsi que d’autres paramètres de liaison à l’aide de messages RA (Router Advertisement). Sur le client (appareil Juniper exécutant ZTP), une fois que le client DHCPv6 est lié, le protocole NDP (Neighbor Discovery Protocol) apprend ces préfixes et installe les routes de préfixe via l’interface client, le saut suivant étant le lien vers l’adresse locale du périphérique passerelle.

Sur l’appareil client, la configuration de la publication du routeur est activée par défaut avec la configuration DHCPv6.

  • Assurez-vous que l’appareil a accès aux ressources réseau suivantes :

    • Serveur DHCP qui fournit l’emplacement de l’image logicielle et des fichiers de configuration sur le réseau

      Reportez-vous à la documentation de votre serveur DHCP pour obtenir des instructions de configuration.

    • Sur le MX Series, le serveur File Transfer Protocol (FTP anonyme), Trivial File Transfer Protocol (TFTP), Hypertext Transfer Protocol (HTTP) ou Hypertext Transfer Protocol Secure (HTTPS) sur lequel l’image logicielle et les fichiers de configuration sont stockés.

      MISE EN GARDE :

      Les URL HTTP sont limitées à 256 caractères.

    • Sur les appareils EX3400, EX4300, QFX5100 et QFX5200, le serveur HTTP (Hypertext Transfer Protocol) ou HTTPS (Hypertext Transfer Protocol Secure) sur lequel l’image logicielle et les fichiers de configuration sont stockés.

      MISE EN GARDE :

      Les URL HTTP sont limitées à 256 caractères.

    • (Facultatif) Un serveur proxy HTTP pour le serveur d’accueil ou le serveur de redirection.

  • Localisez et enregistrez l’adresse MAC imprimée sur l’appareil.

Le Zero-Touch Provisioning (ZTP) permet de provisionner automatiquement les périphériques Juniper Network que vous ajoutez à votre réseau. Vous pouvez provisionner n’importe quel périphérique pris en charge à l’aide d’un script à exécuter ou d’un fichier de configuration à charger.

Pour utiliser le ZTP, vous configurez un serveur DHCP afin qu’il fournisse les informations requises. Si vous ne configurez pas le serveur DHCP pour fournir ces informations, l’appareil démarre avec le logiciel préinstallé et la configuration d’usine par défaut. Si votre appareil n’est pas dans un état d’usine par défaut, vous pouvez lancer la request system zeroize commande.

Vous pouvez également configurer un serveur proxy HTTP pour le serveur phone-home ou le serveur de redirection. Lorsque le client phone-home reçoit des informations concernant le serveur proxy HTTP via l’option DHCP 17 sous-option 8, il crée un tunnel transparent HTTPS avec le serveur proxy. Une fois le tunnel établi, le client de réception utilise le tunnel comme proxy pour le serveur de réception ou le serveur de redirection. Le client télécharge l’image logicielle et le fichier de configuration via le tunnel sur l’appareil. Une fois l’amorçage terminé, l’appareil redémarre et le tunnel se ferme.

Remarque :

À partir de la version 20.2R1-S1 de Junos OS, le client DHCPv6 est pris en charge sur les commutateurs MX-Series, EX3400, EX4300, QFX5100 et QFX5200. Les clients DHCPv4 et DHCPv6 sont inclus dans la configuration par défaut. Au cours du processus d’amorçage, l’appareil utilise d’abord le client DHCPv4 pour demander des informations concernant l’image et le fichier de configuration au serveur DHCP. L’appareil vérifie les liaisons DHCPv4 de manière séquentielle. En cas d’échec avec l’une des liaisons DHCPv4, l’appareil continuera à vérifier les liaisons jusqu’à ce que le provisionnement réussisse. Toutefois, s’il n’y a pas de liaisons DHCPv4, l’appareil recherche les liaisons DHCPv6 et suit le même processus que pour DHCPv4 jusqu’à ce que l’appareil puisse être correctement provisionné. Le serveur DHCP utilise les options DHCPv6 59 et 17 et les sous-options applicables pour échanger des informations relatives à ZTP entre lui-même et le client DHCP.
MISE EN GARDE :

Vous ne pouvez pas valider une configuration pendant que l’appareil effectue le processus de mise à jour logicielle. Si vous validez une configuration pendant que l’appareil effectue le processus d’installation automatique du fichier de configuration, le processus s’arrête et le fichier de configuration n’est pas téléchargé à partir du réseau.

Pour utiliser le Zero-Touch Provisioning d’un appareil à l’aide des options DHCPv6 :

  1. Démarrez l’appareil.
  2. Assurez-vous que la configuration d’usine par défaut est installée sur l’appareil.

    • Si plusieurs réponses DHCP arrivent, le ZTP choisit le meilleur ensemble d’arguments.

    • Si plusieurs interfaces fournissent les mêmes arguments, ZTP choisit l’une des interfaces égales.

    • En cas d’erreur lors de la connexion au serveur DHCP, ZTP tente à nouveau de se connecter au serveur DHCP. Si plusieurs interfaces fournissent à nouveau les mêmes arguments, ZTP choisit l’une des interfaces.

    Nous vous recommandons de provisionner le serveur DHCP et d’enregistrer le logiciel et le fichier de configuration dans le chemin d’accès spécifié au serveur DHCP sur le serveur de fichiers.

  3. Téléchargez le fichier image du logiciel et le fichier de configuration sur le serveur FTP, HTTP, HTTPS ou TFTP à partir duquel l’appareil téléchargera ces fichiers.
  4. Configurez le serveur DHCP pour fournir les informations nécessaires à l’appareil.
  5. Configurez l’attribution des adresses IP.

    Vous pouvez configurer l’attribution d’adresses IP dynamiques ou statiques à l’adresse de gestion de l’appareil. Pour déterminer l’adresse MAC de gestion pour le mappage d’adresses IP statiques, ajoutez 1 au dernier octet de l’adresse MAC du périphérique, comme vous l’avez noté avant de commencer cette procédure.

  6. Définissez le format de l’option DHCPv6 59 (OPT_BOOTFILE_URL) dans le fichier dhcpd6.conf , afin que le serveur puisse envoyer des informations sur les URL aux images au client.
    Remarque :

    Lors de l’utilisation des options DHCPv6 sur des appareils EX3400, EX4300, QFX5100 et QFX5200, seuls les protocoles de transport HTTP et HTTPS sont pris en charge.

    Voici le format de cette option :

    Par exemple :

    Le mode de transfert et l’adresse IPv6 sont obligatoires, mais le numéro de port est facultatif. Si vous ne spécifiez pas le numéro de port, le numéro de port par défaut du mode de transfert est utilisé. Si vous spécifiez le numéro de port dans les options 17 et 59, le numéro de port mentionné dans l’option d’informations spécifiques au fournisseur de l’option 17 est utilisé.

    Vous pouvez spécifier le nom du fichier image dans l’option 59 ou l’option 17. Si le nom du fichier image est mentionné dans les options 59 et 17, le nom de l’image mentionné dans l’option d’informations spécifiques au fournisseur de l’option 17 est utilisé.

  7. Définissez le format des informations spécifiques au fournisseur pour les sous-options DHCP 17 suivantes :

    Voici un exemple de fichier dhcpd6.conf de serveur ISC DHCP 4.2 :

    • Sous-option 00 : Le nom du fichier image du logiciel à installer.

      Remarque :

      Lorsque le serveur DHCP ne peut pas utiliser la sous-option 00, configurez le nom du fichier image du logiciel à l’aide de la sous-option 04. Si la sous-option 00 et la sous-option 4 sont définies, la sous-option 04 est ignorée.

      Par exemple :

    • Sous-option 01 : Nom du script ou du fichier de configuration à installer.

      Par exemple :

      Remarque :

      ZTP détermine si le fichier est un fichier script en fonction de la première ligne du fichier. Si la première ligne contient les caractères #! suivis d’un chemin d’interpréteur, ZTP traite le fichier comme un script et l’exécute avec le chemin d’interprétation spécifié. Pour qu’un script s’exécute, le fichier script doit permettre de récupérer et de charger un fichier de configuration valide sur l’appareil pendant le processus ZTP.

      La liste suivante indique les types de scripts et les chemins d’interprétation qui leur sont associés :

      • Chemin de l’interpréteur de script shell : #!/bin/sh

      • Chemin de l’interpréteur de script SLAX : #!/usr/libexec/ui/cscript

      • Chemin de l’interpréteur de script Python : #!/usr/bin/python

        Pour des raisons de sécurité, Junos OS impose des exigences strictes pour l’exécution de scripts Python non signés sur les équipements exécutant Junos OS. Seuls les équipements exécutant Junos OS avec une automatisation améliorée et les équipements exécutant Junos OS Evolved prennent en charge l’exécution de scripts Python non signés dans le cadre du processus ZTP.

      Si le fichier ne contient pas de caractères spéciaux (#!) , ZTP détermine qu’il s’agit d’un fichier de configuration et charge le fichier de configuration.
      Remarque :

      À partir de la version 21.1R1 de Junos OS, les scripts Python ZTP récupérés à partir du serveur ZTP doivent être migrés vers Python 3, car Python 2.7 n’est plus pris en charge. En d’autres termes, la ligne de directive de l’interpréteur doit pointer vers Python 3 et le code du script doit également être migré vers Python 3.

    • Sous-option 02 : Le type d’image.

      Remarque :

      Si vous ne spécifiez pas la sous-option 2, le processus ZTP gère l’image logicielle comme un nom de fichier et non comme un lien symbolique.

    • Sous-option 04 : Le nom du fichier image du logiciel à installer.

      Remarque :

      Lorsque le serveur DHCP ne peut pas utiliser la sous-option 00, configurez le fichier image à l’aide de la sous-option 04. Si la sous-option 00 et la sous-option 4 sont définies, la sous-option 04 est ignorée.

      Par exemple :

    • Sous-option 05 : Le port que l’appareil utilise pour télécharger l’image ou le fichier de configuration ou les deux au lieu du port par défaut.

    • Sous-option 06 : Nom du fichier du package JLoader (pris en charge uniquement sur les appareils QFX5100)

    • Sous-option 07 : Code de délai d’expiration FTP.

    • Sous-option 08 : Informations sur le serveur proxy HTTP transmises du serveur DHCP au client DHCP. Ceci est utile lorsqu’un appareil doit accéder au serveur d’accueil téléphonique ou au serveur de redirection via un serveur proxy.

      Remarque :

      Lorsque vous configurez le serveur DHCP et le serveur proxy HTTP, assurez-vous d’utiliser le bon numéro de port pour permettre au trafic de circuler dans le tunnel sécurisé. Assurez-vous également que le nom d’hôte ou l’adresse IP du serveur proxy HTTP et le numéro de port sont séparés par deux points : par exemple, « http://[2001 ::1] :3128. Si vous n’utilisez pas de deux-points, le port 1080 est utilisé.

      Lorsque le client DHCP reçoit les informations du serveur proxy HTTP, celles-ci sont enregistrées dans le fichier /var/etc/phc_v6_vendor_specific_info.xml (INET6).

      Vous pouvez renouveler les informations du serveur proxy HTTP en exécutant la request dhcp client renew interface commande. Le client DHCP récupère les informations valides du serveur proxy HTTP à partir du serveur DHCP. L’utilisation de la commande est plus simple que de devoir redémarrer le processus de provisionnement Lorsque le serveur proxy HTTP est renouvelé ou que les informations du serveur proxy HTTP sont modifiées ou supprimées, jdhcp réécrit le fichier /var/etc/phc_v6_vendor_specific_info.xml avec les dernières informations reçues de la sous-option 8.

    • Le protocole DHCPv6 définit l’option d’information spécifique au fournisseur (VSIO) afin d’envoyer les options du fournisseur encapsulées dans une option DHCP standard.

    L’exemple de configuration suivant montre les options DHCPv6 que vous venez de configurer :

  8. Mettez l’appareil sous tension avec la configuration par défaut.
  9. Surveillez le processus ZTP en regardant la console.
    Remarque :

    Lorsque des scripts SLAX sont exécutés, les op-script.log fichiers et event-script.log sont produits.

    Vous pouvez également utiliser ces fichiers journaux pour résoudre les problèmes en cas de problème.

    • /var/log/dhcp_logfile

      Utilisez ce fichier pour consulter les journaux des clients DHCP.

    • /var/log/event-script.log

      Utilisez ce fichier pour vérifier l’état de la validation de la configuration.

    • /var/log/image_load_log

      Utilisez ce fichier pour vérifier l’état de récupération et d’installation de l’image et du fichier de configuration du logiciel.

    • /var/log/messages

      Utilisez ce fichier pour vérifier les journaux au niveau du système.

    • /var/log/op-script.log

      Utilisez ce fichier pour vérifier l’état de la validation de la configuration.

    • /var/log/script_output

      Utilisez ce fichier pour vérifier la sortie d’exécution du script.

    Vous pouvez également surveiller le processus ZTP en examinant les messages d’erreur et en émettant des commandes opérationnelles. Consultez la section Surveillance du Zero-Touch Provisioning pour plus d’informations.

Zero-Touch Provisioning sur les pare-feu SRX Series

Comprendre le Zero-Touch Provisioning sur les pare-feu SRX Series

Cette rubrique comprend les sections suivantes :

Comprendre le ZTP sur les pare-feu SRX Series

Le Zero-Touch Provisioning (ZTP) vous permet de provisionner et de configurer automatiquement les appareils, réduisant ainsi la majeure partie des interventions manuelles nécessaires pour ajouter des appareils à un réseau. La fonctionnalité ZTP est prise en charge sur les appareils SRX300, SRX320, SRX340, SRX345, SRX550M et SRX1500.

À partir de la version 20.2R1 de Junos OS sur les équipements SRX300, SRX320, SRX340, SRX345, SRX550 HM et SRX1500, vous pouvez utiliser le provisionnement sans contact avec les options DHCP pour provisionner votre équipement. Voir Provisionnement sans intervention à l’aide des options DHCP pour plus d’informations.

Remarque :

ZTP est actuellement pris en charge sur les ports xe-0/0/16 et xe-0/0/17 du SRX1500. Pour éviter d’utiliser ces ports, les configurations par défaut suivantes ont été ajoutées aux ports xe-0/0/18 et xe-0/0/19.

Sur les pare-feu SRX Series, le ZTP se charge du démarrage initial et de la configuration de l’appareil lorsque celui-ci est sous tension. Cette fonctionnalité comprend :

  • Fourniture de l’amorçage minimal de l’appareil. Le pare-feu SRX Series est livré avec une configuration d’usine par défaut. La configuration d’usine par défaut inclut l’URL du serveur de redirection, qui est utilisée pour se connecter au serveur central à l’aide d’une connexion cryptée sécurisée.

  • Se connecter automatiquement au serveur via Internet et télécharger la configuration et l’image Junos OS spécifiées par le client ou l’utilisateur à partir du serveur lorsque le pare-feu SRX Series démarre avec la configuration d’usine par défaut. La nouvelle image est d’abord installée, puis la configuration initiale est appliquée et validée sur le pare-feu SRX Series.

Le ZTP offre les avantages suivants :

  • Déploiement simplifié et plus rapide

  • Précision accrue de la configuration

  • Prise en charge de l’évolutivité du réseau sans ressources supplémentaires

Le processus ZTP utilise Network Activator pour provisionner initialement les pare-feu SRX Series.

Présentation de Network Activator

Network Service Activator permet de détecter et de provisionner rapidement les appareils pour les configurer automatiquement afin d’éliminer la configuration complexe des appareils.

Network Activator provisionne initialement les pare-feu SRX Series (ci-après dénommés équipements distants dans cette documentation), qui résident sur les sites des utilisateurs finaux. Les appareils distants téléchargent une image de démarrage et les fichiers de configuration initiale à partir des serveurs hébergeant Network Activator, à l’aide d’un processus qui fournit une autorisation et une authentification complètes pour toutes les interactions. Une fois le provisionnement initial terminé, l’équipement distant communique avec un serveur de gestion, qui commence alors à gérer et à surveiller l’équipement distant.

Network Activator utilise une architecture distribuée pour prendre en charge les appareils distants. Network Activator est installé sur un serveur d’administration central (serveur central) et plusieurs serveurs d’administration régionaux (serveurs régionaux). Un appareil communique directement avec le serveur régional qui lui est attribué. L’architecture distribuée optimise l’efficacité du processus de provisionnement initial, ce qui contribue à des performances élevées et à l’évolutivité du réseau.

Graphique 1 Illustre l’architecture distribuée et les composants impliqués dans le processus de provisionnement initial.

Figure 1 : Composants impliqués dans le provisionnement initial d’un équipement Network architecture diagram showing data flow between a regional server, central and management servers, a remote device, and a Juniper Networks website with a redirect tool. distant

Les rôles des composants dans le processus de provisionnement initial sont les suivants :

  • L’équipement distant envoie des demandes de provisionnement initial. L’équipement distant réside à l’emplacement de l’utilisateur final.

  • L’outil de redirection fournit l’authentification et l’autorisation pour les périphériques distants d’accéder aux serveurs régionaux qui leur sont attribués au moyen de certificats numériques d’infrastructure à clé privée (PKI) UIT-T X.509. Le service de redirection est hébergé sur Amazon Web Services (AWS), exploité et maintenu par Juniper Networks.

  • Le serveur central héberge Network Activator et communique avec les serveurs d’activation régionaux. Les administrateurs d’un fournisseur de services ou d’un site central de l’entreprise interagissent avec ce serveur pour installer et configurer Network Activator. Le serveur central est situé à un emplacement géographique central pour le fournisseur de services.

  • Le serveur régional héberge également Network Activator. Ce serveur stocke des informations sur les périphériques distants qui lui sont attribués et communique directement avec ces périphériques. Ce serveur réside généralement dans un emplacement administratif régional désigné par le fournisseur pour l’utilisateur final.

La figure 2 illustre le flux de travail de provisionnement initial.

Figure 2 : Workflow de provisionnement Workflow diagram of Juniper Networks Redirect Tool for remote device setup and management, showing steps from admin setup to device management. initial

Dans le détail, le workflow de provisionnement se déroule comme suit :

  1. L’administrateur chez le fournisseur de services :

    • Installe et configure Network Activator sur le serveur central.

    • Ajoute les appareils distants et les serveurs régionaux dans l’outil de redirection.

  2. Le serveur central transmet l’installation aux serveurs régionaux.

  3. L’utilisateur final met l’appareil distant sous tension, le connecte à un ordinateur et saisit le code d’authentification sur la page Web pour envoyer une demande de provisionnement initial.

  4. L’appareil transmet son certificat X.509 et son nom de domaine complet (FQDN) sous forme de demande de provisionnement à l’outil de redirection.

  5. L’outil de redirection recherche dans son magasin de données le serveur régional que l’administrateur a spécifié pour cet appareil et confirme que la demande de l’appareil correspond au certificat X.509 spécifié pour le serveur.

  6. L’outil de redirection envoie les informations de contact du serveur régional à l’appareil.

  7. L’appareil envoie une requête au serveur régional pour obtenir l’URL de l’image de démarrage et l’emplacement de la configuration initiale.

  8. Le serveur régional envoie les informations à l’appareil.

  9. L’appareil obtient l’image de démarrage et la configuration à partir du serveur régional.

  10. L’appareil utilise l’image et la configuration de démarrage pour démarrer et devenir opérationnel.

Limites

  • Il n’y a aucune restriction sur le nombre de tentatives pour entrer le bon code d’activation.

  • Si l’appareil distant n’est pas en mesure d’atteindre le serveur (parce que l’adresse configurée dans la configuration d’usine par défaut n’est pas correcte ou que le serveur est en panne, etc.), l’appareil distant tente de se connecter à un autre serveur (s’il est configuré dans la configuration d’usine par défaut). S’il n’y a qu’un seul serveur configuré, vous pouvez réessayer de vous connecter. Dans de tels scénarios, nous vous recommandons de configurer l’appareil manuellement via la console.

  • La redirection du portail captif, nécessaire pour rediriger automatiquement les utilisateurs vers la page Web d’authentification pour entrer le code d’activation, n’est pas prise en charge. Vous devez accéder manuellement à la page d’activation après vous être connecté à l’appareil.

Configuration du Zero-Touch Provisioning sur un pare-feu SRX Series

Avant de commencer :

  • Déballez l’appareil, installez-le, terminez le câblage nécessaire, connectez un ordinateur portable ou tout autre terminal, puis mettez l’appareil sous tension. Consultez le Guide d’installation matérielle de votre appareil pour plus d’informations.

  • Pour les appareils SRX300, SRX320, SRX340, SRX345 et SRX550M, connectez l’équipement de gestion et accédez à l’interface Web J.

    Pour plus d’informations, consultez les guides de démarrage rapide des appareils respectifs à SRX300, SRX320, SRX340, SRX345 et SRX550M.

    Vous avez la possibilité d’utiliser le ZTP ; vous pouvez utiliser cette option ou l’ignorer et continuer avec les assistants J-Web.

  • Pour les appareils SRX1500, avant de pouvoir utiliser J-Web pour configurer votre appareil, vous devez accéder à la CLI pour configurer l’authentification racine et l’interface de gestion. Pour plus d’informations, voir Configuration de votre passerelle de services SRX1500.

Cette section fournit des instructions étape par étape sur la façon d’utiliser ZTP sur un pare-feu SRX Series pour le provisionnement initial de l’appareil.

Pour provisionner un pare-feu SRX Series à l’aide du ZTP :

  1. Connectez un équipement de gestion (PC ou ordinateur portable) à n’importe quel port Ethernet (port WAN) du pare-feu SRX Series.
  2. Lancez un navigateur Web à partir de l’équipement de gestion et entrez le code d’authentification sur la page Web, comme illustré à la figure 3.
    Figure 3 : Saisie du code d’activation pour le ZTP User interface screen from Juniper Networks prompting for activation code entry with options Phone Home Client, Logs, and skip to JWeb.

    Une fois l’authentification réussie, l’appareil commence à télécharger l’image du logiciel et la configuration initiale à partir du serveur, comme illustré à la figure 4.

    Figure 4 : Lancement du processus ZTP (téléchargement d’images du Logiciels) Software update screen for Juniper Networks device showing 5 percent download progress. Options: Phone Home Client, Logs, skip to JWeb.

    À cette étape :

    • Le code d’activation est envoyé au serveur et, si l’authentification réussit, le serveur envoie la configuration initiale à l’appareil. Si l’authentification échoue, il vous est demandé de fournir le code correct.

    • Le serveur peut éventuellement envoyer une nouvelle image logicielle sur le pare-feu SRX Series. Dans ce cas, la nouvelle image est d’abord installée, puis la configuration initiale est appliquée et validée sur l’appareil.

    La nouvelle image est installée, puis la configuration initiale est appliquée et validée sur l’appareil. Une fois le processus terminé, un message de confirmation s’affiche, comme illustré à la figure 5.

    Figure 5 : Achèvement du processus Device activation complete message with options for Logs and skip to JWeb; Juniper Networks application. ZTP
  3. Cliquez sur Journaux pour afficher les détails du processus d’amorçage.

Après avoir installé avec succès la nouvelle image logicielle et la configuration sur le système, le client envoie la bootstrap-complete notification au serveur qui a fourni l’image et la configuration. Une fois la notification envoyée, la configuration qui inclut les noms des serveurs est supprimée du système. Lors de la prochaine utilisation de ZTP, vous devez configurer explicitement l’URL du serveur de redirection.

Remarque :

En cas d’échec à n’importe quel stade, la procédure est recommencée.
Remarque :

Le processus ZTP met à niveau ou rétrograde la version de Junos OS. Lors d’une rétrogradation sur un pare-feu SRX Series, si vous effectuez une rétrogradation vers une version logicielle antérieure à la version 15.1X49-D100 de Junos OS, dans laquelle ZTP n’est pas pris en charge, la phase d’installation automatique du processus ZTP n’a pas lieu.

Pour les appareils SRX300, SRX320, SRX340, SRX345 et SRX550M, ZTP est la méthode par défaut de provisionnement des appareils. Toutefois, si vous souhaitez utiliser le provisionnement basé sur J-Web (assistants de configuration J-Web pris en charge pour la gamme SRX300 de périphériques et de périphériques SRX550M), vous pouvez utiliser l’option fournie dans le portail client pour passer aux assistants de configuration J-Web pour effectuer la configuration logicielle initiale de votre périphérique au lieu de ZTP.

Si vous sélectionnez l’option Passer à JWeb , vous devez configurer le mot de passe d’authentification racine du système comme indiqué à la Figure 6.

Figure 6 : Configuration du mot de passe Juniper Networks JWeb interface login screen prompting system root password setup with Submit and Cancel options. d’authentification racine du système
Remarque :

Pour les périphériques SRX1500, l’option Passer à JWeb n’est pas prise en charge. Pour accéder à J-Web, la configuration du client ZTP doit être supprimée lors de la configuration initiale de SRX1500 via la CLI.

Comprendre la configuration d’usine par défaut sur le pare-feu SRX Series pour le Zero-Touch Provisioning

Votre passerelle de services est livrée avec une configuration d’usine par défaut. Voici un exemple de la configuration par défaut qui inclut la configuration pour ZTP :

Notez que, dans cette configuration :

  • server indique le nom ou l’adresse IP du serveur. La configuration d’usine par défaut d’un pare-feu SRX Series peut inclure les adresses IP de plusieurs serveurs.

  • rfc-compliant indique qu’après une mise à niveau, le serveur applique certains comportements conformes aux normes RFC.

Remarque :

Par défaut, la configuration de l’installation automatique du système fait partie de la configuration d’usine par défaut de l’appareil. L’administrateur doit donc s’assurer que le fichier de configuration envoyé du serveur régional à l’équipement distant (pare-feu SRX Series) doit inclure l’option delete system autoinstallation dans la configuration d’usine par défaut.

Surveillance du Zero-Touch Provisioning

Vous pouvez utiliser les commandes de la console et du mode opérationnel pour surveiller le Zero-Touch Provisioning.

Utilisation de la console pour surveiller le Zero-Touch Provisioning dans Junos OS

Les activités de Zero-Touch Provisioning (ZTP) suivantes s’affichent sur la console pendant le processus ZTP :

  • Heures de début et de fin du processus ZTP.

  • Listes d’interfaces client DHCP liées et non liées.

  • Options DHCP que les serveurs DHCP envoient aux clients DHCP.

  • Journaux indiquant les interfaces utilisées pour le ZTP.

  • ZTP que les clients DHCP obtiennent des serveurs DHCP.

  • Noms de fichiers des fichiers de configuration et d’image, noms des serveurs de fichiers, protocoles utilisés pour récupérer les fichiers et heures auxquelles les serveurs DHCP récupèrent les fichiers de configuration et d’image.

  • États d’échec causés par des fichiers qui ne se trouvent pas sur les serveurs, ou des serveurs inaccessibles, et des expirations.

  • Nombre de tentatives effectuées et nombre de tentatives restantes pour une nouvelle tentative dans le cycle ZTP en cours.

  • Achèvement des transferts de fichiers.

  • Installation, redémarrage et état du processus ZTP.

  • Erreurs d’état internes et arrêt du processus ZTP.

  • Journaux indiquant quand les routes par défaut ont été ajoutées ou supprimées.

Utilisation des alertes du journal système pour surveiller le Zero-Touch Provisioning

Objet

Dans cet exemple, l’alerte du journal système vous avertit que la mise à niveau automatique de l’image va démarrer.

Mesures à prendre

Utilisez l’alerte suivante du journal système pour surveiller le processus de mise à niveau automatique de l’image.

Signification

Cette alerte du journal système indique que la mise à niveau automatique de l’image va démarrer et fournit des informations sur la façon d’arrêter le processus de mise à niveau automatique de l’image.

Utilisation de messages d’erreur pour surveiller le Zero-Touch Provisioning

Objet

Les messages d’erreur fournissent des informations sur les options DHCP qui ne sont pas configurées.

Mesures à prendre

Utilisez les informations du message d’erreur suivant pour savoir quelles options DHCP ne sont pas configurées.

Signification

Le message d’erreur indique que les options du serveur de journaux DHCP, du nom d’hôte et du serveur NTP ne sont pas configurées.

Utilisation de fichiers journaux système pour surveiller le Zero-Touch Provisioning dans Junos OS à l’aide des options DHCP

Objet

Les fichiers journaux système fournissent des informations sur l’état du processus de mise à niveau automatique, la liste des interfaces client DHCP liées et non liées, les adresses IP des serveurs de fichiers, les noms et les emplacements des fichiers image et de configuration, ainsi que les tentatives réussies ou infructueuses de récupération des fichiers image et de configuration.

Mesures à prendre

Utilisez les informations contenues dans les fichiers journaux système suivants pour surveiller le processus de mise à niveau automatique.

Signification

Ces fichiers journaux système indiquent qu’il y a eu six tentatives infructueuses d’extraction du fichier de configuration à partir du serveur de fichiers, l’adresse IP du serveur de fichiers, le nom de l’interface client DHCP et le nombre de fois que le processus de nouvelle tentative s’est produit.

Utilisation des fichiers journaux système pour surveiller le Zero-Touch Provisioning dans Junos OS à l’aide des options DHCPv6

Objet

Les fichiers journaux système fournissent des informations sur l’état du processus de mise à niveau automatique, la liste des interfaces client DHCP liées et non liées, les adresses IP des serveurs de fichiers, les noms et les emplacements des fichiers image et de configuration, ainsi que les tentatives réussies ou infructueuses de récupération des fichiers image et de configuration.

Mesures à prendre

Utilisez les informations contenues dans les fichiers journaux système suivants pour surveiller le processus de mise à niveau automatique.

Signification

Ces fichiers journaux système indiquent qu’il y a eu six tentatives infructueuses d’extraction du fichier image à partir du serveur de fichiers, l’adresse IP du serveur de fichiers, le nom de l’interface client DHCPv6 et le nombre de fois où le processus de nouvelle tentative s’est produit.

Utilisation de la commande show dhcp client binding

Objet

Exécutez la commande pour afficher les show dhcp client binding informations de liaison du client DHCP

Mesures à prendre

Exécutez la show dhcp client binding commande pour afficher l’adresse IP du client DHCP, l’adresse matérielle du client DHCP, le nombre de secondes d’expiration du bail d’adresse IP du client DHCP, l’état de l’adresse IP du client DHCP dans la table de liaison et le nom de l’interface qui a des liaisons client actives.

Afficher la liaison du client DHCP

Signification

La sortie de cette commande indique qu’il existe une interface client liée et que trois interfaces reçoivent des offres DHCP du serveur DHCP.

Utilisation de la commande show dhcpv6 client binding

Objet

Exécutez la commande pour afficher les show dhcpv6 client binding informations de liaison du client DHCP

Mesures à prendre

Exécutez la show dhcp6 client binding commande pour afficher l’adresse IP du client DHCPv6, l’adresse matérielle du client DHCPv6, le nombre de secondes d’expiration du bail de l’adresse IP du client DHCPv6, l’état de l’adresse IP du client DHCPv6 dans la table de liaison et le nom de l’interface qui a des liaisons client actives.

Afficher la liaison client DHCPVv6

Signification

La sortie de cette commande indique qu’il existe une interface client liée et que trois interfaces reçoivent des offres DHCPv6 du serveur DHCP.

Utilisation de la commande show dhcp client statistics

Objet

Exécutez la commande pour afficher les show dhcp client statistics statistiques du client DHCP.

Mesures à prendre

Exécutez la commande pour afficher les show dhcp client statistics statistiques du client DHCP, telles que le nombre de paquets perdus et le nombre de messages DHCP et BOOTP envoyés et reçus.

Afficher les statistiques des clients DHCP

Signification

La sortie de cette commande affiche le nombre de paquets perdus avec des erreurs, le nombre de messages BOOTREPLY et DHCPOFFER qui ont été reçus, et le nombre de messages BOOTREQUEST et DHCPREQUEST qui ont été envoyés.

Utilisation de la commande show dhcpv6 client statistics

Objet

Exécutez la commande pour afficher les show dhcpv6 client statistics statistiques du client DHCPv6.

Mesures à prendre

Exécutez la commande pour afficher les show dhcpv6 client statistics statistiques du client DHCPv6, telles que le nombre de paquets perdus et le nombre de messages DHCPv6 envoyés et reçus.

Afficher les statistiques du client DHCPv6

Signification

La sortie de cette commande affiche le nombre de paquets perdus avec des erreurs et le nombre de messages DHCPV6 reçus et envoyés.

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ération
Descriptif
21.4R1-EVO
À partir de Junos OS version 21.4R1 d’Evolved sur les périphériques QFX5130-32CD, QFX5220 et QFX5700, ZTP prend en charge le client DHCPv6 sur l’interface de gestion. Au cours du processus d’amorçage, l’appareil utilise d’abord le client DHCPv4 pour demander des informations concernant l’image et le fichier de configuration au serveur DHCP. L’appareil vérifie les liaisons DHCPv4 de manière séquentielle. En cas d’échec avec l’une des liaisons DHCPv4, l’appareil continuera à vérifier les liaisons jusqu’à ce que le provisionnement réussisse. Toutefois, s’il n’y a pas de liaisons DHCPv4, l’appareil recherche les liaisons DHCPv6 et suit le même processus que pour DHCPv4 jusqu’à ce que l’appareil puisse être correctement provisionné. Le serveur DHCP utilise les options DHCPv6 59 et 17 et les sous-options applicables pour échanger des informations relatives à ZTP entre lui-même et le client DHCP.
21.3R1-EVO
À partir de Junos OS version 21.3R1 d’Evolved, le ZTP prend désormais en charge les options DHCP 61 et 77 sur les appareils PTX10001-36MR, PTX10003, PTX10004, PTX10008 et PTX10016. L’option DHCP 61 permet de spécifier le numéro de série du châssis et l’option DHCP 77 permet de spécifier la marque, le modèle et la version logicielle du châssis.
21.2R1-EVO
À partir de Junos OS Evolved version 21.2R1 sur les équipements PTX10008, le Zero-Touch Provisioning (ZTP) détecte dynamiquement la vitesse des ports des interfaces WAN et utilise ces informations pour créer des ports de serveur ZTP à la même vitesse.
21.2R1-EVO
À partir de Junos OS version 21.2R1 d’Evolved, les appareils QFX5700 prennent en charge la possibilité pour les interfaces WAN ou de gestion de télécharger et d’installer automatiquement le logiciel approprié et le fichier de configuration sur votre appareil pendant le processus d’amorçage ZTP.
21.2R1
À partir de la version 21.2R1 de Junos OS sur les équipements QFX10002, le Zero-Touch Provisioning (ZTP) détecte dynamiquement la vitesse des ports des interfaces WAN et utilise ces informations pour créer des ports de serveur ZTP à la même vitesse.
21.2R1
À partir de la version 21.2R1 de Junos OS, sur les appareils EX2300-C, EX2300-MP, EX4300, EX4300-MP, EX4300-MP, EX4300-VC, EX4400-24MP, EX4400-48MP, EX4600-VC, EX4650 et EX4650-48Y-VC, pendant le processus d’amorçage, le client d’accueil peut accéder au serveur de redirection via un serveur proxy. Le serveur DHCP utilise l’option DHCP 43, sous-option 8, pour fournir les détails des serveurs proxy IPv4 et/ou IPv6 au client de base. Le démon DHCP exécuté sur le commutateur cible apprend les serveurs proxy lors du cycle DHCP initial, puis remplit les fichiers phc_vendor_specific_info.xml ou phc_v6_vendor-specific_info.xml situés dans le répertoire /var/etc/ avec les informations spécifiques au fournisseur.
21.2R1
À partir de Junos OS version 21.2R1, sur les équipements EX2300-C, EX2300-MP, EX4300, EX4300-MP, EX4300-MP, EX4300-VC, EX4400-24MP, EX4400-48MP, EX4600-VC, EX4650 et EX4650-48Y-VC, vous pouvez utiliser un client DHCPv6 et ZTP pour provisionner un commutateur. Au cours du processus d’amorçage, l’appareil utilise d’abord le client DHCPv4 pour demander des informations concernant l’image et le fichier de configuration au serveur DHCP. L’appareil vérifie les liaisons DHCPv4 de manière séquentielle. En cas d’échec avec l’une des liaisons DHCPv4, l’appareil continue à vérifier les liaisons jusqu’à ce que le provisionnement réussisse. Toutefois, s’il n’y a pas de liaisons DHCPv4, l’appareil recherche les liaisons DHCPv6 et suit le même processus que pour DHCPv4 jusqu’à ce que l’appareil soit correctement provisionné. Les clients DHCPv4 et DHCPv6 sont inclus dans la configuration par défaut de l’appareil. Le serveur DHCP utilise les options DHCPv6 59 et 17 et les sous-options applicables pour échanger des informations relatives au ZTP entre lui-même et le client DHCP.
21.1R1
À partir de la version 21.1R1 de Junos OS, sur les appareils EX2300, EX2300-VC, EX3400, EX3400-VC, EX4400-24T, EX4400-48F, EX4400-48T et EX4600, lorsque le client d’accueil reçoit des informations concernant le serveur proxy HTTP via l’option DHCP 43 sous-option 8, il crée un tunnel transparent HTTPS avec le serveur proxy. Une fois le tunnel établi, le client de réception utilise le tunnel comme proxy pour le serveur de réception ou le serveur de redirection. Le client télécharge l’image logicielle et le fichier de configuration via le tunnel sur l’appareil. Une fois l’amorçage terminé, l’appareil redémarre et le tunnel se ferme.
21.1R1
À partir de la version 21.1R1 de Junos OS, sur les équipements EX2300, EX2300-VC, EX3400, EX3400-VC, EX4400-24T, EX4400-48F, EX4400-48T et EX4600, le client d’accueil peut accéder au serveur de redirection via un serveur proxy. Le serveur DHCP utilise l’option DHCP 43, sous-option 8, pour fournir les détails des serveurs proxy IPv4 et/ou IPv6 au client de base. Le démon DHCP exécuté sur le commutateur cible apprend les serveurs proxy lors du cycle DHCP initial, puis remplit les fichiers phc_vendor_specific_info.xml ou phc_v6_vendor-specific_info.xml situés dans le répertoire /var/etc/ avec les informations spécifiques au fournisseur.
20.4R1-EVO
À partir de la version 20.4R1 de Junos OS Evolved, les équipements PTX10004 prennent en charge l’automatisation de la configuration des équipements et la mise à niveau logicielle via l’interface de gestion du moteur de routage 0 (RE0).
20.4R1-EVO
À partir de Junos OS Evolved version 20.4R1, les équipements ACX5448 et QFX5120-48YM prennent en charge la possibilité pour les interfaces WAN ou les interfaces de gestion de télécharger et d’installer automatiquement le logiciel approprié et le fichier de configuration sur votre équipement pendant le processus d’amorçage ZTP.
20.4R1
À partir de Junos OS version 20.4R1 sur les équipements MX-Series, EX3400, EX4300, QFX5100 et QFX5200, ZTP prend en charge le client DHCPv6. Au cours du processus d’amorçage, l’appareil utilise d’abord le client DHCPv4 pour demander des informations concernant l’image et le fichier de configuration au serveur DHCP. L’appareil vérifie les liaisons DHCPv4 de manière séquentielle. En cas d’échec avec l’une des liaisons DHCPv4, l’appareil continuera à vérifier les liaisons jusqu’à ce que le provisionnement réussisse. Toutefois, s’il n’y a pas de liaisons DHCPv4, l’appareil recherche les liaisons DHCPv6 et suit le même processus que pour DHCPv4 jusqu’à ce que l’appareil puisse être correctement provisionné. Le serveur DHCP utilise les options DHCPv6 59 et 17 et les sous-options applicables pour échanger des informations relatives à ZTP entre lui-même et le client DHCP.
20.4R1
À partir de la version 20.4R1 de Junos OS sur les modèles EX4600, EX4650, EX9200 avec RE-S-EX9200-2X00X6, QFX5110, QFX5200, QFX5200, QFX5210, QFX5120, QFX5120-32C et QFX5120-48Y, vous pouvez utiliser les anciens équipements ZTP basés sur les options DHCP ou le client téléphonique (PHC) pour provisionner le logiciel du commutateur. Au démarrage du commutateur, si des options DHCP ont été reçues du serveur DHCP pour ZTP, le ZTP reprend. Si les options DHCP ne sont pas présentes, PHC est tenté. Le PHC permet au commutateur d’obtenir en toute sécurité des données d’amorçage, telles qu’une configuration ou une image logicielle, sans autre intervention de l’utilisateur que de devoir connecter physiquement le commutateur au réseau. Lorsque le commutateur démarre pour la première fois, PHC se connecte à un serveur de redirection, qui redirige vers un serveur d’accueil téléphonique pour obtenir la configuration ou l’image logicielle.
20.2R1-S1
À partir de la version 20.2R1-S1 de Junos OS sur les équipements MX-Series, EX3400, EX4300, QFX5100 et QFX5200, ZTP prend en charge le client DHCPv6. Au cours du processus d’amorçage, l’appareil utilise d’abord le client DHCPv4 pour demander des informations concernant l’image et le fichier de configuration au serveur DHCP. L’appareil vérifie les liaisons DHCPv4 de manière séquentielle. En cas d’échec avec l’une des liaisons DHCPv4, l’appareil continuera à vérifier les liaisons jusqu’à ce que le provisionnement réussisse. Toutefois, s’il n’y a pas de liaisons DHCPv4, l’appareil recherche les liaisons DHCPv6 et suit le même processus que pour DHCPv4 jusqu’à ce que l’appareil puisse être correctement provisionné. Le serveur DHCP utilise les options DHCPv6 59 et 17 et les sous-options applicables pour échanger des informations relatives à ZTP entre lui-même et le client DHCP.
20.2R1
À partir de la version 20.2R1 de Junos OS sur les équipements SRX300, SRX320, SRX340, SRX345, SRX550 HM et SRX1500, vous pouvez utiliser le Zero-Touch Provisioning avec les options DHCP ou le client de connexion pour provisionner votre équipement.
20.1R1-EVO
À partir de Junos OS Evolved version 20.1R1 sur les équipements PTX10003, le Zero-Touch Provisioning (ZTP) détecte dynamiquement la vitesse des ports des interfaces WAN et utilise ces informations pour créer des ports de serveur ZTP avec la même vitesse.
20.1R1-EVO
À partir de Junos OS Evolved version 20.1R1, les équipements PTX10008 prennent en charge l’automatisation de la configuration des équipements et la mise à niveau logicielle via l’interface de gestion du moteur de routage 0 (RE0).
19.4R1
À partir de la version 19.4R1 de Junos OS, le ZTP peut automatiser le provisionnement de la configuration de l’équipement et de l’image logicielle sur le réflecteur de route de Juniper (JRR). Le ZTP prend en charge la mise à niveau des images personnelles et les mises à jour automatiques de la configuration à l’aide des options DHCP de ZTP. Dans cette version, ZTP prend en charge les ports commerciaux em2 à em9, en plus du port de gestion em0 qui est pris en charge dans les versions de Junos OS antérieures à 19.4R1.
19.3R1-EVO
À partir de Junos OS Evolved version 19.3R1, sur l’équipement QFX5220-128C, dans le Zero-Touch Provisioning (ZTP), vous pouvez utiliser des interfaces WAN ou des interfaces de gestion pour télécharger et installer automatiquement le logiciel approprié et le fichier de configuration sur votre équipement pendant le processus d’amorçage.
19.3R1
À partir de Junos OS version 19.3R1, vous pouvez utiliser des interfaces WAN ou des interfaces de gestion pour télécharger et installer automatiquement le logiciel approprié et le fichier de configuration sur votre routeur pendant le processus d’amorçage ZTP.
19.2R1
À partir de la version 19.2R1 de Junos OS, ZTP peut automatiser le provisionnement de la configuration de l’équipement et de l’image logicielle sur l’interface de gestion em0 pour les commutateurs ACX5448.
19.1R1-EVO
À partir de Junos OS Evolved version 19.1R1, ZTP peut automatiser le provisionnement de la configuration de l’équipement et de l’image logicielle sur l’interface de gestion des appareils QFX5220 et PTX10003.
19.1-EVO
À partir de la version 19.1R1 de Junos OS Evolved, pour surveiller le Zero-Touch Provisioning sur Junos OS Evolved, utilisez la commande show system ztp .
18.3R1
À partir de la version 18.3R1 de Junos OS, le ZTP, qui automatise le provisionnement de la configuration de l’équipement et de l’image logicielle avec un minimum d’intervention manuelle, est pris en charge sur les hôtes de machines virtuelles MX Series.
18.2R1
À partir de la version 18.2R1 de Junos OS, ZTP peut automatiser le provisionnement de la configuration de l’équipement et de l’image logicielle sur les plates-formes hôtes de machines virtuelles qui utilisent des routeurs PTX5000, PTX3000, PTX10008, PTX10016, PTX10002-60C.
18.2R1
À partir de la version 18.2R1 de Junos OS, le ZTP peut automatiser le provisionnement de la configuration de l’équipement et de l’image logicielle sur les plates-formes hôtes de machines virtuelles qui utilisent des commutateurs QFX10008 et QFX10016.
18.1R1
À partir de la version 18.1R1 de Junos OS, ZTP peut automatiser le provisionnement de la configuration de l’équipement et de l’image logicielle sur les plates-formes hôtes de machines virtuelles qui utilisent des commutateurs QFX10002-60C.
17.2R1
À partir de la version 17.2R1 de Junos OS, ZTP peut automatiser le provisionnement de la configuration de l’équipement et de l’image logicielle sur les plates-formes hôtes de machines virtuelles qui utilisent des routeurs PTX1000.
16.1R1
À partir de la version 16.1R1 de Junos OS, vous pouvez provisionner les équipements pris en charge à l’aide d’un script à exécuter ou d’un fichier de configuration à charger.
12.2
À partir de la version 12.2 de Junos OS, vous pouvez utiliser la console et les commandes opérationnelles pour surveiller le Zero-Touch Provisioning.