Inhalt

Einleitung

Hintergrundinformationen

Fabric-Erkennungs-Workflow

Check01 — Systemstatus

Check02 - DHCP-Status

Check03 - AV-Details

Check04 - IP-Erreichbarkeit zum APIC

Check05 - Infra. VLAN

Check06 - LLDP-Adjacency

Check07 — Switch-Version

Check08 — FPGA/EPLD/BIOS nicht synchronisiert

Check09 - SSL-Prüfung

Check10 — Richtlinie herunterladen

Check11 - Zeit

Check12 — Modul, PSU, Lüfterprüfung

Beispiele für fehlerhafte Szenarien

Szenario 1 - Das erste Leaf wird in der Fabric-Mitgliedschaft nicht angezeigt.

Szenario 2 - Andere APICs treten dem Cluster nicht bei

Szenario 3 - Spine wird in der Fabric-Mitgliedschaft nicht angezeigt

4. Szenario: Nach der anfänglichen Fabric-Erkennung wechselt der Cluster zwischen voll betriebsfähig und reduziert ab

Einleitung

In diesem Dokument werden die Schritte zum Verständnis und zur Fehlerbehebung des anfänglichen Fabric-Erkennungsprozesses beschrieben, einschließlich Beispielszenarien.

Hintergrundinformationen

Das Material aus diesem Dokument wurde aus dem Fehlerbehebung: Cisco Application Centric Infrastructure, Second Edition Buch, insbesondere das Fabric Discovery - Ersteinrichtung der Fabric Kapitel.

Fabric-Erkennungs-Workflow

Der Erkennungsprozess der ACI-Fabric folgt einer bestimmten Ereignissequenz. Die grundlegenden Schritte sind wie folgt:

1. Stellen Sie eine Verbindung zur KVM-Konsole des ersten APIC her, und vervollständigen Sie das Einrichtungsskript, indem Sie Werte wie Fabric-Name, APIC-Clustergröße und Tunnel-Endpunkt (TEP)-Adresspool eingeben.

2. Nach Abschluss dieses Vorgangs sendet der APIC1 LLDP über seine Fabric-Ports. Die LLDP-Pakete enthalten spezielle TLVs mit Informationen wie dem Infra-VLAN und seiner Rolle als APIC (auch Controller genannt).

3. Beim Empfang dieser LLDP-Pakete vom APIC1 programmiert das Leaf das Infra-VLAN auf allen Ports, an denen ein APIC erkannt wird.

4. Der Leaf beginnt mit dem Senden der DHCP-Erkennung im jetzt bekannten infra-VLAN.

5. Der Benutzer meldet sich über HTTPS bei der OOB-IP von APIC1 an und registriert den ersten Leaf-Knoten im Untermenü "Fabric-Mitgliedschaft".

6. Nachdem dem Leaf eine Knoten-ID zugewiesen wurde, antwortet APIC1 mit einer IP-Adresse aus dem konfigurierten TEP-Adresspool, und der DHCP-Prozess ist abgeschlossen.

7. Der registrierte Leaf leitet die DHCP-Erkennung von anderen direkt verbundenen Spines, die über LLDP erkannt wurden, an den APIC1 weiter.

8. Der Benutzer sieht diese dynamisch erkannten Spines im Untermenü "Fabric-Mitgliedschaft" und kann sie registrieren.

9. Nach der Registrierung der Spines antwortet der APIC1 mit einer IP-Adresse aus dem TEP-Pool, und DHCP wird für diese Knoten abgeschlossen.

10. Das Spines-Relay, das DHCP von allen anderen Knoten von pod1 erkennt. (Voraussetzung hierfür ist ein Full-Mesh zwischen Spines und Leaf-Switches, wie empfohlen und in der typischen Architektur).

11. Nach der Registrierung der mit den anderen APICs verbundenen Leaf-Knoten kann der APIC-Cluster über TCP-Kommunikation untereinander aufgebaut werden. Schließen Sie den Einrichtungsdialog für APIC2 und APIC3 ab.

12. Bestätigen Sie, dass alle APICs einen Cluster gebildet haben und voll intakt sind. In diesem Fall ist die Fabric-Ermittlung abgeschlossen.

Ab Version 4.2 steht ein neuer CLI-Befehl für Fabric-Knoten zur Verfügung, der die Diagnose häufiger Erkennungsprobleme unterstützt. In den folgenden Abschnitten werden die durchgeführten Prüfungen beschrieben und zusätzliche Validierungsbefehle zur Unterstützung bei der Fehlerbehebung bereitgestellt.

leaf101# show discoveryissues

Checking the platform type................LEAF!

Check01 - System state - in-service [ok]

Check02 - DHCP status [ok]

TEP IP: 10.0.72.67 Node Id: 101 Name: leaf101

Check03 - AV details check [ok]

Check04 - IP rechability to apic [ok]

Ping from switch to 10.0.0.1 passed

Check05 - infra VLAN received [ok]

infra vLAN:3967

Check06 - LLDP Adjacency [ok]

Found adjacency with SPINE

Found adjacency with APIC

Check07 - Switch version [ok]

version: n9000-14.2(1j) and apic version: 4.2(1j)

Check08 - FPGA/BIOS out of sync test [ok]

Check09 - SSL check [check]

SSL certificate details are valid

Check10 - Downloading policies [ok]

Check11 - Checking time [ok]

2019-09-11 07:15:53

Check12 - Checking modules, power and fans [ok]

Check01 — Systemstatus

Wenn dem Leaf eine Knoten-ID zugewiesen und das Leaf für die Fabric registriert wurde, beginnt es, den Bootstrap herunterzuladen, und wechselt dann in den In-Service-Status.

Check01 - System state - out-of-service [FAIL]

Check01 - System state - downloading-boot-script [FAIL]

Um den aktuellen Status des Leaf zu überprüfen, kann der Benutzer moquery -c topSystem ausführen

leaf101# moquery -c topSystem

Total Objects shown: 1

# top.System

address                  : 10.0.72.67

bootstrapState           : done

...

serial                   : FDO20160TPS

serverType               : unspecified

siteId                   : 1

state                    : in-service

status                   :

systemUpTime             : 00:18:17:41.000

tepPool                  : 10.0.0.0/16

unicastXrEpLearnDisable  : no

version                  : n9000-14.2(1j)

virtualMode              : no

Check02 - DHCP-Status

Check02 - DHCP status [FAIL]

ERROR: node Id not configured

ERROR: Ip not assigned by dhcp server

ERROR: Address assigner's IP not populated

TEP IP: unknown Node Id: unknown Name: unknown

Der Leaf muss eine TEP-Adresse über DHCP vom APIC1 empfangen und dann eine IP-Verbindung mit den anderen APICs herstellen. Die physische TEP (PTEP) des Leaf wird Loopback0 zugewiesen. Wenn keine Adresse zugewiesen ist, kann der Benutzer überprüfen, ob das Leaf eine DHCP-Erkennung mit dem Dienstprogramm tpcdump sendet. Beachten Sie, dass wir hierfür die Schnittstelle kpm_inb verwenden, mit der Sie den gesamten Netzwerkverkehr der CPU-In-Band-Kontrollebene anzeigen können.

(none)# tcpdump -ni kpm_inb port 67 or 68

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on kpm_inb, link-type EN10MB (Ethernet), capture size 65535 bytes

16:40:11.041148 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from a0:36:9f:c7:a1:0c, length 300

^C

1 packets captured

1 packets received by filter

0 packets dropped by kernel

Der Benutzer kann auch überprüfen, ob dhcpd auf dem APIC ausgeführt wird und auf der Subschnittstelle bond0 abhört. Die Bond-Schnittstelle stellt die Fabric-seitigen APIC-Ports dar. Wir verwenden das Format bond0.<infra VLAN>.

apic1# ps aux | grep dhcp

root     18929  1.3  0.2 818552 288504 ?       Ssl  Sep26  87:19 /mgmt//bin/dhcpd.bin -f -4 -cf /data//dhcp/dhcpd.conf -lf /data//dhcp/dhcpd.lease -pf /var/run//dhcpd.pid --no-pid bond0.3967

admin   22770  0.0  0.0   9108   868 pts/0    S+   19:42   0:00 grep dhcp

Check03 - AV-Details

Check03 - AV details check [ok]

Das Leaf prüft, ob die IP-Adresse des registrierten APIC in einem gültigen Bereich für den TEP-Pool liegt. Wenn noch keine APIC-Informationen aufgezeichnet wurden, wird diese Prüfung erfolgreich durchgeführt. Der Benutzer kann die aktuellen APIC-Informationen aus der Perspektive des Leaf-Knotens mithilfe des Befehls "acidiag avread" sehen. Beachten Sie im Beispiel unten, dass die Leaf-/Spine-Eingabeaufforderung (none)# anzeigt, dass das Leaf-/Spine-Element noch nicht Teil des Fabric ist.

(none)# acidiag avread

Cluster of 0 lm(t):0(zeroTime) appliances (out of targeted 0 lm(t):0(zeroTime)) with FABRIC_DOMAIN name=Undefined Fabric Domain Name set to version= lm(t):0(zeroTime); discoveryMode=PERMISSIVE lm(t):0(zeroTime); drrMode=OFF lm(t):0(zeroTime)

---------------------------------------------

clusterTime=<diff=0 common=2019-10-01T18:51:50.315+00:00 local=2019-10-01T18:51:50.315+00:00 pF=<displForm=1 offsSt=0 offsVlu=0 lm(t):0(zeroTime)>>

---------------------------------------------

leaf101# acidiag avread

Cluster of 3 lm(t):0(2019-09-30T18:45:10.320-04:00) appliances (out of targeted 3 lm(t):0(2019-10-01T14:52:55.217-04:00)) with FABRIC_DOMAIN name=ACIFabric1 set to version=apic-4.2(1j) lm(t):0(2019-10-01T14:52:55.217-04:00); discoveryMode=PERMISSIVE lm(t):0(1969-12-31T20:00:00.003-04:00); drrMode=OFF lm(t):0(1969-12-31T20:00:00.003-04:00); kafkaMode=OFF lm(t):0(1969-12-31T20:00:00.003-04:00)

appliance id=1  address=10.0.0.1 lm(t):2(2019-09-27T17:32:08.669-04:00) tep address=10.0.0.0/16 lm(t):1(2019-07-09T19:41:24.672-04:00) routable address=192.168.1.1 lm(t):2(2019-09-30T18:37:48.916-04:00) oob address=0.0.0.0 lm(t):0(zeroTime) version=4.2(1j) lm(t):1(2019-09-30T18:37:49.011-04:00) chassisId=c67d1076-a2a2-11e9-874e-a390922be712 lm(t):1(2019-09-30T18:37:49.011-04:00) capabilities=0X3EEFFFFFFFFF--0X2020--0X1 lm(t):1(2019-09-26T09:32:20.747-04:00) rK=(stable,absent,0) lm(t):0(zeroTime) aK=(stable,absent,0) lm(t):0(zeroTime) oobrK=(stable,absent,0) lm(t):0(zeroTime) oobaK=(stable,absent,0) lm(t):0(zeroTime) cntrlSbst=(APPROVED, FCH1929V153) lm(t):1(2019-10-01T12:46:44.711-04:00) (targetMbSn= lm(t):0(zeroTime), failoverStatus=0 lm(t):0(zeroTime)) podId=1 lm(t):1(2019-09-26T09:26:49.422-04:00) commissioned=YES lm(t):101(2019-09-30T18:45:10.320-04:00) registered=YES lm(t):3(2019-09-05T11:42:41.371-04:00) standby=NO lm(t):0(zeroTime) DRR=NO lm(t):101(2019-09-30T18:45:10.320-04:00) apicX=NO lm(t):0(zeroTime) virtual=NO lm(t):0(zeroTime) active=YES

appliance id=2  address=10.0.0.2 lm(t):2(2019-09-26T09:47:34.709-04:00) tep address=10.0.0.0/16 lm(t):2(2019-09-26T09:47:34.709-04:00) routable address=192.168.1.2 lm(t):2(2019-09-05T11:45:36.861-04:00) oob address=0.0.0.0 lm(t):0(zeroTime) version=4.2(1j) lm(t):2(2019-09-30T18:37:48.913-04:00) chassisId=611febfe-89c1-11e8-96b1-c7a7472413f2 lm(t):2(2019-09-30T18:37:48.913-04:00) capabilities=0X3EEFFFFFFFFF--0X2020--0X7 lm(t):2(2019-09-26T09:53:07.047-04:00) rK=(stable,absent,0) lm(t):0(zeroTime) aK=(stable,absent,0) lm(t):0(zeroTime) oobrK=(stable,absent,0) lm(t):0(zeroTime) oobaK=(stable,absent,0) lm(t):0(zeroTime) cntrlSbst=(APPROVED, FCH2045V1X2) lm(t):2(2019-10-01T12:46:44.710-04:00) (targetMbSn= lm(t):0(zeroTime), failoverStatus=0 lm(t):0(zeroTime)) podId=1 lm(t):2(2019-09-26T09:47:34.709-04:00) commissioned=YES lm(t):101(2019-09-30T18:45:10.320-04:00) registered=YES lm(t):2(2019-09-26T09:47:34.709-04:00) standby=NO lm(t):0(zeroTime) DRR=NO lm(t):101(2019-09-30T18:45:10.320-04:00) apicX=NO lm(t):0(zeroTime) virtual=NO lm(t):0(zeroTime) active=YES

appliance id=3  address=10.0.0.3 lm(t):3(2019-09-26T10:12:34.114-04:00) tep address=10.0.0.0/16 lm(t):3(2019-09-05T11:42:27.199-04:00) routable address=192.168.1.3 lm(t):2(2019-10-01T13:19:08.626-04:00) oob address=0.0.0.0 lm(t):0(zeroTime) version=4.2(1j) lm(t):3(2019-09-30T18:37:48.904-04:00) chassisId=99bade8c-cff3-11e9-bba7-5b906a49dc39 lm(t):3(2019-09-30T18:37:48.904-04:00) capabilities=0X3EEFFFFFFFFF--0X2020--0X4 lm(t):3(2019-09-26T10:18:13.149-04:00) rK=(stable,absent,0) lm(t):0(zeroTime) aK=(stable,absent,0) lm(t):0(zeroTime) oobrK=(stable,absent,0) lm(t):0(zeroTime) oobaK=(stable,absent,0) lm(t):0(zeroTime) cntrlSbst=(APPROVED, FCH1824V2VR) lm(t):3(2019-10-01T12:48:03.726-04:00) (targetMbSn= lm(t):0(zeroTime), failoverStatus=0 lm(t):0(zeroTime)) podId=2 lm(t):3(2019-09-26T10:12:34.114-04:00) commissioned=YES lm(t):101(2019-09-30T18:45:10.320-04:00) registered=YES lm(t):2(2019-09-05T11:42:54.935-04:00) standby=NO lm(t):0(zeroTime) DRR=NO lm(t):101(2019-09-30T18:45:10.320-04:00) apicX=NO lm(t):0(zeroTime) virtual=NO lm(t):0(zeroTime) active=YES

---------------------------------------------

clusterTime=<diff=15584 common=2019-10-01T14:53:01.648-04:00 local=2019-10-01T14:52:46.064-04:00 pF=<displForm=0 offsSt=0 offsVlu=-14400 lm(t):21(2019-09-26T10:40:35.412-04:00)>>

---------------------------------------------

Check04 - IP-Erreichbarkeit zum APIC

Wenn das Leaf eine IP-Adresse erhalten hat, versucht es, TCP-Sitzungen mit dem APIC herzustellen und beginnt mit dem Herunterladen der Konfiguration. Der Benutzer kann die IP-Verbindung zum APIC mithilfe des Dienstprogramms "iping" überprüfen.

leaf101# iping -V overlay-1 10.0.0.1

PING 10.0.0.1 (10.0.0.1) from 10.0.0.30: 56 data bytes

64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=0.651 ms

64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.474 ms

64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.477 ms

64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.54 ms

64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.5 ms

--- 10.0.0.1 ping statistics ---  5 packets transmitted, 5 packets received, 0.00% packet loss

round-trip min/avg/max = 0.474/0.528/0.651 ms

Check05 - Infra. VLAN

Check05 - infra VLAN received [ok]

Die Prüfung des Infra-VLAN ist nur erfolgreich, wenn der Knoten mit einem Pod verbunden ist, auf dem ein APIC vorhanden ist. Ist dies nicht der Fall, kann der Benutzer die Nachricht ignorieren, da erwartet wird, dass die Überprüfung fehlschlägt.

Das Leaf bestimmt das Infra-VLAN anhand von LLDP-Paketen, die von anderen ACI-Knoten empfangen werden. Der erste empfangene Switch wird akzeptiert, wenn der Switch erkannt wird.

(none)# moquery -c lldpInst

Total Objects shown: 1

# lldp.Inst

adminSt        : enabled

childAction    :

ctrl           :

dn             : sys/lldp/inst

holdTime       : 120

infraVlan      : 3967

initDelayTime  : 2

lcOwn          : local

modTs          : 2019-09-12T07:25:33.194+00:00

monPolDn       : uni/fabric/monfab-default

name           :

operErr        :

optTlvSel      : mgmt-addr,port-desc,port-vlan,sys-cap,sys-desc,sys-name

rn             : inst

status         :

sysDesc        : topology/pod-1/node-101

txFreq         : 30

(none)# show vlan encap-id 3967

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

8    infra:default                    active    Eth1/1

VLAN Type  Vlan-mode

---- ----- ----------

8    enet  CE

Wenn das Infra-VLAN nicht an den mit den APICs verbundenen Switch-Port-Schnittstellen programmiert wurde, prüfen Sie, ob auf dem Leaf Kabelprobleme erkannt wurden.

(none)# moquery -c lldpIf -f 'lldp.If.wiringIssues!=""'

Total Objects shown: 1

# lldp.If

id           : eth1/1

adminRxSt    : enabled

adminSt      : enabled

adminTxSt    : enabled

childAction  :

descr        :

dn           : sys/lldp/inst/if-[eth1/1]

lcOwn        : local

mac          : E0:0E:DA:A2:F2:83

modTs        : 2019-09-30T18:45:22.323+00:00

monPolDn     : uni/fabric/monfab-default

name         :

operRxSt     : enabled

operTxSt     : enabled

portDesc     :

portMode     : normal

portVlan     : unspecified

rn           : if-[eth1/1]

status       :

sysDesc      :

wiringIssues : infra-vlan-mismatch

Check06 - LLDP-Adjacency

Check06 - LLDP Adjacency [FAIL]

Error: leaf not connected to any spine

Um zu bestimmen, welche Ports mit anderen ACI-Geräten verbunden werden, muss das Leaf LLDP von den anderen Fabric-Knoten empfangen. Um zu überprüfen, ob LLDP empfangen wurde, kann der Benutzer "show lldp neighbors" auswählen.

(none)# show lldp neighbors

Capability codes:

(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device

(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID            Local Intf      Hold-time  Capability  Port ID

apic1                 Eth1/1          120                    eth2-1

apic2                 Eth1/2          120                    eth2-1

switch                Eth1/51         120        BR          Eth2/32

switch                Eth1/54         120        BR          Eth1/25

Total entries displayed: 4

Check07 — Switch-Version

Check07 - Switch version [ok]

version: n9000-14.2(1j) and apic version: 4.2(1j)

Wenn APIC- und Leaf-Versionen nicht identisch sind, kann die Fabric-Erkennung fehlschlagen. Um die auf dem Leaf ausgeführte Version zu überprüfen, verwenden Sie 'show version' oder 'vsh -c 'show version'.

(none)# show version

Cisco Nexus Operating System (NX-OS) Software

TAC support: http://www.cisco.com/tac

Documents: http://www.cisco.com/en/US/products/ps9372/tsd_products_support_series_home.htmlCopyright (c) 2002-2014, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained in this software are

owned by other third parties and used and distributed under

license. Certain components of this software are licensed under

the GNU General Public License (GPL) version 2.0 or the GNU

Lesser General Public License (LGPL) Version 2.1. A copy of each

such license is available at

http://www.opensource.org/licenses/gpl-2.0.php and

http://www.opensource.org/licenses/lgpl-2.1.php

Software

BIOS:      version 07.66

kickstart: version 14.2(1j) [build 14.2(1j)]

system:    version 14.2(1j) [build 14.2(1j)]

PE:        version 4.2(1j)

BIOS compile time:       06/11/2019

kickstart image file is: /bootflash/aci-n9000-dk9.14.2.1j.bin

kickstart compile time:  09/19/2019 07:57:41 [09/19/2019 07:57:41]

system image file is:    /bootflash/auto-s

system compile time:     09/19/2019 07:57:41 [09/19/2019 07:57:41]

...

Derselbe Befehl funktioniert auch auf den APICs.

apic1# show version

Role        Pod         Node        Name                      Version

----------  ----------  ----------  ------------------------  --------------------

controller  1           1           apic1                     4.2(1j)

controller  1           2           apic2                     4.2(1j)

controller  2           3           apic3                     4.2(1j)

leaf        1           101         leaf101                   n9000-14.2(1j)

leaf        1           102         leaf102                   n9000-14.2(1j)

leaf        1           103         leaf103                   n9000-14.2(1j)

spine       1           1001        spine1                    n9000-14.2(1j)

spine       1           1002        spine2                    n9000-14.2(1j)

Check08 — FPGA/EPLD/BIOS nicht synchronisiert

Die FPGA-, EPLD- und BIOS-Versionen können die Fähigkeit des Leaf-Knotens beeinträchtigen, die Module wie erwartet hochzufahren. Sind diese zu veraltet, können die Schnittstellen des Switches nicht mehr angezeigt werden. Der Benutzer kann die aktuelle und die erwartete Version von FPGA, EPLD und BIOS mithilfe der folgenden moquery-Befehle validieren.

(none)# moquery -c firmwareCardRunning

Total Objects shown: 2

# firmware.CardRunning

biosVer        : v07.66(06/11/2019)

childAction    :

descr          :

dn             : sys/ch/supslot-1/sup/running

expectedVer    : v07.65(09/04/2018)  interimVer     : 14.2(1j)

internalLabel  :

modTs          : never

mode           : normal

monPolDn       : uni/fabric/monfab-default

operSt         : ok

rn             : running

status         :

ts             : 1970-01-01T00:00:00.000+00:00

type           : switch

version        : 14.2(1j)

# firmware.CardRunning

biosVer        : v07.66(06/11/2019)

childAction    :

descr          :

dn             : sys/ch/lcslot-1/lc/running

expectedVer    : v07.65(09/04/2018)  interimVer     : 14.2(1j)

internalLabel  :

modTs          : never

mode           : normal

monPolDn       : uni/fabric/monfab-default

operSt         : ok

rn             : running

status         :

ts             : 1970-01-01T00:00:00.000+00:00

type           : switch

version        : 14.2(1j)

(none)# moquery -c firmwareCompRunning

Total Objects shown: 2

# firmware.CompRunning

childAction    :

descr          :

dn             : sys/ch/supslot-1/sup/fpga-1/running

expectedVer    : 0x14  internalLabel  :

modTs          : never

mode           : normal

monPolDn       : uni/fabric/monfab-default

operSt         : ok

rn             : running

status         :

ts             : 1970-01-01T00:00:00.000+00:00

type           : controller

version        : 0x14

# firmware.CompRunning

childAction    :

descr          :

dn             : sys/ch/supslot-1/sup/fpga-2/runnin

expectedVer    : 0x4

internalLabel  :

modTs          : never

mode           : normal

monPolDn       : uni/fabric/monfab-default

operSt         : ok

rn             : running

status         :

ts             : 1970-01-01T00:00:00.000+00:00

type           : controller

version        : 0x4

Wenn die ausgeführte FPGA-Version nicht mit der erwarteten FPGA-Version übereinstimmt, kann sie mit den Schritten aktualisiert werden, die im Kapitel "Fabric discovery", Abschnitt "Device replace" unter dem Szenario "Leaf/Spine EPLD/FPGA not correct, F1582" beschrieben werden.

Check09 - SSL-Prüfung

Check09 - SSL check [check]

SSL certificate details are valid

Die SSL-Kommunikation zwischen allen Fabric-Knoten sorgt für die Verschlüsselung des Kontrollebenenverkehrs. Das verwendete SSL-Zertifikat wird bei der Herstellung installiert und basierend auf der Seriennummer des Gehäuses generiert. Der Betreff sollte folgendes Format haben:

subject= /serialNumber=PID:N9K-C93xxxxx SN:FDOxxxxxxxx/CN=FDOxxxxxxxx

Verwenden Sie den folgenden Befehl, um das SSL-Zertifikat während der Erkennung eines Switches zu validieren.

(none)# cd /securedata/ssl && openssl x509 -noout -subject -in server.crt

subject= /serialNumber=PID:N9K-C93180YC-EX SN:FDO20432LH1/CN=FDO20432LH1

Beachten Sie, dass die oben genannten nur als Nicht-Root-Benutzer funktionieren, wenn der Switch-Knoten noch erkannt wird.

Die Seriennummer des Gehäuses kann mit dem folgenden Befehl gefunden werden.

(none)# show inventory

NAME: "Chassis",  DESCR: "Nexus C93180YC-EX Chassis"

PID: N9K-C93180YC-EX     ,  VID: V00  ,  SN: FDO20160TPS

...

Außerdem muss das Zertifikat zum aktuellen Zeitpunkt gültig sein. Um das gültige Datum des Zertifikats anzuzeigen, verwenden Sie das Flag '-dates' im Befehl openssl.

(none)# cd /securedata/ssl && openssl x509 -noout -dates -in server.crt

notBefore=Nov 28 17:17:05 2016 GMT

notAfter=Nov 28 17:27:05 2026 GMT

Check10 — Richtlinie herunterladen

Check10 - Downloading policies [FAIL]

Registration to all PM shards is not complete

Policy download is not complete

Sobald das Leaf über eine IP-Verbindung mit dem APIC verfügt, lädt es seine Konfiguration vom APIC herunter und der APIC bestätigt, dass der Download abgeschlossen ist. Der Status dieses Prozesses kann mit dem folgenden Befehl angezeigt werden.

(none)# moquery -c pconsBootStrap

Total Objects shown: 1

# pcons.BootStrap

allLeaderAcked         : no

allPortsInService      : yes

allResponsesFromLeader : yes

canBringPortInService  : no

childAction            :

completedPolRes        : no

dn                     : rescont/bootstrap

lcOwn                  : local

modTs                  : 2019-09-27T22:52:48.729+00:00

rn                     : bootstrap

state                  : completed

status                 :

timerTicks             : 360

try                    : 0

worstCaseTaskTry       : 0

Check11 - Zeit

Check11 - Checking time [ok]

2019-10-01 17:02:34

Diese Überprüfung zeigt dem Benutzer die aktuelle Zeit. Wenn zwischen dem APIC und der Switch-Zeit ein zu großes Delta besteht, kann die Erkennung fehlschlagen. Auf dem APIC kann die Zeit mit dem Befehl date überprüft werden.

apic1# date

Tue Oct  1 14:35:38 UTC 2019

Check12 — Modul, PSU, Lüfterprüfung

Damit der Switch mit anderen Geräten verbunden werden kann, müssen die Module online sein. Dies kann mithilfe der Befehle "show module" und "show environment" überprüft werden.

(none)# show module

Mod  Ports  Module-Type                         Model              Status

---  -----  ----------------------------------- ------------------ ----------

1    54     48x10/25G+6x40/100G Switch          N9K-C93180YC-EX    ok

Mod  Sw              Hw

---  --------------  ------

1    14.2(1j)        0.3050

Mod  MAC-Address(es)                         Serial-Num

---  --------------------------------------  ----------

1    e0-0e-da-a2-f2-83 to e0-0e-da-a2-f2-cb  FDO20160TPS

Mod  Online Diag Status

---  ------------------

1    pass

(none)# show environment

Power Supply:

Voltage: 12.0 Volts

Power                              Actual        Total

Supply    Model                    Output     Capacity    Status

(Watts )     (Watts )

-------  -------------------  -----------  -----------  --------------

1        NXA-PAC-650W-PI              0 W        650 W       shut

2        NXA-PAC-650W-PI            171 W        650 W        ok

Actual        Power

Module     Model                     Draw    Allocated    Status

(Watts )     (Watts )

--------  -------------------  -----------  -----------  --------------

1         N9K-C93180YC-EX            171 W        492 W    Powered-Up

fan1      NXA-FAN-30CFM-B              N/A          N/A    Powered-Up

fan2      NXA-FAN-30CFM-B              N/A          N/A    Powered-Up

fan3      NXA-FAN-30CFM-B              N/A          N/A    Powered-Up

fan4      NXA-FAN-30CFM-B              N/A          N/A    Powered-Up

N/A - Per module power not available

Power Usage Summary:

--------------------

Power Supply redundancy mode (configured)                Non-Redundant(combined)

Power Supply redundancy mode (operational)               Non-Redundant(combined)

Total Power Capacity (based on configured mode)               650  W

Total Power of all Inputs (cumulative)                        650  W

Total Power Output (actual draw)                              171  W

Total Power Allocated (budget)                                N/A

Total Power Available for additional modules                  N/A

Fan:

------------------------------------------------------

Fan             Model                Hw         Status

------------------------------------------------------

Fan1(sys_fan1)  NXA-FAN-30CFM-B      --         ok

Fan2(sys_fan2)  NXA-FAN-30CFM-B      --         ok

Fan3(sys_fan3)  NXA-FAN-30CFM-B      --         ok

Fan4(sys_fan4)  NXA-FAN-30CFM-B      --         ok

Fan_in_PS1      --                   --         unknown

Fan_in_PS2      --                   --         ok

Fan Speed: Zone 1:  0x7f

Fan Air Filter : Absent

Temperature:

-----------------------------------------------------------------------------------

Module   Sensor                       MajorThresh   MinorThres   CurTemp     Status

(Celsius)     (Celsius)    (Celsius)

-----------------------------------------------------------------------------------

1        Inlet(1)                      70            42           35         normal

1        outlet(2)                     80            70           37         normal

1        x86 processor(3)              90            80           38         normal

1        Sugarbowl(4)                  110           90           60         normal

1        Sugarbowl vrm(5)              120           110          50         normal

Wenn ein Modul nicht online geht, setzen Sie es wieder ein, und prüfen Sie, ob FPGA, EPLD oder BIOS nicht übereinstimmen.

Beispiele für fehlerhafte Szenarien

Szenario 1 - Das erste Leaf wird in der Fabric-Mitgliedschaft nicht angezeigt.

In diesem Szenario meldet sich der Benutzer nach Abschluss des Setup-Skripts beim APIC1 an, und es wurden keine Switches in der Fabric-Mitgliedschaft angezeigt. Damit die Erkennung des ersten Leaf erfolgreich durchgeführt werden kann, muss der APIC eine DHCP-Erkennung vom Leaf in der Erkennungsphase erhalten.

Überprüfen Sie, ob APIC1 LLDP-TLVs sendet, die den im Setup-Skript festgelegten Parametern entsprechen.

apic1# acidiag run lldptool out eth2-1

Chassis ID TLV

MAC: e8:65:49:54:88:a1

Port ID TLV

MAC: e8:65:49:54:88:a1

Time to Live TLV

120

Port Description TLV

eth2-1

System Name TLV

apic1

System Description TLV

topology/pod-1/node-1

Management Address TLV

IPv4: 10.0.0.1

Ifindex: 4

Cisco Port State TLV

1

Cisco Node Role TLV

0

Cisco Node ID TLV

1

Cisco POD ID TLV

1

Cisco Fabric Name TLV

ACIFabric1

Cisco Appliance Vector TLV

Id: 1

IPv4: 10.0.0.1

UUID: c67d1076-a2a2-11e9-874e-a390922be712

Cisco Node IP TLV

IPv4:10.0.0.1

Cisco Port Role TLV

2

Cisco Infra VLAN TLV

3967

Cisco Serial Number TLV

FCH1929V153

Cisco Authentication Cookie TLV

1372058352

Cisco Standby APIC TLV

0

End of LLDPDU TLV

Überprüfen Sie außerdem, ob der APIC1 LLDP vom direkt verbundenen Leaf-Knoten empfängt.

apic1# acidiag run lldptool in eth2-1

Chassis ID TLV

MAC: e0:0e:da:a2:f2:83

Port ID TLV

Local: Eth1/1

Time to Live TLV

120

Port Description TLV

Ethernet1/1

System Name TLV

switch

System Description TLV

Cisco Nexus Operating System (NX-OS) Software 14.2(1j)

TAC support: http://www.cisco.com/tacCopyright (c) 2002-2020, Cisco Systems, Inc. All rights reserved.

System Capabilities TLV

System capabilities:  Bridge, Router

Enabled capabilities: Bridge, Router

Management Address TLV

MAC: e0:0e:da:a2:f2:83

Ifindex: 83886080

Cisco 4-wire Power-via-MDI TLV

4-Pair PoE supported

Spare pair Detection/Classification not required

PD Spare pair Desired State: Disabled

PSE Spare pair Operational State: Disabled

Cisco Port Mode TLV

0

Cisco Port State TLV

1

Cisco Serial Number TLV

FDO20160TPS

Cisco Model TLV

N9K-C93180YC-EX

Cisco Firmware Version TLV

n9000-14.2(1j)

Cisco Node Role TLV

1

Cisco Infra VLAN TLV

3967

Cisco Node ID TLV

0

End of LLDPDU TLV

Wenn APIC1 LLDP vom direkt verbundenen Leaf-Knoten empfängt, muss das Leaf das Infra-VLAN an den mit dem APIC verbundenen Ports programmieren. Diese VLAN-Programmierung kann mithilfe des Befehls "show vlan encap-id <x>" validiert werden, wobei "x" das konfigurierte infra-VLAN ist.

(none)# show vlan encap-id 3967

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

8    infra:default                    active    Eth1/1

VLAN Type  Vlan-mode

---- ----- ----------

8    enet  CE

Wenn das Infra-VLAN nicht programmiert wurde, überprüfen Sie, ob vom Leaf-Knoten Probleme mit der Verkabelung erkannt wurden.

(none)# moquery -c lldpIf -f 'lldp.If.wiringIssues!=""'

Total Objects shown: 1

# lldp.If

id           : eth1/1

adminRxSt    : enabled

adminSt      : enabled

adminTxSt    : enabled

childAction  :

descr        :

dn           : sys/lldp/inst/if-[eth1/1]

lcOwn        : local

mac          : E0:0E:DA:A2:F2:83

modTs        : 2019-09-30T18:45:22.323+00:00

monPolDn     : uni/fabric/monfab-default

name         :

operRxSt     : enabled

operTxSt     : enabled

portDesc     :

portMode     : normal

portVlan     : unspecified

rn           : if-[eth1/1]

status       :

sysDesc      :

wiringIssues : infra-vlan-mismatch

Wenn das Attribut für Verkabelungsprobleme auf "infra-vlan-mismatch" gesetzt ist, bedeutet dies, dass das Leaf von einem anderen infra-VLAN als dem vom APIC gesendeten Wert erfahren hat (der vom APIC gesendete Wert kann mit dem Befehl "moquery -c lldpInst" überprüft werden). Dieses Szenario kann eintreten, wenn das Leaf LLDP von einem Knoten empfängt, der früher Teil einer anderen Fabric war. Im Wesentlichen akzeptiert ein Knoten bei der Erkennung das erste über LLDP empfangene Infra-VLAN. Um dieses Problem zu beheben, entfernen Sie die Verbindungen zwischen diesem Leaf und den anderen ACI-Knoten (mit Ausnahme des APIC), und laden Sie den Switch mit den Befehlen "acidiag touch clean" und "reload" neu. Nachdem der Switch gestartet wurde, überprüfen Sie, ob das richtige Infra-VLAN programmiert ist. In diesem Fall können die Verbindungen zu den anderen Knoten wiederhergestellt werden, und der Benutzer kann die ACI-Fabric weiter einrichten.

Szenario 2 - Andere APICs treten dem Cluster nicht bei

In diesem Szenario wurden alle Fabric-Knoten erkannt, aber APIC2 und APIC3 sind noch nicht Teil des APIC-Clusters.

Validierung der Setup-Skriptwerte über APICs hinweg Folgende Werte müssen übereinstimmen:

- Fabric-Domäne

- Fabric-ID

- TEP-Pool

- Infra. VLAN

- GIPo

- Clustergröße

- Firmware-Version

apic1# cat /data/data_admin/sam_exported.config

Setup for Active and Standby APIC

fabricDomain = ACIFabric1

fabricID = 1

systemName =apic1

controllerID = 1

tepPool = 10.0.0.0/16

infraVlan = 3967

GIPo = 225.0.0.0/15

clusterSize = 3

standbyApic = NO

enableIPv4 = Y

enableIPv6 = N

firmwareVersion = 4.2(1j)

ifcIpAddr = 10.0.0.1

apicX = NO

podId = 1

oobIpAddr = 10.48.22.69/24

Überprüfen Sie häufige Probleme mit dem Befehl "acidiag cluster" auf allen 3 APICs.

apic1# acidiag cluster

Admin password:

Product-name = APIC-SERVER-M1

Serial-number = FCH1906V1XV

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: 10.48.22.69 - OK

APIC-2: 10.48.22.70 - OK

APIC-3: 10.48.22.71 - OK

Ping Infra IPs:

APIC-1: 10.0.0.1 - OK

APIC-2: 10.0.0.2 - OK

APIC-3: 10.0.0.3 - OK

Checking APIC Versions: Same (4.2(1j))

Checking SSL: OK

Done!

Überprüfen Sie abschließend mit "avread", ob diese Einstellungen in allen APICs übereinstimmen. Beachten Sie, dass dies ein anderer Befehl als die typische "acidiag avread", die ähnliche Ausgabe zeigt, aber es ist für einen einfacheren Verbrauch analysiert.

apic1# avread

Cluster:

-------------------------------------------------------------------------

fabricDomainName        ACIFabric1

discoveryMode           PERMISSIVE

clusterSize             3

version                 4.2(1j)

drrMode                 OFF

operSize                3

APICs:

-------------------------------------------------------------------------

APIC 1                  APIC 2                  APIC 3

version           4.2(1j)                 4.2(1j)                 4.2(1j)

address           10.0.0.1                10.0.0.2                10.0.0.3

oobAddress        10.48.22.69/24          10.48.22.70/24          10.48.22.71/24

routableAddress   0.0.0.0                 0.0.0.0                 0.0.0.0

tepAddress        10.0.0.0/16             10.0.0.0/16             10.0.0.0/16

podId             1                       1                       1

chassisId         3c9e5024-.-5a78727f     573e12c0-.-6b8da0e5     44c4bf18-.-20b4f52&    cntrlSbst_serial  (APPROVED,FCH1906V1XV)  (APPROVED,FCH1921V1Q9)  (APPROVED,FCH1906V1PW)

active            YES                     YES                     YES

flags             cra-                    cra-                    cra-

health            255                     255                     255

apic1#

Szenario 3 - Spine wird in der Fabric-Mitgliedschaft nicht angezeigt

In diesem Szenario wurde der erste Leaf im Fabric entdeckt, aber es wurden keine Stacheln im Untermenü "Fabric-Mitgliedschaft" zur Erkennung angezeigt.

Validierung der physischen Verbindungen von Leaf zu Spine Im folgenden Beispiel ist der Leaf-Switch über die Schnittstelle e1/49 mit einem Spine verbunden.

leaf101# show int eth1/49

Ethernet1/49 is up

admin state is up, Dedicated Interface

Hardware: 1000/10000/100000/40000 Ethernet, address: 0000.0000.0000 (bia e00e.daa2.f3f3)

MTU 9366 bytes, BW 100000000 Kbit, DLY 1 usec

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, medium is broadcast

Port mode is routed

full-duplex, 100 Gb/s

...

Wenn sich der Port in einem Out-of-Service-Status befindet, überprüfen Sie auf dem Spine, ob LLDP vom direkt verbundenen Leaf empfangen wurde.

(none)# show lldp neighbors

Capability codes:

(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device

(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID            Local Intf      Hold-time  Capability  Port ID

leaf102               Eth2/27         120        BR          Eth1/53

leaf103               Eth2/29         120        BR          Eth1/49

leaf101               Eth2/32         120        BR          Eth1/51

Total entries displayed: 3

Eine weitere Validierung besteht darin, zu überprüfen, ob zwischen Leaf und Spine kein Versionsunterschied besteht. Wenn dies der Fall ist, beheben Sie die Situation, indem Sie die neuere Version nach /bootflash des Spine kopieren. Konfigurieren Sie dann den Switch so, dass er mit den folgenden Befehlen von der Software bootet:

(none)# ls -alh /bootflash

total 3.0G

drwxrwxr-x  3 root admin 4.0K Oct  1 20:21 .

drwxr-xr-x 50 root root  1.3K Oct  1 00:22 ..

-rw-r--r--  1 root root  3.5M Sep 30 21:24 CpuUsage.Log

-rw-rw-rw-  1 root root  1.7G Sep 27 14:50 aci-n9000-dk9.14.2.1j.bin

-rw-r--r--  1 root root  1.4G Sep 27 21:20 auto-s

-rw-rw-rw-  1 root root     2 Sep 27 21:25 diag_bootup

-rw-r--r--  1 root root    54 Oct  1 20:20 disk_log.txt

-rw-rw-rw-  1 root root   693 Sep 27 21:23 libmon.logs

drwxr-xr-x  4 root root  4.0K Sep 26 15:24 lxc

-rw-r--r--  1 root root  384K Oct  1 20:20 mem_log.txt

-rw-r--r--  1 root root  915K Sep 27 21:10 mem_log.txt.old.gz

-rw-rw-rw-  1 root root   12K Sep 27 21:17 urib_api_log.txt

(none)# setup-bootvars.sh aci-n9000-dk9.14.2.1j.bin

In progress

In progress

In progress

In progress

Done

Wenn das neue Image kontinuierlich aus dem Bootflash entfernt wird, stellen Sie sicher, dass der Ordner weniger als halb voll ist, indem Sie ältere Images oder Auto-s-Dateien entfernen. Überprüfen Sie die Speichernutzung mit 'df -h' auf dem Switch.

Nachdem Sie die Boot-Variable festgelegt haben, laden Sie den Switch neu, und er sollte mit der neuen Version gestartet werden.

Nach dem Neuladen ist möglicherweise eine FPGA-, EPLD- und BIOS-Validierung erforderlich. Weitere Informationen zur Fehlerbehebung finden Sie im Unterabschnitt "Leaf/Spine EPLD/FPGA not correct, F1582".

4. Szenario: Nach der anfänglichen Fabric-Erkennung wechselt der Cluster zwischen voll betriebsfähig und reduziert ab

Wenn dies nach einer neuen Fabric-Konfiguration der Fall ist, kann dies durch eine falsche Verkabelung des APIC-M3 oder APIC-L3 verursacht werden, der mit der Fabric verbunden ist. Sie können eine solche falsche Verkabelung bestätigen, indem Sie "show lldp neighbors" auf beiden Leaf-Switches ausführen, die mit dem APIC verbunden sind. Nach mehrmaligem Ausführen sehen Sie, dass beide Leaf-Switches die gleiche APIC-Schnittstelle verwenden.

Die Rückseite eines APIC-M3/L3-Servers sieht wie folgt aus:

Rückansicht des APIC-M3/L3-Servers

Beachten Sie, dass die VIC-Karte für einen APIC-M3/L3 über 4 Ports verfügt: ETH2-1, ETH2-2, ETH2-3 und ETH2-4 (siehe unten):

Ansicht der APIC VIC 1455 mit Beschriftungen

Für die Verbindung des APIC-Servers mit den Leaf-Switches gelten folgende Regeln:

- Alle Ports müssen dieselbe Geschwindigkeit aufweisen, entweder 10-Gigabit oder 25-Gigabit.

- ETH2-1 und ETH2-2 sind ein Port-Channel-Paar, das eth2-1 ("ifconfig"-Ausgabe) des APIC-Betriebssystems entspricht.

- ETH2-3 und ETH2-4 ist das andere Port-Channel-Paar, das eth2-2 ("ifconfig"-Ausgabe) auf dem APIC-Betriebssystem entspricht.

- Pro Port-Channel-Paar ist nur eine Verbindung zulässig. Schließen Sie beispielsweise ein Kabel an ETH2-1 oder ETH2-2 und ein weiteres Kabel an ETH2-3 oder ETH2-4 an (Verbinden Sie niemals beide ETHs in einem Port-Channel-Paar). Dies führt zu Problemen mit der Fabric-Erkennung.).

Im Folgenden wird die VIC-Port-Zuordnung zur APIC-Verbindung dargestellt.

VIC 1455-Ports - redundanter APIC-Fabric-Port