Fehlerbehebung: ACI Fabric Discovery - Geräteaustausch

Einleitung

In diesem Dokument werden die Schritte zum Verständnis und zur Fehlerbehebung bei Szenarien für den Geräteaustausch in der ACI beschrieben.

Hintergrundinformationen

Das Material aus diesem Dokument wurde aus dem Fehlerbehebung: Cisco Application Centric Infrastructure, Second Edition Buch, insbesondere die Fabric Discovery - Austausch von Geräten Kapitel.

Überblick

Im Zuge der Entwicklung einer ACI-Fabric müssen verschiedene Komponenten ersetzt werden: APICs, Leaf-Switches, Spine-Switches und IPN-Geräte. Die häufigsten Gründe für den Austausch sind RMAs und Hardware-Upgrades. Diese Verfahren sind in den Cisco Installations- und Upgrade-Leitfäden gut dokumentiert. Das aktuelle Handbuch sollte vor dem Austausch gelesen werden. In diesem Abschnitt wird die Funktionsweise der Verfahren unter der Haube genauer untersucht. sowie einige der häufigsten Fehlerbehebungsszenarien durchgehen.

Verfahren und Prüfung

Anmerkung: Ab ACI-Switch Version 5.2(3) können an einen erkannten ACI Fabric Switch angeschlossene NXOS-Switches POAP verwenden, um einen ACI Switch zu konvertieren.

Hardware-Ersatz

Blatt

Ein Leaf vom RMA-Depot, auf dem die NXOS-Software ausgeführt wird, wird zugestellt. Bitte beziehen Sie sich auf den Abschnitt 'Problem: Wird im NXOS-Modus angezeigt, um das Leaf richtig in den ACI-Modus zu konvertieren. Wenn Sie ein Leaf aus einer anderen Fabric oder mit einer vorherigen Konfiguration verwenden, stellen Sie sicher, dass Sie die Befehle "acidiag touch clean" und "reload" verwenden.

Wenn die oben genannten Schritte abgeschlossen sind und der neue Leaf-Switch registriert werden kann, entfernen Sie das zu ersetzende Leaf mithilfe der Option "Vom Controller entfernen" aus der Fabric.

Mit der Option "Vom Controller entfernen" wird der Knoten vollständig aus dem APIC entfernt. Dabei werden die vom APIC zugewiesene Knoten-ID, SN-Zuordnung und TEP-Adresse freigegeben. Diese Prozesse sind beim Ersetzen eines Switch-Knotens erforderlich. Die Option "Stilllegen" wird nur verwendet, wenn davon ausgegangen wird, dass derselbe Knoten mit derselben Knoten-ID und -SN wieder der Fabric beitritt.

Wenn der zu ersetzende Leaf-Switch nicht mehr auf der Seite Fabric-Mitgliedschaft angezeigt wird, kann der neue Leaf über die Spine-Schnittstellen mit dem Fabric verbunden werden. Sobald das Leaf vom APIC erkannt wurde, wird es im Fabric-Bestand angezeigt und kann registriert werden. Wenn das zu ersetzende Gerät seine Knoten-ID noch nicht freigegeben hat und ein neuer Switch mit derselben Knoten-ID registriert ist, wird ein Fehler ausgelöst, der darauf hinweist, dass die ID bereits einem anderen Leaf-Knoten zugeordnet ist. Der Fehler sollte nach einiger Zeit behoben sein. Wenn der neue Knoten nicht im Untermenü "Fabric-Mitgliedschaft" angezeigt wird, liegt möglicherweise ein Verkabelungsproblem vor. Überprüfen Sie dies, indem Sie die LLDP-Nachbarn mit dem Befehl "show lldp neighbors detail" auf den Spine-Switches anzeigen, die mit dem neu angeschlossenen Leaf-Switch verbunden sind. Weitere Informationen zum Fabric Discovery-Prozess finden Sie im Kapitel "Initial Fabric Setup".

Wenn das Infra-VLAN geändert wird, müssen alle Leaf-Knoten gleichzeitig neu gestartet werden. Wenn nicht alle Leaf-Switches gleichzeitig bereinigt werden, wird ein neu geladener Switch online geschaltet und erhält das alte Infra-VLAN über LLDP von einem noch nicht bereinigten Leaf, und das neu geladene Leaf kann sich nicht beim APIC registrieren. Weitere Informationen finden Sie im Kapitel "Erste Fabric-Konfiguration".

Aufgrund von Plattformeinschränkungen können VPC-Paare nicht aus Leaf-Switches der 1. und 2. Generation oder höher bestehen. Zum Zeitpunkt der Dokumenterstellung kann jedoch jedes Leaf der 2. Generation oder höher mit jedem anderen Leaf der 2. Generation oder höher kombiniert werden.

Wirbelsäule

Wie ein Leaf kann es je nach HW des Spine (z. B. modularer Spine) im NXOS-Modus ankommen. Gehen Sie folgendermaßen vor: Kommt im NXOS-Modus" unter den Szenarien, um die Umwandlung durchzuführen.

Beim Austausch eines Spine-Switches muss der Benutzer die Funktion des BGP-Routen-Reflektors in Betracht ziehen. Als Best Practice müssen mindestens zwei Spine-Switches als BGP-Routen-Reflektoren für eine Layer 3-Cisco ACI-Fabric konfiguriert sein. Diese Konfiguration befindet sich unter "System > System Settings > BGP Route Reflectors" unter "Route Reflector Nodes". Wenn Sie einen Spine-Switch ersetzen oder entfernen, stellen Sie sicher, dass die entsprechenden Konfigurationsänderungen vorgenommen wurden, um einen aktiven Routen-Reflektor beizubehalten, und stellen Sie sicher, dass nach Abschluss der Änderungen mindestens zwei aktive Routen-Reflektoren vorhanden sind.

Weitere Informationen zu den BGP-Routen-Reflektoren finden Sie im Abschnitt "Pod-Richtlinien - BGP RR / Datum und Uhrzeit / SNMP" im Kapitel "Management und Core-Services".

APIC

Der wichtigste Gesichtspunkt beim APIC-Austausch ist der Zustand des vorhandenen APIC-Clusters. Vor dem Austausch müssen alle APICs im Cluster als voll passend gemeldet werden. In Version 4.2 wurde ein zusätzliches Tool eingeführt, um die Integrität des APIC-Clusters über die CLI zu überprüfen:

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!

Achten Sie beim Austauschen eines APIC darauf, die Variablen für die Ersteinrichtung des zu ersetzenden APIC zu berücksichtigen, bevor Sie den APIC außer Betrieb nehmen.

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

Bereiten Sie den neuen APIC mit der richtigen Softwareversion vor, und geben Sie die anfänglichen Setup-Werte, auf die zuvor verwiesen wurde, erneut ein. Wenn die Ersteinrichtung abgeschlossen und der APIC vollständig gestartet wurde, setzen Sie ihn über die Benutzeroberfläche eines der anderen APICs im Cluster wieder in die Fabric ein.

Austausch von IPN-Geräten

In einer Multi-Pod-Umgebung kann es erforderlich sein, eines der für das IPN (Inter-Pod-Netzwerk) verwendeten Geräte zu ersetzen. Vor dem Austausch muss im IPN-Netzwerk die bidirektionale PIM-Rendezvous-Point-Redundanz in Form von Phantom-RPs konfiguriert werden. Wenn Phantom-RPs vorhanden wären und der ersetzte Knoten der RP wäre, gäbe es eine PIM-Konvergenz, und es würde für den gesamten über das IPN gesendeten BUM-Datenverkehr ein Paketverlust auftreten.

Weitere Informationen zur Konfiguration des Phantom-RPs finden Sie im Kapitel "RP-Konfiguration" im Abschnitt "Multi-Pod-Erkennung".

Reinigen Sie das Neuladen des APIC/Leaf/Spine.

In bestimmten Szenarien besteht die beste Option zum Wiederherstellen eines Leaf/Spine, das nicht in die Fabric aufgenommen wird, darin, das Gerät neu zu laden.

Es wird nicht empfohlen, ein Gerät neu zu laden, das auf ein Upgrade wartet. Das saubere Neuladen eines Geräts kann längere Zeit in Anspruch nehmen.

Der Befehl "acidiag touch" hat zwei Optionen: "clean" und "setup". Die Clean-Option entfernt alle Richtliniendaten und behält die APIC-Netzwerkkonfiguration bei (z. B. Fabric-Name, IP-Adresse, Anmeldung). Mit der Setup-Option werden sowohl Richtliniendaten als auch die APIC-Netzwerkkonfiguration entfernt. Die Setup-Option wird am häufigsten verwendet, wenn Geräte über PODs verschoben werden, da die Pod-ID geändert werden muss. Normalerweise muss auch das Managementnetzwerk aktualisiert werden.

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

Leaf/Spine

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

Der 'acidiag touch clean' Befehl funktioniert, indem eine versteckte Datei auf dem Blatt in /mnt/pss namens .clean abgelegt wird. Beim Booten des Leaf wird ein Shell-Skript ausgeführt, das überprüft, ob eine .clean-Datei vorhanden ist. Falls die .clean-Datei unter /mnt/pss vorhanden ist, wird die Richtlinienkonfiguration gelöscht und die Konfiguration erneut vom APIC heruntergeladen. Wenn dieser Befehl eingegeben wird und der Knoten nicht neu geladen wird, ist die Datei immer noch vorhanden, und die Richtlinie wird auch beim nächsten Neuladen gelöscht, unabhängig davon, wie viel Zeit seit der Eingabe der Bereinigung vergangen ist.

Fehlerbehebungsszenarien

Problem: Ankunft im NXOS-Modus

Verifizierung

Wenn ein Switch über RMA versendet wird, kann er manchmal mit NXOS-Software geliefert werden, die noch nicht über den POAP-Prozess (Power On Auto Provisioning) konfiguriert wurde. Wenn der Benutzer sich in dieses Gerät einwählt, wird ihm die folgende Meldung angezeigt:

Auto-Provisioning abbrechen und mit normaler Einrichtung fortfahren? (Ja/Nein)

Wenn das Gerät den POAP bereits durchlaufen hat, ist die einfachste Möglichkeit, festzustellen, ob auf einem Leaf ein eigenständiger NXOS-Code ausgeführt wird, die Suche nach der Zeile "NXOS image file" in der Ausgabe von "show version". Wenn eine solche Ausgabe vorhanden ist, führt das Leaf eigenständigen Code aus und muss in den ACI-Modus konvertiert werden. Das Vorhandensein von Kickstart- und System-Images kann überprüft werden und ist nur auf einem Leaf vorhanden, auf dem ein ACI-Image ausgeführt wird. Hierzu wird das Image selbst betrachtet, d. h. n9000 auf der Standalone-Lösung und aci-n9000 auf der ACI.

Standalone NXOS

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]

Lösung

Wenn der Switch mit NXOS-Code ausgeliefert wurde, muss er in den ACI-Modus konvertiert werden. Im Lieferumfang des Switches sollten sowohl das NX-OS als auch das ACI-Image im Bootflash enthalten sein, was jedoch nicht immer der Fall ist. Das ACI-Image beginnt mit "aci-n9000". Wenn das ACI-Image nicht vorhanden ist, muss es manuell in den Bootflash geladen werden. Dies kann über den USB-Anschluss (lokaler Zugriff erforderlich) oder über SCP direkt vom APIC erfolgen (vorausgesetzt beide Geräte sind über ein Managementnetzwerk verbunden). So kopieren Sie das Bild über die SCP:

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

Der Leaf muss dann so konfiguriert werden, dass das NXOS-Image nicht gebootet, die Konfiguration nicht gespeichert und die Boot-Anweisungen nicht in ACI geändert werden.

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

Problem: Leaf/Spine EPLD/FPGA nicht korrekt, F1582

Verifizierung

Die folgenden Fehler sind in den Fehlern für den Nexus 9000 ACI-Switch zu sehen.

F1582 FPGA-Versionskonflikt festgestellt. Aktuelle Version:0x(z) Erwartete Version:0x(y)

Suchen Sie in der APIC-CLI nach allen Instanzen des Fehlers F1582:

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

EPLD-Notizen

Die Cisco Nexus ACI-Modus-Switches der Serie 9000 enthalten mehrere programmierbare logische Geräte (Programmable Logical Devices, PLDs), die Hardwarefunktionen in allen Modulen bereitstellen. Cisco bietet EPLD-Image-Upgrades (Electronic Programmable Logic Device), um die Hardwarefunktionalität zu verbessern oder bekannte Probleme zu beheben. PLDs umfassen EPLDs (Electronic Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays) und CPLDs (Complex Programmable Logic Devices), jedoch keine ASICs.

Der Begriff EPLD wird sowohl für FPGA als auch für CPLD verwendet.

Der Vorteil von EPLDs für einige Modulfunktionen besteht darin, dass diese Funktionen aktualisiert werden müssen, indem die Software-Images aktualisiert werden, anstatt die Hardware zu ersetzen.

Durch EPLD-Image-Upgrades für ein E/A-Modul wird der Datenverkehr durch das Modul unterbrochen, da das Modul während des Upgrades kurz heruntergefahren werden muss. In einem modularen Gehäuse führt das System EPLD-Upgrades für jeweils ein Modul durch, sodass zu jedem Zeitpunkt nur der Datenverkehr über ein Modul unterbrochen wird.

Cisco stellt für jede Version die neuesten EPLD-Images zur Verfügung. Normalerweise sind diese Images die gleichen wie in früheren Versionen, aber gelegentlich werden einige dieser Images aktualisiert. Diese EPLD-Image-Updates sind nicht obligatorisch, sofern nicht anders angegeben. Wenn Cisco ein EPLD-Image-Upgrade verfügbar macht, werden in den Versionshinweisen die Verfügbarkeit dieser Images bekannt gegeben, die dann von der Cisco Website heruntergeladen werden können.

Wenn neue EPLD-Images verfügbar sind, werden Upgrades immer dann empfohlen, wenn die Netzwerkumgebung einen Wartungszeitraum zulässt, in dem ein gewisses Maß an Datenverkehrsunterbrechung akzeptabel ist. Generell sind EPLD-Upgrades erforderlich, wenn infolge eines Software-Upgrades neue Hardwarefunktionen hinzugefügt werden.

Es kann auch verschiedene Gründe geben, warum die EPLD-Firmware aktualisiert werden muss, während sie sich bereits im ACI-Modus befindet:

1. Die EPLD-Versionen mussten vor der Umwandlung von Cisco NX-OS in den ACI-Startmodus aktualisiert werden, und die FPGA/EPLDs wurden NICHT aktualisiert.
2. Leaf/Spine wurde manuell aktualisiert (anstelle eines Richtlinien-Upgrades vom APIC), das kein EPLD-Upgrade beinhaltet.

Sobald Leaf oder Spine zur Fabric hinzugefügt wurden, wird das EPLD automatisch mit allen Richtlinien-Upgrades aktualisiert (normale Upgrades werden über die APIC-Firmware-Registerkarte initiiert), wenn eine neue Version von EPLD verfügbar ist.

Lösung

In älteren Versionen der ACI war es erforderlich, das betreffende Leaf/Spine herabzustufen und anschließend zu aktualisieren. Ab 11.2(1m) stehen dem Administrator jedoch zwei Shell-Skripts zur Verfügung, die den Prozess erheblich vereinfachen.

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

Das '/usr/sbin/chassis-power-cycle.sh'-Skript setzt die Stromversorgung zurück, im Gegensatz zu einem 'reload', bei dem es sich einfach um einen Software-Neustart handelt. Beim Upgrade von EPLD muss der Strom vollständig abgeschaltet werden, um die Firmware auf den Line Cards neu zu programmieren. Wenn '/usr/sbin/chassis-power-cycle.sh' nicht verfügbar ist oder nicht funktioniert, müssen die Netzkabel für mindestens 30 Sekunden entfernt und dann wieder angeschlossen werden, um den Strom wieder herzustellen.