February 15, 2026

Layer-2-Troubleshooting mit SPAN/ERSPAN: Fortgeschrittene Techniken

Layer-2-Troubleshooting mit SPAN/ERSPAN ist im Enterprise- und Data-Center-Betrieb oft der schnellste Weg, um „unsichtbare“ Probleme sichtbar zu machen: MAC-Flapping, Broadcast-Stürme, ARP/ND-Anomalien, STP-Topology-Changes, LACP-Inkonsistenzen oder merkwürdige Paketverluste, die in Countern nur als „Drops irgendwo“ auftauchen. Während Logs und Telemetrie Ihnen sagen, dass etwas passiert, zeigen SPAN (Switch Port Analyzer) und ERSPAN (Encapsulated Remote SPAN) im Mitschnitt, was tatsächlich über den Draht geht – inklusive VLAN-Tags, EtherTypes, BPDUs, LLDP, LACP-PDUs und anderer Control-Plane-Frames, die bei höheren Layer-Tools oft untergehen. Gerade bei Layer-2-Fehlerbildern ist dieser Blick entscheidend, weil viele Ursachen nicht in Routing oder Applikation liegen, sondern in Weiterleitung, Flooding, Tagging oder Zustandsmaschinen der Switches. Gleichzeitig gilt: SPAN/ERSPAN ist kein „einfach einschalten und fertig“. Moderne ASICs, hohe Portdichten, MLAG/EVPN-Fabrics und verschlüsselte Workloads erfordern fortgeschrittene Techniken, um den richtigen Verkehr am richtigen Ort, in der richtigen Richtung und in der richtigen Granularität zu erfassen – ohne den Betrieb zu stören. Dieser Artikel beschreibt bewährte, fortgeschrittene Vorgehensweisen für SPAN/ERSPAN, typische Fallstricke und Telemetrie-gestützte Methoden, damit Sie Mitschnitte zielgerichtet einsetzen und schnell zu einer belastbaren Root-Cause-Hypothese kommen.

Table of Contents

SPAN, RSPAN und ERSPAN: Begriffe und Unterschiede, die im Betrieb zählen

SPAN spiegelt Verkehr von einer oder mehreren Quell-Interfaces (oder VLANs) auf ein Ziel-Interface, an dem Sie einen Analyzer (z. B. Laptop, Probe, Appliance) anschließen. RSPAN erweitert das Prinzip über ein dediziertes RSPAN-VLAN, sodass der Mirror-Verkehr Layer 2 über das Netz transportiert werden kann. ERSPAN kapselt den gespiegelten Verkehr in IP (typischerweise GRE) und kann ihn als „Remote Mirror“ über ein Layer-3-Netz zu einem Collector senden. Die Wahl beeinflusst Reichweite, Stabilität, Sichtbarkeit von Tags und die Fehlersuche selbst.

SPAN: lokal am Switch, geringe Komplexität, aber physisch gebunden (Analyzer muss nah dran sein).
RSPAN: Layer-2-Transport über ein Mirror-VLAN, anfällig für VLAN-Fehler und potenziell größere Blast-Radius-Themen.
ERSPAN: Layer-3-Transport, flexibel für Fabrics/Standorte, aber zusätzliche Overhead-, MTU- und Routing-Aspekte.

Das wichtigste Prinzip: Erst Hypothese, dann Capture-Design

Fortgeschrittenes Troubleshooting beginnt nicht mit „ich spiegele mal alles“, sondern mit einer Hypothese, die Sie mit minimal-invasiven Daten bestätigen oder widerlegen. SPAN kann Pakete droppen, ist oft best-effort und kann den Switch je nach Plattformressourcen beeinflussen. Ein gutes Capture-Design beantwortet drei Fragen: (1) Wo ist der beste Beobachtungspunkt? (2) Welche Richtung ist relevant? (3) Welcher Filter reduziert Datenvolumen ohne Beweisverlust?

Beobachtungspunkt: möglichst nah an der vermuteten Ursache, nicht am Symptom-Ende.
Richtung: ingress/egress getrennt betrachten, wenn möglich.
Scope: lieber kurz und gezielt, als lang und „alles“.

Beobachtungspunkte in modernen L2-Topologien

In klassischen Campus-Netzen ist der Access-Switch-Port oft der beste Start. In Data-Center-Fabrics oder MLAG-Designs reicht das selten aus, weil der relevante Verkehr über Peer-Links, Port-Channels oder VXLAN-Edge-Ports laufen kann. Typische, bewährte Beobachtungspunkte:

Edge-Port (Client/Server): ideal für ARP/ND, DHCP, 802.1X/MAB, Voice/WLAN-Tagging-Probleme.
Uplink/Port-Channel: nützlich bei Broadcast-Domain-Problemen, Trunking, Allowed-VLAN-Drift, LACP-Fehlern.
MLAG-/vPC-Peer-Link: relevant bei MAC-Flapping, Split-Brain-Indikatoren, unerwartetem Peer-Traffic.
SVI/Gateway-Nähe: hilfreich bei ARP/ND-Storms, Gateway-Redundanz (VRRP/HSRP) und Fehlrouting auf L2-Grenze.
Fabric Edge (Leaf): wenn EVPN/VXLAN involviert ist und Sie BUM-Handling oder ARP-Suppression prüfen müssen.

Best-effort ist real: SPAN-Qualität, Drops und Truncation verstehen

Ein häufiger Fehler ist die Annahme, ein SPAN-Mitschnitt sei „vollständig“. In der Praxis ist SPAN auf vielen Plattformen best-effort: Wenn die Mirror-Engine oder das Zielinterface nicht hinterherkommt, werden Pakete verworfen. Manche Plattformen schneiden Frames (Truncation) oder spiegeln bestimmte ASIC-Pfade nicht. Fortgeschritten heißt deshalb: Sie interpretieren Captures immer im Kontext von Countern und Ressourcen.

Oversubscription: Quellports liefern mehr Traffic, als das SPAN-Ziel transportieren kann.
Microbursts: kurze Spitzen werden in Countern sichtbar, aber im Capture fehlen Frames.
Hardware-Limits: nicht alle Control-Plane-Frames oder nicht alle Richtungen werden gleich zuverlässig gespiegelt.
Timestamping: Mirror-Timestamps können von echten Interface-Timestamps abweichen.

Kapazitätsabschätzung für ein SPAN-Ziel

$Erforderliche_Bandbreite = Summe_Quellrate \times Spiegel_Faktor$

Der Spiegel_Faktor ist in der Praxis oft größer als 1, wenn Sie mehrere Quellen spiegeln oder wenn der Verkehr durch Tagging/Encapsulation wächst. Wenn das Zielinterface kleiner ist als die erforderliche Bandbreite, müssen Sie filtern, sampeln oder den Beobachtungspunkt ändern.

Filterstrategien: Von „zu viel“ zu „beweisbar“

Die effektivste fortgeschrittene Technik ist nicht ein exotischer ERSPAN-Tunnel, sondern ein sauberer Filter. Dabei unterscheiden Sie zwischen Switch-seitigem Filtering (wenn verfügbar) und Analyzer-seitigem Filtering (Capture Filter in tcpdump/Wireshark). Switch-seitige Filter reduzieren die SPAN-Last auf dem Gerät und sind daher häufig überlegen.

Control-Plane-Fokus: nur BPDUs, LACP, LLDP, ARP/ND, DHCP – ideal für L2-Fehlerbilder.
VLAN-Fokus: nur das betroffene VLAN oder nur bestimmte VLAN-Tag-Kombinationen.
MAC-Fokus: nur Quell-/Ziel-MACs der betroffenen Endpunkte, Gateways oder VIPs.
Rate-/Zeitfenster: kurze Capture-Fenster rund um das Event (z. B. beim Link-Flap).

Praktischer Ansatz: „Control Frames zuerst“

Wenn Sie Loops, Flaps oder Segmentierungsfehler vermuten, ist es oft effizienter, zuerst nur Control Frames zu erfassen: STP BPDUs, LACP-PDUs, LLDP, ARP/ND und DHCP. Damit sind viele Root Causes in Minuten sichtbar, ohne dass Sie Gigabytes an Daten sammeln.

Direction matters: Ingress/Egress und die „fehlende Hälfte“

Viele Teams spiegeln nur „beide Richtungen“ und wundern sich, warum sich die Ursache nicht zeigt. Fortgeschrittenes Troubleshooting trennt Ingress und Egress, weil viele L2-Fehlerbilder richtungsabhängig sind: Ein Host sendet ARP Requests (Ingress am Switch-Port), aber ARP Replies fehlen (Egress) – oder umgekehrt werden Replies gedroppt. Bei Port-Channels kann zusätzlich die Member-Verteilung eine Rolle spielen: Ein Flow „klebt“ an einem Member, Sie spiegeln aber nur einen anderen Member.

Bei Port-Channels: nach Möglichkeit das logische Bundle spiegeln, nicht nur ein Member.
Bei asymmetrischen Pfaden: Capture auf beiden Seiten (z. B. Access und Distribution) vergleichen.
Bei MLAG: Capture auf beiden Peers erwägen, wenn MAC-Moves oder Peer-Link-Traffic im Verdacht stehen.

ERSPAN in der Praxis: Encapsulation, MTU und Routing als versteckte Risiken

ERSPAN ist mächtig, weil Sie Captures zentralisieren können. Gleichzeitig ist ERSPAN ein eigenes „Transportproblem“: Sie kapseln Layer-2-Frames in IP/GRE und transportieren sie über das Netzwerk, das Sie gerade debuggen. Fortgeschritten bedeutet daher: Sie stellen sicher, dass ERSPAN den Fehler nicht maskiert oder verschlimmert.

MTU prüfen: Encapsulation vergrößert Pakete; bei zu kleiner MTU drohen Fragmentierung oder Drops.
Pfadstabilität: ERSPAN sollte über stabile, möglichst geroutete Pfade laufen, nicht über fragiles L2.
QoS/Policing: ERSPAN kann als „unwichtig“ klassifiziert und gedrosselt werden; das verfälscht Captures.
Security: ERSPAN transportiert Rohdaten – Zugriff, Logging und Datenhandling müssen geregelt sein.

Overhead-Überlegung bei Encapsulation

$Effektive_Paketgröße = L2_Frame + GRE_Overhead + IP_Overhead + ERSPAN_Header$

Die konkreten Overheads hängen von Implementierung und ERSPAN-Variante ab. Für das Design genügt die Erkenntnis: Bei großen Frames kann ein kleiner MTU-Mismatch reichen, um ERSPAN-Pakete zu verlieren und die Diagnose zu verfälschen.

Fortgeschrittene Use Cases: Was SPAN/ERSPAN bei L2 wirklich aufklärt

SPAN/ERSPAN entfaltet seine Stärke dort, wo „Zustandsmaschinen“ und Control Frames entscheiden. Einige bewährte Szenarien:

STP-Probleme: BPDUs, Topology Change Notifications, unerwartete Root Bridges, PortFast/BPDU-Guard-Fälle.
LACP/MLAG-Inkonsistenzen: LACP-PDUs, Actor/Partner States, unerwartete Individual/Collecting/Distributing-Zustände.
ARP/ND-Storms: ARP Requests/Replies, Gratuitous ARP, ND Solicitation/Advertisement, RA-Anomalien.
VLAN/Tagging-Fehler: fehlende oder falsche 802.1Q-Tags, Native-VLAN-Mismatch, VLAN-Leaks auf Trunks.
MAC-Flapping: gleiche Quell-MAC auf unterschiedlichen Ports/Peers, oft sichtbar über wiederkehrende Source-MACs und Flooding-Muster.
Rogue DHCP: DHCP Offers/ACKs aus falschen Ports, Option-Manipulation, falsche Default Gateways.

Capture in MLAG- und Fabric-Umgebungen: Stolpersteine und Lösungen

In MLAG/vPC-Designs ist die häufigste Falle, dass Sie „am falschen Peer“ capturen. Wenn Hashing oder Peer-Link-Fallback Traffic verschiebt, sehen Sie nur einen Teil. Fortgeschrittene Vorgehensweise:

Peer-Symmetrie prüfen: identische VLAN-Listen, MTU, LACP-Parameter; Drift kann die Ursache sein.
Peer-Link-Observation: bei MAC-Flaps oder Traffic-„Teleportation“ Capture auf Peer-Link (gezielt, kurz) erwägen.
Event-Korrelation: Capture-Zeitpunkt auf Link-Events, LACP-Transitions oder STP-Events legen.
„Zwei-Punkt-Capture“: gleichzeitig am Edge-Port und am Uplink capturen, um Ingress/Egress-Pfade zu bestätigen.

Telemetrie + SPAN: Die schnellste Kombination für Root Cause

Reine Packet Captures können Zeit fressen, wenn Sie nicht wissen, wonach Sie suchen. Fortgeschrittene Teams koppeln SPAN/ERSPAN eng an Telemetrie: Counters, Logs und Flow-Daten geben den Kontext, Capture liefert den Beweis. Ein praxistaugliches Muster ist „Counter zuerst, Capture danach“.

Counters: Broadcast/Multicast/Unknown-Unicast, Input/Output Drops, Queue Drops, Storm-Control-Drops.
Events/Logs: MAC-Flapping, STP-Topology Changes, Port-Security/DAI-Events, LACP-Partner-Changes.
Capture-Ziel: nur die Frames, die zu genau diesen Countern/Events passen (z. B. nur ARP, nur BPDU).

Beweisführung im Capture: Praktische Signaturen, die Sie kennen sollten

Viele L2-Probleme haben typische „Signaturen“, die im Mitschnitt schnell erkennbar sind. Einige Beispiele:

Loop-Indikator: identische Broadcast-Frames wiederholen sich in sehr kurzer Folge; MACs „springen“; BPDUs zeigen unerwartete Topologieänderungen.
Native-VLAN-Mismatch: untagged Frames erscheinen im falschen VLAN-Kontext; DHCP/ARP wirkt „falsch zugeordnet“.
ARP Poisoning: ARP Replies mit Gateway-IP, aber anderer MAC; häufige Gratuitous ARPs, die MAC des Gateways „überschreiben“.
LACP-Problem: LACP-PDUs fehlen oder zeigen „Individual“ statt „Collecting/Distributing“; Traffic läuft nur über einen Link.
Rogue DHCP: DHCPOFFER/DHCPACK von unerwarteter MAC/Port-Richtung; Option 3 (Router) oder Option 6 (DNS) verdächtig.

Performance und Sicherheit: SPAN/ERSPAN ohne Nebenwirkungen betreiben

SPAN/ERSPAN kann sensible Daten sichtbar machen. Zudem kann ein falsch dimensionierter Mirror-Job Ports belasten oder zu Diagnoseartefakten führen. Fortgeschrittene Betriebsregeln:

Least Privilege: Zugriff auf Mirror-Sessions und Collector-Systeme stark begrenzen.
Datenschutz/Compliance: Captures als potenziell vertraulich behandeln; klare Aufbewahrungs- und Löschregeln.
Change-Disziplin: SPAN-Enablement als kontrollierte Maßnahme mit Zeitfenster; Sessions nach Analyse wieder entfernen.
Isolation des Analyzers: SPAN-Zielports dürfen nicht „zurück ins Netz“ bridgen; Analyzer-Port-Mode sauber definieren.
Kurze Captures: lieber mehrere kurze, hypothesengetriebene Captures als ein langer „Alles-Mitschnitt“.

Tooling: Wireshark, tcpdump und Capture-Workflows für L2

Für Layer-2-Analyse ist das Werkzeugset entscheidend. Wireshark eignet sich für Deep Inspection (BPDUs, LACP, DHCP Options), tcpdump für schnelle Filter und reproduzierbare CLI-Workflows. In fortgeschrittenen Setups nutzen Teams zentralisierte ERSPAN-Collector, die Captures automatisiert speichern, taggen und korrelieren.

Capture Filter (vor dem Mitschnitt): reduziert Datenmenge und Drops auf dem Analyzer.
Display Filter (nach dem Mitschnitt): flexibel für Analyse, aber Daten sind bereits aufgenommen.
Ring Buffers: kontinuierlich, aber begrenzt (z. B. 10 Dateien à 100 MB), ideal für „sporadische“ Fehler.
Zeitsynchronisation: NTP auf Analyzer und Infrastruktur, damit Event-Korrelation funktioniert.

Outbound-Links für vertiefende Referenzen

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.