Agent de périphérique Cisco
Présentation de l’agent de périphérique Cisco NX-OS
Bien qu’il soit préférable d’installer les agents système des périphériques à partir de l’interface graphique d’Apstra, vous pouvez les installer manuellement à partir de l’interface de ligne de commande. Ce n’est que dans de rares exceptions que vous devrez installer manuellement des agents, ce qui demande plus d’efforts et est sujet aux erreurs. Avant d’installer manuellement les agents, vous devez avoir une compréhension approfondie des différents états des périphériques, des étapes de configuration et des opérations des agents. Pour obtenir de l’aide, contactez l’assistance Juniper.
Vous pouvez également utiliser Apstra ZTP pour démarrer et installer automatiquement les agents et la configuration prérequise sur les commutateurs. L’utilisation d’Apstra ZTP est plus simple et plus facile à gérer à grande échelle que l’installation manuelle des agents.
L’installation manuelle d’un agent pour les périphériques Cisco implique les étapes suivantes :
- Mettez à jour la taille du disque, la mémoire et le processeur du guestshell, puis activez/redémarrez le guestshell.
- Installez l’agent d’appareil.
- Mettez à jour le fichier aos.config.
- Démarrer le service.
Cisco GuestShell n’est pas partitionné pour être unique avec Apstra. S’il existe d’autres applications hébergées sur le guestshell, toute modification dans le guestshell peut les affecter.
Les commandes de la configuration « Bootstrap » ou « Pristine » peuvent interférer avec la configuration Apstra ajoutée lors du déploiement de la fabric.
Si vous configurez NX-OS « system jumbomtu » avec une valeur inférieure aux MTU qu’Apstra utilise, les commandes Apstra MTU échoueront.
Configuration requise pour l’équipement
Configurez l’appareil dans l’ordre suivant : VRF, NXAPI, GuestShell, Create Management VRF. Pour permettre la communication agent-serveur, l'agent d'appareil d'Apstra utilise le nom managementVRF . Assurez-vous que ces lignes apparaissent dans la configuration en cours d’exécution.
! no password strength-check username admin password admin-password role network-admin copp profile strict ! vrf context management ip route 0.0.0.0/0 <Management Default Gateway> ! interface mgmt0 vrf member management ip address <Management CIDR Address> !
Redimensionner et activer Guestshell
- Exécutez les commandes suivantes pour redimensionner l’espace disque, la mémoire et le processeur :
guestshell resize rootfs 1024 guestshell resize memory 2048 guestshell resize cpu 6
- Si le guestshell n’est pas activé, exécutez la commande
guestshell enablepour activer les modifications. - Si le guestshell était déjà activé, exécutez la commande
guestshell rebootpour redémarrer le shell et activer les modifications. - Exécutez la commande
switch# show guestshell detailet vérifiez que le guestshell a été activé.
Télécharger le programme d’installation de l’agent
Vous pouvez copier les agents d’installation via HTTPS à partir du serveur Apstra. Après le téléchargement, vérifiez que la somme MD5 de votre copie téléchargée correspond à ce qu’Apstra stocke.
Pour récupérer le fichier agent, l’appareil Cisco se connecte au serveur Apstra à l’aide du protocole HTTPS. Avant de continuer, assurez-vous que cette connectivité fonctionne.
Apstra est livré avec l’agent à partir du serveur Apstra. Nous pouvons le copier à l’emplacement /volatiledu système de fichiers ou volatile: . Apstra est également fourni avec un fichier md5sum dans le /home/admin dossier du serveur Apstra.
Remplacez la aos_server_ip variable et aos_version à partir du fichier d’exécution ci-dessous. (Pour vérifier la version du serveur Apstra à partir de l’interface graphique d’Apstra, accédez à Platform > About).
switch# guestshell run sudo chvrf management wget --no-check-certificate -o /volatile/aos_download.log -O /volatile/aos.run https://<aos_server_ip>/device_agent_images/aos_device_agent_<aos_version>.run guestshell run sudo chvrf management wget --no-check-certificate -o /volatile/aos_download.log -O /volatile/aos.run.md5 https://<aos_server_ip>/device_agent_images/aos_device_agent_<aos_version>.run.md5
Vérifiez que le fichier a été téléchargé correctement.
switch# show file volatile:aos.run md5 a28780880a8d674f6eb6a397509db101 switch# show file volatile:aos.run.md5 a28780880a8d674f6eb6a397509db101 aos_device_agent_<aos_version>.run
Installer Cisco Device Agent
Nous vous recommandons d’exécuter la commande copy running-config startup-config pour enregistrer vos dernières modifications, au cas où des problèmes surviendraient.
À partir de l’interpréteur invité du commutateur Cisco NX-OS, exécutez la commande pour installer l’agent comme indiqué ci-dessous :
switch# guestshell run sudo chmod +x /volatile/aos.run switch# guestshell run sudo /volatile/aos.run -- --no-start <omitted output> created 7855 files created 1386 directories created 602 symlinks created 0 devices created 0 fifos + [[ True == \T\r\u\e ]] + true + systemctl enable aos
Mettre à jour le fichier de configuration de l’agent et le service de démarrage
Après l’installation de l’agent et avant de démarrer le service, mettez à jour le aos.conf fichier afin qu’il se connecte au serveur.
Configurez le fichier de configuration de l’agent de périphérique Cisco NX-OS situé à l’adresse /etc/aos/aos.conf. Reportez-vous au fichier de configuration de l’agent de périphérique Apstra pour connaître les paramètres.
Après avoir mis à jour le fichier, exécutez la commande service aos start pour démarrer l’agent de périphérique Apstra.
Activer des appareils Apstra sur un serveur Apstra
Lorsque l’agent d’équipement Apstra communique avec Apstra, il utilise une « clé de périphérique » pour s’identifier. Pour les commutateurs Cisco NXOS, la clé de périphérique est l’adresse MAC de l’interface de gestion « eth0 ».
root@Cisco:/etc/aos# ip link show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000 link/ether 08:00:27:8a:39:05 brd ff:ff:ff:ff:ff:ff
Déployer l’équipement
Dans le menu de navigation de gauche de l’interface graphique d’Apstra, accédez à Devices > Managed Devices. Lorsque l’agent est opérationnel, il apparaît dans cette liste et peut être accusé de réception et affecté à un blueprint à l’aide de l’interface graphique conformément à la procédure standard.
Réinitialiser l’agent de périphérique Apstra
Si vous devez réinitialiser l'agent Apstra pour une raison quelconque (modification des blueprints, redéploiement, restauration de l'appareil à partir d'une sauvegarde, etc.), il est préférable d'effacer les métadonnées de l'agent Apstra, d'enregistrer à nouveau l'appareil et de le redéployer sur le blueprint.
C9K-172-20-65-5# guestshell [guestshell@guestshell ~]$ sudo su - [root@guestshell ~]# systemctl stop aos [root@guestshell ~]# rm -rf /var/log/aos/* [root@guestshell ~]# systemctl start aos Starting AOS Agents...root@guestshell ~]#
Désinstaller Apstra Device Agent
Pour désinstaller l’agent, commencez par le dédéployer et le désaffecter du blueprint conformément aux procédures standard à l’aide de l’interface graphique. Vous pouvez également le supprimer entièrement à partir de la page Appareils gérés.
Pour supprimer le package Apstra de NX-OS, détruisez le guestshell. Ne le faites que si aucune autre application n’utilise le guestshell :
C9K-172-20-65-5# guestshell destroy Remove remaining AOS data from system Removing the guest-shell deletes most of the data left by AOS. Some files are still on the bootflash:/.aos folder. C9K-172-20-65-5# delete bootflash:.aos no-prompt
Supprimer les scripts Apstra EEM
L’agent d’équipement Apstra installe des applets de gestionnaire d’événements pour faciliter la télémétrie. Ceux-ci peuvent être retirés en toute sécurité
C9K-172-20-65-5(config)# pas d’applet de gestionnaire d’événements AOS_PROTO_VSH_LAUNCH C9K-172-20-65-5(config)# pas d’applet de gestionnaire d’événements AOS_STATS_VSH_LAUNCH C9K-172-20-65-5(config)# pas d’applet de gestionnaire d’événements aos_bgp_applet C9K-172-20-65-5(config)# pas d’applet de gestionnaire d’événements aos_ifdown_applet C9K-172-20-65-5(config)# pas d’applet de gestionnaire d’événements aos_ifup_applet
Dépannage de l’agent Cisco
L’agent Apstra s’exécute sous le guestshell NXOS pour interagir avec les environnements bash et Linux sous-jacents. Il s’agit d’un conteneur Linux interne (LXC) dans lequel Apstra opère. Dans le cadre de LXC, Apstra utilise NXAPI et d’autres méthodes pour communiquer directement avec NXOS. Pour des raisons de sécurité, Cisco partitionne une grande partie de l’interface LXC du reste du périphérique NXOS, nous devons donc passer à l’invite bash de l’interpréteur de commandes invité pour effectuer d’autres commandes de dépannage.
Vérifiez que le Guest Shell est en cours d’exécution sur NX-OS L’agent Apstra s’exécute sous le NXOS Guest Shell pour interagir avec les environnements bash et linux sous-jacents. Il s’agit d’un conteneur Linux interne (LXC) dans lequel Apstra opère. Nous vérifions que le shell invité est activé et en cours d’exécution.
C9K-172-20-65-5# show guestshell detail Virtual service guestshell+ detail State : Activated Package information Name : guestshell.ova Path : /isanboot/bin/guestshell.ova Application Name : GuestShell Installed version : 2.1(0.0) Description : Cisco Systems Guest Shell Signing Key type : Cisco release key Method : SHA-1 Licensing Name : None Version : None Resource reservation Disk : 1024 MB Memory : 3072 MB CPU : 6% system CPU Attached devices Type Name Alias --------------------------------------------- Disk _rootfs Disk /cisco/core Serial/shell Serial/aux Serial/Syslog serial2 Serial/Trace serial3
Affichage des services enregistrés
C9K-172-20-65-5# show virtual-service list Virtual Service List: Name Status Package Name ----------------------------------------------------------------------- guestshell+ Activated guestshell.ova
- Confirmer l’accessibilité du réseau à Apstra
- Confirmer l’installation de l’agent
- Vérifiez que l’agent Apstra est en cours d’exécution
- Vérifier la présence de fichiers dans /etc/aos
- Recherchez les données Apstra dans /var/log/aos
- Déterminer la version de l’agent Apstra
- Échec de la résolution DNS
- Le service Apstra prend beaucoup de temps à démarrer sur Cisco NX-OS
- Apstra s’arrête et s’arrête sans erreur (MGMT VRF)
- Vérifier le VRF de gestion dans l’interpréteur de commandes invité NX-OS
Confirmer l’accessibilité du réseau à Apstra
Dans l’interpréteur de commandes invité, envoyez une requête ping au serveur Apstra pour vérifier le ping ICMP. Lorsque vous exécutez des commandes dans le contexte d'un VRF, utilisez la commande chvrf <vrf> Dans ce cas, il s'agit de management VRF.
[guestshell@guestshell ~]$ chvrf management ping 172.20.65.3 PING 172.20.65.3 (172.20.65.3) 56(84) bytes of data. 64 bytes from 172.20.65.3: icmp_seq=1 ttl=64 time=0.239 ms 64 bytes from 172.20.65.3: icmp_seq=2 ttl=64 time=0.215 ms
Confirmer l’installation de l’agent
Vérifiez si le package de l’agent de périphérique Apstra est installé. Dans NXOS, l’agent Apstra s’installe sur /etc/rc.d/init.d/aos pour démarrer au démarrage de l’instance de guestshell.
[guestshell@guestshell ~]$ systemctl status aos
aos.service - LSB: Start AOS device agents
Loaded: loaded (/etc/rc.d/init.d/aos)
Active: active (running) since Tue 2016-11-15 00:10:49 UTC; 3h 54min ago
Process: 30 ExecStart=/etc/rc.d/init.d/aos start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/aos.service
├─113 tacspawner --daemonize=/var/log/aos/aos.log --pidfile=/var/run/aos.pid --name=SAL2028T5NE --hostname=localhost --domainSocket=aos_spawner_sock --hostSysdbAddress=tb...
├─115 tacleafsysdb --agentName=SAL2028T5NE-LocalTasks-SAL2028T5NE-0 --partition= --storage-mode=persistent --eventLogDir=. --eventLogSev=TaccSpawner/error,Mounter/error,M...
├─116 /usr/bin/python /bin/aos_agent --class=aos.device.common.ProxyDeploymentAgent.ProxyDeploymentAgent --name=DeploymentProxyAgent device_type=Cisco serial_number=@(SWI...
├─117 /usr/bin/python /bin/aos_agent --class=aos.device.common.ProxyCountersAgent.ProxyCountersAgent --name=CounterProxyAgent device_type=Cisco serial_number=@(SWITCH_UNI...
└─118 /usr/bin/python /bin/aos_agent --class=aos.device.cisco.CiscoTelemetryAgent.CiscoTelemetryAgent --name=DeviceTelemetryAgent serial_number=@(SWITCH_UNIQUE_ID)
Vérifiez que l’agent Apstra est en cours d’exécution
Vérifiez l’état du système en cours d’exécution à l’aide de la commande 'service' et vérifiez les processus en cours d’exécution à l’aide de la commande 'ps'. Nous cherchons à confirmer aos_agent fonctionne correctement.
[root@guestshell ~]# service aos status aos is running [root@guestshell ~]# ps wax PID TTY STAT TIME COMMAND 1 ? Ss 0:00 /sbin/init 9 ? Ss 0:00 /usr/lib/systemd/systemd-journald 19 ? Ss 0:00 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 22 ? Ss 0:00 /usr/lib/systemd/systemd-logind 29 ? Ss 0:00 /usr/sbin/sshd -D -f /etc/ssh/sshd_config-cisco -p 17682 -o ListenAddress=localhost 38 ? Ss 0:00 /usr/sbin/crond -n 55 pts/1Ss+0:00 /sbin/agetty --noclear ttyS1 56 pts/0Ss+0:00 /sbin/agetty --noclear ttyS0 113 ? Sl 0:01 tacspawner --daemonize=/var/log/aos/aos.log --pidfile=/var/run/aos.pid --name=C9K --hostname=localhost --domainSocket=aos_spawner_sock --hostSysdbAdd 115 ? S 0:03 tacleafsysdb --agentName=C9K-LocalTasks-C9K-0 --partition= --storage-mode=persistent --eventLogDir=. --eventLogSev=TaccSpawner/error,Mounter/ 116 ? Sl 0:01 /usr/bin/python /bin/aos_agent --class=aos.device.common.ProxyDeploymentAgent.ProxyDeploymentAgent --name=DeploymentProxyAgent device_type=Cisco serial_numbe 117 ? Sl 0:19 /usr/bin/python /bin/aos_agent --class=aos.device.common.ProxyCountersAgent.ProxyCountersAgent --name=CounterProxyAgent device_type=Cisco serial_number=@(SWI 118 ? Sl 0:02 /usr/bin/python /bin/aos_agent --class=aos.device.cisco.CiscoTelemetryAgent.CiscoTelemetryAgent --name=DeviceTelemetryAgent serial_number=@(SWITCH_UNIQUE_ID) 700 ? Ss 0:00 sshd: guestshell [priv] 702 ? S 0:00 sshd: guestshell@pts/4 703 pts/4Ss 0:00 bash -li 732 pts/4S 0:00 sudo su - 733 pts/4S 0:00 su - 734 pts/4S 0:00 -bash 823 pts/4R+ 0:00 ps wax
Vérifier la présence de fichiers dans /etc/aos
Sous l’interpréteur de commandes invité, Apstra stocke un certain nombre de fichiers de configuration sous /etc/aos.
[root@guestshell aos]# ls -lah /etc/aos total 44K drwxr-xr-x 2 root root 4.0K Nov 15 00:05 . drwxr-xr-x 63 root root 4.0K Nov 15 00:09 .. -rwxr-xr-x 1 root root 1.1K Nov 14 22:26 agent.json -rw-r--r-- 1 root root 1.1K Nov 15 00:05 aos.conf -rwxr-xr-x 1 root root 992 Nov 14 22:26 common_functions -rwxr-xr-x 1 root root 1.4K Nov 14 22:26 health_check_functions -rwxr-xr-x 1 root root 450 Nov 14 22:26 iproute2_functions -rwxr-xr-x 1 root root 916 Nov 14 22:26 lsb_functions -rwxr-xr-x 1 root root 4.5K Nov 14 22:26 platform_functions -rwxr-xr-x 1 root root 156 Nov 14 22:26 version
Recherchez les données Apstra dans /var/log/aos
Apstra écrit la base de données interne dans /var/log/aos
[root@guestshell aos]# ls -lah /var/log/aos total 500K drwxr-xr-x 2 root root 480 Nov 15 00:10 . drwxr-xr-x 3 root root 120 Nov 15 00:10 .. -rw-r--r-- 1 root root 3.2K Nov 15 00:11 CounterProxyAgent.117.1479168658.log -rw-r--r-- 1 root root 289K Nov 15 02:27 CounterProxyAgent.err -rw-r--r-- 1 root root0 Nov 15 00:10 CounterProxyAgent.out -rw------- 1 root root 31K Nov 15 00:11 CounterProxyAgentC9K_2016-11-15--00-10-59_117-2016-11-15--00-10-59.tel -rw-r--r-- 1 root root 104 Nov 15 00:45 DeploymentProxyAgent.116.1479168650.log -rw-r--r-- 1 root root 12K Nov 15 00:45 DeploymentProxyAgent.err -rw-r--r-- 1 root root0 Nov 15 00:10 DeploymentProxyAgent.out -rw------- 1 root root 31K Nov 15 00:10 DeploymentProxyAgentC9K_2016-11-15--00-10-51_116-2016-11-15--00-10-51.tel -rw-r--r-- 1 root root 4.1K Nov 15 00:11 DeviceTelemetryAgent.118.1479168657.log -rw-r--r-- 1 root root 1.4K Nov 15 00:11 DeviceTelemetryAgent.err -rw-r--r-- 1 root root0 Nov 15 00:10 DeviceTelemetryAgent.out -rw------- 1 root root 31K Nov 15 00:11 DeviceTelemetryAgentC9K_2016-11-15--00-10-58_118-2016-11-15--00-10-58.tel -rw-r--r-- 1 root root0 Nov 15 00:10 C9K-0.115.1479168649.log -rw-r--r-- 1 root root0 Nov 15 00:10 C9K-0.err -rw-r--r-- 1 root root0 Nov 15 00:10 C9K-0.out -rw------- 1 root root 39K Nov 15 00:10 C9K-LocalTasks-C9K-0_2016-11-15--00-10-50_115-2016-11-15--00-10-50.tel -rw------- 1 root root 36K Nov 15 00:10 Spawner-C9K_2016-11-15--00-10-49_111-2016-11-15--00-10-49.tel -rw------- 1 root root 634 Nov 15 00:10 _C9K-00000000582a528a-0001744b-checkpoint -rw-r--r-- 1 root root0 Nov 15 00:10 _C9K-00000000582a528a-0001744b-checkpoint-valid -rw------- 1 root root0 Nov 15 00:10 _C9K-00000000582a528a-0001744b-log -rw-r--r-- 1 root root0 Nov 15 00:10 _C9K-00000000582a528a-0001744b-log-valid -rw-r--r-- 1 root root0 Nov 15 00:10 aos.log [root@guestshell aos]#
Déterminer la version de l’agent Apstra
La version de l’agent Apstra est disponible dans /etc/aos/version. Avant d’exécuter cette commande, nous devons nous attacher au service aos.
[root@guestshell admin]# service aos attach aos@guestshell:/# cat /etc/aos/version VERSION=99.0.0-3874 BUILD_ID=AOS_latest_OB.3874 BRANCH_NAME=master COMMIT_ID=d3eb2585608f0509a11b95fb9d07aed6e26d6c32 BUILD_DATETIME=2018-05-20_10:22:32_PDT AOS_DI_RELEASE=2.2.0-169 aos@guestshell:/#
Échec de la résolution DNS
L’agent Apstra est sensible à la résolution DNS de la connexion metadb. Assurez-vous que l’adresse IP et/ou le DNS de /etc/aos/aos.conf est accessible à partir du port de gestion eth0 de l’appareil.
[root@guestshell ~]# aos_show_tech | grep -i dns [2016/10/20 23:04:20.534538UTC@event-'warning']:(textMsg=Failing outgoing mount to <'tbt://aos-server:29731/Data/ReplicaStatus?flags=i','/Metadb/ReplicaStatus'>' due to code 'resynchronizing' and reason 'Dns lookup issue "Temporary failure in name resolution" Unknown error 18446744073709551613) [2016/10/20 23:04:21.540444UTC@OutgoingMountConnectionError-'warning']:(connectionName=--NONE--,localPath=/Metadb/ReplicaStatus,remotePath=tbt://aos-server:29731/Data/ReplicaStatus?flags=i,msg=Tac::ErrnoException: Dns lookup issue "Temporary failure in name resolution" Unknown error 18446744073709551613) [2016/10/20 23:04:21.541174UTC@event-'warning']:(textMsg=Failing outgoing mount to <'tbt://aos-server:29731/Data/ReplicaStatus?flags=i','/Metadb/ReplicaStatus'>' due to code 'resynchronizing' and reason 'Dns lookup issue "Temporary failure in name resolution" Unknown error 18446744073709551613) Insufficient Guestshell filesystem size An error message ‘AOS Agent needs XXMB on the / filesystem’ will occur if the rootfs partition is not at least 1GB large. Please make sure to resize the guestshell filesystem to 2gb ram, 1gb disk, and 6% CPU. <snip> + popd /tmp/selfgz18527139 + rpm -Uvh --nodeps --force /tmp/selfgz18527139/aos-device-agent-1.1.0-0.1.1108.x86_64.rpm Preparing... ################################# [100%] installing package aos-device-agent-1.1.0-0.1.1108.x86_64 needs 55MB on the / filesystem
Le service Apstra prend beaucoup de temps à démarrer sur Cisco NX-OS
Il faut quelques minutes au GuestShell sur Cisco NX-OS pour initialiser le NXAPI dans le conteneur LXC. C’est normal. Pour tenir compte de ce délai, un délai d’attente a été ajouté à l’initialisation du script Apstra.
Apstra s’arrête et s’arrête sans erreur (MGMT VRF)
Assurez-vous que le guestshell est correctement derrière le VRF de gestion.
Nous ne devrions pas être en mesure d’envoyer un ping au serveur Apstra lors de l’exécution de la commande 'ping' par défaut :
Ci-dessous - nous nous attendons à ce qu’un ping de la table de routage globale par défaut vers le serveur Apstra à 172.20.156.3 échoue, mais réussisse sous le shell invité.
SAL2028T5PP-172-20-156-5# ping 172.20.156.3 PING 172.20.156.3 (172.20.156.3): 56 data bytes ping: sendto 172.20.156.3 64 chars, No route to host ^C --- 172.20.156.3 ping statistics --- 1 packets transmitted, 0 packets received, 100.00% packet loss SAL2028T5PP-172-20-156-5# ping 172.20.156.3 vrf management PING 172.20.156.3 (172.20.156.3): 56 data bytes 64 bytes from 172.20.156.3: icmp_seq=0 ttl=63 time=0.649 ms 64 bytes from 172.20.156.3: icmp_seq=1 ttl=63 time=0.449 ms 64 bytes from 172.20.156.3: icmp_seq=2 ttl=63 time=0.428 ms 64 bytes from 172.20.156.3: icmp_seq=3 ttl=63 time=0.423 ms 64 bytes from 172.20.156.3: icmp_seq=4 ttl=63 time=0.404 ms ^C
Vérifier le VRF de gestion dans l’interpréteur de commandes invité NX-OS
[root@guestshell ~]# ping 172.20.157.3 connect: Network is unreachable [root@guestshell ~]# sudo ip netns exec management ping 172.20.156.3 PING 172.20.156.3 (172.20.156.3) 56(84) bytes of data. 64 bytes from 172.20.156.3: icmp_seq=1 ttl=64 time=0.226 ms 64 bytes from 172.20.156.3: icmp_seq=2 ttl=64 time=0.232 ms ^C