Apstra ZTP (Équipements)

Note:

Ce document s’applique aux versions d’Apstra ZTP 4.1. Utilisez la version Apstra ZTP correspondant à la version Juniper Apstra que vous utilisez. (Les versions Apstra antérieures à 4.0 utilisent Apstra ZTP versions 1.0.0 ou 2.0.0. Pour plus d’informations, consultez le Guide de l’utilisateur Juniper Apstra 3.3.0.)

Apstra ZTP est un serveur de provisionnement sans intervention pour les systèmes d’infrastructure de centre de données. (Apstra ZTP remplace le logiciel Aeon-ZTPS pris en charge par la communauté qui était auparavant utilisé pour l’implémentation ZTP dans l’environnement Apstra.) Apstra ZTP vous permet de démarrer les équipements de centre de données Apstra sans tenir compte des différences entre les mécanismes NOS sous-jacents. Le ZTP, du point de vue d’Apstra, est un processus qui amène un équipement depuis le démarrage initial jusqu’à un point où il est géré par Apstra via des agents système d’équipement.

En fonction de la configuration ZTP, le processus peut inclure (mais pas toujours) les fonctionnalités suivantes :

• Un service DHCP
• Définition du mot de passe administrateur/racine de l’équipement
• Création d’un utilisateur d’équipement pour l’agent système de l’équipement
• Mise à niveau/déclassement DES
• Installation de l’agent système d’équipement onbox ou offbox

Voir également les informations spécifiques aux fournisseurs :

• Juniper Junos
• SONiC d’entreprise
• Cisco NX-OS
• Arista EOS

Note:

Pour éviter qu’un équipement ne soit verrouillé en cas de problème pendant le processus ZTP, ZTP utilise des informations d’identification codées en dur par défaut. Ces certifications sont les suivants :

• racine /admin
• aosadmin/aosadmin

Vous pouvez utiliser une image vm fournie par Apstra (.ova, .qcow2.gz, .vhdx.gz) ou créer votre propre serveur ZTP et utiliser les scripts de provisionnement des équipements fournis par Apstra dans le cadre du processus ZTP/DHCP existant pour installer automatiquement des agents sur les équipements dans le cadre du processus de démarrage. L’implémentation de référence Apstra ZTP comprend les trois phases suivantes :

1. Phase DHCP générique
   • L’équipement demande une adresse IP via DHCP.
   • L’équipement reçoit l’adresse IP attribuée et un pointeur vers un script à exécuter (ou une image du système d’exploitation à installer si l’image de vm fournie par Apstra).
2. Phase d’initialisation
   • L’équipement télécharge le script ZTP à l’aide de TFTP.
   • L’équipement exécute le script téléchargé pour le préparer à être géré. Il s’agit notamment de vérifier que l’équipement exécute un système d’exploitation pris en charge.
3. Phase d’installation de l’agent
   • Le script ZTP effectue un appel API pour installer un agent système sur l’équipement.

Exigences de ressources serveur Apstra ZTP VM

Apstra ZTP s’exécute comme un serveur Ubuntu 18.04 LTS exécutant un serveur DHCP, HTTP et TFTP et inclut des scripts ZTP fournis par Apstra que vous devez personnaliser pour votre environnement. Le tableau ci-dessous présente les spécifications minimales du serveur pour un environnement de production :

Configuration des ressources
Type de système d’exploitation invité	Ubuntu 18.04 LTS 64 bits
Mémoire	2 Go
CPU	1 processeur virtuel
Stockage sur disque	64 Go
Réseau	Au moins 1 adaptateur réseau. Configuré initialement pour DHCP

Exigences du réseau Apstra ZTP

Rôle	des ports	de destination	source
Agents d’équipement	Serveur DHCP (renouvellements) et diffusion (demandes)	udp/67 -> udp/68	DHCP Client
Agents d’équipement	Apstra ZTP	tout -> tcp/80	Scripts d’initialisation et API
Agents d’équipement Arista et Cisco	Apstra ZTP	any -> udp/69	TFTP pour POAP et ZTP
Apstra ZTP	Contrôleur	tout -> tcp/443	API d’installation de l’agent système d’équipement

Outre les exigences réseau spécifiques à ZTP, le serveur Et les agents d’équipement Apstra ZTP ont besoin d’une connectivité au contrôleur. Pour plus d’informations, reportez-vous aux ports de communication requis dans le guide d’installation et de mise à niveau de Juniper Apstra .

Vous pouvez surveiller l’état du ZTP de l’équipement à partir de l’interface graphique Apstra. Dans le menu de navigation de gauche, accédez à Équipements > statut ZTP > Équipements.

Chaque équipement qui interagit avec DHCP et ZTP est répertorié avec son ID système (numéro de série) s’il est connu, l’état ZTP, le dernier événement ZTP et la date de la dernière mise à jour de l’état de l’équipement.

Pour voir l’intégralité des journaux DHCP et ZTP de l’équipement, cliquez sur l’icône « Afficher le journal ».

Tous les équipements qui interagissent avec DHCP ou ZTP sont répertoriés. Si vous n'avez plus besoin des journaux d'un équipement, cliquez sur le bouton Supprimer .

Les fichiers journaux de tous les processus sont dans le /containers_data/logs répertoire.

Vous pouvez surveiller les services ZTP sur le serveur Apstra ZTP à partir de l’interface graphique Apstra. Dans le menu de navigation de gauche, accédez à Équipements > services > statut ZTP.

Chaque nom de service inclut son adresse IP Docker, l’état du service et la date de la dernière mise à jour du service.

Vous pouvez utiliser n’importe quel utilisateur gui Apstra configuré qui dispose d’un accès en écriture API (comme l’administrateur), mais nous vous recommandons de créer un utilisateur désigné (par exemple « ztp ») auquel le rôle prédéfini device_ztp. Le rôle device_ztp permet aux utilisateurs titulaires de ce rôle de passer des appels API au contrôleur pour demander l’installation de l’agent système de l’équipement. Pour plus d’informations, voir Gestion des utilisateurs/rôles.

Configurez l’IP du contrôleur et le nom d’utilisateur Apstra ZTP dans le /containers_data/status/app/aos.conf fichier sur le serveur Apstra ZTP.

ip	Adresse IP du contrôleur
user	Nom d’utilisateur ZTP ou administrateur
password	Mot de passe de l'utilisateur

Apstra ZTP VM comprend un serveur TFTP et NGINX HTTP. Ces serveurs ne nécessitent pas de configuration. Les deux serveurs servent des fichiers hors du /containers_data/tftp répertoire. (Cumulus n’est plus pris en charge à compter de la version 4.1.0 d’Apstra.)

Le ztp.json fichier contient toute la configuration du script ztp.pyApstra ZTP .

1. Modifiez le ztp.json fichier avec l’éditeur de texte vi ou nano.
2. Le ztp.json fichier est organisé par les éléments suivants :

   valeurs par défaut : les valeurs sont utilisées pour tous les équipements, sauf si des clés plus spécifiques sont définies.	"defaults": { "device-root-password": "root-password-123", "device-user": "admin", "device-user-password": "admin-password-123", "system-agent-params": { "agent_type": "onbox", "install_requirements": false } }
   plate-forme : les valeurs sont utilisées pour tous les équipements d’une plate-forme réseau (« nxos », « eos », « junos », « sonic ») à moins que des clés plus spécifiques ne soient définies.	"sonic": { "sonic-versions": ["SONiC-OS-3.4.0-Enterprise_Advanced"], "sonic-image": "http://10.85.24.52/sonic/3.4.0/sonic-3.4.0-GA-adv-bcm.bin", "device-root-password": "admin", "device-user": "admin", "device-user-password": "admin", "custom-config": "sonic_custom.sh", "system-agent-params": { "agent_type": "onbox", "job_on_create": "install" } }
   modèle : les valeurs sont utilisées pour tous les équipements d’un modèle d’équipement spécifique (par exemple « QFX10002-36Q »).	"QFX10002-36Q": { "junos-versions": ["21.2R1-S2.2"], "junos-image": "http://10.85.24.52/juniper/21.2R1-S2.2/jinstall-host-qfx-10-f-x86-64-21.2R1-S2.2-secure-signed.tgz" }
   numéro de série : les valeurs sont utilisées pour un équipement correspondant à un numéro de série spécifique (par exemple « TH0TFD6TCET0015G0015 »).	"TH0TFD6TCET0015G0015": { "sonic-versions": ["SONiC-OS-4.0.5-Enterprise_Advanced"], "sonic-image": "http://10.85.24.52/sonic/4.0.5/sonic-broadcom-enterprise-advanced-4.0.5-GA.bin" }

   Les données plus spécifiques ont priorité sur les autres données. Par exemple, les données d’un numéro de série spécifique ont priorité sur toutes les autres données, puis le modèle, puis la plate-forme, et enfin les données par défaut.

3. Lla ztp.json utilise les clés suivantes :

   junos-versions - Versions valides pour les équipements Juniper Junos. Si un équipement n’exécute pas de version dans cette liste, ZTP le met à niveau avec l’image junos-image .	"junos-versions": [ "20.2R2-S3.5" ]
   junos-image - Nom de fichier de l’image Juniper Junos TGZ à charger si la version en cours d’exécution ne correspond pas à une version de la junos-versions liste.	Par défaut, le nom de l’image est chargé à partir du serveur ZTP via TFTP à partir du répertoire du /container_data/tftp/ serveur ZTP. Par exemple : "junos-image": "jinstall-host-qfx-5-20.2R2-S3.5-signed.tgz" Pour utiliser n’importe quel serveur HTTP pour le transfert d’images, saisissez une URL HTTP valide avec adresse IP. Par exemple : "junos-image": "http://192.168.59.4/jinstall-host-qfx-5-20.2R2-S3.5-signed.tgz" Cet exemple utilise HTTP depuis le contrôleur pour transférer l’image Juniper Junos.
   sonic-versions- Versions valides pour les équipements SONiC. Si un équipement n’exécute pas de version dans cette liste, ZTP le met à niveau avec l’image sonic-image .	"sonic-versions": [ "SONiC-OS-3.1.0a-Enterprise_Base" ]
   sonic-image - Nom de fichier de l’image SONiC ONIE BIN à charger si la version en cours d’exécution ne correspond pas à une version de la sonic-versions liste.	Par défaut, le nom de l’image est chargé à partir du serveur ZTP via TFTP à partir du répertoire du /container_data/tftp/ serveur ZTP. Par exemple : "sonic-image": "sonic-3.1.0a-bcm.bin" Pour utiliser n’importe quel serveur HTTP pour le transfert d’images, saisissez une URL HTTP valide avec adresse IP. Par exemple : "sonic-image": "http://192.168.59.3/sonic-3.1.0a-bcm.bin" Cet exemple utilise HTTP à partir du contrôleur pour transférer l’image SONiC.
   nxos-versions - Versions valides pour les équipements NX-OS. Si un équipement n’exécute pas de version dans cette liste, ZTP le met à niveau avec l’image nxos-image .	"nxos-versions": [ "9.2(2)", "9.3(6)" ]
   nxos-image - Nom de fichier de l’image NX-OS à charger si la version en cours d’exécution ne correspond pas à une version de la nxos-versions liste.	Par défaut, le nom de l’image est chargé à partir du serveur ZTP via TFTP à partir du répertoire du /container_data/tftp/ serveur ZTP. Par exemple : "nxos-image": "nxos.9.3.6.bin" Pour utiliser n’importe quel serveur HTTP pour le transfert d’images, saisissez une URL HTTP valide avec adresse IP. Par exemple : "nxos-image": "http://192.168.59.4/nxos.9.3.6.bin" Cet exemple utilise HTTP du serveur ZTP pour transférer l’image de Cisco NX-OS.
   eos-versions - Versions valides pour les équipements Arista EOS. Si un équipement n’exécute pas de version dans cette liste, ZTP le met à niveau avec l’image eos-image .	"eos-versions": [ "4.22.3M", "4.24.5M" ]
   eos-image - Nom de fichier de l’image Arista EOS SWI à charger si la version en cours d’exécution ne correspond pas à une version de la eos-versions liste.	Par défaut, le nom de l’image est chargé à partir du serveur ZTP via TFTP à partir du répertoire du /container_data/tftp/ serveur ZTP. Par exemple : "eos-image": "EOS-4.24.5M.swi" Pour utiliser n’importe quel serveur HTTP pour le transfert d’images, saisissez une URL HTTP valide avec adresse IP. Par exemple : "eos-image": "http://192.168.59.3/dos_images/EOS-4.24.5M.swi" Cet exemple utilise HTTP du contrôleur pour transférer l’image Arista EOS.
   device-root-password - Le processus ZTP définit le mot de passe racine de l’équipement à cette valeur. Pour les équipements Arista EOS et Cisco NX-OS, le device-root-password mot de passe est utilisé pour définir le mot de passe du système admin .	"device-root-password": "root-admin-password"
   device-user / device-user-password - Nom d’utilisateur et mot de passe utilisés pour l’agent système de l’équipement. En outre, si nécessaire, le processus ZTP crée un utilisateur sur l’équipement avec ce nom d’utilisateur et ce mot de passe.	"device-user": "aosadmin", "device-user-password": "aosadmin-password"
   custom-config - Nom de fichier du script shell de configuration personnalisé dans le répertoire TFTP ou d’une URL pointant vers le fichier sur un serveur HTTP. Ce script shell s’exécute pendant ZTP, ce qui vous permet d’ajouter une configuration personnalisée à l’équipement. Pour plus d’informations, reportez-vous à la section Informations spécifiques à la plate-forme ci-dessous.	"custom-config": "sonic_custom.sh"
   system-agent-params	Informations utilisées pour créer de nouveaux utilisateurs et agents système sur les équipements, comme décrit ci-dessous.
   agent_type - Type d’agent, boîte de réception ou hors boîte de réception	"agent_type": "onbox"
   install_requirements - Toujours défini sur false. Aucun système d’exploitation réseau n’est actuellement nécessaire.	"install_requirements": false
   job_on_create - Configurez pour install installer l’agent onbox sur l’équipement	"job_on_create": "install" Exemple Junos { "junos": { "junos-versions": ["21.2R1-S2.2"], "junos-image": "http://10.85.24.52/juniper/21.2R1-S2.2/jinstall-host-qfx-5e-x86-64-21.2R1-S2.2-secure-signed.tgz", "device-root-password": "root123", "device-user": "admin", "device-user-password": "admin", "system-agent-params": { "platform": "junos", "agent_type": "offbox", "job_on_create": "install" } }, "QFX10002-36Q": { "junos-versions": ["21.2R1-S2.2"], "junos-image": "http://10.85.24.52/juniper/21.2R1-S2.2/jinstall-host-qfx-10-f-x86-64-21.2R1-S2.2-secure-signed.tgz" }, "JNP10002-60C [QFX10002-60C]": { "junos-versions": ["21.2R1-S1.3"], "junos-image": "http://10.85.24.52/juniper/21.2R1-S1.3/junos-vmhost-install-qfx-x86-64-21.2R1-S1.3.tgz" } }
   platform - (Requis pour les agents hors boîte de réception uniquement) Définissez la plate-forme de l’équipement (« eos », « nxos », « junos »). En minuscule uniquement.	"platform": "junos"
   open_options - (agents offbox uniquement) Définir pour activer https entre l’agent offbox et l’interface API de l’équipement. Si open_options n’est pas défini, la connexion par défaut est HTTP.	"open_options": { "proto": "https", "port": "443" }
   packages - Configurez le SDK ou les packages de télémétrie supplémentaires à télécharger sur l’agent système.	"packages": [ "aos-deployment-helper-nxos", "aosstdcollectors-builtin-nxos", "aosstdcollectors-custom-nxos" ]

Pour obtenir de la documentation sur l’API REST pour obtenir toutes les options disponibles system-agent-params dans /api/system-agents, reportez-vous à Swagger.