Dépannage de la découverte de fabric ACI - Remplacement de périphérique

Introduction

Ce document décrit les étapes à suivre pour comprendre et dépanner les scénarios de remplacement de périphériques dans l'ACI.

Informations générales

Le matériel de ce document a été extrait de la Dépannage de l'infrastructure axée sur les applications Cisco, deuxième édition , en particulier la découverte du fabric - Remplacement de périphérique chapitre.

Aperçu

Au cours de l'évolution d'un fabric ACI, il sera nécessaire de remplacer divers composants, notamment : Les APIC, les commutateurs Leaf, les commutateurs Spine et les périphériques IPN. Les RMA et les mises à niveau matérielles sont les raisons les plus courantes du remplacement. Ces procédures sont bien documentées dans les guides d'installation et de mise à niveau de Cisco et le guide le plus récent doit être lu avant le remplacement. Cette section comprend un examen plus approfondi de la façon dont les procédures fonctionnent sous le capot ; ainsi que de parcourir plusieurs des scénarios de dépannage les plus courants.

Procédures et vérification

Note: Depuis la version 5.2(3) du commutateur ACI, les commutateurs NXOS connectés à un commutateur de fabric ACI découvert peuvent utiliser le protocole POAP pour effectuer la conversion en commutateur ACI.

Remplacement de matériel

Feuille

Un leaf du dépôt RMA arrive et exécute le logiciel NXOS. Veuillez vous reporter à la section ci-dessous intitulée « Problème : Arrive en mode NXOS' pour convertir correctement le leaf en mode ACI. Si vous utilisez un leaf d'un autre fabric ou avec une configuration précédente, veillez à utiliser les commandes « acidiag touch clean » et « reload ».

Une fois que les étapes ci-dessus sont terminées et que le nouveau commutateur leaf est prêt pour l'enregistrement, retirez le leaf à remplacer du fabric via l'option « Retirer du contrôleur ».

L'option « Supprimer du contrôleur » supprime complètement le noeud du contrôleur APIC, libérant l'ID de noeud, l'association de numéro de série et l'adresse TEP qui a été attribuée par le contrôleur APIC. Ces processus sont souhaités lors du remplacement d’un noeud de commutateur. L'option « Désaffectation » n'est utilisée que si le même noeud doit rejoindre le fabric avec le même ID de noeud et le même numéro de série.

Lorsque le commutateur leaf à remplacer n'est plus visible sur la page Appartenance au fabric, le nouveau leaf peut être connecté au fabric via les interfaces de spine. Une fois le leaf découvert par le contrôleur APIC, il apparaît dans l'inventaire du fabric et est prêt à être enregistré. Si le périphérique à remplacer n'a pas encore libéré son ID de noeud et qu'un nouveau commutateur est enregistré avec le même ID de noeud, une erreur est générée en se référant au fait que l'ID est déjà associé à un autre noeud leaf. Le défaut devrait s'effacer après un certain temps. Si le nouveau noeud n'apparaît pas dans le sous-menu Appartenance au fabric, il peut y avoir un problème de câblage ; cela peut être vérifié en affichant les voisins LLDP via la commande « show lldp neighbors detail » sur les commutateurs spine connectés au commutateur leaf nouvellement connecté. Pour plus de détails sur le processus de découverte de fabric, reportez-vous au chapitre « Configuration initiale du fabric ».

Si le VLAN infra est modifié, tous les noeuds leaf doivent être redémarrés correctement en même temps. Si tous les commutateurs leaf ne sont pas nettoyés en même temps, un commutateur propre rechargé se met en ligne et reçoit l'ancien VLAN infrarouge via LLDP d'un leaf non encore nettoyé, et le leaf propre rechargé ne s'enregistre pas auprès de l'APIC. Reportez-vous au chapitre "Configuration initiale du fabric" pour plus de détails.

En raison des limitations de la plate-forme, les paires VPC ne peuvent pas être un mélange de commutateurs Leaf Gen1 et Gen2 ou supérieurs. Cependant, au moment de l'écriture, n'importe quelle feuille Gen2 et supérieure peut se mélanger avec n'importe quelle autre feuille Gen2 ou supérieure.

Dos

Comme une feuille, en fonction du matériel de la colonne vertébrale (comme une colonne vertébrale modulaire), elle peut arriver en mode NXOS. Suivez la procédure « Problème : Arrive en mode NXOS" sous les scénarios pour effectuer la conversion.

Lors du remplacement d'un commutateur spine, l'utilisateur doit tenir compte de la fonctionnalité BGP Route Reflector. La meilleure pratique consiste à configurer au moins deux commutateurs Spine comme réflecteurs de route BGP pour un fabric Cisco ACI de couche 3. Cette configuration se trouve dans 'System > System Settings > BGP Route Reflectors' sous Route Reflector Nodes. Lors du remplacement ou du retrait d'un commutateur spine, assurez-vous que les modifications de configuration appropriées ont été apportées pour conserver un réflecteur de route actif et assurez-vous qu'au moins deux réflecteurs de route actifs sont actifs une fois les modifications effectuées.

Référez-vous à la section "Politiques de pod — BGP RR / Date&Time / SNMP" dans le chapitre "Gestion et services principaux" pour plus d'informations sur les réflecteurs de route BGP.

APIC

La considération la plus importante lors du remplacement d'un APIC est l'intégrité du cluster APIC existant. Avant le remplacement, tous les APIC du cluster doivent être signalés comme étant parfaitement adaptés. Dans la version 4.2, un outil supplémentaire a été introduit pour vérifier l'intégrité du cluster APIC via l'interface de ligne de commande :

apic1# acidiag cluster
Admin password:
Product-name = APIC-SERVER-L2
Serial-number = FCH2206W0RK
Running...

Checking Core Generation: OK
Checking Wiring and UUID: OK
Checking AD Processes: Running
Checking All Apics in Commission State: OK
Checking All Apics in Active State: OK
Checking Fabric Nodes: OK
Checking Apic Fully-Fit: OK
Checking Shard Convergence: OK
Checking Leadership Degration: Optimal leader for all shards
Ping OOB IPs:
APIC-1: 192.168.4.20 - OK
Ping Infra IPs:
APIC-1: 10.0.0.1 - OK
Checking APIC Versions: Same (4.2(1i))
Checking SSL: OK

Done!

Lors du remplacement d'un APIC, veillez à noter les variables de configuration initiales de l'APIC à remplacer, avant d'effectuer une mise hors service de l'APIC.

apic1# cat /data/data_admin/sam_exported.config
Setup for Active and Standby APIC
fabricDomain = POD37 
fabricID = 1 
systemName =apic1 
controllerID = 1 
tepPool = 10.0.0.0/16 
infraVlan = 3937 
GIPo = 225.0.0.0/15 
clusterSize = 3 
standbyApic = NO 
enableIPv4 = Y 
enableIPv6 = N 
firmwareVersion = 4.2(1i) 
ifcIpAddr = 10.0.0.1 
apicX = NO 
podId = 1 
oobIpAddr = 10.48.176.57/24

Préparez le nouveau contrôleur APIC avec la version logicielle appropriée et saisissez à nouveau les valeurs de configuration initiales mentionnées précédemment. Lorsque la configuration initiale est terminée et que le contrôleur APIC est entièrement amorcé, réinitialisez-le dans le fabric à partir de l'interface utilisateur de l'un des autres contrôleurs APIC du cluster.

Remplacement de périphérique IPN

Dans un environnement à plusieurs pods, il peut être nécessaire de remplacer l'un des périphériques utilisés pour le réseau IPN (Inter-Pod Network). Avant le remplacement, le réseau IPN doit avoir une redondance de point de rendez-vous bidirectionnel PIM configurée sous la forme de RP fantômes. Sans les RP fantômes en place, si le noeud remplacé était le RP, il y aurait une convergence PIM et une perte de paquets serait visible pour tout le trafic BUM envoyé à travers l'IPN.

Reportez-vous à la section "Configuration RP" du chapitre "Découverte de multipod" pour plus d'informations sur la façon de configurer le RP fantôme.

Rechargement propre du module APIC/leaf/spine

Dans certains scénarios, la meilleure option pour récupérer une feuille/colonne vertébrale qui ne rejoint pas le fabric est d'effectuer un rechargement propre du périphérique.

Il n'est pas recommandé d'effectuer un rechargement propre sur un périphérique qui attend son tour pour effectuer une mise à niveau. Le rechargement de n'importe quel périphérique peut prendre un certain temps.

La commande « acidiag touch » propose deux options : nettoyer et configurer. L'option clean supprime toutes les données de stratégie tout en conservant la configuration du réseau APIC (comme le nom du fabric, l'adresse IP, la connexion). L'option setup supprime à la fois les données de stratégie et la configuration du réseau APIC. L'option de configuration est généralement utilisée lors du déplacement de périphériques sur des pods, car l'ID de pod doit être modifié, et normalement le réseau de gestion doit également être mis à jour.

APIC

fab1-apic1# acidiag touch clean 
This command will wipe out this device, Proceed? [y/N] y

fab1-apic1# acidiag reboot 
This command will restart this device, Proceed? [y/N] y

Feuille/Dos

fab1-leaf101# acidiag touch clean 
This command will wipe out this device, Proceed? [y/N] y 

fab1-leaf101# reload 
This command will reload the chassis, Proceed (y/n)? [n]: y

La commande 'acidiag touch clean' fonctionne en plaçant un fichier caché sur le leaf dans /mnt/pss appelé .clean. Lorsque le leaf est démarré, un script shell s'exécute pour vérifier si un fichier .clean est présent. Si un fichier .clean existe sous /mnt/pss, la configuration de la stratégie est effacée et la configuration est téléchargée à nouveau à partir du contrôleur APIC. Si vous entrez cette commande et que le noeud n'est pas rechargé, le fichier est toujours présent et la stratégie est effacée lors du prochain rechargement, quel que soit le temps écoulé depuis l'entrée du nettoyage tactile.

Scénarios de dépannage

Problème : Arrive en mode NXOS

Vérification

Parfois, lorsqu'un commutateur est expédié via RMA, il peut arriver avec le logiciel NXOS qui n'a pas encore été configuré via le processus POAP (Power On Auto Provisioning). Lorsque l'utilisateur accède à ce périphérique via la console, il voit une forme du message suivant :

Abandonner le provisionnement automatique et poursuivre la configuration normale ?(oui/non)

Si le périphérique est déjà passé par le POAP, la façon la plus simple de déterminer si un leaf exécute du code NXOS autonome est de rechercher la ligne « NXOS image file » dans la sortie « show version ». Si une telle sortie est présente, le leaf exécute du code autonome et devra être converti en mode ACI. La présence des images Kickstart et système peut être vérifiée et ne sera présente que sur un leaf exécutant une image ACI, en regardant l'image elle-même, qui sera n9000 sur standalone et aci-n9000 sur ACI.

NXOS autonome

nxos-n9k# show version
Cisco Nexus Operating System (NX-OS) Software
.
.
.
Software
  BIOS: version 07.17
  NXOS: version 6.1(2)I3(4)
  BIOS compile time:  09/10/2014
  NXOS image file is: bootflash:///n9000-dk9.6.1.2.I3.4.bin
  NXOS compile time:  3/18/2015 0:00:00 [03/18/2015 07:49:10]

ACI

aci-leaf101# show version
Cisco Nexus Operating System (NX-OS) Software
.
.
.
Software
  BIOS:      version 07.66
  kickstart: version 14.2(1i) [build 14.2(1i)]
  system:    version 14.2(1i) [build 14.2(1i)]
  PE:        version 4.2(1i)
  BIOS compile time:       06/11/2019
  kickstart image file is: /bootflash/aci-n9000-dk9.14.2.1i.bin
  kickstart compile time:  09/07/2019 10:25:16 [09/07/2019 10:25:16]
  system image file is:    /bootflash/auto-s
  system compile time:     09/07/2019 10:25:16 [09/07/2019 10:25:16]

Solution

Si le commutateur a été livré avec du code NXOS, il doit être converti en mode ACI. Le commutateur doit être livré avec l'image NXOS et l'image ACI dans le bootflash, bien que ce ne soit pas toujours le cas. L'image ACI commence par « aci-n9000 ». Si l'image ACI n'est pas présente, elle doit être chargée manuellement dans le bootflash. Cette opération peut être effectuée via la connexion USB (accès local requis) ou via SCP à partir du contrôleur APIC directement (en supposant que les deux périphériques soient connectés via un réseau de gestion). Voici les instructions pour copier l'image via SCP :

1. nexus-9000(config)# feature scp-server
2. apic1# scp -r /firmware/fwrepos/fwrepo/switch-image-name admin@standalone_switch:switch-image-name

Le leaf devra alors être configuré pour ne pas démarrer l'image NXOS, enregistrer la configuration, changer les instructions de démarrage en ACI.

1. (config)# no boot nxos
2. (config)# copy run start
3. (config)# boot aci bootflash:
     
     
4. (config)# reload

Problème : EPLD/FPGA feuille/colonne vertébrale incorrect, F1582

Vérification

Les défaillances suivantes sont visibles dans les défaillances du commutateur Nexus 9000 ACI.

Incompatibilité de version FPGA F1582 détectée. Version en cours : 0x(z) Version attendue : 0x(y)

Dans l'interface de ligne de commande APIC, recherchez toutes les instances de Fault F1582 :

apic1# moquery -c faultInst -f 'fault.Inst.code=="F1582"'

notes EPLD

Les commutateurs en mode ACI de la gamme Cisco Nexus 9000 contiennent plusieurs unités logiques programmables (PLD) qui fournissent des fonctionnalités matérielles dans tous les modules. Cisco fournit des mises à niveau d'image EPLD (Electronic Programmable Logic Device) pour améliorer les fonctionnalités matérielles ou résoudre les problèmes connus. Les PLD incluent les dispositifs logiques programmables électroniques (EPLD), les réseaux prédiffusés programmables sur site (FPGA) et les dispositifs logiques programmables complexes (CPLD), mais ils n'incluent pas les ASIC.

Le terme EPLD est utilisé pour désigner les FPGA et les CPLD.

L'avantage d'avoir des EPLD pour certaines fonctions de module est que lorsque ces fonctions doivent être mises à niveau, il suffit de mettre à niveau leurs images logicielles au lieu de remplacer leur matériel.

Les mises à niveau de l'image EPLD d'un module d'E/S interrompent le trafic traversant le module, car ce dernier doit être mis brièvement hors tension pendant la mise à niveau. Dans un châssis modulaire, le système effectue des mises à niveau EPLD sur un module à la fois, de sorte qu'à tout moment, la mise à niveau interrompt uniquement le trafic passant par un module.

Cisco fournit les dernières images EPLD avec chaque version. En général, ces images sont les mêmes que celles fournies dans les versions précédentes, mais certaines d'entre elles sont parfois mises à jour. Ces mises à jour d'image EPLD ne sont pas obligatoires sauf indication contraire. Lorsque Cisco met à disposition une mise à niveau d'image EPLD, ces notes de version annoncent leur disponibilité et peuvent être téléchargées à partir du site Web de Cisco.

Lorsque de nouvelles images EPLD sont disponibles, les mises à niveau sont toujours recommandées si l'environnement réseau permet une période de maintenance au cours de laquelle un certain niveau d'interruption du trafic est acceptable. En général, les mises à niveau EPLD sont nécessaires lorsque de nouvelles fonctionnalités matérielles sont ajoutées à la suite d'une mise à niveau logicielle.

Plusieurs raisons peuvent également expliquer la nécessité de mettre à niveau le micrologiciel EPLD lorsque vous êtes déjà en mode ACI :

1. Les versions EPLD nécessitaient une mise à niveau avant la conversion de Cisco NX-OS en mode de démarrage ACI et les FPGA/EPLD n'étaient PAS mis à niveau.
2. Leaf/Spine a été mis à niveau manuellement (au lieu d'une mise à niveau de stratégie à partir de l'APIC), ce qui n'inclut pas de mise à niveau EPLD.

Une fois le noeud leaf ou le noeud spine ajouté au fabric, l'EPLD est automatiquement mis à niveau avec toute mise à niveau de stratégie (mise à niveau normale initiée à partir de l'onglet du micrologiciel APIC) lorsqu'une nouvelle version de l'EPLD est disponible.

Solution

Dans les versions plus anciennes de l'ACI, il était nécessaire de rétrograder puis de mettre à niveau le leaf/spine en question, mais depuis la version 11.2(1m), deux scripts shell sont disponibles pour l'utilisateur admin, ce qui simplifie grandement le processus.

fab1-leaf101# /bin/check-fpga.sh FpGaDoWnGrAdE
fab1-leaf101# /usr/sbin/chassis-power-cycle.sh

Le script '/usr/sbin/chassis-power-cycle.sh' réinitialise l'alimentation, par rapport à un 'reload' qui est simplement un redémarrage logiciel. Lors de la mise à niveau de l'EPLD, l'alimentation doit être entièrement coupée pour reprogrammer le micrologiciel sur les cartes de ligne. Si « /usr/sbin/chassis-power-cycle.sh » n'est pas disponible ou ne fonctionne pas, vous devez retirer les câbles d'alimentation pendant au moins 30 secondes, puis les reconnecter pour rétablir l'alimentation.