SPAN vs. ERSPAN: Setup und Oversubscription-Risiken

SPAN vs. ERSPAN ist im NOC-, Security- und Troubleshooting-Alltag ein Dauerbrenner: Beide Verfahren spiegeln Pakete zur Analyse, unterscheiden sich jedoch deutlich in Setup, Reichweite und den Risiken rund um Oversubscription. SPAN (Switched Port Analyzer) ist klassisches Port-Mirroring auf demselben Switch: Ein oder mehrere Quellports (oder VLANs) werden auf einen Zielport kopiert, an dem ein Sniffer, IDS-Sensor oder Packet-Broker hängt. ERSPAN (Encapsulated Remote SPAN) erweitert das Konzept über L3-Netze hinweg, indem gespiegelter Traffic in Tunnelpakete gekapselt und an einen entfernten Empfänger transportiert wird. In modernen Infrastrukturen mit verteilten Racks, Leaf-Spine-Fabrics, Cloud-Edges und Segmentierung ist ERSPAN oft praktischer – aber auch fehleranfälliger, wenn Oversubscription, MTU, Hashing oder Gerätelimits unterschätzt werden. Dieser Artikel erklärt verständlich, wie SPAN und ERSPAN funktionieren, wie ein sauberes Setup aussieht und welche Oversubscription-Risiken typischerweise zu „unvollständigen Captures“, Drops oder verfälschten Analysen führen.

Begriffe und Grundprinzip: Was wird bei SPAN und ERSPAN eigentlich gespiegelt?

Port Mirroring erzeugt Kopien von Frames/Paketen, ohne den Originalverkehr zu verändern. Das Ziel ist Beobachtung: Fehlersuche (z. B. Retransmissions, MTU-Probleme), Security (IDS/IPS/NSM), Compliance oder Performance-Analysen. Entscheidend ist: Die Kopie ist nicht automatisch verlustfrei. Mirroring hängt von Hardwarefähigkeiten, Portgeschwindigkeit und internen Ressourcen (ASIC/CPU, Mirror-Buffer) ab.

• SPAN: Spiegelung auf demselben Gerät, typischerweise Layer-2-nah, Zielport lokal.
• RSPAN (häufig als Zwischenstufe): Remote SPAN über ein spezielles VLAN innerhalb eines L2-Domains.
• ERSPAN: Spiegelung über L3 via Kapselung (meist GRE), Ziel kann über Routing erreichbar sein.

Als allgemeine Einordnung zu Port Mirroring ist Port Mirroring eine nützliche Übersicht. Für ERSPAN-Details lohnt sich außerdem ein Blick in Herstellerdokumentation, z. B. in die Cisco-Dokumentation zu ERSPAN.

SPAN im Detail: Setup, Stärken und Grenzen

SPAN ist das „Brot-und-Butter“-Werkzeug, wenn Quelle und Analysepunkt am gleichen Switch liegen. Typische Quellen sind Access-Ports (Server/Clients), Uplinks/Trunks, Port-Channels oder ganze VLANs. Der Zielport wird als „Monitor“-Port konfiguriert und sollte idealerweise ausschließlich für den Capture genutzt werden.

Typisches SPAN-Setup in der Praxis

• Quelle festlegen: ein Port, mehrere Ports, ein VLAN oder eine Richtung (ingress/egress/bidirektional).
• Zielport definieren: dedizierter Port für Sniffer/Probe/Packet-Broker.
• Filter/Scope begrenzen: wenn verfügbar, nur relevante VLANs, nur bestimmte Richtungen oder ACL-basierte Filter nutzen.
• Sniffer korrekt anschließen: Zielport meist „receive-only“; viele Plattformen blockieren TX am Zielport oder behandeln ihn speziell.

Wichtige SPAN-Eigenschaften, die Captures beeinflussen

• VLAN-Tags: Je nach Plattform kann der Zielport getaggte oder ungetaggte Frames liefern. Bei Trunks kann die Tag-Integrität entscheidend sein.
• Port-Channel-Quellen: Mirroring auf einem LAG kann je nach ASIC nur einen Teil der Member oder nur Hash-abhängig abbilden, wenn falsch gewählt.
• Hardware-Limits: Anzahl paralleler SPAN-Sessions und maximaler Mirror-Throughput sind oft begrenzt.
• Timing und Reihenfolge: Mirror-Kopien können zeitlich „nachgelagert“ entstehen; die Reihenfolge kann in Stresssituationen abweichen.

ERSPAN im Detail: Setup, Reichweite und typische Stolpersteine

ERSPAN ist besonders attraktiv, wenn die Analyseplattform zentral steht (z. B. im Security-Cluster) und Sie nicht in jedem Rack einen Sensor platzieren möchten. Technisch wird der gespiegelte Traffic in ein Tunnelprotokoll gekapselt und über das IP-Netz zum Empfänger transportiert. Viele Implementierungen nutzen GRE als Transport. Eine allgemeinverständliche Basis zu GRE finden Sie unter Generic Routing Encapsulation (GRE).

Typisches ERSPAN-Setup in der Praxis

• Quelle definieren: Port/VLAN/Port-Channel wie bei SPAN, aber als ERSPAN-Quelle.
• Transportparameter festlegen: Quell-IP, Ziel-IP, ggf. ERSPAN-ID/Session-ID, TTL, DSCP/ToS (plattformabhängig).
• Routen sicherstellen: ERSPAN-Pakete müssen zum Collector geroutet werden; Rückroute ist für „One-Way“-Mirroring meist nicht nötig, aber Management/Monitoring schon.
• MTU berücksichtigen: Kapselung erzeugt Overhead; bei knappem MTU-Budget drohen Fragmentierung oder Drops.
• Collector/Decapsulator: Sensor, Packet-Broker oder Server muss ERSPAN/GRE decapsulieren oder direkt verstehen.

ERSPAN-Varianten und warum das für Tools relevant ist

In der Praxis gibt es unterschiedliche ERSPAN-Typen/Versionen, die sich u. a. in Metadaten (z. B. VLAN, Direction, Timestamping) unterscheiden. Für Incident-Analysen ist das wichtig, weil manche Tools Metadaten auswerten oder bestimmte Header erwarten. Prüfen Sie daher vorab, ob Ihr Collector die ERSPAN-Variante Ihrer Plattform unterstützt.

Oversubscription verstehen: Warum Mirroring „zu viel“ werden kann

Oversubscription bedeutet beim Mirroring: Der gespiegelte Traffic kann nicht vollständig zum Zielport bzw. durch den Tunnel transportiert werden. Dann werden Mirror-Kopien gedroppt oder reduziert (Truncation, Sampling), während der Originaltraffic weiterhin korrekt läuft. Das führt zu gefährlichen Fehlschlüssen: Der Capture „zeigt“ z. B. keine Retransmissions oder keinen Angriff, weil genau diese Pakete im Mirror verloren gingen.

Die zentrale Oversubscription-Falle bei SPAN

Bei SPAN ist der Engpass meistens der Zielport oder die interne Mirror-Pipeline. Spiegeln Sie z. B. mehrere 10G-Quellen auf einen 10G-Zielport, ist Oversubscription sehr wahrscheinlich – selbst wenn die Quellen nicht dauerhaft voll laufen, reichen Bursts.

Die zentrale Oversubscription-Falle bei ERSPAN

Bei ERSPAN verschiebt sich der Engpass: Zusätzlich zum Zielport/Collector wird das IP-Transportnetz zum kritischen Faktor. Engpässe entstehen typischerweise durch:

• Unterdimensionierte Links auf dem Pfad (z. B. 1G-Transit für 5G Mirror-Last).
• QoS-Policies, die ERSPAN als Best Effort behandeln und bei Stau droppen.
• Fragmentierung durch MTU-Probleme (GRE/ERSPAN-Overhead), die dann gefiltert oder gedroppt wird.
• CPU/ASIC-Limits beim Encapsulator oder Decapsulator.

Oversubscription grob berechnen

Für eine erste Plausibilitätsprüfung können Sie den erwarteten Mirror-Durchsatz abschätzen. Sei R die Summe der relevanten Quellraten (in Bit/s) und C die Kapazität des Zielports oder des Engpasslinks (in Bit/s). Dann ist der Oversubscription-Faktor O:

$O=\frac{R}{C}$

Liegt O dauerhaft über 1, ist Verlust sehr wahrscheinlich. In der Praxis sollten Sie zusätzlich Burst-Reserven berücksichtigen. Bei ERSPAN kommt Kapselungs-Overhead hinzu. Wenn h der Overhead-Anteil ist (z. B. 0,05 für 5 %), dann wird die effektive Last R’:

$R^{\prime }=R\cdot (1+h)$

Diese Rechnung ist bewusst grob, hilft aber, „10G Quellen auf 1G Tunnel“ sofort als riskant zu erkennen.

Typische Symptome: Woran Sie Oversubscription in Captures erkennen

Oversubscription ist tückisch, weil der Liveverkehr oft stabil bleibt. Hinweise finden Sie eher in Capture-Anomalien und in Counter-/Telemetry-Daten.

• Unplausible Lücken: Sequenzen fehlen, ohne dass Anwendungen gleichzeitig Fehler zeigen.
• Asymmetrische Sicht: Sie sehen nur eine Richtung, obwohl beide Richtungen vorhanden sein müssten.
• „Gezackte“ Traffic-Kurven im Capture, während Interface-Auslastung glatt wirkt.
• Fehlende Bursts: Gerade die Spitzen, die Sie untersuchen wollen, fehlen im Mirror.
• Mirror-/ERSPAN-Drops in gerätespezifischen Countern (wenn verfügbar).

Ein sinnvoller Praxisansatz ist, Mirror-Interpretationen stets mit Interface-Countern (Errors/Discards) und Flow-Daten (Top Talkers) abzugleichen, damit ein unvollständiger Capture nicht als „Beweis“ missverstanden wird.

Setup-Best-Practices für SPAN: So bleiben Captures verwertbar

Mit wenigen Grundregeln vermeiden Sie die häufigsten SPAN-Fallen.

Scope gezielt reduzieren

• Spiegeln Sie nicht „den ganzen Trunk“, wenn nur ein einzelner Host oder ein VLAN relevant ist.
• Nutzen Sie – falls verfügbar – Filter (ACL/Policy), um nur die relevante Kommunikation zu spiegeln.
• Wählen Sie die Richtung bewusst: Oft reicht ingress oder egress, statt bidirektional alles zu verdoppeln.

Zielport passend dimensionieren

• Wählen Sie den Zielport mindestens so schnell wie die erwartete Mirror-Last.
• Vermeiden Sie „viele Quellen auf einen langsamen Zielport“ – das ist Oversubscription by Design.
• Wenn ein Packet-Broker verfügbar ist: Nutzen Sie Aggregation, Filtering, Slicing, Load-Balancing auf mehrere Tools.

Port-Channel-Quellen sauber behandeln

• Wenn Sie einen LAG spiegeln, prüfen Sie, ob die Plattform alle Member korrekt abdeckt.
• Bei Bedarf spiegeln Sie gezielt den relevanten Member oder spiegeln Sie auf einer höheren Ebene (z. B. VLAN/VRF), wenn das präziser ist.

Setup-Best-Practices für ERSPAN: Transport, MTU und QoS im Blick behalten

ERSPAN scheitert selten an „falschem Source Port“, sondern an Transportdetails. Ein sauberer ERSPAN-Setup betrachtet den gesamten Pfad als Bestandteil der Messkette.

MTU und Fragmentierung vermeiden

• Planen Sie Overhead ein (GRE/ERSPAN-Header). Wenn Ihr Netz knapp an MTU 1500 betrieben wird, können Captures fragmentieren.
• Stellen Sie sicher, dass Fragmentierung entweder sauber funktioniert oder vermeiden Sie sie konsequent (z. B. durch höhere MTU im Transportnetz, wo möglich).
• Beachten Sie, dass manche Security- oder WAN-Geräte Fragmente restriktiv behandeln.

QoS: ERSPAN nicht „versehentlich“ droppen

• Klassifizieren Sie ERSPAN-Traffic bewusst (DSCP/CoS), damit er bei Stau nicht vollständig verloren geht.
• Vermeiden Sie, dass ERSPAN kritische Produktionsklassen verdrängt; Monitoring darf nicht zum Störfaktor werden.
• Wenn möglich: Separate Monitoring-Transportpfade oder dedizierte Kapazität einplanen.

Collector-Design: Mehr als nur „eine Ziel-IP“

• Nutzen Sie Collector-Redundanz oder Load-Balancing, wenn große Mirror-Lasten zu erwarten sind.
• Prüfen Sie, ob Ihr Tool ERSPAN-Metadaten korrekt decodiert (VLAN/Direction/Session-ID).
• Achten Sie auf Storage und Schreibdurchsatz: Captures sind datenintensiv, Drops können auch am Collector entstehen.

Oversubscription-Risiken gezielt minimieren: Praktische Strategien

Die effektivste Gegenmaßnahme ist fast immer: weniger, aber relevanter spiegeln. Ergänzend helfen technische Strategien, Oversubscription in den Griff zu bekommen.

Sampling und Truncation bewusst einsetzen

• Sampling: reduziert Last, kann aber kleine/seltene Ereignisse verdecken. Für volumetrische Analysen oft ok, für Debugging (TCP-Handshakes, Retransmits) riskant.
• Truncation: schneidet Pakete nach N Bytes ab, reduziert Durchsatz, aber kann Layer-7-Analysen unmöglich machen.

Wenn Sie Sampling oder Truncation nutzen, dokumentieren Sie es im Incident-Protokoll, damit niemand den Capture als vollständige Wahrheit interpretiert.

Mirror-Quellen entkoppeln

• Spiegeln Sie nach Möglichkeit näher an der Quelle, um unnötige Mengen über das Netz zu schieben.
• Bei ERSPAN: Spiegeln Sie gezielt nur die relevanten VLANs/Ports und nicht ganze Uplinks.
• Verteilen Sie Mirror-Sessions auf mehrere Geräte/Ports, statt eine „Monster-Session“ zu bauen.

Packet-Broker und TAPs als Alternative

Wenn Captures regelmäßig kritisch sind (z. B. Security-Monitoring), kann ein dedizierter Packet-Broker oder ein physischer TAP sinnvoll sein. TAPs spiegeln elektrisch/optisch und vermeiden manche SPAN-Limits, benötigen aber Hardware und Planung. Packet-Broker bieten Filter, Masking, Aggregation und Tool-Distribution. In großen Umgebungen ist das oft der nachhaltigere Weg als „noch eine SPAN-Session“.

Fehlerquellen, die nicht nach Oversubscription aussehen, aber so wirken

Manchmal sieht ein Capture unvollständig aus, obwohl keine klassische Oversubscription vorliegt. Häufige Ursachen:

• Falsche Richtung: Es wird nur ingress gespiegelt, aber die Antwortpakete laufen über einen anderen Pfad.
• Asymmetrisches Routing: Gerade bei ERSPAN-Quellen an einem Punkt sehen Sie nur die Hälfte einer Konversation.
• ECMP/MLAG: Verkehr verteilt sich, aber Sie spiegeln nur einen Pfad oder einen Switch.
• Policy/Firewall: ERSPAN-Tunnel wird gedrosselt oder gefiltert (z. B. GRE blockiert).
• MTU/Fragment-Handling: Ein Teil der Tunnelpakete fragmentiert und geht verloren, obwohl der Rest sauber ankommt.

Für GRE-bezogene Transportfragen ist die allgemeine Einordnung über GRE hilfreich, weil viele Troubleshooting-Schritte (MTU, Filter, Routing) direkt daraus ableitbar sind.

So wählen Sie im Betrieb zwischen SPAN und ERSPAN

Für NOC und Incident Response ist die Entscheidung oft pragmatisch: Was liefert schnell verwertbare Daten mit geringstem Risiko?

• SPAN ist meist sinnvoll, wenn Quelle und Analysepunkt lokal sind, die Datenrate moderat ist und Sie schnell „on-box“ spiegeln können.
• ERSPAN ist meist sinnvoll, wenn Sie zentral sammeln, entfernte Standorte/Racks abdecken oder Captures ohne physische Präsenz benötigen.
• Bei hohen Datenraten sollten Sie früh über Packet-Broker/TAPs oder gezielte Filterung nachdenken, statt große Mirror-Sessions zu erzwingen.

Outbound-Quellen für vertiefendes Verständnis

Für eine allgemeine Einordnung von Port Mirroring und typischen Einsatzszenarien eignet sich Port Mirroring. Für ERSPAN-spezifische Konzepte, Parameter und Implementierungsdetails ist die Cisco-Dokumentation zu ERSPAN eine praxisnahe Referenz. Für den Transportmechanismus hinter vielen ERSPAN-Implementierungen liefert GRE einen hilfreichen technischen Überblick, insbesondere zu Overhead, MTU und Tunnel-Verhalten.

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.