Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Topologie

Option 1. ERSPAN-Einrichtung mit Flow-ID

Schritt 1. Einrichtung des ESPAN-Ziels

Schritt 2a: Erstellen einer Spanning Source für den Datenverkehr, der direkt mit dem SRC verbunden ist

Schritt 2b. Erstellen einer Spanning Source für den Datenverkehr, der direkt mit dem DST verbunden ist

Schritt 3: Schnelle Wireshark-Analyse

Option 2. Plattformzähler

Plattformzähler löschen

Identifizieren einer Paketgröße mit niedrigen oder null Paketen

Datenverkehrsfluss verfolgen

Zugehörige Informationen

Einleitung

In diesem Dokument wird beschrieben, wie ein Netzwerkfluss mithilfe von Paketfarbtechniken nachverfolgt wird.

Voraussetzungen

Anforderungen

- Grundkenntnisse der ACI

- Endpunktgruppen und Vertrag

- Wireshark - Grundkenntnisse

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Hardware- und Softwareversionen beschränkt.

Verwendete Geräte:

- Cisco ACI mit Version 5.3(2)

- Übergreifendes Ziel

- Gen2-Switches

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Erstellen von Filtern in Wireshark

Öffnen Sie die Erfassung. Wählen Sie mithilfe eines Frames innerhalb des Encapsulated Remote Switch Packet die Zeile SpanID aus, und klicken Sie mit der rechten Maustaste.

Wählen Sie Anwenden als Filter > Ausgewählt, wie das Bild zeigt:

Topologie

Option 1. ERSPAN-Einrichtung mit Flow-ID

Wenn ein Zielserver den gesamten Datenverkehr verarbeiten kann, enthält der ERSPAN-Header eine Option zur Definition einer Flow-ID. Diese Flow-ID kann so konfiguriert werden, dass eingehender Datenverkehr an die Fabric identifiziert wird, während eine andere Flow-ID für ausgehenden Datenverkehr eingerichtet werden kann.

Schritt 1. Einrichtung des ESPAN-Ziels

Eine Zielgruppe hat die Flow-ID 1.

Unter Fabric > Access Policies > Policies > Troubleshooting > SPAN > SPAN Destination Groups

Konfigurieren Sie für die zweite Zielgruppe die Fluss-ID 2:

Schritt 2a: Erstellen einer Spanning Source für den Datenverkehr, der direkt mit dem SRC verbunden ist

Unter Fabric > Access Policies > Policies > Troubleshooting > SPAN > SPAN Source Groups

Filtern Sie den Datenverkehr mehr, indem Sie den Pfad und die EPG hinzufügen. Das Übungsbeispiel ist Tenant jr Application Profile ALL und EPG app.

Schritt 2b. Erstellen einer Spanning Source für den Datenverkehr, der direkt mit dem DST verbunden ist

Unter Fabric > Access Policies > Policies > Troubleshooting > SPAN > SPAN Source Groups

Filtern Sie den Datenverkehr stärker, indem Sie nicht nur den Pfad, sondern auch die EPG-DB hinzufügen:

Schritt 3: Schnelle Wireshark-Analyse

In diesem Beispiel überprüfen Sie, ob die Anzahl der ICMP-Anforderungspakete mit der Anzahl der ICMP-Antwortpakete übereinstimmt, und stellen sicher, dass es in der ACI-Fabric keine Paketverluste gibt.

Öffnen Sie die Erfassung in Wireshark, um den Filter mithilfe der zusammen mit SRC und DST IP konfigurierten SPAN-ID/Flow-ID zu erstellen:

(erspan.spanid ==

and

) && (ip.src==

and ip.dst ==

)

Filter für den getesteten Fluss:

(erspan.spanid == 1 and icmp) && (ip.src== 10.1.2.1 and ip.dst == 10.1.1.1)

Vergewissern Sie sich, dass das angezeigte Paket den gleichen Betrag wie gesendet hat:

Die nächste SPAN-ID muss den gleichen Betrag aufweisen. Andernfalls wurde das Paket innerhalb der Fabric verworfen.

Filter:

(erspan.spanid == 2 and icmp) && (ip.src== 10.1.2.1 and ip.dst == 10.1.1.1)

Option 2. Plattformzähler

Diese Methode nutzt den Vorteil, dass Nexus die Leistung einzelner Schnittstellen mit unterschiedlichen Paketgrößen verfolgt, dass jedoch mindestens eine Warteschlange einen geringen Datenverkehr, wenn nicht gar null, aufweisen muss.

Plattformzähler löschen

Öffnen Sie den individuellen Switch, und deaktivieren Sie die Schnittstelle, die mit den Geräten verbunden ist.

Switch#vsh_lc -c “clear platform internal counters port

”

LEAF3# vsh_lc -c “clear platform internal counters port 6”

LEAF1# vsh_lc -c “clear platform internal counters port 45”

LEAF2# vsh_lc -c “clear platform internal counters port 45”

Identifizieren einer Paketgröße mit niedrigen oder null Paketen

Suchen Sie nach einer Paketgröße, die möglicherweise keine Zähler in allen Leafs für RX und TX enthält:

vsh_lc -c ‘show platform internal counters port

’ | grep X_PKT

Im nächsten Beispiel ist die Paketgröße größer als 512 und kleiner als 1024:

LEAF101# vsh_lc -c "show platform internal counters port 45 " | grep X_PKT

RX_PKTOK          1187

RX_PKTTOTAL       1187

RX_PKT_LT64          0

RX_PKT_64            0

RX_PKT_65         1179

RX_PKT_128           8

RX_PKT_256           0

RX_PKT_512           0 <<

RX_PKT_1024          0

RX_PKT_1519          0

RX_PKT_2048          0

RX_PKT_4096          7

RX_PKT_8192          43

RX_PKT_GT9216        0

TX_PKTOK          3865

TX_PKTTOTAL       3865

TX_PKT_LT64          0

TX_PKT_64            0

TX_PKT_65         3842

TX_PKT_128          17

TX_PKT_256           6

TX_PKT_512           0 <<

TX_PKT_1024          10

TX_PKT_1519          3

TX_PKT_2048          662

TX_PKT_4096          0

TX_PKT_8192          0

TX_PKT_GT9216        0

Der Schritt muss in der Verbindung ausgeführt werden, an die die Pakete weitergeleitet werden.

Datenverkehrsfluss verfolgen

Vom Server 10.1.2.1 werden 1.000 Pakete mit einer Paketgröße von 520 gesendet.

Überprüfen Sie auf der Leaf 103-Schnittstelle 1/6, wo der Datenverkehr auf RX initiiert wird:

MXS2-LF103# vsh_lc -c "show platform internal counters port 6 " | grep X_PKT_512

RX_PKT_512        1000

TX_PKT_512         647

1000 Paket RX, aber nur 647 wurden als Antwort gesendet.

Der nächste Schritt besteht darin, die ausgehenden Schnittstellen der anderen Server zu überprüfen:

Für Leaf102:

MXS2-LF102# vsh_lc -c "show platform internal counters port 45 " | grep X_PKT_512

RX_PKT_512           0

TX_PKT_512        1000

Die Anforderung wurde vom Fabric nicht verworfen.

Für Leaf 101 ist RX mit 647 verbunden und entspricht der Anzahl an Paketen TX von ACI.

MXS2-LF101#  vsh_lc -c "show platform internal counters port 45 " | grep X_PKT_512

RX_PKT_512        647

TX_PKT_512          0

Zugehörige Informationen

Fehlerbehebung: ACI Intra-Fabric Forwarding - zeitweilige Unterbrechungen