Inhalt

Einführung

Hintergrund

Beispieleinrichtung

Verwendete Komponenten

Fehlerbehebung

Schritt 1: Routen-Reflektor

Schritt 2: Bridge-Domäne zu L3Out

Schritt 3: Verträge

Schritt 4: IP-Route

Schritt 5: Endgerätelernen und -iping

Schritt 6: Adressenauflösungsprotokoll

Schritt 7: Integriertes Logik-Analysemodul

Schritt 8: IPN-Geräteprüfung

Schritt 9: IP-Adresse der BD-Gruppe

Schritt 10: mroute

Zugehörige Informationen

Einführung

In diesem Dokument wird beschrieben, wie Sie in einem ACI-Netzwerk (Application Centric Infrastructure) Routingprobleme bei mehreren PODs beheben können.

Hintergrund

Wenn Sie ein Inter-Pod-Netzwerk (IPN) (ein Nicht-GOLF-Netzwerk (Giant Overlay Forwarding)) in einer Multi-Pod-Konfiguration konfigurieren, sind einige Schritte leicht zu verpassen. Dies gilt insbesondere, wenn Pod 1 zuvor konfiguriert wurde, aber einige der grundlegenden Schritte noch immer nicht bestanden. Dies ist eine allgemeine Guthaben-/Checkliste, und die Beispiele sind nicht für jede Situation spezifisch. In diesem Dokument soll die Vorgehensweise zur Fehlerbehebung bei der Konfiguration beschrieben werden.

Beispieleinrichtung

Der Quell-Endpunkt in Pod 2 kann das Ziel in Pod 1 nicht über das IPN pingen, wie in diesem Bild gezeigt.

Verwendete Komponenten

Die Informationen in diesem Dokument wurden auf Basis der Geräte in einer ACI-Lab-Umgebung in Version 2.3(1i) erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Fehlerbehebung

Diese Schritte gelten für alle Designs, einschließlich Multi-Pod.

Schritt 1: Routen-Reflektor

Überprüfen Sie, ob die Routen-Reflektoren auf beiden PODs konfiguriert sind.

Geben Sie im Compute-Leaf von Pod 2 den folgenden Befehl ein:

show bgp sessions vrf overlay-1

Geben Sie in Pod 1 im Compute/Border Leaf den folgenden Befehl ein:

show bgp sessions vrf overlay-1

Schritt 2: Bridge-Domäne zu L3Out

Die Bridge-Domäne (BD), die der Quellendpunktgruppe (EPG) zugeordnet ist, muss Folgendes aufweisen:

- Unicast-Routing aktiviert

- Mit BD verknüpftes L3out

Schritt 3: Verträge

L3out und EPG müssen über entsprechende Verträge verfügen. Wenn Sie der Meinung sind, dass Verträge das Problem darstellen, heben Sie die Durchsetzung von Virtual Routing and Forwarding (VRF) auf.

Geben Sie den folgenden Befehl ein, um die Verwerfen von Verträgen auf einem beliebigen Leaf zu überprüfen:

show logging ip access-list internal packet-log deny | grep

Schritt 4: IP-Route

Aus dem Computing-Leaf in Pod 1 müssen die Routen für das Ziel angezeigt werden. Genauso müssen Sie aus dem Border Leaf in Pod 2 die Routen für die Quelle sehen. Geben Sie diesen Befehl ein, um die Routen zu überprüfen:

show ip route

vrf

Schritt 5: Endgerätelernen und -iping

Überprüfen Sie die Quell- und Zielerkennung für jedes Leaf, um veraltete Endpunkteinträge auszuschließen. Verfolgen Sie die Endpunkterfahrung bis zum richtigen Leaf, und verfolgen Sie, wo der Ping unterbrochen wird.

Geben Sie sowohl im Compute-Leaf in Pod 2 als auch im Border Leaf in Pod 1 die folgenden Befehle ein:

show endpoint ip

show endpoint ip

show interface tunnelx acidiag fnvread

iping -V

-S

iping -V

-S

Schritt 6: Adressenauflösungsprotokoll

Überprüfen Sie die Quelle, um festzustellen, ob das Address Resolution Protocol (ARP) für das Ziel aufgelöst wurde.

Schritt 7: Integriertes Logik-Analysemodul

Auslösen des Eingangs-Embedded Logic Analyzer Module (ELAM) für Internet Control Message Protocol (ICMP) (oder ggf. ARP) auf dem Compute Leaf in Pod 2.

Ein allgemeines Beispiel für einen EX-Switch ist:

vsh_lc

deb plat int tah el as 0

trig reset

trig init in 6 o 1

set outer ipv4 src_ip

dst_ip

stat

start

stat

report | egrep SRC|hdr.*_idx|ovector_idx|a.ce_|l3v.ip.*a:|af.*cla|f.epg_|fwd_|vec.op|cap_idx

Ausgangs-ELAM für ICMP (oder ggf. ARP) auf dem Grenzübergang in Pod 1 auslösen.

Ein allgemeines Beispiel für einen EX-Switch ist:

vsh_lc

deb plat int tah el as 0

trig reset

trig init in 7 o 1

set inner ipv4 src_ip

dst_ip

stat

start

stat

report | egrep SRC|hdr.*_idx|ovector_idx|a.ce_|l3v.ip.*a:|af.*cla|f.epg_|fwd_|vec.op|cap_idx

Die nächsten Schritte beziehen sich speziell auf Multi-Pod-Designs.

Schritt 8: IPN-Geräteprüfung

Führen Sie für JEDES IPN-Gerät die folgenden Schritte aus:

1. Sammeln Sie die RP-Adresse (Route Processor). Stellen Sie sicher, dass die RP-Adresse auf allen IPN-Geräten identisch ist.
show run pim

2. Überprüfen Sie, ob das IPN-Gerät mit den niedrigsten Kosten zum RP geht (wenn es sich um einen Phantom-RP handelt, suchen Sie nach einem sekundären RP).
show run interface

3. Stellen Sie sicher, dass alle IPNs einen Ping an die RP-/sekundäre RP-Adresse senden können.
ping

vrf

4. Stellen Sie sicher, dass die Routen zu diesem RP NICHT zu den Spines gehen.
show ip route

vrf

show lldp neighbors

Schritt 9: IP-Adresse der BD-Gruppe

Die äußere Adresse der BD-Gruppe (GIPo) ist die Multicast-Adresse.

Um das BD GIPo über die Benutzeroberfläche zu finden, navigieren Sie zu Bridge Domain > Policy > Advanced/Troubleshooting > Multicast Address (Bridge-Domäne > Richtlinie > Advanced/Troubleshooting > Multicast Address).

Schritt 10: mroute

Geben Sie im ACI Computing Leaf in Pod 2 den folgenden Befehl ein, um zu überprüfen, ob der Prozess durchgestellt wird:

show ip mroute

vrf

Geben Sie im ACI Border Leaf in Pod 1 den folgenden Befehl ein, um zu überprüfen, ob der Prozess durchgestellt wird:

show ip mroute

vrf

Zugehörige Informationen

- Whitepaper zu Multi-Pod

- Whitepaper zur Multi-Pod-Konfiguration

- Technischer Support und Dokumentation - Cisco Systems