Problemen met ACI Fabric Discovery oplossen - Apparaatvervanging

Inleiding

In dit document worden stappen beschreven voor het begrijpen en oplossen van problemen met scenario's voor vervanging van apparaten in ACI.

Achtergrondinformatie

Het materiaal uit dit document is afkomstig uit het boek Problemen oplossen Cisco Application Centric Infrastructure, Second Edition, met name het hoofdstuk Fabric Discovery - Device Replacement.

Overzicht

Tijdens de ontwikkeling van een ACI-stof zal het nodig zijn om verschillende onderdelen te vervangen, waaronder: APIC's, switches van bladeren, switches van de wervelkolom en IPN-apparaten. De meest voorkomende redenen voor vervanging zijn RMA's en hardware-upgrades. Deze procedures zijn goed gedocumenteerd in de installatie-/upgradehandleidingen van Cisco en de meest recente handleiding moet worden gelezen voordat deze wordt vervangen. Dit gedeelte bevat een dieper onderzoek naar hoe de procedures onder de motorkap werken; evenals een wandeling door verschillende van de meest voorkomende scenario's voor probleemoplossing.

Procedures en verificatie

Opmerking: vanaf ACI Switch versie 5.2(3) kunnen NXOS-switches die zijn aangesloten op een ontdekte ACI Fabric switch POAP gebruiken om te converteren naar een ACI-Switch.

Hardwarevervanging

blad

Een blad van het RMA-depot zal aankomen met NXOS-software. Raadpleeg het onderstaande gedeelte met de titel 'Probleem: arriveert in NXOS-modus' om het blad correct om te zetten naar ACI-modus. Als u een blad van een andere stof of met een eerdere configuratie gebruikt, moet u de opdrachten 'zure aanraking reinigen' en 'opnieuw laden' gebruiken.

Nadat de bovenstaande stappen zijn doorlopen en de nieuwe bladzijde klaar is voor switch, verwijdert u het te vervangen blad van de stof via de optie 'Verwijderen van controller' (of de optie 'Uit bedrijf nemen en verwijderen' voor 6.0(1) of nieuwere versies).

De optie 'Verwijderen van controller' verwijdert de node volledig uit de APIC, waardoor de node-ID, de SN-associatie en het TEP-adres vrijkomen dat door de APIC is toegewezen. Deze processen zijn gewenst bij het vervangen van een switch node. De optie 'Uit bedrijf nemen' wordt alleen gebruikt wanneer de verwachting is dat dezelfde node zich opnieuw bij de fabric aansluit met dezelfde node-ID en SN.

Wanneer de te vervangen switch niet meer te zien is op de pagina Fabric Membership, kan het nieuwe blad via de interface van de ruggengraat met de stof worden verbonden. Zodra het blad is ontdekt door de APIC, zal het verschijnen in de Fabric Inventory en klaar zijn voor registratie. Als het te vervangen toestel zijn node-ID nog niet heeft vrijgegeven en een nieuwe switch is geregistreerd met dezelfde node-ID, wordt een fout gegenereerd die verwijst naar het feit dat de id al is gekoppeld aan een andere leaf-node. De fout zou na enige tijd moeten verdwijnen. Als het nieuwe knooppunt niet wordt weergegeven in het submenu Fabric Membership, kan er een kabelprobleem zijn; dit kan worden geverifieerd door de LLDP-buren te bekijken via de opdracht 'show lldp neighbors detail' op de switches van de wervelkolom die verbinding maken met de nieuw aangesloten switch. Raadpleeg het hoofdstuk "Eerste configuratie van fabric" voor meer informatie over het Fabric Discovery-proces.

Als het infra-VLAN wordt gewijzigd, moeten alle bladknooppunten tegelijkertijd schoon en opnieuw worden opgestart. Als niet alle switches tegelijkertijd worden schoongemaakt, komt een opgeruimde herladen switch online en ontvangt het oude infra-VLAN via LLDP van een nog niet schoongemaakt blad en kan het opgeruimde herladen blad zich niet registreren bij de APIC. Zie het hoofdstuk "Initiële configuratie" voor meer informatie.

Vanwege platformbeperkingen kunnen VPC-paren geen mix zijn van Gen1- en Gen2- of hogere switches. Op het moment van schrijven kan elk Gen2-blad en hoger zich echter mengen met elk ander Gen2-blad of hoger.

ruggegraat

Als een blad, afhankelijk van het HW van de wervelkolom (zoals modulaire wervelkolom) kan het in de NXOS-modus aankomen. Gebruik de procedure "Probleem: arriveert in NXOS-modus" onder de scenario's om de conversie uit te voeren.

Bij het vervangen van een wervelkolom switch, moet de gebruiker rekening houden met de BGP Route Reflector functionaliteit. Als beste praktijk moeten er ten minste twee switches van de wervelkolom zijn geconfigureerd als BGP-routereflectoren voor een Layer 3 Cisco ACI-fabric. Deze configuratie bevindt zich bij 'Systeem > Systeeminstellingen > BGP Route Reflectors' onder Route Reflector Nodes. Zorg er bij het vervangen of verwijderen van een switch van de wervelkolom voor dat de juiste configuratiewijzigingen worden aangebracht om één actieve routereflector te behouden en zorg ervoor dat er ten minste twee actieve routereflectoren zijn nadat de wijzigingen zijn voltooid.

Raadpleeg de sectie "Pod Policies — BGP RR / Date&Time / SNMP" in het hoofdstuk "Management and core services" voor meer informatie over de BGP Route Reflectors.

APIC

De belangrijkste overweging bij het uitvoeren van een APIC-vervanging is de gezondheid van het bestaande APIC-cluster. Voorafgaand aan de vervanging moeten alle APIC's in het cluster als volledig geschikt worden gerapporteerd. In 4.2 werd een extra instrument ingevoerd om de gezondheid van het APIC-cluster te verifiëren via CLI:

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!

Let bij het vervangen van een APIC op de initiële configuratievariabelen van de APIC die moet worden vervangen voordat u de APIC uitschakelt.

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

Bereid de nieuwe APIC voor met de juiste softwareversie en voer de eerder genoemde initiële installatiewaarden opnieuw in. Wanneer de eerste configuratie is voltooid en de APIC volledig is opgestart, stelt u de verbinding opnieuw in vanuit de gebruikersinterface van een van de andere APIC's in het cluster.

IPN-hulpmiddelvervanging

In een Multi-Pod-omgeving kan het nodig zijn om een van de apparaten te vervangen die worden gebruikt voor het IPN (Inter-Pod Network). Voorafgaand aan de vervanging moet het IPN-netwerk PIM Bidirectional Rendezvous Point Redundancy hebben geconfigureerd in de vorm van Phantom RP's. Zonder Phantom RP's op zijn plaats, als het knooppunt werd vervangen door de RP, zou er een PIM-convergentie zijn en zou pakketverlies worden gezien voor al het BUM-verkeer dat over de IPN wordt verzonden.

Raadpleeg "RP-configuratie" in het hoofdstuk "Multi-Pod Discovery" voor meer informatie over het configureren van Phantom RP.

Opnieuw laden van APIC/blad/wervelkolom reinigen

In bepaalde scenario's is de beste optie voor het herstellen van een blad / ruggengraat dat zich niet bij de stof aansluit, het opnieuw laden van het apparaat.

Het wordt niet aanbevolen om een schone herlaadbeurt uit te voeren op een apparaat dat wacht tot het aan de beurt is om te upgraden. Het opschonen en opnieuw laden van elk apparaat kan een langere periode in beslag nemen.

De opdracht 'zure aanraking' heeft twee opties: opschonen en instellen. De optie Opschonen verwijdert alle beleidsgegevens met behoud van de APIC-netwerkconfiguratie (zoals fabrikantnaam, IP-adres, aanmeldingsgegevens). De optie Setup verwijdert zowel beleidsgegevens als de APIC-netwerkconfiguratie. De installatieoptie wordt het meest gebruikt bij het verplaatsen van apparaten over Pods, omdat de Pod ID moet worden gewijzigd en normaal gesproken het beheernetwerk ook moet worden bijgewerkt.

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

Blad/ruggengraat

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

De opdracht 'acidiag touch clean' werkt door een verborgen bestand op het blad in /mnt/pss te plaatsen met de naam .clean. Wanneer het blad wordt opgestart, wordt een shell-script uitgevoerd dat controleert of het .clean-bestand aanwezig is. Als het .clean-bestand bestaat onder /mnt/pss, wordt de beleidsconfiguratie gewist en wordt de configuratie opnieuw gedownload van de APIC. Als deze opdracht wordt ingevoerd en de node niet opnieuw wordt geladen, is het bestand nog steeds aanwezig en wordt het beleid nog steeds gewist bij de volgende herlading, ongeacht hoeveel tijd is verstreken sinds het aanraken schoon is ingevoerd.

Scenario's voor probleemoplossing

Probleem: komt aan in NXOS-modus

Verificatie

Soms wanneer een switch via RMA wordt verzonden, kan deze aankomen met NXOS-software die nog niet is geconfigureerd via het Power On Auto Provisioning (POAP) -proces. Wanneer de gebruiker consoles in dit apparaat zullen ze een vorm van het volgende bericht te zien:

Auto Provisioning afbreken en doorgaan met de normale installatie? (ja/nee)

Als het apparaat al door POAP is gegaan, is de eenvoudigste manier om te bepalen of een blad zelfstandige NXOS-code uitvoert, om te zoeken naar de regel 'NXOS-beeldbestand' in de uitvoer 'show version'. Als een dergelijke uitvoer aanwezig is, draait het blad op zichzelf staande code en moet het worden geconverteerd naar de ACI-modus. De aanwezigheid van Kickstart en systeemafbeeldingen kan worden geverifieerd en zal alleen aanwezig zijn op een blad met een ACI-afbeelding, door naar het beeld zelf te kijken, dat n9000 op standalone en aci-n9000 op ACI zal zijn.

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]

Oplossing

Als de switch is verzonden met NXOS-code, moet deze worden geconverteerd naar de ACI-modus. De switch moet worden geleverd met zowel de NXOS- als de ACI-afbeelding in de bootflash, hoewel dit niet altijd het geval is. Het ACI-beeld begint met 'aci-n9000'. Als de ACI-afbeelding niet aanwezig is, moet deze handmatig op de bootflash worden geladen. Dit kan via de USB-aansluiting (lokale toegang vereist) of via SCP rechtstreeks vanuit de APIC (ervan uitgaande dat beide apparaten via een beheernetwerk zijn verbonden). Hier zijn de instructies om de afbeelding via SCP te kopiëren:

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

Het blad moet dan worden geconfigureerd om het NXOS-image niet op te starten, de configuratie op te slaan en de opstartinstructies in ACI te wijzigen.

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

Probleem: Leaf/Spine EPLD/FPGA niet correct, F1582

Verificatie

De volgende fouten zijn te zien in de fouten voor de Nexus 9000 ACI-switch.

F1582 FPGA-versie mismatch gedetecteerd. Uitvoerende versie: 0x(z) Verwachte versie: 0x(y)

Zoek in de APIC CLI naar alle instanties van Fout F1582:

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

EPLD-notities

De Cisco Nexus 9000 Series ACI-mode switches bevatten verschillende programmeerbare logische devices (PLD's) die hardwarefunctionaliteiten bieden in alle modules. Cisco biedt upgrades voor images voor elektronische programmeerbare logische apparaten (EPLD's) om de hardwarefunctionaliteit te verbeteren of bekende problemen op te lossen. PLD's omvatten elektronische programmeerbare logische apparaten (EPLD's), field programmeerbare gate-arrays (FPGA's) en complexe programmeerbare logische apparaten (CPLD's), maar ze bevatten geen ASIC's.

De term EPLD wordt gebruikt voor zowel FPGA als CPLD.

Het voordeel van het hebben van EPLD's voor sommige modulefuncties is dat wanneer die functies moeten worden bijgewerkt, u gewoon hun software-images moet upgraden in plaats van hun hardware te vervangen.

Upgrades van EPLD-images voor een I/O-module verstoren het verkeer dat door de module gaat, omdat de module tijdens de upgrade kort moet worden uitgeschakeld. In een modulair chassis voert het systeem EPLD-upgrades uit op één module tegelijk, dus op elk moment verstoort de upgrade alleen het verkeer dat door één module gaat.

Cisco levert bij elke release de nieuwste EPLD-images. Meestal zijn deze afbeeldingen hetzelfde als in eerdere releases, maar soms worden sommige van deze afbeeldingen bijgewerkt. Deze EPLD-image-updates zijn niet verplicht, tenzij anders aangegeven. Wanneer Cisco een EPLD-image-upgrade beschikbaar stelt, kondigen deze release-notities hun beschikbaarheid aan en kunnen ze worden gedownload van de Cisco-website.

Wanneer nieuwe EPLD-images beschikbaar zijn, worden de upgrades altijd aanbevolen als de netwerkomgeving een onderhoudsperiode toestaat waarin een zekere mate van verkeersverstoring aanvaardbaar is. Over het algemeen zullen EPLD-upgrades nodig zijn wanneer nieuwe hardwarefunctionaliteit wordt toegevoegd als gevolg van een software-upgrade.

Er kunnen ook verschillende redenen zijn voor de noodzaak om de EPLD-firmware te upgraden terwijl deze zich al in de ACI-modus bevindt:

1. Voor EPLD-versies was een upgrade vereist voorafgaand aan een conversie van Cisco NX-OS naar ACI Boot Mode en de FPGA/EPLD's werden NIET bijgewerkt.
2. Leaf/Spine werd handmatig bijgewerkt (in plaats van een beleidsupgrade van de APIC), die geen EPLD-upgrade bevat.

Zodra het blad of de ruggengraat aan de stof is toegevoegd, wordt de EPLD automatisch bijgewerkt met elke beleidsupgrade (normale upgrade gestart vanaf het tabblad APIC-firmware) waar een nieuwe versie van EPLD beschikbaar is.

Oplossing

In oudere versies van ACI was het noodzakelijk om het betreffende blad / de ruggengraat te downgraden en vervolgens te upgraden, maar vanaf 11.2 (1m) zijn er twee shell-scripts beschikbaar voor de admin-gebruiker die het proces aanzienlijk vereenvoudigen.

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

Het script '/usr/sbin/chassis-power-cycle.sh' reset hard de stroom, in vergelijking met een 'reload' die gewoon een software-herstart is. Bij het upgraden van EPLD moet de stroom volledig worden verwijderd om de firmware op de lijnkaarten opnieuw te programmeren. Als '/usr/sbin/chassis-power-cycle.sh' niet beschikbaar is of niet werkt, moeten de stroomkabels ten minste 30 seconden worden verwijderd en vervolgens opnieuw worden aangesloten om de stroom te herstellen.