Fehlerbehebung bei Problemen mit mehreren PODs in einem ACI-Netzwerk

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