Ein sauber eingerichteter Mirror-Port gehört zu den nützlichsten Werkzeugen, wenn ich Verkehr auf einem Switch sichtbar machen will, ohne den Produktivverkehr anzutasten. In diesem Artikel zeige ich, was die Funktion technisch liefert, wann sie in der Fehlersuche wirklich hilft und wo ihre Grenzen liegen. Genau das ist in Telekommunikations- und Infrastrukturnetzen wichtig, weil Messdaten nur dann wertvoll sind, wenn sie vollständig genug und gleichzeitig sauber eingegrenzt sind.
Die Technik ist nützlich, aber nur dann, wenn Quelle, Richtung und Ziel sauber geplant sind
- Ein SPAN-Port kopiert ausgewählte Pakete auf einen separaten Analyseport, an dem ein Analyzer oder eine Capture-Box hängt.
- Die Funktion ist ideal für Paketmitschnitt, Security-Monitoring, Latenzdiagnosen und das Prüfen von Fehlern nach Änderungen.
- Zu wenig Bandbreite am Ziel führt zu Paketverlusten, auch wenn der Produktionsverkehr weiterläuft.
- Für verteilte Netze sind RSPAN oder ERSPAN oft sinnvoller als eine rein lokale Spiegelung.
- Je enger ich Quelle, Richtung und Filter setze, desto brauchbarer wird der Mitschnitt.
Was ein Mirror-Port im Switch wirklich tut
Die Grundidee ist schlicht: Ein Switch kopiert ausgewählte Frames von einem Quellport, einem Port-Channel oder einer VLAN-Quelle auf einen separaten Zielport. An diesem Ziel hängt ein Analyzer, also ein Rechner, eine Appliance oder eine Capture-Box, die die Kopien auswertet. Cisco beschreibt SPAN im Kern genau so: Verkehr wird von Quellports auf einen Zielport gespiegelt, damit er analysiert werden kann.
Wichtig ist dabei die Trennung zwischen Produktivpfad und Analysepfad. Der Switch leitet die normalen Daten weiter, während die Kopie zusätzlich an die Messseite geht. Das klingt banal, macht in der Praxis aber den Unterschied zwischen einer sauberen Diagnose und einer Messung, die selbst zum Problem wird.
Lesen Sie auch: OSI vs. TCP/IP - Der wahre Unterschied für Ihr Netzwerk
Ingress und egress unterscheiden
Ich achte zuerst darauf, ob ich Eingangsverkehr, Ausgangsverkehr oder beides sehen will. Ingress zeigt Pakete so, wie sie am Port ankommen, also oft noch bevor eine Forwarding-Entscheidung greift. Das ist nützlich, wenn ich ACLs, STP-Effekte, Routing-Probleme oder unerwartete Drops untersuchen will. Egress zeigt dagegen, was den Port tatsächlich verlässt. Wer nur eine Richtung spiegelt, übersieht leicht genau die Seite, auf der der Fehler entsteht.
Bei vielen Plattformen gilt außerdem: Der Zielport ist exklusiv. Er ist kein normaler Benutzerport, sondern ein Beobachtungspunkt. Genau deshalb sollte ich ihn weder für Switching noch für parallele Betriebsaufgaben einplanen. Wer das ignoriert, bekommt ein Setup, das zwar technisch aktiv ist, aber diagnostisch schnell unzuverlässig wird.
Diese Trennung ist die Basis, auf der man die typischen Einsatzfälle sinnvoll bewerten kann.
Wann die Spiegelung im Alltag ihren größten Wert hat
Der größte Nutzen liegt fast nie in der abstrakten Netzwerkanalyse, sondern in einer konkreten Frage: Wer hat was wann gesendet, und was ist daraus geworden? Genau dafür ist die Funktion stark. Ich setze sie ein, wenn ein Problem sporadisch auftritt, sich nicht sauber im Log zeigt oder nur unter Last sichtbar wird.
- Fehlersuche bei Aussetzern - Ein Mitschnitt zeigt, ob Retransmits, Fragmentierung oder unerwartete Reset-Sequenzen auftreten.
- Security-Analyse - IDS-, NDR- oder Forensik-Tools brauchen Verkehrskopien, um Anomalien, Scans oder ungewöhnliche Verbindungen zu erkennen.
- Sprach- und Videodienste - Bei VoIP oder Videokonferenzen helfen Spiegelungen, Jitter, Paketverlust und falsche Priorisierung sichtbar zu machen.
- Change-Validierung - Nach VLAN-, ACL- oder STP-Änderungen sehe ich sofort, ob sich der Verkehr so verhält, wie geplant.
Gerade in verteilten Infrastrukturen mit knapper Bandbreite ist das hilfreich, weil ich nicht überall dauerhafte Messpunkte installieren muss. Stattdessen kann ich gezielt dort mitschneiden, wo das Problem entsteht. Bevor ich den Mitschnitt aber aktiviere, muss die Zielseite technisch mitspielen.
So plane ich eine Spiegelung ohne unnötige Verluste
Juniper weist ausdrücklich darauf hin, dass Pakete verworfen werden, wenn die Kapazität des Ausgangsinterface nicht ausreicht. Genau deshalb plane ich eine Spiegelung nie nach dem Motto „Port frei, also passt schon“, sondern nach Last, Richtung und Zielsystem. Ein 10-Mbit/s-Zielport, der einen 100-Mbit/s-Quellport beobachten soll, ist ein klassisches Rezept für verlorene Pakete.
- Ich begrenze die Quelle - Statt „alles“ zu spiegeln, wähle ich einzelne Interfaces, eine klar definierte VLAN-Quelle oder ein enges Port-Set.
- Ich lege die Richtung fest - Ingress, egress oder beides muss dem Diagnoseziel entsprechen. Andernfalls messe ich zu viel oder das Falsche.
- Ich prüfe die Zielbandbreite - Der Analyseport sollte den tatsächlichen Peak tragen können, nicht nur den Durchschnitt.
- Ich dimensioniere den Analyzer - Capture-NIC, CPU, Buffer und Speicher müssen den Datenstrom aufnehmen können, sonst verlagere ich den Engpass nur.
- Ich teste mit echtem Verkehr - Ein kurzer Test mit bekannten Flows zeigt schneller als jede Vermutung, ob Drops oder Verzerrungen entstehen.
- Ich dokumentiere die Session - Wer spiegeln darf, was gespiegelt wird und wann die Session wieder beendet wird, sollte sauber festgehalten sein.
Mein Praxisprinzip ist dabei einfach: lieber eng und verlässlich als breit und unbrauchbar. Ein gezielt gespiegelter Ausschnitt bringt fast immer mehr Erkenntnis als eine scheinbar vollständige, aber überladene Kopie. Sobald das Setup steht, stellt sich die Frage, welche Variante lokal, über mehrere Switches oder geroutet am sinnvollsten ist.
SPAN, RSPAN und ERSPAN unterscheiden sich deutlicher als viele denken
Lokale Spiegelung ist die einfachste Form. Sobald jedoch mehrere Switches, getrennte Standorte oder geroutete Netze im Spiel sind, wird die Wahl der Variante wichtig. Ich trenne diese drei Begriffe deshalb immer sehr bewusst, weil sie in der Praxis unterschiedliche Reichweiten und Anforderungen haben.
| Variante | Reichweite | Stärken | Grenzen | Typisch sinnvoll, wenn |
|---|---|---|---|---|
| Lokale Spiegelung | Nur auf demselben Switch | Einfach, schnell, wenig Zusatzaufwand | Analysator muss lokal erreichbar sein | Ich einen konkreten Port oder ein VLAN direkt am Standort prüfen will |
| RSPAN | Über mehrere Switches im Layer-2-Bereich | Zentraler Analysepunkt ohne direkte Nähe zum Quellport | Benötigt ein dediziertes Transport-VLAN und saubere L2-Planung | Ich Verkehr aus mehreren Verteilpunkten zu einem Analyseort ziehen will |
| ERSPAN | Über geroutete Netze | Geeignet für entfernte Standorte und IP-basierte Transportwege | Mehr Overhead, Tunnel-Design und MTU-Planung nötig | Der Analyzer nicht im selben Layer-2-Segment steht |
Juniper beschreibt Remote-Mirroring mit GRE-Kapselung, und genau das ist in der Praxis der Knackpunkt: Sobald Verkehr zusätzlich verpackt wird, muss ich MTU, Latenz und mögliche Engpässe mitdenken. Für einfache lokale Diagnosen nehme ich daher fast immer die lokale Variante. Wenn Standorte oder verteilte Infrastrukturen ins Spiel kommen, wird Remote-Mirroring interessant, aber auch deutlich empfindlicher gegenüber Planungsfehlern.
Wenn ich maximale Genauigkeit brauche, etwa bei forensischen Mitschnitten oder sehr feinen Timing-Analysen, ziehe ich oft einen TAP vor. Der ist nicht dasselbe wie ein Mirror-Port, liefert aber in kritischen Fällen oft die sauberere Sicht. Genau daran sieht man, dass die Technikfrage nicht nur „was geht?“, sondern auch „wie belastbar muss das Ergebnis sein?“ lautet.
Die häufigsten Fehler, die ein gutes Setup wertlos machen
Die meisten Probleme entstehen nicht durch die Funktion selbst, sondern durch eine zu grobe Konfiguration. Ich sehe immer wieder dieselben Muster, und fast alle davon sind vermeidbar:
- Zu viele Quellen auf einmal - Wer mehrere aktive Ports ungefiltert spiegelt, produziert schnell mehr Verkehr, als der Zielport verkraftet.
- Der falsche Richtungsfilter - Einseitige Spiegelung ist nur dann sinnvoll, wenn ich genau diese Seite untersuchen will.
- Der Zielport wird anderweitig genutzt - Ein Mirror-Port sollte nicht gleichzeitig für normale Switch-Aufgaben eingeplant werden.
- Alles statt gezielt - „All“ wirkt bequem, liefert aber oft nur Rauschen und unnötige Last.
- Der Analyzer ist zu schwach - Eine langsame Capture-NIC oder ein volles Speichermedium verfälschen das Bild genauso wie ein überlasteter Switch.
- Remote-Mirroring ohne MTU-Test - Zusätzliche Kapselung verändert das Paketformat und kann genau dort Verluste auslösen, wo niemand sie erwartet.
- Unklare Zugriffsregeln - Mitschnitte können sensible Inhalte enthalten; wer sie ansehen darf, sollte organisatorisch sauber geregelt sein.
Der letzte Punkt wird oft unterschätzt. In deutschen Unternehmensnetzen und in Betriebsumgebungen mit mehreren Zuständigkeiten ist nicht nur die Technik relevant, sondern auch die klare Freigabe für Mitschnitte. Ich behandle einen Spiegelport daher immer als Werkzeug für gezielte Diagnose, nicht als Dauerlösung für allgemeine Beobachtung.
Worauf ich bei einer belastbaren Monitoring-Architektur zuerst achte
Am Ende entscheide ich nicht nach dem Etikett, sondern nach der Betriebsrealität. Wenn ich einen einzelnen Switch lokal prüfen will, reicht eine präzise konfigurierte Spiegelung oft völlig aus. Wenn mehrere Standorte, getrennte Layer-2-Domänen oder geroutete Wege beteiligt sind, brauche ich RSPAN oder ERSPAN. Und wenn die Sicht wirklich lückenlos sein muss, bevorzuge ich eine dedizierte Messstrecke oder einen TAP statt eines überlastbaren Kopierpfads.
Die drei Fragen, die ich mir immer zuerst stelle, sind einfach: Wie viel Verkehr fällt wirklich an? Wo liegt der Zielpunkt? Wie kritisch ist die Vollständigkeit der Daten? Wer darauf ehrlich antwortet, vermeidet die meisten Fehlentscheidungen rund um Port-Mirroring und bekommt genau die Sicht auf das Netzwerk, die für Fehlersuche, Analyse und Betrieb tatsächlich brauchbar ist.
