SPAN Port konfigurieren: Paketmitschnitt für Troubleshooting

Ein sauberer Paketmitschnitt ist im Troubleshooting oft der schnellste Weg zur Wahrheit. Wenn Ping, Traceroute, „show“-Befehle und Logs keine eindeutige Antwort liefern, zeigt ein Packet Capture unmittelbar, was wirklich über das Netz geht: ARP-Auflösung, DHCP-Abläufe, TCP-Handshake, TLS-Fehler, Retransmissions, MTU-Probleme oder verdächtige Broadcast-Stürme. In Cisco-Switching-Umgebungen ist dafür der SPAN Port (Switched Port Analyzer) das Standardwerkzeug. Mit SPAN spiegeln Sie den Traffic eines Ports, eines VLANs oder sogar eines gesamten Trunks auf einen Zielport, an dem ein Analyzer (z. B. Laptop mit Wireshark) mitliest. Das ist besonders hilfreich, wenn Sie den Datenverkehr „zwischen“ Geräten untersuchen müssen, ohne die produktive Verbindung zu unterbrechen. Gleichzeitig ist SPAN kein „einfach mal einschalten“-Feature: Falsch konfigurierte Sessions, überbuchte Mirror-Ports oder das Spiegeln zu großer Traffic-Mengen können zu unvollständigen Captures führen und im schlimmsten Fall die Performance beeinflussen. Dieser Leitfaden zeigt Ihnen praxisnah, wie Sie einen SPAN Port konfigurieren, welche SPAN-Varianten es gibt (Local SPAN, RSPAN, ERSPAN), welche Best Practices für zuverlässige Mitschnitte gelten und wie Sie typische Fehlerbilder schnell eingrenzen.

Was ist ein SPAN Port und wann wird er eingesetzt?

SPAN ist eine Funktion auf Cisco Switches, die ausgewählten Verkehr kopiert und an einen dedizierten Zielport weiterleitet. Der Zielport ist dabei der „Monitor-Port“, an dem Ihr Capture-System angeschlossen wird. Typische Einsatzfälle:

• Fehlerhafte DHCP-Zuweisung: Discover/Offer/Request/Ack prüfen, Rogue DHCP erkennen.
• ARP-Probleme und IP-Konflikte: ARP-Requests/Replies und Grat-ARP analysieren.
• TCP/Anwendungsprobleme: Handshakes, Retransmissions, Window-Size, Reset/FIN, Timeouts.
• VLAN/Trunk-Fehler: Tagging, Native VLAN, Allowed VLANs, unerwartete VLAN-Zuordnung.
• Security-Analysen: Port-Scanning, ungewöhnliche Kommunikation, Broadcast/Multicast-Last.
• QoS-Überprüfung: DSCP/CoS-Markierungen verifizieren, Queueing-Fehler indirekt erkennen.

Für die Auswertung bietet sich als Standardtool Wireshark Dokumentation an. Für Cisco-spezifische Syntaxvarianten ist die passende Plattformdokumentation entscheidend; als Einstieg eignet sich der Anchor-Text Cisco Catalyst Dokumentation.

SPAN-Grundbegriffe: Source, Destination, Direction

Eine SPAN-Session besteht immer aus:

• Source: Der Port, das VLAN oder die Port-Channel-Schnittstelle, deren Traffic gespiegelt wird.
• Destination: Der Zielport, an dem Ihr Analyzer angeschlossen ist.
• Direction: Welche Richtung gespiegelt wird: rx (eingehend), tx (ausgehend) oder both (beides).

Merksatz: Wenn Sie den Traffic „vom Client zum Switch“ und „vom Switch zum Client“ sehen wollen, brauchen Sie in der Regel both. Wenn Sie nur das Problem „Upload“ oder „Download“ eingrenzen möchten, kann rx/tx gezielt helfen.

Welche SPAN-Varianten gibt es?

Cisco bietet je nach Plattform mehrere SPAN-Methoden. Die wichtigsten sind:

• Local SPAN: Quelle und Ziel liegen auf demselben Switch. Das ist die häufigste und einfachste Variante.
• RSPAN (Remote SPAN): Quelle und Ziel liegen auf unterschiedlichen Switches, verbunden über ein spezielles RSPAN-VLAN, das den gespiegelten Traffic transportiert.
• ERSPAN (Encapsulated Remote SPAN): Spiegelung wird in GRE (oder vergleichbar) kapselt und über Layer 3 transportiert. Ideal, wenn Sie keinen Layer-2-Pfad für RSPAN haben oder über geroutete Netze spiegeln müssen.

Für Troubleshooting im Campus genügt in den meisten Fällen Local SPAN. RSPAN/ERSPAN sind sinnvoll, wenn Sie nicht physisch am Quell-Switch mitschneiden können oder die Analyse zentral erfolgen soll.

Vorbereitung: Analyzer-Port und Capture-Setup sauber planen

Bevor Sie konfigurieren, klären Sie drei praktische Punkte. Das reduziert Fehlmessungen und spart Zeit:

• Wo sitzt das Problem wirklich? Spiegeln Sie so nah wie möglich an der Fehlerquelle (Client-Port, Server-Port, Uplink), statt „irgendwo im Core“.
• Wie viel Traffic erwarten Sie? Ein 1-Gbit/s-Analyzer-Port kann keinen 10-Gbit/s-Trunk vollständig spiegeln. Überbuchung führt zu Drops im Mirror-Traffic und damit zu unvollständigen Captures.
• Benötigen Sie VLAN-Tags? Wenn Sie Trunk-Traffic analysieren, ist es oft wichtig, 802.1Q-Tags im Capture zu sehen. Prüfen Sie, ob Ihr SPAN-Setup Tags beibehält oder entfernt (plattformabhängig).

Praxis-Tipp: Für hohe Bandbreiten ist ein dedizierter Capture-Adapter (z. B. 10G NIC) und ein leistungsfähiger Capture-Host hilfreich. Außerdem sollten Sie auf dem Analyzer passende Capture-Filter setzen, damit Sie nicht unnötig riesige Dateien erzeugen.

Local SPAN Schritt-für-Schritt: Port auf Port spiegeln

Der klassische Fall: Sie möchten den Traffic eines bestimmten Access-Ports spiegeln, an dem ein Client hängt. Beispiel: Quelle ist Gi1/0/10, Ziel ist Gi1/0/48 (dort steckt Ihr Laptop).

Beispielkonfiguration (typisches Cisco IOS/IOS XE Muster)

configure terminal
monitor session 1 source interface GigabitEthernet1/0/10 both
monitor session 1 destination interface GigabitEthernet1/0/48
end

Was passiert dabei?

• Der Switch kopiert RX und TX des Quellports.
• Der Zielport wird in den SPAN-Modus versetzt und ist typischerweise nicht mehr für normalen Traffic nutzbar, solange die Session aktiv ist.

VLAN SPAN: Gesamtes VLAN spiegeln

Wenn Sie ein Problem innerhalb eines VLANs vermuten (z. B. DHCP, Broadcast-Sturm, ARP-Spoofing), kann VLAN SPAN sinnvoll sein. Dabei wird Traffic aus einem VLAN gespiegelt, unabhängig davon, über welchen Port er läuft.

Beispiel: VLAN 10 spiegeln

configure terminal
monitor session 2 source vlan 10 both
monitor session 2 destination interface GigabitEthernet1/0/48
end

Best Practice: VLAN SPAN erzeugt oft viel Traffic. Nutzen Sie es gezielt und möglichst kurz. Wenn das VLAN groß ist, kann Ihr Analyzer-Port überfordert sein. In solchen Fällen ist es besser, direkt den betroffenen Access-Port oder einen spezifischen Uplink zu spiegeln und zusätzlich Capture-Filter einzusetzen.

Trunk/Uplink SPAN: Wenn das Problem „zwischen Switches“ liegt

Viele Probleme zeigen sich erst auf Uplinks: VLAN-Tagging ist falsch, Native VLAN passt nicht, Allowed VLANs sind zu eng oder zu weit, oder EtherChannel verteilt Flows unerwartet. Dann ist es sinnvoll, den Trunk (oder Port-Channel) zu spiegeln.

Beispiel: Uplink-Port spiegeln

configure terminal
monitor session 3 source interface GigabitEthernet1/0/49 both
monitor session 3 destination interface GigabitEthernet1/0/48
end

Wenn der Uplink ein Port-Channel ist, spiegeln Sie nach Möglichkeit den Port-Channel selbst oder den relevanten Member-Port (plattformabhängig). Wichtig ist: Spiegeln Sie nicht gleichzeitig mehrere 10G-Quellen auf einen 1G-Zielport, wenn Sie vollständige Sicht erwarten.

Richtung richtig wählen: rx, tx oder both?

Die Direction beeinflusst, welche Pakete Sie sehen. Eine saubere Wahl kann Ihnen viel Zeit sparen:

• rx: Sie sehen, was am Quellport in den Switch hineingeht (z. B. Client sendet DHCP Discover).
• tx: Sie sehen, was der Switch zum Port hinaussendet (z. B. DHCP Offer kommt beim Client an).
• both: Vollbild, ideal für End-to-End-Diagnose, aber doppelte Menge an Mirror-Traffic.

Praxisbeispiel: Wenn der Client keine IP bekommt, ist es hilfreich, sowohl Discover (rx) als auch Offer/Ack (tx) zu sehen. Mit both sparen Sie sich Iterationen.

Wichtige Einschränkungen und typische Überraschungen bei SPAN

SPAN ist extrem nützlich, aber es gibt technische Grenzen, die Sie in der Interpretation berücksichtigen sollten:

• Oversubscription: Wenn Quelle schneller ist als Destination, werden Mirror-Pakete verworfen. Das Capture wirkt dann „unvollständig“.
• Timing: SPAN kann Timing leicht verändern; für Mikrosekunden-genaue Latenzanalysen ist SPAN nicht ideal.
• Duplikate: Je nach Setup können Sie bestimmte Frames doppelt sehen (insbesondere bei VLAN SPAN oder komplexen Pfaden).
• Layer-1/Fehler: SPAN zeigt nicht immer alle physikalischen Layer-1-Effekte. Für physische Fehlerdiagnose bleiben Interface-Counter wichtig.
• VLAN-Tags: Tagging im Capture hängt von Plattform und Konfiguration ab. Prüfen Sie, ob Ihr Use Case Tags benötigt.

Best Practice: Kombinieren Sie SPAN immer mit „show interfaces“ (Errors/Drops), „show mac address-table“, „show spanning-tree“ und ggf. DHCP Snooping/DAI-Status, um eine vollständige Diagnose zu erhalten.

RSPAN: Remote SPAN für Mitschnitt über mehrere Switches

Wenn Ihr Analyzer nicht am gleichen Switch stehen kann, ist RSPAN eine klassische Lösung. Sie definieren ein spezielles VLAN als RSPAN-VLAN, das den gespiegelten Traffic über Trunks transportiert. Am Ziel-Switch leiten Sie dieses VLAN auf den Analyzer-Port.

RSPAN-VLAN konfigurieren (Konzept)

Auf allen beteiligten Switches:

configure terminal
vlan 999
remote-span
end

Dann auf dem Quell-Switch die SPAN-Session in das RSPAN-VLAN spiegeln (Quelle → RSPAN-VLAN). Auf dem Ziel-Switch spiegeln Sie das RSPAN-VLAN auf den Analyzer-Port (RSPAN-VLAN → Destination-Port). Die genaue Syntax ist plattformabhängig; prüfen Sie dafür die Dokumentation Ihrer Switchserie über den Anchor-Text Cisco Catalyst Dokumentation.

Best Practices für RSPAN:

• RSPAN-VLAN nur auf benötigten Trunks zulassen (Allowed VLANs), sonst unnötige Verbreitung.
• RSPAN-VLAN nicht routen und nicht für produktiven Traffic verwenden.
• Bandbreite bedenken: RSPAN transportiert Mirror-Traffic über Ihre Trunks.

ERSPAN: Spiegeln über geroutete Netze

ERSPAN kapselt SPAN-Traffic und transportiert ihn über Layer 3 zu einem Ziel, oft einem zentralen Collector. Das ist praktisch, wenn kein Layer-2-Pfad vorhanden ist oder wenn Sie zentralisierte Analysen durchführen möchten. ERSPAN ist besonders in großen Netzen und in Data-Center-nahen Architekturen beliebt.

Da ERSPAN-Syntax und -Support je Plattform stark variieren, ist es sinnvoll, die offizielle Cisco-Dokumentation für Ihre konkrete Hardware und IOS/IOS XE-Version zu nutzen. Ein hilfreicher Einstieg ist der Anchor-Text Cisco IOS/IOS XE Dokumentationsübersicht.

Best Practices: So werden SPAN-Captures wirklich brauchbar

Viele SPAN-Probleme entstehen nicht durch die Funktion selbst, sondern durch unklare Methodik. Diese Best Practices haben sich im Betrieb bewährt:

• So nah wie möglich an der Quelle spiegeln: Client-Port oder Server-Port statt „irgendein Uplink“.
• Bandbreite beachten: Spiegeln Sie nicht mehr, als Ihr Zielport und Ihr Analyzer aufnehmen können.
• Capture-Filter nutzen: In Wireshark/tcpdump einen Filter setzen (z. B. Host-IP, Port 443, DHCP), statt „alles“ zu speichern.
• Kurze Zeitfenster: Lieber mehrere kurze Captures statt einer riesigen Datei, die schwer zu analysieren ist.
• Session sauber entfernen: SPAN-Sessions nach Abschluss löschen, damit Ports wieder normal arbeiten.
• Dokumentieren: Bei Incidents festhalten, welche Quelle/Ziel/Session aktiv war, damit andere Admins nicht überrascht werden.

Verifikation: So prüfen Sie, ob die SPAN-Session aktiv ist

Nach der Konfiguration sollten Sie prüfen, ob die Session wirklich läuft. Typische „show“-Befehle (plattformabhängig, aber häufig vorhanden):

show monitor session 1
show monitor session all

Worauf Sie achten sollten:

• Ist die richtige Source (Port/VLAN) eingetragen?
• Ist die Direction korrekt (rx/tx/both)?
• Ist die Destination korrekt und aktiv?
• Gibt es Hinweise auf Einschränkungen (z. B. nicht unterstützte Kombinationen)?

Zusätzlich sollte Ihr Analyzer am Zielport Link haben und im Capture tatsächliche Pakete sehen. Wenn Link anliegt, aber keine Pakete ankommen, ist häufig die Source falsch gewählt oder die Richtung passt nicht.

SPAN wieder entfernen: Aufräumen nach dem Troubleshooting

Wenn der Mitschnitt abgeschlossen ist, sollten Sie die Session entfernen, damit der Zielport wieder normal verwendbar ist und keine Ressourcen unnötig gebunden werden.

configure terminal
no monitor session 1
end

Wenn Sie mehrere Sessions genutzt haben, entfernen Sie nur die relevante oder löschen Sie alle nicht mehr benötigten Sessions. In Change-Prozessen ist es sinnvoll, „SPAN entfernt“ als Abschlusskriterium zu dokumentieren.

Typische Fehlerbilder und schnelle Ursachenanalyse

• Capture ist leer: Falsche Source, falsche Direction oder Session nicht aktiv. Prüfen Sie show monitor session.
• Capture ist unvollständig: Oversubscription. Spiegeln Sie weniger Traffic, nutzen Sie Filter oder einen schnelleren Destination-Port.
• VLAN-Tags fehlen: Plattformabhängiges Verhalten. Spiegeln Sie näher am Endgerät oder prüfen Sie SPAN-Tagging-Optionen Ihrer Plattform.
• Analyzer sieht nur eine Richtung: Direction falsch gesetzt oder nur rx/tx aktiv. Umstellen auf both.
• Netzwerk wird langsamer: Zu große Mirror-Last, ungünstige Quelle (z. B. VLAN SPAN in großem VLAN). Spiegelung reduzieren oder zeitlich begrenzen.

Praxis-Checkliste: SPAN Port konfigurieren für Paketmitschnitt

• Ist klar, welcher Port/VLAN/Trunk die beste Source für das Problem ist?
• Kann der Destination-Port die erwartete Traffic-Menge aufnehmen (keine massive Oversubscription)?
• Ist die richtige Direction gewählt (rx/tx/both)?
• Benötigen Sie VLAN-Tags im Capture, und unterstützt Ihr Setup das?
• Ist der Analyzer korrekt angeschlossen und laufen Capture-Filter, um Noise zu reduzieren?
• Wurde die Session verifiziert (show monitor session) und sind Pakete sichtbar?
• Wurde die SPAN-Session nach Abschluss wieder entfernt (no monitor session)?

Für vertiefende Analysen und Filtertechniken lohnt sich der Blick in die Wireshark User’s Guide. Für Cisco-spezifische SPAN-Details und plattformabhängige Besonderheiten ist die Dokumentation Ihrer Switchserie der zuverlässigste Einstieg, z. B. über den Anchor-Text Cisco Catalyst Dokumentation.

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.