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

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:

• SPAN: lokale Port-Spiegelung auf einem Gerät (Quelle → Zielport). Gut, wenn Ihr Analyzer physisch oder virtuell am selben Switch hängt.
• RSPAN: Remote-SPAN über ein dediziertes VLAN (klassisch L2-Transport). In VXLAN-Fabrics seltener sinnvoll, weil es wieder eine große L2-Domäne als Transport voraussetzt.
• ERSPAN: Encapsulated Remote SPAN, typischerweise via GRE/IP transportiert. Gut, wenn Ihr Collector/Analyzer nicht am gleichen Switch sitzt oder wenn Sie zentral sammeln möchten.

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:

• Overlay-Perspektive: der „innere“ Traffic zwischen Workloads (Ethernet/IP wie vom Host gesendet).
• Underlay-Perspektive: der „äußere“ transportierte Traffic (VXLAN über UDP/IP zwischen VTEPs).

Das führt zu vier praktischen Konsequenzen:

• Encapsulation verändert Sichtbarkeit: Ein PCAP im Underlay zeigt VXLAN-Header, VTEP-IPs, UDP/4789 und ggf. nicht direkt die inneren MACs/IPs.
• ECMP verteilt Flows: Spiegeln Sie nur auf einem Link, sehen Sie möglicherweise nur einen Teil der Flows.
• Richtungssymmetrie ist nicht garantiert: Hin- und Rückweg können unterschiedliche Pfade nehmen; ein einseitiges PCAP ist häufig.
• MTU/Overhead wird relevant: ERSPAN + VXLAN kann zusätzliche Overheads erzeugen; Drops können in der Capture-Pipeline entstehen.

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

• Vorteil: Sie sehen den Traffic so, wie er vom Host kommt/geht. Ideal für Applikationsdebugging, TCP-Handshakes, TLS, HTTP, DNS.
• Nachteil: Sie sehen nicht, was im Underlay passiert (Encapsulation, ECMP-Pfad, Underlay-Drops).
• Best Use: „Applikation bricht ab“, „nur bestimmte Ports“, „Handshake-Probleme“, „DNS/TLS“-Troubleshooting.

Option B: VTEP/Leaf-Port Richtung Underlay spiegeln

• Vorteil: Sie sehen VXLAN-Tunnel-Traffic inklusive outer headers (VTEP-IP, UDP/4789), geeignet für MTU/PMTUD, ECMP, Underlay-Drops, Tunnel-Health.
• Nachteil: Ohne Decapsulation ist die Analyse anspruchsvoller; Sie brauchen Tools, die VXLAN decodieren können.
• Best Use: „nur große Pakete droppen“, „pfadspezifische Drops“, „ECMP-/Hashing-Probleme“, „Overlay ok, Data Plane kaputt“.

Option C: SVI/Anycast Gateway spiegeln

• Vorteil: Gut für North-South oder Inter-VRF/Inter-Subnet Flows, weil viele Probleme an der Gateway-Kante sichtbar werden (ARP/ND, Routing-Entscheidung, NAT/Policy-Steering).
• Nachteil: In Anycast-Designs kann Traffic an unterschiedlichen Leafs terminieren; Sie müssen den „richtigen“ Leaf erwischen.
• Best Use: „Default-Gateway-Probleme“, „Inter-VRF“, „Policy-Based Routing/Service Insertion“.

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

• Vorteil: Beste Sicht auf stateful Verhalten (Session-Drops, NAT, TLS Termination).
• Nachteil: Sie sehen nicht unbedingt, ob der Traffic korrekt zum Service gesteuert wurde; Sie sehen nur, was ankommt.
• Best Use: „Firewall droppt“, „LB Pool down“, „asymmetrischer Flow“, „Policy-Steering“.

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.

• SPAN ist ideal, wenn: Analyzer in Rack-Nähe, kurze Laufzeit, geringes Risiko, schnelle Iteration.
• ERSPAN ist ideal, wenn: Remote-Analyse, mehrere Mirror-Sources, zentrale Forensik, SOC-Use-Cases.
• Risiko bei ERSPAN: zusätzlicher Transport-Traffic, MTU/Fragmentation, potenzieller Einfluss auf Underlay-Policies und CoPP.

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:

• Inner Capture: entspricht dem Overlay-Frame/Packet ohne VXLAN-Header. Gut für Applikationsanalyse.
• Outer Capture: zeigt VXLAN/UDP/IP inklusive VTEP-IPs. Gut für Underlay/MTU/ECMP-Diagnose.
• Hybrid: manche Plattformen können beides liefern oder bieten Metadaten, die inner/outer korrelieren.

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

• 5-Tuple-Filter: Quell-/Ziel-IP, Ports, Protokoll (TCP/UDP). Für Applikationsfälle meist ausreichend.
• VLAN/VNI-Kontext: wenn möglich, auf das Segment beschränken (z. B. nur eine Bridge-Domain).
• ARP/ND-only: für Resolution-Probleme (ARP/ND Suppression, stale Bindings) gezielt nur ARP/ICMPv6 ND.
• VXLAN/UDP 4789-only: für Underlay-Diagnose und Decapsulation im Analyzer.
• Timeboxing: kurze Fenster (z. B. 30–120 Sekunden) statt „stundenlang laufen lassen“.

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)

$\mathrm{MirrorRate}\approx \mathrm{CapturedRate}\times \mathrm{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)

$\mathrm{ERSPANTransportRate}\approx \mathrm{MirrorRate}+\mathrm{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.

• Best Practice: Mirror-Transportpfad (ERSPAN Destination) MTU-bewusst planen, PMTUD nicht blockieren.
• Best Practice: Wenn möglich inner spiegeln und ERSPAN nur als Transport nutzen, um doppeltes Encapsulation-Risiko zu reduzieren.
• Check: Mirror-Drops/Queue-Full Counters getrennt von Data-Plane-Drops beobachten.

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:

• Nur eine Richtung im PCAP: Hinweg und Rückweg nehmen unterschiedliche Pfade.
• Nur manche Flows sichtbar: Hash verteilt unterschiedliche 5-Tuples auf unterschiedliche Links.
• Capture wirkt „inkonsistent“: Weil der Mirror-Point nicht auf dem Hotspot-Pfad liegt.

Best Practices gegen diese Falle:

• Mirror am Edge, nicht im Core: Access-Port oder SVI/Gateway liefert oft vollständigeres Bild als ein einzelner Spine-Link.
• Wenn Underlay spiegeln: Spiegeln Sie am VTEP-Uplink mit Blick auf den betroffenen VTEP (und ggf. mehrere Member-Links, wenn möglich).
• Flow-Korrelation: Arbeiten Sie mit klaren Flow-IDs (5-Tuple) und erfassen Sie beide Richtungen gezielt.

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

• Dedizierte VRF oder Management-Transport: Spiegelverkehr getrennt vom Tenant-Data-Plane-Traffic halten.
• QoS-Klassifizierung: Mirror-Traffic darf das Underlay nicht dominieren; Priorität sinnvoll begrenzen.
• Rate Limits: Begrenzen Sie ERSPAN-Quellen, um „Runaway Captures“ zu verhindern.

Sicherheits-Best Practices

• Minimale Reichweite: ERSPAN nur zu definierten Collector-IPs erlauben (ACLs), nicht „ins Offene“.
• Datenschutz und Geheimhaltung: PCAP enthält oft Credentials, Tokens, personenbezogene Daten; Zugriff und Aufbewahrung regeln.
• Audit-Trail: Wer hat wann welche Mirror-Session aktiviert, wie lange, mit welchem Filter?

Collector- und Tooling-Best Practices

• VXLAN-Decoding: Tools müssen VXLAN/UDP 4789 sauber decodieren (für outer Captures).
• Time Sync: NTP/PTP konsistent, sonst sind Timeline-Analysen (Handshake, Retransmissions) unzuverlässig.
• Storage und Rotation: kurze Capture-Fenster, definierte Rotation/Retention, kein „endloses“ Schreiben.

PCAP im VXLAN-Fabric interpretieren: typische Analysefehler vermeiden

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

• Mirror-Drops vs. Data-Plane-Drops: Wenn der Mirror-Port überlastet ist, fehlen Pakete im PCAP, ohne dass der echte Traffic droppt.
• Outer vs. Inner IPs: Outer Capture zeigt VTEP-IPs, nicht die Host-IPs. Ohne Decapsulation wirkt der Traffic „fremd“.
• ARP/ND und Suppression: In EVPN kann ARP/ND unterdrückt werden; „kein ARP im PCAP“ ist nicht automatisch „kein ARP im Netz“.
• ECMP-Sicht: Ein PCAP auf einem Pfad ist kein Beweis für „so sieht der gesamte Traffic aus“.

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

• Welche Hypothese? MTU-Drops, TCP Retransmissions, ARP/ND, Policy-Steering, EVPN Route-Problem.
• Welche Perspektive? Inner (Overlay) oder Outer (Underlay) – oder bewusst beides, aber getrennt.
• Welche Flows? 5-Tuple, Subnet, VIP, bestimmte Ports.

Schritt: Beobachtungspunkt wählen

• Applikationsproblem: Access-Port oder SVI/Gateway.
• Underlay/MTU/ECMP: VTEP-Uplink (outer) oder VTEP↔VTEP Pfad.
• Security/LB: Service-Node Interfaces.

Schritt: Filter und Limits setzen

• Filter zuerst: so eng wie möglich, um Mirror-Last zu begrenzen.
• Timebox: definierter Start/Stop, typischerweise 30–120 Sekunden pro Iteration.
• Rate Safety: wenn möglich Mirror-Rate begrenzen und Mirror-Drops überwachen.

Schritt: Capture durchführen und sofort validieren

• Ist der erwartete Traffic sichtbar? Wenn nein: falscher Mirror-Point oder falscher Filter.
• Gibt es Mirror-Drops? Wenn ja: PCAP ist unvollständig; Ursache zuerst beheben oder interpretieren.
• Inner/Outer korrekt erkannt? VXLAN-Decoding im Tool prüfen.

Schritt: Korrelation mit Telemetrie

• Interface Drops/Errors: unterscheiden zwischen echten Drops und Mirror-Drops.
• EVPN/Control Plane Events: bei Mobility/Route Updates zeitlich korrelieren.
• MTU/PMTUD Indizien: bei „nur große Pakete“ unbedingt mit Underlay prüfen.

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

• Perspektive klar: inner oder outer – getrennte Captures statt Mischform.
• Beobachtungspunkt passend: Edge für Applikation, VTEP-Uplink für Underlay, Service-Node für Steering.
• Filter aktiv: 5-Tuple/VNI/Protokoll, Timeboxing, kein „Full Mirror“ ohne Not.
• Ressourcen geprüft: Mirror-Port Kapazität, ERSPAN-Transportpfad, Collector throughput/storage.
• MTU bedacht: insbesondere bei ERSPAN over Underlay, PMTUD nicht sabotieren.
• ECMP berücksichtigt: unvollständige Captures als Risiko eingeplant; ggf. mehrere Mirror-Sources.
• Security/Audit: Zugriff, Aufbewahrung, Nachvollziehbarkeit, sensible Daten schützen.

Outbound-Ressourcen

• RFC 7169 (ERSPAN: Encapsulated Remote SPAN)
• RFC 7348 (VXLAN: Encapsulation und UDP/4789)
• RFC 7432 (EVPN: Control Plane, relevant für Overlay-Kontext)
• RFC 1191 (Path MTU Discovery IPv4)
• RFC 8201 (Path MTU Discovery IPv6)
• Wireshark Dokumentation (Decoding von VXLAN/ERSPAN in PCAPs)

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.