Fehlerbehebung bei ACI Management und Core Services - In-Band- und Out-of-Band-Management

Einleitung

In diesem Dokument werden die Schritte zur Fehlerbehebung bei ACI-Out-of-Band- (OOB) und In-Band-Management (INB) beschrieben.

Hintergrundinformationen

Das Material aus diesem Dokument wurde aus dem Buch Troubleshooting Cisco Application Centric Infrastructure, Second Edition (Fehlerbehebung bei Cisco Application Centric Infrastructure, zweite Ausgabe) extrahiert, das speziell die Kapitel Management und Core-Services - In-Band- und Out-of-Band-Management behandelt.

In-Band- und Out-of-Band-Management

ACI Fabric-Knoten bieten zwei Optionen für die Management-Anbindung. Out-of-Band (OOB), der den dedizierten physischen Management-Port auf der Geräterückseite steuert, oder In-Band (INB), der mithilfe einer spezifischen EPG/BD/VRF-Instanz im Management-Tenant mit einem gewissen Grad an konfigurierbaren Parametern bereitgestellt wird. Es ist eine OOB-EPG im Management-Tenant ('mgmt') vorhanden, diese ist jedoch standardmäßig vorhanden und kann nicht geändert werden. Es ist nur die Konfiguration der bereitgestellten OOB-Verträge zulässig. Auf dem APIC wird die OOB-Schnittstelle in der Ausgabe des Befehls "ifconfig" als "oobmgmt" angezeigt, und die In-Band-Schnittstelle wird durch die Schnittstelle "bond.x" dargestellt, wobei "" das für die In-Band-EPG konfigurierte Encap-VLAN ist.

apic1# ifconfig oobmgmt
oobmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.4.20  netmask 255.255.255.0  broadcast 192.168.4.255
        inet6 fe80::7269:5aff:feca:2986  prefixlen 64  scopeid 0x20
        ether 70:69:5a:ca:29:86  txqueuelen 1000  (Ethernet)
        RX packets 495815  bytes 852703636 (813.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 432927  bytes 110333594 (105.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

apic1# ifconfig bond0.300
bond0.300: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1496
        inet 10.30.30.254  netmask 255.255.255.0  broadcast 10.30.30.255
        inet6 fe80::25d:73ff:fec1:8d9e  prefixlen 64  scopeid 0x20
        ether 00:5d:73:c1:8d:9e  txqueuelen 1000  (Ethernet)
        RX packets 545  bytes 25298 (24.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6996  bytes 535314 (522.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Auf dem Leaf wird die OOB-Schnittstelle in der Ausgabe des Befehls "ifconfig" als "eth0" und der INB als dedizierte SVI angesehen. Der Benutzer kann die Schnittstelle mit "ifconfig" oder mit "show ip interface vrf mgmt:" anzeigen, wobei der für die In-Band-VRF-Instanz ausgewählte Name ist.

leaf101# show interface mgmt 0
mgmt0 is up
admin state is up,
  Hardware: GigabitEthernet, address: 00fc.baa8.2760 (bia 00fc.baa8.2760)
  Internet Address is 192.168.4.23/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, medium is broadcast
  Port mode is routed
  full-duplex, 1000 Mb/s
  Beacon is turned off
  Auto-Negotiation is turned on
  Input flow-control is off, output flow-control is off
  Auto-mdix is turned off
  EtherType is 0x0000
  30 seconds input rate 3664 bits/sec, 4 packets/sec
  30 seconds output rate 4192 bits/sec, 4 packets/sec
  Rx
    14114 input packets 8580 unicast packets 5058 multicast packets
    476 broadcast packets 2494768 bytes
  Tx
    9701 output packets 9686 unicast packets 8 multicast packets
    7 broadcast packets 1648081 bytes

leaf101# show ip interface vrf mgmt:inb
  IP Interface Status for VRF "mgmt:inb-vrf" 
  vlan16, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: pervasive 
    IP address: 10.30.30.1, IP subnet: 10.30.30.0/24 
    secondary IP address: 10.30.30.3, IP subnet: 10.30.30.0/24 
    IP broadcast address: 255.255.255.255 
  IP primary address route-preference: 0, tag: 0

'show ip interface vrf mgmt:' zeigt die BD-Subnetz-IP-Adresse für das In-Band-Management als sekundäre IP-Adresse an; Dies ist die erwartete Ausgabe.

Auf Spine-Switches wird die In-Band-Management-IP-Adresse als dedizierte Loopback-Schnittstelle zur VRF-Instanz "mgmt:" hinzugefügt. Diese Implementierung unterscheidet sich daher von der In-Band-Management-IP-Implementierung auf Leaf-Switches. Beobachten Sie die folgende Ausgabe des Befehls 'show ip int vrf mgmt:' auf einem Spine-Switch.

spine201# show ip interface vrf mgmt:inb
  IP Interface Status for VRF "mgmt:inb"
  lo10, Interface status: protocol-up/link-up/admin-up, iod: 98, mode: pervasive
    IP address: 10.30.30.12, IP subnet: 10.30.30.12/32
    IP broadcast address: 255.255.255.255
 IP primary address route-preference: 0, tag: 0 

In den Systemeinstellungen können Sie die In-Band- oder Out-of-Band-Verbindungseinstellungen für die APICs auswählen.

Nur der vom APIC gesendete Datenverkehr verwendet die in den APIC-Verbindungseinstellungen ausgewählte Verwaltungseinstellung. Der APIC kann weiterhin Datenverkehr entweder über In-Band- oder Out-of-Band-Verbindungen empfangen, sofern eine der beiden Optionen konfiguriert ist. Der APIC verwendet die folgende Weiterleitungslogik:

• Pakete, die über eine Schnittstelle gesendet und über dieselbe Schnittstelle gesendet werden.
• Pakete, die vom APIC generiert und für ein direkt verbundenes Netzwerk bestimmt sind, werden über die direkt verbundene Schnittstelle übertragen.
• Aus dem APIC stammende Pakete, die für ein Remote-Netzwerk bestimmt sind, bevorzugen In-Band oder Out-of-Band, basierend auf den APIC-Verbindungseinstellungen.

APIC-Verbindungseinstellungen

APIC-Routing-Tabelle mit ausgewähltem OOB Beachten Sie den metrischen Wert von 16 für die obmgmt-Schnittstelle, der niedriger ist als der Wert für die Inband-Managementschnittstelle bond0.300 von 32. Das bedeutet, dass die obmgmt-Out-of-Band-Managementschnittstelle für ausgehenden Managementverkehr verwendet wird.

apic1# bash
admin@apic1:~> route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.4.1     0.0.0.0         UG    16     0        0 oobmgmt
0.0.0.0         10.30.30.1      0.0.0.0         UG    32     0        0 bond0.300

APIC-Routing-Tabelle mit In-Band-Auswahl Beachten Sie die Metrik der Inband-Management-Schnittstelle bond0.300, wenn 8, die jetzt niedriger ist als die Metrik der Obmgmt-Schnittstelle von 16. Das bedeutet, dass die In-Band-Management-Schnittstelle bond0.300 für ausgehenden Managementverkehr verwendet wird.

admin@apic1:~> route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.30.30.1      0.0.0.0         UG    8      0        0 bond0.300
0.0.0.0         192.168.4.1     0.0.0.0         UG    16     0        0 oobmgmt

Die Einstellungen für die Leaf- und Spine-Knotenverwaltung werden von dieser Einstellung nicht beeinflusst. Diese Verbindungseinstellungen werden unter den Protokollrichtlinien ausgewählt. Nachfolgend finden Sie ein Beispiel für NTP.

Wenn "In-Band" unter den APIC-Verbindungseinstellungen und "Out-of-Band" unter dem Protokoll ausgewählt ist, welche Schnittstelle mit dem Protokollpaket verwendet wird?

• Die APIC-Konnektivitätspräferenz hat immer Vorrang vor der Protokollauswahl auf dem APIC.
• Die Endknoten sind das Gegenteil, sie verweisen nur auf die Auswahl unter dem Protokoll.

Szenario: Management-Netzwerk kann nicht erreicht werden

Wenn der Benutzer nicht in der Lage ist, das Managementnetzwerk zu erreichen, kann dies auf verschiedene Probleme zurückzuführen sein, aber er kann immer die gleiche Methode verwenden, um das Problem zu isolieren. In diesem Szenario wird davon ausgegangen, dass der Benutzer hinter seinem L3Out keine Geräte im Managementnetzwerk erreichen kann.

• Überprüfen der APIC-Verbindungseinstellungen Dies ist in der Abbildung "APIC-Verbindungseinstellungen" dargestellt, und die Optionen sind OOB oder In-Band.
• Überprüfen Sie je nach gewählter Einstellung, ob die Konfiguration korrekt ist, ob die Schnittstellen aktiv sind, ob das Standard-Gateway über die ausgewählte Schnittstelle erreichbar ist und ob der Pfad des Pakets verworfen wird.

Vergessen Sie nicht, in jedem Konfigurationsabschnitt der GUI nach Fehlern zu suchen. Einige Konfigurationsfehler können sich jedoch in unerwarteten Zuständen äußern, aber es kann sein, dass ein Fehler in einem anderen Abschnitt generiert wird, als dem, den der Benutzer ursprünglich in Betracht ziehen würde.

Out-of-Band-Managementzugriff

Verifizierung der Out-of-Band-Konfiguration

Für die Out-of-Band-Konfiguration gibt es vier Ordner, die unter einem speziellen Tenant namens "mgmt" überprüft werden müssen:

• Adressen für das Knotenmanagement
• Knoten-Management-EPGs.
• Out-of-Band-Verträge (im Rahmen von Verträgen).
• Externe Netzwerk-Instanzprofile.

Knotenverwaltungsadressen können entweder statisch oder aus einem Pool zugewiesen werden. Nachfolgend finden Sie ein Beispiel für die Zuweisung statischer Adressen. Überprüfen Sie, ob die Out-of-Band-IP-Adressen zugewiesen wurden und das Standard-Gateway korrekt ist.

GUI-Verifizierung für statische Knotenverwaltung

Die Out-of-Band-EPG sollte sich im Ordner Node Management EPGs befinden.

Out-of-Band-EPG - Standard

Die Verträge, die bestimmen, welche Management-Services von der Out-of-Band-EPG bereitgestellt werden, sind spezielle Verträge, die im Ordner für Out-of-Band-Verträge konfiguriert werden.

Out-of-Band-Vertrag

Überprüfen Sie anschließend, ob das externe Management-Netzwerkinstanzprofil erstellt wurde und ob der richtige Out-of-Band-Vertrag als "Consumed Out-Of-Band Contract" konfiguriert ist.

Externes Management-Netzwerk-Instanzprofil

Als Nächstes müssen der Schnittstellenstatus und die Verkabelung sowie die Verbindung zum Gateway überprüft werden.

• Um zu überprüfen, ob die obmgmt-Schnittstelle aktiv ist, geben Sie "ifconfig oobmgmt" in die APIC-CLI ein. Überprüfen Sie, ob die Schnittstellenmarkierungen 'UP' und 'RUNNING' lauten, ob die richtige IP-Adresse konfiguriert ist und ob die Pakete in den RX- und TX-Zählern zunehmen. Wenn keine Prüfungen fehlen, überprüfen Sie, ob die richtigen Kabel verwendet und mit den richtigen physischen Management-Ports am APIC verbunden wurden. Die Management-Ports sind mit Eth1-1 und Eth1-2 gekennzeichnet, und die aktuelle Hardware verfügt über obmgmt-Aufkleber zur Kennzeichnung der Out-of-Band-Schnittstelle. Weitere Informationen zu den physischen Out-of-Band-Mgmt-Ports auf der Rückseite eines APIC finden Sie im Abschnitt "Anfängliche Fabric-Einrichtung" im Kapitel "Fabric-Ermittlung".
  
  

apic1# ifconfig oobmgmt
oobmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.4.20  netmask 255.255.255.0  broadcast 192.168.4.255
inet6 fe80::7269:5aff:feca:2986  prefixlen 64  scopeid 0x20
ether 70:69:5a:ca:29:86  txqueuelen 1000  (Ethernet)
RX packets 295605  bytes 766226440 (730.7 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 253310  bytes 38954978 (37.1 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• Um die Netzwerkverbindung über den OOB zu überprüfen, verwenden Sie ping, um den Pfad des Pakets durch das Out-of-Band-Netzwerk zu testen.

apic1# ping 192.168.4.1
PING 192.168.4.1 (192.168.4.1) 56(84) bytes of data.
64 bytes from 192.168.4.1: icmp_seq=1 ttl=255 time=0.409 ms
64 bytes from 192.168.4.1: icmp_seq=2 ttl=255 time=0.393 ms
64 bytes from 192.168.4.1: icmp_seq=3 ttl=255 time=0.354 ms

Verfolgen Sie die Verbindung zum Endbenutzer mithilfe von Traceroute in der Bash-Shell des APIC. Wenn die Traceroute unvollständig ist, melden Sie sich bei diesem Gerät an (falls verfügbar), und pingen Sie die obmgmt-Schnittstelle und den Host. Je nachdem, welche Richtung fehlschlägt, beheben Sie das Problem wie ein herkömmliches Netzwerkproblem.

Traceroute funktioniert durch Senden von UDP-Paketen mit einer zunehmenden TTL, beginnend mit 1. Wenn ein Router das Paket mit TTL 1 empfängt und weiterleiten muss, verwirft er den Frame und sendet eine ICMP-Nachricht zurück, die nicht erreichbar ist. Jeder Hop erhält drei UDP-Pakete mit der aktuellen TTL, und die Sternchen stehen für Versuche, bei denen kein ICMP Unreachable/TTL Exceeded-Paket empfangen wurde. Diese 3 Sternchen-Blöcke werden in den meisten Netzwerken erwartet, da einige Routing-Geräte Nachrichten mit deaktiviertem ICMP unreachable/TTL Exceeded haben. Wenn sie also TTL 1-Pakete empfangen, die sie weiterleiten müssen, verwerfen sie einfach das Paket und senden die Nachricht nicht zurück an den Absender.

apic1# bash
admin@apic1:~> traceroute 10.55.0.16
traceroute to 10.55.0.16 (10.55.0.16), 30 hops max, 60 byte packets
    1  192.168.4.1 (192.168.4.1)  0.368 ms  0.355 ms  0.396 ms
    2  * * *
    3  * * *
    4  10.0.255.221 (10.0.255.221)  6.419 ms 10.0.255.225 (10.0.255.225)  6.447 ms *
    5  * * *
    6  * * *
    7  10.55.0.16 (10.55.0.16)  8.652 ms  8.676 ms  8.694 ms

Die Leaf-Switches haben Zugriff auf den tcpdump-Befehl, mit dem überprüft werden kann, welche Pakete die Obmgmt-Schnittstelle passieren. Das nachfolgende Beispiel erfasst "eth0", die obmgmt-Schnittstelle, die auf den Leaf- und Spine-Switches verwendet wird, und verwendet die Option "-n" für tcpdump, um die IP-Adressen zu ermitteln, die anstelle der DNS-Namen verwendet werden, und dann speziell für NTP-Pakete zu filtern (UDP-Port 123). Denken Sie daran, dass der Leaf im vorherigen Beispiel den NTP-Server 172.18.108.14 abfragt. Unten kann der Benutzer überprüfen, ob NTP-Pakete über die Out-of-Band-Schnittstelle übertragen werden und ob der Leaf eine Antwort vom Server erhält.

fab1-leaf101# tcpdump -n -i eth0 dst port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:49:01.431624 IP 192.168.4.23.123 > 172.18.108.14.123: NTPv4, Client, length 48
16:49:01.440303 IP 172.18.108.14.123 > 192.168.4.23.123: NTPv4, Server, length 48

Die In-Band-Managementkonfiguration erfordert spezielle Überlegungen für Layer-2- oder Layer-3-Bereitstellungen. In diesem Beispiel werden nur die Bereitstellung und Fehlerbehebung für Layer 3 behandelt.

In-Band-Managementkonfiguration

Überprüfen Sie, ob ein BD im mgmt-Tenant mit einem Subnetz vorhanden ist, von dem aus den Fabric-Knoten In-Band-Knoten-Managementadressen für In-Band-Verbindungen zugewiesen werden, und stellen Sie sicher, dass L3Out dem In-Band-Management-BD zugeordnet ist.

Bridge-Domänen-Subnetz, das als In-Band-Management-Gateway fungiert

Überprüfen Sie, ob eine In-Band-Knoten-Management-EPG vorhanden ist. Wie im folgenden Screenshot gezeigt, werden die In-Band-EPG-Namen in der GUI mit dem Präfix "inb-" gekennzeichnet. Überprüfen Sie, ob das In-Band-EPG-Encap-VLAN korrekt mit einem VLAN-Pool verknüpft ist.

Das in der In-Band-Management-EPG konfigurierte Kapselungs-VLAN muss von den Zugriffsrichtlinien zugelassen werden: "inb mgmt EPG encap VLAN > VLAN Pool > Domain > AEP > Interface Policy Group > Leaf Interface Profile > Switch Profile". Wenn die unterstützenden Zugriffsrichtlinien nicht konfiguriert sind, wird ein Fehler mit dem Code F0467 gemäß dem unten stehenden Screenshot ausgelöst.

Fehler F0467 - inb-EPG

Überprüfen Sie, ob die Bridge-Domäne mit der oben für das In-Band-Subnetz erstellten Domäne übereinstimmt. Überprüfen Sie abschließend, ob auf der In-Band-Verwaltungs-EPG ein bereitgestellter Vertrag konfiguriert ist, der von der externen EPG genutzt wird.

In-Band-EPG

Externes EPG-Instanzprofil

Ähnlich wie Out-of-Band können Fabric-Knoten-In-Band-Mgmt-IP-Adressen statisch oder dynamisch aus einem vorab ausgewählten Bereich zugewiesen werden. Überprüfen Sie, ob die Adressen für den In-Band-Typ mit dem zuvor konfigurierten BD-Subnetz übereinstimmen. Überprüfen Sie außerdem, ob das Standard-Gateway korrekt ist.

Adressen für statisches Knotenmanagement

Wenn alles korrekt konfiguriert wurde und in den oben genannten Abschnitten keine Fehler auftreten, wird im nächsten Schritt ein Ping zwischen den Switches und/oder APICs gesendet, um zu überprüfen, ob die In-Band-Verbindung innerhalb der ACI richtig funktioniert.

Die Spine-Knoten reagieren nicht auf Ping-Signale im In-Band-Netzwerk, da sie Loopback-Schnittstellen für Verbindungen verwenden, die nicht auf ARP reagieren.

Die auf den Leaf-Switches verwendete In-Band-Schnittstelle lautet kpm_inb. Überprüfen Sie mit einer ähnlichen tcpdump-Erfassung, ob das Paket die In-Band-CPU-Schnittstelle verlässt.

fab2-leaf101# tcpdump -n -i kpm_inb dst port 123 
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:46:50.431647 IP 10.30.30.3.123 > 172.18.108.14.123: NTPv4, Client, length 48
16:47:19.431650 IP 10.30.30.3.123 > 172.18.108.15.123: NTPv4, Client, length 48

Überprüfen Sie, ob als SVI für In-Band "protocol-up/link-up/admin-up" (Protokoll aktiviert/Verbindung aktiviert/Administrator aktiviert) verwendet wird.

fab1-leaf101# show ip interface vrf mgmt:inb-vrf
IP Interface Status for VRF "mgmt:inb-vrf"
vlan16, Interface status: protocol-up/link-up/admin-up, iod: 4, mode: pervasive
    IP address: 10.30.30.1, IP subnet: 10.30.30.0/24 secondary
    IP address: 10.30.30.3, IP subnet: 10.30.30.0/24
    IP broadcast address: 255.255.255.255
    IP primary address route-preference: 0, tag: 0