Switched Port Analyzer auf der ACI konfigurieren

Einleitung

In diesem Dokument wird die Konfiguration von Switched Port Analyzer (SPAN) auf der Cisco Application Centric Infrastructure (ACI) beschrieben. 

Hintergrundinformationen

Im Allgemeinen gibt es drei Arten von SPAN. Lokales SPAN, Remote SPAN (RSPAN) und Encapsulated Remote SPAN (ERSPAN). Die Unterschiede zwischen diesen SPANs sind hauptsächlich das Ziel von Kopierpaketen. Die Cisco ACI unterstützt Local SPAN und ERSPAN.

SPAN-Typ in Cisco ACI

Die Cisco ACI umfasst drei SPAN-Typen:  Fabric SPAN, Tenant SPAN und Access SPAN. Der Unterschied zwischen den einzelnen SPANs ist die Quelle der Kopierpakete.

Wie bereits erwähnt,

• Fabric SPAN dient der Erfassung von Paketen, die über Schnittstellen zwischen Leaf- und Spine-Switches ein- und ausgehen.
• Access SPAN dient dazu, eingehende und ausgehende Pakete von Schnittstellen zwischen Leaf-Switches und externen Geräten zu erfassen.
• Tenant-SPAN dient der Erfassung von Paketen, die in eine Endpunktgruppe (EPG) auf ACI-Leaf-Switches eingehen und aus dieser ausgehen.

Dieser SPAN-Name entspricht dem auf der Cisco ACI-GUI zu konfigurierenden Standort.

• Fabric SPAN wird unter Fabric > Fabric Policies (Fabric > Fabric-Richtlinien) konfiguriert.
• Access SPAN wird unter Fabric > Access Policies (Fabric > Zugriffsrichtlinien) konfiguriert.
• Tenant-SPAN wird unter Tenants > {each tenant} konfiguriert.

Was das Ziel jedes SPAN angeht, so kann nur das Zugangs-SPAN sowohl das lokale SPAN als auch das ERSPAN unterstützen. Die beiden anderen SPANs (Fabric und Tenant) sind nur ERSPAN-fähig.

Einschränkungen und Richtlinien

Lesen Sie die Einschränkungen und Richtlinien im Cisco APIC-Fehlerbehebungshandbuch. Sie wird unter Troubleshooting Tools and Methodology > Using SPAN erwähnt.

Konfiguration

In diesem Abschnitt werden kurze Beispiele vorgestellt, die sich auf die Konfiguration für die einzelnen SPAN-Typen beziehen. Im nachfolgenden Abschnitt finden Sie Beispiele für die Auswahl des Spannentyps.

Die SPAN-Konfiguration wird auch im Cisco APIC Troubleshooting Guide beschrieben: Tools und Methoden zur Fehlerbehebung > Verwendung von SPAN

Die Benutzeroberfläche kann sich von der aktuellen Version unterscheiden, die Konfigurationsmethode ist jedoch dieselbe.

Zugangs-SPAN (ERSPAN)

Beispieltopologie

Konfigurationsbeispiel

Dabei gilt:

Navigieren Sie zu FABRIC > ACCESS POLICIES > Troubleshoot Policies > SPAN.

• SPAN-Quellgruppen
• SPAN-Zielgruppen

SPAN Source Group Verbindungen Destination und Sources.

Vorgehensweise:

1. Erstellen Sie eine SPAN-Quellgruppe (SRC_GRP1).
2. Erstellen Sie eine SPAN-Quelle (SRC1) unter SPAN-Quellgruppe (SRC_GRP1).
3. Konfigurieren Sie diese Parameter für die SPAN-Quelle (SRC1).
   - Richtung - Quell-EPG (optional)
   - Quellpfade (können mehrere Schnittstellen sein)
   
   

   Hinweis: Details zu den einzelnen Parametern finden Sie im Bild.

4. Erstellen Sie eine SPAN-Zielgruppe (DST_EPG).
5. Erstellen eines SPAN-Ziels (DST)
6. Konfigurieren Sie diese Parameter für SPAN-Ziel (DST).
   - Ziel-EPG
   -Ziel-IP
   - Quell-IP/Präfix (Dies kann eine beliebige IP sein. Wenn das Präfix verwendet wird, wird die Knoten-ID des Quellknotens für die nicht definierten Bits verwendet. Beispiel: prefix: 1.0.0.0/8 on node-101 => src IP 1.0.0.101)
     - Andere Parameter können als Standard beibehalten werden.
   
   

   Anmerkung: Detaillierte Informationen zu den einzelnen Parametern finden Sie im Bild.

7. Stellen Sie sicher, dass die SPAN-Zielgruppe mit einer geeigneten SPAN-Quellgruppe verknüpft ist.
8. Stellen Sie sicher, dass der Admin-Status aktiviert ist.
   
   

   Anmerkung: SPAN wird beendet, wenn Sie in diesem Admin-Status Disabled (Deaktiviert) auswählen. Es müssen nicht alle Richtlinien gelöscht werden, wenn Sie sie später wiederverwenden.

Stellen Sie außerdem sicher, dass die Ziel-IP-Adresse für ERSPAN als Endpunkt in der angegebenen Ziel-EPG erfasst wird. Im oben genannten Beispiel ist 192.168.254.1 unter Tenant TK > Anwendungsprofil SPAN_APP > EPG SPAN zu erlernen. Die Ziel-IP-Adresse kann auch als statischer Endpunkt unter dieser EPG konfiguriert werden, wenn es sich bei dem Zielgerät um einen unbeaufsichtigten Host handelt.

Zugangs-SPAN (Lokal)

Beispieltopologie

Konfigurationsbeispiel

• Dabei gilt:

Fabric > ACCESS POLICIES > Troubleshoot Policies > SPAN

- SPAN Source Groups

- SPAN Destination Groups

SPAN Source Group Bindungen Destination  und Sources.



• Vorgehensweise:

1. SPAN-Quellgruppe erstellen (SRC_GRP1)
2. Erstellen einer SPAN-Quelle (SRC1) unter SPAN-Quellgruppe (SRC_GRP1)
3. Konfigurieren Sie diese Parameter für die SPAN-Quelle (SRC1).
   -Richtung
   - Quell-EPG (optional)
   - Quellpfade (können mehrere Schnittstellen sein)
   ※ Details zu den einzelnen Parametern finden Sie im Bild.
4. SPAN-Zielgruppe erstellen(DST_Leaf1)
5. Erstellen eines SPAN-Ziels (DST)
6. Konfigurieren Sie diese Parameter für SPAN-Ziel (DST).
   - Zielschnittstelle und Knoten.
7. Stellen Sie sicher, dass die SPAN-Zielgruppe mit einer geeigneten SPAN-Quellgruppe verknüpft ist.

8. Stellen Sie sicher, dass der Administratorstatus aktiviert ist.
   ※ SPAN wird beendet, wenn Sie in diesem Admin-Status Disabled (Deaktiviert) auswählen. Es müssen nicht alle Richtlinien gelöscht werden, wenn Sie sie später wiederverwenden.

Die Zielschnittstelle muss nicht nach Schnittstellen-Richtliniengruppen konfiguriert werden. Sie funktioniert, wenn Sie ein Kabel an die Schnittstelle der ACI-Leaf anschließen.

Einschränkungen:

• Für Local SPAN müssen eine Ziel- und eine Quellschnittstelle auf demselben Leaf konfiguriert werden.
• Für die Zielschnittstelle muss sie sich nicht in einer EPG befinden, solange sie aktiviert ist.
• Wenn die vPC-Schnittstelle (Virtual Port-Channel) als Quellport angegeben ist, kann kein lokales SPAN verwendet werden. 
  Es gibt jedoch einen Workaround. Auf einem Leaf der ersten Generation kann ein einzelner physischer Port, der zu vPC oder PC gehört, als SPAN-Quelle konfiguriert werden. Dadurch kann Local SPAN für den Datenverkehr an vPC-Ports verwendet werden.
  Diese Option ist jedoch auf einem Leaf der zweiten Generation (Cisco Bug-ID CSCvc11053) nicht verfügbar. Stattdessen wurde die SPAN-Unterstützung für "VPC-Komponenten-PC" über die Cisco Bug-ID CSCvc44643 in 2.1(2e), 2.2(2e) und weiter hinzugefügt. Auf diese Weise kann ein beliebiger Generationsknoten einen Port-Channel, der zu vPC gehört, als SPAN-Quelle konfigurieren. Auf diese Weise kann ein beliebiges Generations-Leaf Local SPAN für den Datenverkehr an vPC-Ports verwenden.
• Wenn Sie die einzelnen Ports eines Port-Channels für die zweite Generation festlegen, wird nur eine Teilmenge der Pakete überbrückt (auch aufgrund der Cisco Bug-ID CSCvc11053).
• PC und vPC können nicht als Zielport für das lokale SPAN verwendet werden. Ab 4.1(1) kann der PC als Zielport für Local SPAN verwendet werden.

Zugriff auf SPAN - mit ACL-Filtern

Sie können ACL-Filter für Access Span-Quellen verwenden. Diese Funktion bietet die Möglichkeit, einen bestimmten Datenfluss oder -fluss innerhalb/außerhalb einer SPAN-Quelle per SPAN zu regeln.
Benutzer können die SPAN-ACLs auf eine Quelle anwenden, wenn SPAN-Datenverkehr für bestimmte Datenströme erforderlich ist.
Sie wird in Fabric SPAN- und Tenant Span-Quellgruppen/-quellen nicht unterstützt.
Beim Hinzufügen von Filtereinträgen in einer Filtergruppe ist Vorsicht geboten, da für jede Quelle, die derzeit die Filtergruppe verwendet, tcam-Einträge hinzugefügt werden können.

Eine Filtergruppe kann zugeordnet werden zu:
-Quelle für Spanne: Die Filtergruppe wird verwendet, um Datenverkehr auf ALLEN Schnittstellen zu filtern, die unter dieser Spannenquelle definiert sind.
- Quellgruppe Spanne: Die Filtergruppe (z. B. x) wird zum Filtern des Datenverkehrs auf ALLEN Schnittstellen verwendet, die unter jeder der Spannenquellen dieser Spannenquellengruppe definiert sind.

In diesem Konfigurations-Snapshot wird die Filtergruppe auf die Span-Quellgruppe angewendet.

Wenn eine bestimmte Spanning Source bereits einer Filtergruppe zugeordnet ist (z. B. y), wird stattdessen die Filtergruppe (y) verwendet, um die Gruppe auf allen Schnittstellen unter dieser Spanning Source zu filtern.

- Eine Filtergruppe, die in einer Quellgruppe angewendet wird, wird automatisch auf alle Quellen in dieser Quellgruppe angewendet.
- Eine Filtergruppe, die an einer Quelle angewendet wird, gilt nur für diese Quelle.
- Eine Filtergruppe wird sowohl in der Quellgruppe als auch in einer Quelle in dieser Quellgruppe angewendet, wobei die Filtergruppe, die an der Quelle angewendet wird, Vorrang hat.
- Eine an einer Quelle angewendete Filtergruppe wird gelöscht, und die an der übergeordneten Quellgruppe angewendete Filtergruppe wird automatisch angewendet.
- Eine Filtergruppe, die in einer Quellgruppe angewendet wird, wird gelöscht. Sie wird aus allen Quellen gelöscht, die derzeit in dieser Quellgruppe erben.

Tenant-SPAN (ERSPAN)

Beispieltopologie

Konfigurationsbeispiel

• Dabei gilt:

Tenants > {Tenant-Name} > Problembehandlung bei Richtlinien > SPAN

- SPAN-Quellgruppen

- SPAN-Zielgruppen

※ SPAN-Quellgruppen-Verbindungen Destination und Sources.

• Vorgehensweise:

1. SPAN-Quellgruppe erstellen (SRC_GRP)
2. SPAN-Quelle (SRC_A) unter SPAN-Quellgruppe (SRC_GRP) erstellen
3. Konfigurieren Sie diese Parameter für die SPAN-Quelle (SRC_A).
        -Richtung
        - Quell-EPG
   ※ Details zu den einzelnen Parametern finden Sie im Bild.
4. SPAN-Zielgruppe erstellen (DST_GRP)
5. SPAN-Ziel erstellen (DST_A)
6. Konfigurieren Sie diese Parameter für SPAN-Ziel (DST_A).
        - Ziel-EPG
        -Ziel-IP
        - Quell-IP/Präfix
        - Andere Parameter können als Standard beibehalten werden.
   ※ Details zu den einzelnen Parametern finden Sie im Bild.
7. Stellen Sie sicher, dass die SPAN-Zielgruppe mit einer geeigneten SPAN-Quellgruppe verknüpft ist.
8. Stellen Sie sicher, dass der Administratorstatus aktiviert ist.
   ※ SPAN wird beendet, wenn Sie in diesem Admin-Status Disabled (Deaktiviert) auswählen. Es müssen nicht alle Richtlinien gelöscht werden, wenn Sie sie später wiederverwenden.

Fabric-SPAN (ERSPAN)

Beispieltopologie

Konfigurationsbeispiel

• Dabei gilt:

Fabric > FABRIC-RICHTLINIEN > Fehlerbehebung - Richtlinien > SPAN

- Fabric

- SPAN-Zielgruppen

SPAN-Quellgruppe verknüpft Ziel und Quellen

• Vorgehensweise:

1. SPAN-Quellgruppe erstellen (SRC_GRP)
2. Erstellen einer SPAN-Quelle (SRC_A) unter SPAN-Quellgruppe (SRC_GRP)
3. Konfigurieren Sie diese Parameter für die SPAN-Quelle (SRC_A).
        -Richtung
        - Privates Netzwerk (optional)
        - Bridge-Domäne (optional)
        - Quellpfade (können mehrere Schnittstellen sein)
   ※ Details zu den einzelnen Parametern finden Sie im Bild.
4. SPAN-Zielgruppe erstellen (DST_GRP)
5. SPAN-Ziel erstellen (DST_A)
6. Konfigurieren Sie diese Parameter für SPAN-Ziel (DST_A).
        - Ziel-EPG
        -Ziel-IP
        - Quell-IP/Präfix
        - Andere Parameter können als Standard beibehalten werden.
   ※ Details zu den einzelnen Parametern finden Sie im Bild.
7. Stellen Sie sicher, dass die SPAN-Zielgruppe mit einer geeigneten SPAN-Quellgruppe verknüpft ist.
8. Stellen Sie sicher, dass der Admin-Status aktiviert ist.
   ※ SPAN wird beendet, wenn Sie in diesem Admin-Status Disabled (Deaktiviert) auswählen. Es müssen nicht alle Richtlinien gelöscht werden, wenn Sie sie später wiederverwenden.

Obwohl sie in einem späteren Abschnitt über die ERSPAN-Version (Typ) beschrieben wird, können Sie feststellen, dass ERSPAN-Version II für Fabric SPAN und Version I für Tenant- und Zugangs-SPAN verwendet wird.

GUI-Überprüfung

• Überprüfen der SPAN-Konfigurationsrichtlinie

1. Fabric > ACCESS POLICIES > Troubleshoot Policies > SPAN > SPAN Source Groups > Registerkarte Operational
2. Fabric > FABRIC POLICIES > Troubleshoot Policies > SPAN > SPAN Source Groups > Registerkarte Operational
3. Tenants > {Tenant-Name} > Problembehandlung bei Richtlinien > SPAN > SPAN-Quellgruppen > Registerkarte "Betrieb"

Stellen Sie sicher, dass der Betriebsstatus aktiv ist.

• Überprüfung der SPAN-Sitzung auf dem Knoten selbst

1. Doppelklicken Sie auf jede Sitzung in SPAN Configuration Policy or Fabric > INVENTORY > Node > Span Sessions > { SPAN session name }

Stellen Sie sicher, dass der Betriebsstatus aktiv ist.

Namenskonvention für SPAN-Sitzungen:

     - Fabric-SPAN: Fabric xxxx

     - Zugriff auf SPAN: infra_xxxx
     - Tenant-SPAN: tn xxxx

ACI-SPAN-Typ auswählen

In diesem Abschnitt werden detaillierte Szenarien für jeden ACI-SPAN-Typ (Access, Tenant, Fabric) beschrieben. Die Basistopologie für jedes Szenario wird im vorherigen Abschnitt erwähnt.

Wenn Sie diese Szenarien verstehen, können Sie den für Ihre Anforderungen geeigneten ACI-SPAN-Typ auswählen. Beispielsweise müssen Pakete nur auf bestimmten Schnittstellen oder alle Pakete auf einer bestimmten EPG unabhängig von den Schnittstellen erfasst werden.

In der Cisco ACI wird SPAN mit der Quellgruppe und der Zielgruppe konfiguriert. Die Quellgruppe enthält mehrere Quellfaktoren, z. B. Schnittstellen oder EPG. Die Zielgruppe enthält Zielinformationen wie die Zielschnittstelle für Local SPAN oder Ziel-IP für ESPAN.

Nachdem die Pakete erfasst wurden, lesen Sie den Abschnitt "Lesen von SPAN-Daten", um die erfassten Pakete zu dekodieren.

Zugangs-SPAN (ERSPAN)

Fall 1

Quelle "Leaf1 e1/11 e1/34 & Leaf2 e1/11"  | Dst "192.168.254.1"

• Quellgruppe
  • Leaf1 e1/11
  • Leaf1 e1/34
  • Leaf2 e1/11
• Zielgruppe
  • 192.168.254.1 für EPG X

Access-SPAN kann mehrere Schnittstellen für eine einzelne SPAN-Sitzung angeben. Er kann alle Pakete erfassen, die über bestimmte Schnittstellen eingehen oder austreten, unabhängig von ihrer EPG.

Wenn mehrere Schnittstellen von mehreren Leaf-Switches als Quellgruppe angegeben werden, muss es sich bei der Zielgruppe um ERSPAN und nicht um Local SPAN handeln.

In diesem Beispiel werden Pakete von allen VMs in EPG1 und EPG2 kopiert.

CLI-Prüfpunkt

• Stellen Sie sicher, dass der Status aktiv ist.
• destination-ip ist die Ziel-IP für ERSPAN
• origine-ip ist Quell-IP für ERSPAN

Fall 2

Quelle "Leaf1 e1/11 & Leaf2 e1/11"  | Dst "192.168.254.1"

• Quellgruppe
  • Leaf1 e1/11
  • Leaf2 e1/11
• Zielgruppe
  • 192.168.254.1 für EPG X

In diesem Beispiel wird Leaf1 e1/34 aus der SPAN-Quellgruppe entfernt, die in der vorherigen Case1-Konfiguration konfiguriert wurde.

Der zentrale Punkt in diesem Beispiel ist, dass Access SPAN Quellschnittstellen unabhängig von der EPG angeben kann.

CLI-Prüfpunkt:

• Die Quellschnittstelle auf Leaf1 wird von "Eth1/11 Eth1/34" in "Eth1/11 Eth1/11" geändert.

Fall 3

Quelle: "Leaf1 e1/11 & Leaf2 e1/11 & EPG1 filter"  | Dst "192.168.254.1"

• Quellgruppe
  • Leaf1 e1/11
  • Leaf2 e1/11
  • Filter-EPG1
• Zielgruppe
  • 192.168.254.1 für EPG X

Dieses Beispiel zeigt, dass Access SPAN auch eine bestimmte EPG auf den Quell-Ports angeben kann. Dies ist nützlich, wenn mehrere EPGs auf einer Schnittstelle übertragen werden und der Datenverkehr nur für EPG1 auf dieser Schnittstelle erfasst werden muss.

Da EPG1 auf Leaf2 nicht bereitgestellt wird, schlägt SPAN für Leaf2 mit den Fehlern F1553 und F1561 fehl. SPAN auf Leaf1 funktioniert jedoch weiterhin.

Außerdem werden automatisch zwei VLAN-Filter für die SPAN-Sitzung auf Leaf1 hinzugefügt, da EPG1 zwei VLANs (VLAN-751.752) auf Leaf1 verwendet.

Beachten Sie, dass die VLAN-ID auf CLI (35, 39) die interne VLAN-ID (PI-VLAN (Platform Independent VLAN)) ist, die nicht die tatsächliche ID auf der Leitung ist. Wie in der Abbildung dargestellt, zeigt der Befehl show vlan extended die Zuordnung der tatsächlichen VLAN-ID des Encaps und des IP-VLAN.

Mit dieser SPAN-Sitzung können Pakete nur für EPG1 (VLAN-752) auf Leaf1 e1/11 erfasst werden, obwohl EPG2 (VLAN-753) über dieselbe Schnittstelle übertragen wird.

CLI-Prüfpunkt:

• Filter-VLANs werden gemäß den für den Filter verwendeten EPGs hinzugefügt.
• Wenn auf dem Leaf keine entsprechenden EPGs vorhanden sind, schlägt die SPAN-Sitzung auf diesem Leaf fehl.

Fall 4

Quelle "Leaf1-Leaf2 vPC"  | Dst "192.168.254.1"

• Quellgruppe
  • Leaf1 - 2e1/11
• Zielgruppe
  • 192.168.254.1 für EPG X

Wenn die vPC-Schnittstelle als Quelle konfiguriert ist, muss ein Ziel die Remote-IP (ERSPAN) und nicht die Schnittstelle (Local SPAN) sein

Zugangs-SPAN (Lokales SPAN)

Fall 1

Quelle "Leaf1 e1/11 e1/34"  | Ziel "Leaf1 e1/33"

• Quellgruppe
  • Leaf1 e1/11
  • Leaf1 e1/34
• Zielgruppe
  • Leaf1 e1/33

Access SPAN kann auch Local SPAN verwenden (d. h. eine bestimmte Schnittstelle als Ziel).

In diesem Fall müssen sich die Quellschnittstellen jedoch auf demselben Leaf befinden wie die Zielschnittstelle.

Fall 2

Quelle "Leaf1 e1/11 e1/34 & EPG1 filter  | DST " Leaf1 e1/33"

• Quellgruppe
  • Leaf1 e1/11
  • Leaf1 e1/34
  • EPG1-Filter
• Zielgruppe
  • Leaf1 e1/33

Access SPAN mit Local SPAN kann auch den EPG-Filter sowie ERSPAN verwenden.

Fall 3

Quelle "Leaf1 e1/11 & Leaf2 e/11"  | Dst "Leaf1 e1/33" (schlechter Fall)

• Quellgruppe
  • Leaf1 e1/11
  • Leaf2 e1/11
• Zielgruppe
  • Leaf1 e1/33

Fall 4

Quelle: "Leaf1 e1/11 & EPG3 filter"  | Dst "Leaf1 e1/33" (schlechter Fall)

• Quellgruppe
  • Leaf1 e1/11
  • EPG3-Filter
• Zielgruppe
  • Leaf1 e1/33

Dies ähnelt Fall 3 bei Access SPAN (ERSPAN), aber in diesem Beispiel schlägt die einzige SPAN-Sitzung auf Leaf1 fehl, da EPG3 auf Leaf1 nicht vorhanden ist. SPAN funktioniert also überhaupt nicht.

Fall 5

Quelle "EPG1 filter"  | Dst "Leaf1 e1/33" (schlechter Fall)

• Quellgruppe
  
  • EPG1-Filter
• Zielgruppe
  • Leaf1 e1/33

Der EPG-Filter für Access SPAN funktioniert nur, wenn Quell-Ports konfiguriert sind. Wenn EPG als einzige Quelle angegeben wird, muss Tenant-SPAN anstelle von Access-SPAN verwendet werden.

Fall 6

Quelle "Leaf1 - Leaf2 vPC"  | Dst "Leaf1 e1/33" (schlechter Fall)

• Quellgruppe
  
  • Leaf1-2 vPC
• Zielgruppe
  • Leaf1 e1/33

Eine vPC-Schnittstelle kann nicht als Quelle mit Local SPAN konfiguriert werden. Verwenden Sie ERSPAN. Informationen zu Access SPAN (ERSPAN) finden Sie in case4.

Fall 7

Quelle "Leaf1 e1/11  | Dst "Leaf1 e1/33 & e1/33 gehört zur EPG" (arbeitet fehlerhaft)

Wenn ein Ziel-I/F für SPAN bereits zur EPG gehört, wird der Fehler "F1696 : Port hat eine ungültige Konfiguration von "EPG" und "span destination" wird unter der physischen E/A ausgelöst.

Aber selbst bei diesem Fehler funktioniert SPAN problemlos. Dieser Fehler ist nur eine Warnung vor zusätzlichem Datenverkehr, der durch SPAN verursacht wird, da er sich auf den normalen EPG-Datenverkehr von Kunden auf derselben E/A-Schnittstelle auswirken kann.

Tenant-SPAN (ERSPAN)

Fall 1

Quelle "EPG1"  | Dst "192.168.254.1"

• Quellgruppe
  
  • EPG1 (kein Filter)
• Zielgruppe
  • 192.168.254.1 für EPG X

Tenant-SPAN verwendet die EPG selbst als Quelle, während Access-SPAN die EPG nur als Filter verwendet.

Der Hauptvorteil von Tenant SPAN besteht darin, dass Sie nicht jeden einzelnen Port angeben müssen, und dass die ACI automatisch die entsprechenden VLANs auf jedem Leaf-Switch erkennt. Dies ist nützlich, wenn alle Pakete für eine bestimmte EPG überwacht werden müssen und die Endpunkte für diese EPG mehreren Schnittstellen über Leaf-Switches angehören.

Fabric-SPAN (ERSPAN)

Fall 1

Quelle "Leaf1 e1/49-50"  | Dst "192.168.254.1"

• Quellgruppe
  
  • Leaf1 e1/49-50
• Zielgruppe
  • 192.168.254.1 für EPG X

Fabric SPAN gibt Fabric-Ports als Quelle an, wobei Fabric-Ports Schnittstellen zwischen Leaf- und Spine-Switches sind.

Dieses SPAN ist nützlich, wenn Pakete zwischen Leaf- und Spine-Switches kopiert werden müssen. Pakete zwischen Leaf- und Spine-Switches werden jedoch mit dem iVxLAN-Header gekapselt. Es ist also ein kleiner Trick nötig, um es zu lesen. Weitere Informationen finden Sie unter "Lesen von SPAN-Daten".

Fall 2

Quelle: "Leaf1 e1/49-50 & VRF-Filter"  | Dst "192.168.254.1"

• Quellgruppe
  
  • Leaf1 e1/49-50
  • VRF-Filter
• Zielgruppe
  • 192.168.254.1 für EPG X

Fabric SPAN kann Filter sowie Access SPAN verwenden. Der Filtertyp ist jedoch anders. Fabric SPAN verwendet Virtual Routing and Forwarding (VRF) oder BD als Filter.

Wie bereits beschrieben, werden in der Cisco ACI Pakete, die Fabric-Ports durchlaufen, mit einem iVxLAN-Header verkapselt. Dieser iVxLAN-Header enthält VRF- oder BD-Informationen als Virtual Network Identifier (VNID). Wenn Pakete als Layer 2 (L2) weitergeleitet werden, steht "iVxLAN VNID" für "BD". Wenn Pakete als Layer 3 (L3) weitergeleitet werden, steht iVxLAN VNID für VRF.

Wenn es also erforderlich ist, gerouteten Verkehr an Fabric-Ports zu erfassen, sollten Sie VRF als Filter verwenden.

Fall 3

Quelle: "Leaf1 e1/49-50 & BD filter"  | Dst "192.168.254.1"

• Quellgruppe
  
  • Leaf1 e1/49-50
  • BD-Filter
• Zielgruppe
  • 192.168.254.1 für EPG X

Wie im vorherigen Fall 2 beschrieben, kann Fabric SPAN BD als Filter verwenden.

Wenn Bridge-Datenverkehr an Fabric-Ports erfasst werden soll, sollte BD als Filter verwendet werden.

Spanne bis CPU

• Diese Funktion ist ab Version 6.2(1) und höher verfügbar.
• Stellt eine SPAN-Zieloption bereit, die gespiegelten Datenverkehr an den CPU-Port (sup-eth0) des Leaf-Switches anstatt an einen externen Collector sendet.
• Enthält eine integrierte Durchsatzbegrenzung, um zu verhindern, dass der SPAN-Datenverkehr die CPU überlastet.
• SPAN-Statistiken (-HX only): Ein Statistikbefehl auf Switches der HX-Plattform bestätigt, dass der Datenverkehr auf die CPU gespiegelt wird.

Konfigurationsschritte

• Erstellen einer neuen SPAN-Zielgruppe
• Wenn Sie die Zielschnittstelle angeben, können Sie sup-eth0 (den CPU-Port) als Ziel auswählen oder eingeben.
• Ordnen Sie diese Zielgruppe einer SPAN-Quellgruppe zu (diese definiert den zu spiegelnden Datenverkehr).

Video-Link:

https://community.cisco.com/t5/data-center-and-cloud-knowledge-base/aci-span-to-cpu-in-cisco-aci/ta-p/5372105

Unterstützte Plattformen

SPAN zu CPU wird nur auf diesen Plattformen unterstützt. Diese Liste ist nicht statisch und kann sich mit der Zeit ändern.

• FX2 
• FX3 
• GX
• GX2 
• HX 

SPAN-Statistikunterstützung

• Nur HX

Es gibt keine CLI zur Überprüfung der Policer-Rate. Sie ist mit 500 Kbit/s fest codiert.

Einschränkungen und Einschränkungen

Lesen Sie die Versionsinformationen, z. B. Cisco APIC Basic Configuration Guide, Version 6.2(x).

• SPAN zu CPU wird nur für ACL-basiertes SPAN unterstützt, nicht für Port-basiertes SPAN. Das bedeutet, dass SPAN zu CPU im Skalierungsmodus nicht unterstützt wird, sondern nur im Filtermodus.
• Cisco Nexus Switches der Serie 9000 FX2 und höher unterstützen die SPAN-to-CPU-Funktion
• Wenn diese Funktion auf nicht unterstützten Switches konfiguriert ist, wird ein Fehler ausgelöst. Überprüfen Sie die Registerkarte Faults (Fehler) unter System > Faults (System > Fehler) in der APIC-GUI.
• Fabric- und vPC-Ports auf dem Leaf werden nicht als Quellschnittstelle der SPAN-CPU-Sitzung unterstützt. Verwenden Sie für vPC-Ports den Pfadtyp "VPC component PC" als Quelle pro Switch anstelle von "Virtual Port Channel".
• Nur Access-Port und Access-Port-Channels werden unterstützt. kann ein Layer-2- oder Layer-3-Port sein.
• TX-Multicast wird nicht unterstützt.
• Im Fall einer gemeinsamen Nutzung der Quelle zwischen SPAN und CPU-Sitzung und anderen Sitzungen wird die Richtlinie auf beide Sitzungen angewendet. Es wird daher nicht empfohlen, Quellen für SPAN-to-CPU-Sitzungen mit anderen Sitzungen zu teilen.

Konfigurationszusammenfassung

Wie bei der Konfiguration von lokalem SPAN konfigurieren Sie Folgendes:

• Eine Quellgruppe mit einem Zugriffsport als Quellpfad
• Eine Zielgruppe, deren Ziel sup-eth0 ist.

Der einzige Unterschied zu einem typischen lokalen SPAN-Ziel besteht darin, sup-eth0 als Zielschnittstelle auszuwählen.

Schritt 1: Konfigurieren von SPAN zur CPU in der GUI

Klicken Sie auf Fabric > Access Policies > Troubleshooting > SPAN > SPAN Destination Groups.

 

Spanning-Konfiguration mit Quell-, Ziel- und Filterinformationen:

Phase 2: Überprüfen der SPAN-Sitzung auf dem Blatt

Wie bei jeder SPAN-Konfiguration können Sie Sitzungen mit der Switch-CLI überprüfen:

leaf103# show monitor session all
<snip>
 session 5
---------------
name : spansource_vpc_component
description : Span session 5
type : sup
scale-mode : filter
state : up (active)
mode : access
Filter Group : 4
source intf :
rx : [Po3, FG:4] 
tx : [Po3, FG:4] 
both : [Po3, FG:4] 
source VLANs :
rx : 
tx : 
both : 
filter VLANs : filter not specified
filter L3Outs : filter not specified
destination ports : sup-eth0
tx :
both :
filter VLANs : filter not specified
filter L3Outs : filter not specified
destination ports : sup-eth0

Schritt 3: Überprüfen des angewendeten Filters

Überprüfen Sie die auf dem Leaf-Switch programmierten Filtereinträge:

leaf103# show monitor filter 4
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Filter name (id): interandintraepg (4)
Filter Entries:
Src IP                                          Dst IP                                          Src port        Dst port           Proto             dscp           dot1p               Routeable       tcpflags
------                                          ------                                          --------        --------           -----             ----           -----               ----------      ---------
10.1.121.0/24                                   10.1.130.0/24                                   -               -                  -                 -              -                   both
10.1.121.0/24                                   10.1.121.0/24                                   -               -                  -                 -              -                   both
10.1.130.0/24                                   10.1.121.0/24                                   -               -                  -                 -              -                   both
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Schritt 4: SPAN-Statistik für HX überprüfen

Zähler für gespiegelte Pakete pro Sitzung zeigen an, ob der Datenverkehr übereinstimmt und gespiegelt wird. Nur Switches der HX-Plattform.

aci-HX-leaf# vsh_lc
module-1# show platform internal hal span session all stats
SPAN hardware session id:30 asic:0 slice:0 packet counts:2557
SPAN hardware session id:31 asic:0 slice:0 packet counts:510634359

Schritt 5: Erfassung und Dekodierung von SPAN-Datenverkehr auf dem Leaf

Nach der Konfiguration alle übereinstimmenden Zugriffe (Beispiel: ICMP zwischen den Subnetzen, die eth1/4 durchlaufen, wird über SPAN an die CPU übertragen.

Wo ist der SPAN-Datenverkehr zu sehen?

• Der SPAN-Datenverkehr kann mithilfe von tcpdump an der tahoe0-Schnittstelle erfasst werden.

• Es kann mit dem integrierten Skript decodiert und gefiltert werden:

  • /isan/utils/span_to_cpu_parser.py

Beispielerfassung und -dekodierung

Das Erfassungsbeispiel stammt aus einer anderen Konfiguration als im Konfigurationsabschnitt gezeigt.

pod16-leaf3# tcpdump -xxxvi tahoe0 | python3 isan/utils/span_to_cpu_parser.py --decoder tahoe --verbose --payload
tcpdump: listening on tahoe0, link-type EN10MB (Ethernet), capture size 262144 bytes
Frame 9 
Time: 1970-01-01T19:01:53.944622+00:00
ieth-extn:
sup_code=0x2b sup_qnum=0x6
<snipped>
icmp-request(8): id:0x7710, seq:0xf00
Payload:
Internal Header:
0x0000: 0101 0101 0101 0000 0000 0000 a00e 0000 ................
0x0010: 0404 0404 8889 0000 0000 ae00 0000 0006 ................
0x0020: 2b00 0000 fb00 0000 003f ffff ffc0 0000 +........?......
0x0030: 1000 0000 ....
Frame Data:
0x0000: 0022 bdf8 19ff acf2 c5f8 2e01 8100 0a6d .".............m
0x0010: 0800 4500 0054 ff89 0000 ff01 aec9 c0a8 ..E..T..........
0x0020: 7802 c0a8 1402 0800 a049 7710 0f00 114e x........Iw....N
0x0030: 5d69 7f67 0e00 cdab 0000 cdab 0000 cdab ]i.g............
0x0040: 0000 cdab 0000 cdab 0000 cdab 0000 cdab ................
0x0050: 0000 cdab 0000 cdab 0000 cdab ............

Anmerkung: span_to_cpu_parser.py ist knet_parser.py mit einer zusätzlichen Funktion zum Filtern von Paketen mit ISTACK_SUP_CODE_SPAN(0x2b) (SPAN-Datenverkehr).

Speichern der Ausgabe in einem PCAP

Sie können die dekodierte Ausgabe in einer pcap-Datei speichern, indem Sie die Option —write verwenden:

pod16-leaf3# tcpdump -xxxvi tahoe0 | python3 /isan/utils/span_to_cpu_parser.py --decoder tahoe --write /data/techsupport/mualshei-SPAN-CPU.pcap
tcpdump: listening on tahoe0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
Bye!
659 packets captured
662 packets received by filter
0 packets dropped by kernel

Dann lesen Sie es zurück:

pod16-leaf3# tcpdump -r /data/techsupport/mualshei-SPAN-CPU.pcap
reading from file /data/techsupport/mualshei-SPAN-CPU.pcap, link-type EN10MB (Ethernet)
20:07:43.966489 IP truncated-ip - 10 bytes missing! 192.168.120.2 > 192.168.20.2: ICMP echo request, id 30480, seq 27905, length 64
20:07:43.966901 IP truncated-ip - 10 bytes missing! 192.168.20.2 > 192.168.120.2: ICMP echo reply, id 30480, seq 27905, length 64
20:07:44.966505 IP truncated-ip - 10 bytes missing! 192.168.120.2 > 192.168.20.2: ICMP echo request, id 30480, seq 28161, length 64
20:07:44.966843 IP truncated-ip - 10 bytes missing! 192.168.20.2 > 192.168.120.2: ICMP echo reply, id 30480, seq 28161, length 64

Probleme

• SPAN-Sitzung unterbrochen/no-oper-src-dst: Vergewissern Sie sich, dass die Quellschnittstelle betriebsbereit ist, die Plattform die SPAN-zu-CPU-Funktion und eine unterstützte Quelle unterstützt.
• Nicht verfügbarer ZielpfadEp-Fehler: Validierung der unterstützten Versionen von APIC und Leaf-Switches und Sicherstellung, dass die Plattform die Funktionen SPAN-zu-CPU unterstützt
• Keine Pakete in diesem Port0 beobachtet: Bestätigen Sie, dass der Sitzungsstatus aktiv ist (aktiv), bestätigen Sie, dass der Filter richtig ist und der Datenverkehr übereinstimmt, stellen Sie sicher, dass Sie den Filtermodus verwenden, und bestätigen Sie, dass das Ziel sup-eth0 ist und die Sitzung SPAN für lokalen Zugriff ist (nicht Spine/keine Fabric/keine vPC-Quelle).

Was benötigen Sie auf dem SPAN-Zielgerät?

Führen Sie einfach eine Paketerfassungsanwendung wie tcpdump, wireshark auf ihr aus. Es ist nicht erforderlich, die ERSPAN-Zielsitzung zu konfigurieren.

Für ERSPAN

Stellen Sie sicher, dass auf der Schnittstelle mit der Ziel-IP für ERSPAN ein Erfassungstool ausgeführt wird, da SPAN-Pakete an die Ziel-IP weitergeleitet werden.

Das empfangene Paket wird mit einem GRE-Header gekapselt. Informationen zum Decodieren des ERSPAN GRE-Headers finden Sie im Abschnitt "Lesen von ERSPAN-Daten".

Für lokales SPAN

Stellen Sie sicher, dass auf der Schnittstelle, die mit der SPAN-Zielschnittstelle auf dem ACI-Leaf verbunden ist, ein Erfassungstool ausgeführt wird.

Rohpakete werden über diese Schnittstelle empfangen. es ist nicht erforderlich, den ERSPAN-Header zu bearbeiten.

Lesen von ERSPAN-Daten

ERSPAN-Version (Typ)

ERSPAN kapselt kopierte Pakete, um sie an das Remote-Ziel weiterzuleiten. GRE wird für diese Kapselung verwendet. Der Protokolltyp für ERSPAN auf dem GRE-Header ist 0x88be.

Im Dokument der Internet Engineering Task Force (IETF) wird die ERSPAN-Version als Typ und nicht als Version beschrieben.

Es gibt drei Arten von ERSPAN. I, II und III. Der ERSPAN-Typ wird in diesem RFC-Entwurf erwähnt. Außerdem kann dieser GRE-RFC1701 hilfreich sein, um jeden ERSPAN-Typ zu verstehen.

Nachfolgend finden Sie das Paketformat der einzelnen Typen:

ERSPAN Typ I (von Broadcom Trident 2 verwendet)

Bei Typ I wird das Sequenzfeld im GRE-Header nicht verwendet. Er verwendet nicht einmal den ERSPAN-Header, der auf den GRE-Header folgen muss, wenn es sich um ERSPAN Typ II und III handelt. Broadcom Trident 2 unterstützt nur diesen ERSPAN Typ I.

ERSPAN Typ II oder III

Wird das Sequenzfeld durch das S-Bit aktiviert, so muss dies ERSPAN Typ II oder III sein. Das Versionsfeld im ERSPAN-Header gibt den ERSPAN-Typ an. In der ACI wird Typ III ab dem 20.03.2016 nicht mehr unterstützt.

Wenn eine SPAN-Quellgruppe für Access- oder Tenant-SPAN Quellen auf Knoten der 1. und 2. Generation aufweist, empfängt das ERSPAN-Ziel sowohl ERSPAN-Pakete vom Typ I als auch von Typ II von jeder Generation von Knoten. Wireshark kann jedoch jeweils nur einen der ERSPAN-Typen decodieren. Standardmäßig wird nur ERSPAN Typ II dekodiert. Wenn Sie die Dekodierung von ERSPAN Typ I aktivieren, dekodiert Wireshark ERSPAN Typ II nicht. Weitere Informationen zum Decodieren von ERSPAN Typ I in Wireshark finden Sie im nachfolgenden Abschnitt.

Um diese Art von Problem zu vermeiden, können Sie den ERSPAN-Typ für eine SPAN-Zielgruppe konfigurieren.

• SPAN-Version (Version 1 oder Version 2): Dies bezieht sich auf den ERSPAN-Typ I oder II
• SPAN-Version erzwingen (aktiviert oder deaktiviert): Diese entscheidet, ob die SPAN-Sitzung fehlschlagen muss, falls der konfigurierte ERSPAN-Typ nicht von der Quellknotenhardware unterstützt wird.

Standardmäßig ist SPAN-Version 2, und SPAN-Version erzwingen ist deaktiviert. Wenn es sich beim Quellknoten um einen Knoten der 2. Generation oder höher handelt, der ERSPAN Typ II unterstützt, generiert er ERSPAN mit Typ II. Wenn der Quellknoten der 1. Generation angehört, die ERSPAN Typ II nicht unterstützt (mit Ausnahme von Fabric SPAN), fällt er auf Typ I zurück, da die SPAN-Version erzwingen nicht aktiviert ist. Dadurch erhält das ERSPAN-Ziel einen gemischten ERSPAN-Typ.

In dieser Tabelle werden die einzelnen Kombinationen für Access und Tenant-SPAN erläutert.

SPAN-Version	SPAN-Version erzwingen	Quellknoten der 1. Generation	Quellknoten der 2. Generation
Version 2	Deaktiviert	Verwendet Typ I	Verwendet Typ II
Version 2	Aktiviert	Fehlschläge	Verwendet Typ II
Version 1	Deaktiviert	Verwendet Typ I	Verwendet Typ I
Version 1	Aktiviert	Verwendet Typ I	Verwendet Typ I

ERSPAN-Datenbeispiel

Tenant-SPAN/Zugangs-SPAN (ERSPAN)

Pakete müssen decodiert werden, da sie von ERSPAN Typ I gekapselt werden. Dies ist mit Wireshark möglich. Weitere Informationen finden Sie im Abschnitt "Decodierung von ERSPAN-Typ 1".

Details des erfassten Pakets (ERSPAN-Typ I)

Fabric-SPAN (ERSPAN)

Wireshark decodiert automatisch ERSPAN Typ II. Sie wird jedoch weiterhin vom iVxLAN-Header gekapselt.

Standardmäßig versteht Wireshark den iVxLAN-Header nicht, da es sich um einen internen ACI-Header handelt. Weitere Informationen finden Sie unter How to Decode iVxLAN Header.

Details des erfassten Pakets (ERSPAN Typ II)

Dekodierung von ERSPAN Typ I

Option 1. Navigieren Sie zu Edit > Preference > Protocols > ERSPAN, und aktivieren Sie FORCE, um den gefälschten ERSPAN-Frame zu decodieren.

• Wireshark (GUI)

• Tshark (CLI-Version von Wireshark):

user1@linux# tshark -f 'proto GRE' -nV -i eth0 -o erspan.fake_erspan:true

Option 2. Navigieren Sie zu Decode As > Network > ICMP (if it’s ICMP).

So dekodieren Sie den iVxLAN-Header

Der iVxLAN-Header verwendet den Zielport 48879. Sie können also sowohl den iVxLAN-Header als auch das VxLAN dekodieren, wenn Sie den UDP-Zielport 48879 in Wireshark als VxLAN konfigurieren.

1. Stellen Sie sicher, dass Sie zuerst VLAN-gekapselte Pakete auswählen.
2. Navigieren Sie zu Analyze > Decode As > Transport > UDP destination (48879) > VxLAN.
3. Und dann bewerben.

Wenn Sie eine Spanning-Erfassung in einem Anwendernetzwerk durchführen, in dem Precision Time Protocol (PTP) ausgeführt wird, kann es vorkommen, dass Wireshark die Daten aufgrund eines unbekannten Ethertyps innerhalb des GRE-Encaps (0x8988) nicht interpretiert. 0x8988 ist der Ethertyp für das Zeitkennzeichen, das bei aktiviertem PTP in Dataplane-Pakete eingefügt wird. Decodieren Sie den Ethertyp 0x8988 als "Cisco Tag", um die Paketdetails aufzudecken.

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
3.0	07-Oct-2026	Neuformatierung
2.0	06-Aug-2024	Umbenannt in "Aktionsaufruf"-WortEntferntes 'Follow'Aktualisiertes MDF-Tag
1.0	01-Feb-2023	Erstveröffentlichung