Site icon bintorosoft.com

SPAN/ERSPAN im VXLAN-Fabric: Best Practices für PCAP

Red Snapper

SPAN/ERSPAN im VXLAN-Fabric ist eines der wichtigsten Werkzeuge, wenn Sie für Troubleshooting oder Security-Forensik wirklich ein PCAP benötigen. Gleichzeitig ist es in Overlays deutlich anspruchsvoller als in klassischen VLAN-Topologien: Sie müssen entscheiden, ob Sie den Traffic „innerhalb“ des Overlays (inner payload) oder „außen“ im Underlay (encapsulated) spiegeln, wie Sie VTEPs, VNIs und VRFs richtig zuordnen und wie Sie vermeiden, dass die Spiegelung selbst zum Problem wird (Drops, CPU-Spikes, MTU-Fallen, unvollständige PCAPs). In einer VXLAN-Fabric ist die Datenebene meist ECMP-basiert, Traffic verteilt sich über mehrere Pfade, und viele Symptome sind pfadspezifisch (z. B. nur bestimmte Flows, nur große Pakete, nur nach Failover). Ein schlechtes SPAN/ERSPAN-Setup liefert dann scheinbar „widersprüchliche“ Captures: mal sieht man nur ARP/ND, mal nur Retransmissions, mal fehlen ganze Richtungen des Flows. Best Practices für PCAP in einer VXLAN-Fabric bedeuten deshalb: erst den Beobachtungspunkt korrekt wählen (wo im Fabric ist die Wahrheit?), dann die Spiegelung mit klaren Filtern und Ressourcenlimits umsetzen, und anschließend die Capture-Daten so interpretieren, dass Underlay und Overlay nicht vermischt werden. Dieser Leitfaden erklärt praxisnah, wie Sie SPAN (lokal) und ERSPAN (remote) im VXLAN-Fabric sicher einsetzen, welche häufigen Fehlerbilder auftreten, wie Sie mit Encapsulation umgehen, wie Sie Bandbreite und MTU kalkulieren und wie eine einsatzbereite Checkliste für PCAP-Aufnahmen aussieht.

Begriffe und Abgrenzung: SPAN, RSPAN und ERSPAN

In der Praxis werden mehrere Begriffe vermischt, die operativ unterschiedliche Anforderungen haben:

Für ERSPAN als standardisierten Ansatz ist RFC 7169 eine relevante Referenz. Für VXLAN-Overlays ist RFC 7348 der grundlegende Einstieg. Wenn Ihr Fabric EVPN als Control Plane nutzt, ist RFC 7432 die zentrale Grundlage.

Warum SPAN/ERSPAN in VXLAN anders ist als in klassischem VLAN

In einem klassischen VLAN-Netz ist der Beobachtungspunkt relativ eindeutig: Spiegeln Sie am Access-Port, sehen Sie den Host-Traffic; spiegeln Sie am Trunk, sehen Sie VLAN-getaggte Frames. In VXLAN haben Sie mindestens zwei Perspektiven:

Das führt zu vier praktischen Konsequenzen:

Die wichtigste Entscheidung: Wo wollen Sie spiegeln?

Best Practices beginnen nicht mit „ERSPAN konfigurieren“, sondern mit der Frage: Welche Hypothese wollen Sie beweisen oder widerlegen? Daraus folgt der richtige Mirror-Point. In VXLAN-Fabrics haben sich diese Beobachtungspunkte bewährt:

Option A: Access-Port (Host/Server) spiegeln

Option B: VTEP/Leaf-Port Richtung Underlay spiegeln

Option C: SVI/Anycast Gateway spiegeln

Option D: Service-Nodes (Firewall/LB) spiegeln

SPAN vs. ERSPAN im Fabric: Wann welche Methode sinnvoll ist

Als Faustregel gilt: SPAN ist einfacher und zuverlässiger, wenn Sie lokal sammeln können. ERSPAN ist skalierbarer, wenn Sie zentral sammeln müssen oder wenn Sie mehrere Geräte/Pods bedienen wollen. In VXLAN-Fabrics ist ERSPAN besonders nützlich, weil Sie Captures in einem zentralen Packet-Broker oder in einem Analyzer-Cluster konsolidieren können.

Encapsulation verstehen: Welche PCAP-Perspektive brauchen Sie?

In VXLAN können Sie (je nach Plattform) entweder den Traffic vor Encapsulation (inner) oder nach Encapsulation (outer) spiegeln. Für saubere Interpretation ist es hilfreich, diese Perspektiven klar zu benennen:

Ein häufiger Operativfehler ist, inner und outer in einem Capture zu vermischen und dann falsch zu interpretieren. Definieren Sie daher vor dem Start: „Ich will inner sehen“ oder „Ich will outer sehen“ – und wählen Sie Mirror-Point und Filter entsprechend.

Filtern ist Pflicht: Sonst wird PCAP unbrauchbar oder gefährlich

In Fabrics sind Linkraten hoch. Ungefiltertes SPAN/ERSPAN kann Ports überfahren, Mirror-Queues füllen, Analyzer-Storage sprengen und im Worst Case selbst Drops oder CPU-Spikes auslösen. Best Practice ist daher: immer so früh wie möglich filtern und die Capture-Dauer begrenzen.

Filter-Strategien, die sich bewährt haben

Bandbreite und Overhead: Warum Mirror-Traffic häufig unterschätzt wird

SPAN/ERSPAN vervielfacht Traffic: Alles, was Sie spiegeln, wird zusätzlich auf den Mirror-Port oder in den ERSPAN-Tunnel kopiert. Das ist kein theoretisches Problem, sondern eine direkte Kapazitätsfrage – auf dem Switch, auf dem Underlay und auf dem Collector.

Mirror-Last als einfache Abschätzung (MathML)

MirrorRate ≈ CapturedRate × ReplicationFactor

Bei klassischem SPAN ist der ReplicationFactor meist 1 (ein zusätzlicher Output). Bei komplexeren Szenarien (z. B. mehrere Sources, bidirektional, mehrere Sessions) kann er effektiv höher sein. Für ERSPAN kommt zusätzlich Encapsulation-Overhead hinzu.

ERSPAN-Transport mit Overhead (MathML)

ERSPANTransportRate ≈ MirrorRate + EncapOverheadRate

Die praktische Konsequenz: Wenn Sie 1 Gbit/s spiegeln, müssen Switch und Collector mehr als 1 Gbit/s verarbeiten können. In VXLAN-Fabrics ist es daher oft sinnvoll, das Capture sehr eng zu filtern und mit kurzen Fenstern zu arbeiten.

MTU-Fallen: VXLAN plus ERSPAN kann zusätzliche Drops erzeugen

Wenn Sie outer Traffic spiegeln (VXLAN encapsulated) und ihn dann zusätzlich via ERSPAN transportieren, addieren sich Overheads. Je nach Pfad kann das zu Fragmentierung oder Drops führen – und zwar im Mirror-Stream, nicht im Originaltraffic. Das ist besonders gefährlich, weil Sie dann „Drops im PCAP“ sehen und fälschlich glauben, es seien Drops im Produktivtraffic.

Für PMTUD-Grundlagen sind RFC 1191 (IPv4) und RFC 8201 (IPv6) relevante Referenzen.

ECMP und „unvollständige PCAPs“: Warum Sie oft nur einen Teil des Traffics sehen

In Fabrics ist ECMP normal. Das bedeutet: Ein Flow kann über verschiedene Underlay-Pfade laufen, und je nachdem, wo Sie spiegeln, sehen Sie nur den Anteil, der über diesen Link/Port läuft. Häufige Folgen:

Best Practices gegen diese Falle:

ERSPAN Best Practices: Transport, Sicherheit und Collector-Design

ERSPAN verschickt Ihre Mirror-Daten über das Netzwerk. Das ist praktisch, bringt aber Sicherheits- und Betriebsfragen mit sich.

Transport-Best Practices

Sicherheits-Best Practices

Collector- und Tooling-Best Practices

PCAP im VXLAN-Fabric interpretieren: typische Analysefehler vermeiden

Die häufigsten Fehlinterpretationen entstehen durch Verwechslung von Overlay und Underlay oder durch Mirror-spezifische Drops.

Praxis-Runbook: SPAN/ERSPAN für VXLAN-PCAP Schritt für Schritt

Dieses Runbook ist absichtlich generisch gehalten. Es funktioniert, wenn Sie systematisch entscheiden, was Sie sehen wollen und wie Sie es sicher sammeln.

Schritt: Ziel definieren

Schritt: Beobachtungspunkt wählen

Schritt: Filter und Limits setzen

Schritt: Capture durchführen und sofort validieren

Schritt: Korrelation mit Telemetrie

Validierungs-Checkliste: Best Practices für PCAP via SPAN/ERSPAN im VXLAN-Fabric

Outbound-Ressourcen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version