Cisco SPAN Ports - Fehler vermeiden, Netzwerke analysieren

Ein SPAN-Port auf Cisco-Switches ist für mich kein Nebenthema, sondern eines der nützlichsten Werkzeuge, wenn ich Verkehr gezielt beobachten, Fehler eingrenzen oder Security-Tools mit echten Paketen versorgen will. Entscheidend ist dabei nicht nur die Spiegelung selbst, sondern die saubere Wahl von Quelle, Ziel, Richtung und Bandbreite. In diesem Artikel zeige ich, wie die Funktion auf Cisco-Hardware arbeitet, welche Varianten es gibt, wo die Grenzen liegen und wie ich sie in produktiven Netzen pragmatisch einsetze.

Wie der SPAN-Port auf Cisco-Geräten wirklich arbeitet

SPAN steht für Switched Port Analyzer. Vereinfacht gesagt kopiert der Switch den Verkehr von einem oder mehreren Quellports oder Quell-VLANs und sendet diese Kopie an einen Zielport, an dem dann ein Analyzer, ein IDS oder ein Mitschnitt-System hängt. Der Originalverkehr bleibt dabei auf seinem normalen Weg. SPAN verändert also nicht den Datenpfad des Produktionsverkehrs, sondern erzeugt eine zusätzliche Beobachtungskopie.

Für die Fehlersuche denke ich in drei Ebenen: Quelle, Richtung und Ziel. Quelle heißt, welche Schnittstelle oder welches VLAN ich beobachte. Richtung heißt, ob ich eingehenden Verkehr, ausgehenden Verkehr oder beides mitschneide. Ziel heißt, wohin die Kopie geht. Wenn diese drei Punkte nicht sauber zusammenpassen, wird der Mitschnitt schnell unvollständig oder schlicht unbrauchbar.

Wichtig ist auch die Kapazität des Zielports. Cisco dokumentiert ausdrücklich, dass ein überlasteter Zielport Pakete verlieren kann, obwohl das eigentliche Netzwerk normal weiterarbeitet. Genau deshalb ist SPAN ein Diagnosetool und kein Freifahrtschein für beliebige Massenmitschnitte. Je mehr Quellen ich spiegele, desto sorgfältiger muss ich die Zielgeschwindigkeit und die Gesamtlast planen.

Ich halte außerdem fest: Auf vielen Cisco-Plattformen können sowohl Switched als auch Routed Ports als Quellen und Ziele dienen. Das ist praktisch, aber es ersetzt keine saubere Architektur. Wenn ich das Grundprinzip verstanden habe, wird auch klar, warum die verschiedenen SPAN-Varianten nicht austauschbar sind. Darum schaue ich mir als Nächstes die Unterschiede zwischen local SPAN, RSPAN und ERSPAN an.

Welche Varianten ich in der Praxis unterscheide

In echten Netzen geht es selten nur um „SPAN ja oder nein“. Die eigentliche Frage lautet meist: Reicht eine lokale Spiegelung, oder muss die Kopie über mehrere Switches oder sogar über ein geroutetes Netz transportiert werden? Genau hier trennen sich die Varianten.

Ich entscheide mich für Local SPAN, wenn der Analyzer physisch in der Nähe des Quellsystems steht und ich keine zusätzliche Transportlogik brauche. RSPAN setze ich ein, wenn ich innerhalb derselben L2-Struktur mehrere Switches überbrücken will. ERSPAN nehme ich, wenn die Kopie über Routing-Grenzen oder über Standorte hinweg transportiert werden muss, also etwa in verteilten Carrier- oder Enterprise-Topologien. Der Unterschied ist nicht akademisch, sondern entscheidet über Stabilität, Aufwand und Fehlertoleranz. Die Wahl der Variante ist oft wichtiger als das eigentliche Capture-Tool.

Wenn diese Einordnung sitzt, wird die eigentliche Konfiguration deutlich einfacher. Dann geht es nur noch darum, die Session sauber zu bauen und nicht durch kleine Detailfehler zu sabotieren.

So richte ich eine Monitor-Session sauber ein

Die Syntax variiert je nach Cisco-Plattform und IOS-XE- oder NX-OS-Version leicht, aber das Grundmuster bleibt gleich: Quelle auswählen, Zielport festlegen, Richtung bestimmen, danach prüfen. Ich arbeite dabei bewusst schrittweise, weil man Fehler so viel schneller erkennt.

1. Ich wähle die Quelle. Das kann ein einzelner Port, ein Portbereich oder ein VLAN sein. Ports und VLANs mische ich in derselben Session nicht.
2. Ich definiere die Richtung. Für viele Probleme reicht ingress, bei anderen brauche ich egress oder beides.
3. Ich reserviere einen dedizierten Zielport mit genug Bandbreite für den Mitschnitt.
4. Ich lege die Session an und halte sie zunächst so klein wie möglich.
5. Ich prüfe das Ergebnis mit den Anzeige- oder Verifikationsbefehlen des jeweiligen Systems.

monitor session 1 source interface TenGigabitEthernet1/0/1 both
monitor session 1 destination interface TenGigabitEthernet1/0/24

show monitor session all

Der erste Befehl spiegelt in diesem Beispiel beide Richtungen eines Interfaces, der zweite ordnet den Zielport zu. Der letzte Befehl dient der Kontrolle. Ich schaue mir dabei nicht nur an, ob die Session existiert, sondern auch, ob die Richtung stimmt und ob der Zielport wirklich als Monitorport behandelt wird. Auf manchen Plattformen wird ein Zielport nämlich faktisch zu einem dedizierten Spiegelport und ist dann nicht mehr für normalen Verkehr gedacht.

Ein Detail, das ich in der Praxis oft berücksichtige: Die Session kann zwar auf einem deaktivierten Port konfiguriert werden, aktiv wird sie aber erst, wenn Zielport und mindestens eine Quelle tatsächlich up sind. Das klingt banal, spart aber Zeit, wenn man in einer Umbauphase gerade erst Teile des Netzes vorbereitet. Genau an dieser Stelle zeigen sich in der Praxis die meisten Stolperfallen.

Welche Fehler ich in echten Netzen am häufigsten sehe

Die meisten Probleme mit SPAN entstehen nicht durch das Feature selbst, sondern durch falsche Erwartungen. Man geht davon aus, dass ein Mitschnitt automatisch alles sichtbar macht. In Wirklichkeit ist SPAN nur so gut wie die Planung dahinter.

• Der Zielport ist zu langsam. Ein 10-Mbit-Ziel auf einen 1-Gbit-Quellport ist keine Diagnose, sondern ein Paketverlustgenerator.
• Quelle und Ziel werden verwechselt. Ein Port kann nicht gleichzeitig Quelle und Ziel derselben Session sein.
• Ports und VLANs werden vermischt. Das ist in vielen SPAN-Setups nicht erlaubt und führt schnell zu Fehlkonfigurationen.
• Der Zielport bleibt als Normalport eingeplant. Wer einen Monitorport parallel produktiv nutzen will, läuft je nach Plattform in harte Grenzen.
• Zu viele Quellen werden gespiegelt. Dann wird das Capture laut, unübersichtlich und oft nur noch teilweise verwertbar.
• Die Switch-Unterstützung wird überschätzt. Nicht jede Plattform unterstützt RSPAN oder ERSPAN in derselben Form.

Ein weiterer Punkt ist die Erwartung an die Sichtbarkeit. SPAN zeigt nur, was an der gewählten Stelle tatsächlich kopiert wird. Wenn ich einen Fehler hinter einer Policy, einem VLAN-Filter oder einer Routing-Grenze suche, kann ein lokaler Mitschnitt in die Irre führen. Deshalb prüfe ich bei komplexeren Fällen immer erst, ob die Spiegelstelle überhaupt die richtige Beobachtungsebene hat.

Wenn die Architektur feststeht, bleibt noch die Frage, welche Variante im konkreten Netz wirklich am besten passt. Genau dort wird aus einer technischen Funktion eine sinnvolle Betriebsentscheidung.

Wann ich SPAN, RSPAN oder ERSPAN nehme

Für mich ist die Auswahl vor allem eine Frage der Distanz und der betrieblichen Realität. Je näher der Analyzer an der Quelle steht, desto einfacher und robuster wird die Lösung. Je weiter die Strecke, desto mehr gewinnt die transportierte Variante an Wert, aber auch an Komplexität.

• Local SPAN nehme ich, wenn ich an einem einzelnen Switch, einem Stack oder einem klar abgegrenzten Segment arbeite.
• RSPAN nutze ich, wenn ich innerhalb eines Layer-2-Designs zentral mitsniffen will, ohne den Analyzer an jedem Schalterpunkt zu verteilen.
• ERSPAN setze ich ein, wenn die Quelle und der Analyzer über Layer-3-Strecken getrennt sind oder wenn mehrere Standorte in einer gemeinsamen Analyseplattform zusammenlaufen sollen.
• Local SPAN ist meist die beste Wahl für schnelle Fehlersuche im Zugriffsknoten, weil es am wenigsten zusätzliche Fehlerquellen erzeugt.
• ERSPAN ist besonders stark, wenn ich in verteilten Netzen arbeite, etwa in Campus-Umgebungen, im WAN oder an entfernten Betriebsstandorten.

In Netzen mit mehreren Außenstellen oder mit komplexer Transportlogik, wie ich sie auch in Telekommunikations- und Infrastrukturumgebungen erwarte, ist ERSPAN oft die sauberere Lösung. Der Preis dafür ist mehr Planung: GRE-Kapselung, Routing, Kapselungsgrenzen und die Frage, ob die Zielplattform den Verkehr zuverlässig entschlüsseln und auswerten kann. RSPAN ist einfacher, aber eben nur dort sinnvoll, wo das Layer-2-Design die Bewegung der Kopie erlaubt. Deshalb entscheide ich nicht nach Gewohnheit, sondern nach Topologie.

Am Ende will ich nicht die eleganteste Technik im Diagramm, sondern den brauchbarsten Mitschnitt im Betrieb. Genau deshalb plane ich SPAN nie isoliert, sondern immer zusammen mit der Messstrategie.

Wie ich Spiegelung in produktiven Netzen klein und belastbar halte

Wenn ich SPAN in produktiven Umgebungen einsetze, versuche ich immer, den Mitschnitt so schmal wie möglich zu halten. Ein großzügig aufgesetzter Spiegelport sieht auf dem Papier bequem aus, erzeugt in der Praxis aber oft nur unnötige Last und unruhige Capture-Dateien. Weniger Quellen, klarere Richtung, kürzere Dauer ist fast immer die bessere Kombination.

Ich achte außerdem auf drei Dinge, die oft unterschätzt werden: Erstens braucht der Analyzer genügend Durchsatz und Speicher, sonst ist die Qualität des Mitschnitts schlecht, obwohl der Switch korrekt arbeitet. Zweitens sollte die Session nach dem Test wieder entfernt werden, damit sie nicht unbemerkt im Netz hängen bleibt. Drittens ist SPAN ein Werkzeug für Paketinspektion, nicht für Langzeitbeobachtung. Wenn ich dauerhaft Auslastung, Latenz oder Pfadverhalten sehen will, ergänze ich die Spiegelung lieber mit Telemetrie- oder Flow-Daten.

Gerade in produktiven Infrastrukturen ist das die vernünftigste Haltung: SPAN ist hervorragend für gezielte Analysen, aber nur dann, wenn ich es wie ein Präzisionswerkzeug behandle und nicht wie eine Dauereinrichtung. Wer die Spiegelung sauber begrenzt, bekommt verwertbare Daten, ohne das Netz selbst zur Fehlerquelle zu machen.