February 15, 2026

ERSPAN in VXLAN-Fabrics: Best Practices und Fallstricke

ERSPAN in VXLAN-Fabrics ist für viele Operations- und Netzwerk-Teams das Mittel der Wahl, wenn klassisches SPAN an Grenzen stößt: verteilte Leaf-Spine-Topologien, Overlay-Tunnel, Multi-Tenant-Segmentierung und Remote-Standorte machen „lokales Mitschneiden“ oft unpraktisch. Gleichzeitig ist ERSPAN kein „Set-and-forget“-Feature. In VXLAN-Umgebungen kann ein unüberlegtes Mirroring zu unerwarteten Effekten führen: MTU-Probleme durch zusätzliche Encapsulation, falsch interpretierte Pakete (inner/outer Header), zu hohe CPU-Last auf Switches, Microbursts auf dem Underlay oder sogar Datenschutzrisiken, weil plötzlich mehr Traffic als nötig gespiegelt wird. Wer ERSPAN gezielt einsetzt, kann jedoch schnellere RCA, reproduzierbare Troubleshooting-Workflows und deutlich bessere Sichtbarkeit in Layer 2/3/4 erreichen – ohne die Fabric zu destabilisieren. Dieser Artikel zeigt Best Practices und typische Fallstricke für ERSPAN in VXLAN-Fabrics: vom Design der Mirror-Quelle, über Transport und MTU, bis zur Auswertung im Collector und der sicheren Betriebsorganisation.

Table of Contents

Begriffe sauber trennen: SPAN, RSPAN und ERSPAN im VXLAN-Kontext

In der Praxis werden „SPAN“ und „ERSPAN“ oft synonym verwendet, obwohl die Betriebswirkung stark unterschiedlich ist. SPAN ist lokales Port- oder VLAN-Mirroring auf einem Gerät. RSPAN transportiert Spiegeltraffic per VLAN über Layer 2. ERSPAN kapselt den Mirror-Stream typischerweise in GRE (und ggf. zusätzliche Header) und schickt ihn per Layer 3 an einen entfernten Collector. In VXLAN-Fabrics kommt hinzu: Ihr produktiver Datenverkehr ist bereits über VXLAN (UDP/4789) als Overlay gekapselt, während ERSPAN ein separater Mirror-Transport ist, der über das Underlay oder ein separates Analyse-Netz geführt werden kann.

SPAN: lokal, simpel, aber an die physische Nähe gebunden.
ERSPAN: remote-fähig, flexibler, aber deutlich anspruchsvoller in MTU, Kapazität und Filterung.
VXLAN-Fabric: Overlay-/Underlay-Trennung; ein Capture kann „inner“ oder „outer“ betrachten – oder beides, je nach Mirror-Punkt.

Warum ERSPAN in VXLAN-Fabrics besonders nützlich ist

VXLAN-Fabrics sind darauf ausgelegt, L2- und L3-Segmente über ein routendes Underlay zu skalieren. Genau diese Skalierung erschwert aber oft die Diagnose: Der relevante Traffic kann über mehrere Leafs laufen, der Problemfluss ist nicht an einem festen „Trunk-Port“ sichtbar, und Overlay-IDs (VNI) müssen interpretiert werden. ERSPAN erlaubt, die Pakete von dort zu spiegeln, wo sie wirklich auftreten – etwa am Leaf-Port eines betroffenen Servers oder am VTEP-Interface – und an einen zentralen Analyzer zu senden.

Zentrale Auswertung: Wireshark/Zeek/Suricata oder kommerzielle NPM/APM-Tools können im SOC/NOC konsolidiert werden.
Reproduzierbarkeit: Standardisierte Mirror-Profile reduzieren „Trial-and-Error“ im Incident.
Segmentierung: Pro VNI/VRF lassen sich zielgerichtete Captures aufsetzen, statt breit zu spiegeln.

Design-Entscheidung: Wo in der Fabric sollte gespiegelt werden?

Der wichtigste Hebel für schnelle RCA ist nicht die Tool-Auswahl, sondern der Mirror-Punkt. In VXLAN-Fabrics ergeben sich drei typische Perspektiven, die jeweils andere Fragen beantworten.

Access-Port am Leaf (Host-/Server-nah)

Hier sehen Sie den Traffic so, wie ihn der Host sendet/empfängt. Das ist ideal, wenn Sie Application-Timeouts, TCP-Retransmissions, TLS-Handshake-Probleme oder falsche VLAN-Zuordnung untersuchen. Vorteil: minimale Komplexität in der Auswertung, weil Sie meist „native“ Frames sehen. Nachteil: Sie sehen nicht unbedingt, was im Overlay/Underlay passiert.

VTEP-/SVI-/Bridge-Domain-Perspektive (Overlay-nah)

Wenn die Frage lautet „wird der Traffic korrekt in die VNI gemappt?“ oder „kommt ARP/ND sauber an?“, kann ein Mirror an relevanten Overlay-Interfaces sinnvoll sein. Diese Perspektive hilft bei EVPN/VXLAN-spezifischen Fehlerbildern wie MAC-Mobility, Duplicate IP Detection, ARP-Suppression-Missverhalten oder inkonsistenten Policies.

Underlay-/Uplink-Perspektive (Transport-nah)

Wenn Sie Underlay-Path-Probleme (MTU, ECMP, Microbursts, Drops) vermuten, kann ein Mirror am Uplink oder an ausgewählten Spine-Ports helfen. Hier sehen Sie häufig VXLAN-Encapsulation (UDP/4789) als Outer Traffic. Vorteil: Underlay-Issues lassen sich beweisen. Nachteil: Für L7-Analysen müssen Sie ggf. decapsulieren oder den Inner Flow rekonstruieren.

Best Practice: Inner vs. Outer Traffic bewusst wählen

Ein häufiger Fallstrick ist die Annahme, ein Mirror zeige „den“ Traffic. In VXLAN können Sie je nach Mirror-Punkt unterschiedliche „Sichten“ erzeugen. Für operative Prozesse sollten Sie im Runbook klar definieren, wann Sie welchen Blick brauchen.

Inner Traffic (Tenant-/Workload-Sicht): ideal für TCP/TLS/HTTP, App-Fehler, Header, Retries.
Outer Traffic (Underlay-/Transport-Sicht): ideal für MTU, ECMP-Hashing, Underlay-Drops, VXLAN-Port/DSCP, Pfadwechsel.
Kombiniert: in manchen Tools möglich, aber meist aufwendiger und datenintensiver.

MTU und Overhead: Der Klassiker, der ERSPAN-Deployments bricht

ERSPAN produziert zusätzlichen Overhead, der auf dem Transportpfad berücksichtigt werden muss. In VXLAN-Fabrics kommt bereits VXLAN-Overhead hinzu, wenn Sie Outer Traffic spiegeln oder wenn der Mirror-Transport selbst über Tunnel/Overlays läuft. Das Ergebnis: Fragmentierung oder Drops – und damit irreführende Captures oder zusätzliche Störungen.

Overhead greifbar machen mit einer einfachen Rechnung

Für eine pragmatische Planung hilft eine Worst-Case-Annäherung: Nehmen Sie an, dass Ihr gespiegelter Frame maximal groß ist (z. B. 1500 Byte L3-MTU bzw. 1518 Byte Ethernet-Frame ohne VLAN/mit VLAN etwas mehr) und addieren Sie die Encapsulation-Header für ERSPAN (häufig GRE plus ERSPAN-Header plus neue IP/Ethernet-Header). Je nach Plattform und ERSPAN-Variante schwankt das, aber die Richtung ist klar: Sie brauchen Headroom.

$MTU \geq Payload + IP + GRE + ERSPAN + L2$

Als Best Practice gilt: Planen Sie Mirror-Transports so, dass sie Jumbo-fähig sind (z. B. 9000 Byte im Underlay), oder spiegeln Sie möglichst inneren Traffic an Access-Ports, wenn Sie keine Jumbo-MTU sicherstellen können. Bei Cloud-/Hybrid-Pfaden oder WAN-Links ist das besonders kritisch.

Kapazität und Performance: ERSPAN ist „Traffic plus X“

Ein ERSPAN-Stream verdoppelt nicht nur Traffic, er kann ihn je nach Konfiguration vervielfachen: mehrere Mirror-Quellen, breite VLAN-/VNI-Spiegelung oder Mirror von Broadcast/Multicast kann schnell zu hohen Datenraten führen. Außerdem ist Mirroring auf vielen Switches nicht „gratis“: Die Paketkopie kostet ASIC-Ressourcen, Buffer, manchmal CPU, und sie kann Drops verursachen – im schlimmsten Fall im produktiven Datenpfad.

Begrenzen Sie Scope: Spiegeln Sie gezielt Ports, ACL-Matches oder definierte Flows statt ganze VLANs/VNIs.
Rate-Limiting nutzen: Wenn die Plattform es erlaubt, begrenzen Sie Mirror-Bandbreite, um die Fabric zu schützen.
Microbursts beachten: Mirror-Traffic kann Burstiness verstärken; planen Sie Buffer/Queues und Collector-Interface entsprechend.
Offloading vermeiden: Schicken Sie Mirror-Streams nicht über knappe Control-/Management-Netze.

Filterung richtig machen: Präzise statt breit spiegeln

In VXLAN-Fabrics ist „alles spiegeln“ selten sinnvoll. Die beste Praxis ist, bereits an der Quelle zu filtern, wenn die Plattform das unterstützt: über ACL-basierte Mirror-Policies (z. B. nur TCP/443 zu einem Ziel), über Richtung (ingress/egress) oder über bestimmte VLANs/VNIs. So bleibt der ERSPAN-Stream klein, analysierbar und compliant.

Richtung festlegen: Ingress-only spart oft 50 % und reicht für viele Diagnosen. Für Retransmissions/Handshake-Probleme ist bidirektional meist nötig.
Flow-Fokus: 5-Tuple (src/dst IP, Ports, Protokoll) ist der operative Goldstandard.
Control Plane ausklammern: Spiegeln Sie BGP/OSPF/EVPN-Control-Plane nur, wenn Sie genau das untersuchen – sonst erzeugen Sie Lärm.

ERSPAN-Collector-Design: Damit Auswertung nicht zum Bottleneck wird

Viele ERSPAN-Projekte scheitern nicht am Mirroring, sondern am Collector. Wenn der Collector nicht schnell genug schreibt, decapsuliert oder speichert, erhalten Sie lückenhafte Captures. Zudem müssen Tools ERSPAN/GRE korrekt verstehen. Planen Sie den Collector daher wie eine Produktionskomponente.

Interface-Kapazität: 10G/25G/40G je nach erwarteter Mirror-Last; vermeiden Sie 1G-Flaschenhälse.
Speicherstrategie: Ringbuffer und Rotation (Zeit/Größe) statt endloser Files.
Decapsulation: Stellen Sie sicher, dass Ihre Toolchain ERSPAN/GRE sauber verarbeitet (Wireshark unterstützt GRE/ERSPAN; andere Tools benötigen Plugins oder Vorverarbeitung).
Time Sync: NTP/PTP auf Collector und Netzwerkgeräten, damit Korrelation mit Logs/Metriken stimmt.

Fallstricke in VXLAN-Fabrics: Typische Fehlerbilder und ihre Ursachen

Die folgenden Probleme treten in der Praxis besonders häufig auf und führen dazu, dass Captures „komisch“ aussehen oder gar nicht ankommen.

Asymmetrische Sicht durch ECMP und Multi-Path

In Leaf-Spine-Fabrics läuft Hin- und Rückweg oft über unterschiedliche Pfade. Wenn Sie nur an einem Punkt capturen, sehen Sie möglicherweise nur eine Richtung. Das wirkt dann wie Drops, obwohl es nur Path-Diversität ist. Best Practice: Capturen Sie entweder nahe am Endpunkt (Access-Port) oder definieren Sie zwei Messpunkte (z. B. VIP-Seite und Backend-Seite, oder zwei Leafs).

MTU-Blackholes durch kombinierte Encapsulation

Wenn Underlay-MTU knapp ist und Sie Outer Traffic spiegeln, kann der ERSPAN-Transport fragmentieren oder droppen. Das führt zu scheinbar „kaputten“ Sessions im Capture, obwohl die Produktion ggf. noch funktioniert – oder umgekehrt: Produktion hat Probleme, Capture zeigt aber nur Fragmente. Best Practice: MTU-Ende-zu-Ende validieren und Mirror-Pfad separat testen.

Falsche Interpretation von Inner/Outer Headern

Ein Analyzer, der nur den äußeren IP-Header betrachtet, kann die eigentlichen Flows nicht korrekt aggregieren. Das ist besonders relevant bei VXLAN-Outer Traffic: Viele Flows sehen „gleich“ aus (z. B. UDP/4789 zwischen VTEPs), obwohl sie unterschiedliche Inner Sessions tragen. Best Practice: Stellen Sie sicher, dass Ihr Tool Inner Header decodiert oder spiegeln Sie inneren Traffic.

Über-Spiegelung von Broadcast/Multicast

ARP/ND, BUM-Traffic (Broadcast, Unknown unicast, Multicast) und Control-Plane-Protokolle können Mirror-Streams aufblasen. In VXLAN/EVPN gibt es je nach Design mehr oder weniger BUM. Best Practice: BUM nur gezielt spiegeln, z. B. zur Analyse von ARP/ND-Storm oder Duplicate MAC/IP Events.

Operational Best Practices: Runbooks, Namenskonventionen und sichere Prozesse

ERSPAN ist am effektivsten, wenn es in standardisierte Betriebsabläufe eingebettet ist. Das reduziert Fehler im Incident, beschleunigt Freigaben und schützt die Produktion.

Standard-Profile: vordefinierte Mirror-Profile (z. B. „Client↔VIP“, „VIP↔Backend“, „Access-Port Server“) mit klaren Filtern.
Change-Disziplin: Mirroring in Produktion ist ein Change; dokumentieren Sie Scope, Dauer, Rückbau und Verantwortliche.
Zeitliche Begrenzung: Captures grundsätzlich mit Ablaufzeit oder Reminder betreiben, um „vergessene Mirrors“ zu vermeiden.
Datenschutz: Minimalprinzip, Zugriffskontrolle und sichere Ablage der PCAPs.

Tooling und Referenzen: Vertiefung für Praxis und Standards

Praktische Checkliste: ERSPAN in VXLAN-Fabrics ohne Überraschungen betreiben

Mirror-Punkt wählen: Access-Port (inner) für App/TCP/TLS, Uplink/Underlay (outer) für Transport/MTU/ECMP.
Scope minimieren: Ports/Flows/ACL-Matches statt VLAN-/VNI-Breite.
MTU prüfen: End-to-End inklusive Encapsulation-Headroom; bevorzugt Jumbo im Mirror-Pfad.
Kapazität planen: Mirror-Traffic als zusätzliche Last; Collector-Interface und Storage dimensionieren.
Asymmetrie berücksichtigen: ECMP/MLAG kann Sicht verzerren; ggf. zwei Capture-Punkte.
Collector absichern: Time Sync, Rotation, Zugriffskontrolle, definierte Aufbewahrung.
Rückbau garantieren: Ablaufzeit, Runbook, Ownership – damit Mirrors nicht dauerhaft laufen.

Typische Einsatzszenarien: Wann ERSPAN die schnellste RCA ermöglicht

ERSPAN spielt seine Stärken aus, wenn Sie schnell beweisen müssen, ob ein Problem im Underlay, Overlay oder in einer Middlebox entsteht. Beispiele sind sporadische TCP-Resets hinter dem Load Balancer, TLS-Handshake-Ausfälle nur für bestimmte VNIs, ARP/ND-Anomalien in einzelnen Segmenten oder vermutete MTU-Blackholes nach einem Change am Underlay. Durch die Kombination aus gezielter Quelle, sauberer Filterung und leistungsfähigem Collector können Sie in VXLAN-Fabrics reproduzierbar Pakete sammeln, ohne die Fabric zu überlasten – und damit Diagnosezeit und Eskalationsschleifen spürbar reduzieren.

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.