Whenever a network problem needs a real packet capture — not summarized flow statistics, not interface counters, but the actual bytes on the wire — SPAN (Switched Port Analyzer) is the tool that gets you there. It’s the feature that lets you plug a laptop with Wireshark into a switch and see traffic that isn’t even addressed to that laptop. This guide covers SPAN, RSPAN, and ERSPAN on Cisco Catalyst switches: the theory, the exact CLI, verification steps, and the mistakes that trip people up in production.
Why You Can’t Just Plug In and Capture
Ethernet switches forward frames based on MAC address tables — a switch sends a unicast frame only out the port where the destination MAC lives, not to every port. That’s the entire point of switching versus using a hub. It means a packet capture tool plugged into a random switch port sees only its own traffic and broadcast/multicast frames — nothing else. SPAN exists specifically to override that behavior for one or more designated ports, copying their traffic to a separate monitoring port without disrupting normal switching.
SPAN Terminology
- Source port/VLAN — the traffic you want to capture (a physical port, port-channel, or entire VLAN).
- Destination port — the port where a capture device (packet analyzer, IDS sensor) is connected. This port stops normal switching behavior and becomes dedicated to receiving mirrored traffic.
- Local SPAN — source and destination are on the same physical switch.
- RSPAN (Remote SPAN) — source and destination are on different switches, connected via a special RSPAN VLAN that carries mirrored traffic across a trunk.
- ERSPAN (Encapsulated Remote SPAN) — Cisco proprietary, encapsulates mirrored traffic in GRE so it can be routed across Layer 3 boundaries to a remote destination, even off-site.
Fundamentals: Ingress, Egress, and Both
Every SPAN session lets you choose direction per source:
rx(ingress) — traffic entering the source port.tx(egress) — traffic leaving the source port.both— the default if unspecified, captures both directions.
This matters a lot for interpreting captures — mirroring only rx on an uplink port shows you what’s coming from downstream devices, while tx shows what the switch is sending out to them. For full visibility into a conversation, both is typically what you want, understanding you’ll see some frames duplicated if source and destination of a conversation are both being monitored on the same session.
Lab Topology
- Cisco Catalyst 9300 switch, hostname SW1
- Source: Gi1/0/5 (a server uplink you want to monitor)
- Destination: Gi1/0/24 (packet analyzer / IDS sensor)
- For RSPAN: a second switch SW2 with the sensor attached, connected to SW1 via a trunk carrying VLAN 999 (dedicated RSPAN VLAN)
Part 1: Local SPAN Configuration
Step 1 — Create the SPAN Session
SW1(config)# monitor session 1 source interface GigabitEthernet1/0/5 both
SW1(config)# monitor session 1 destination interface GigabitEthernet1/0/24
To mirror an entire VLAN instead of a single port:
SW1(config)# monitor session 1 source vlan 10 both
To mirror multiple sources into the same session:
SW1(config)# monitor session 1 source interface GigabitEthernet1/0/5 - 6 both
Step 2 — (Optional) Preserve Encapsulation or Allow Ingress Traffic on the Destination
By default, the destination port drops any traffic it receives from the connected device (it’s receive-only for normal switching purposes). If your analyzer also needs to send traffic out that port (uncommon, but needed for some inline tools), allow ingress:
SW1(config)# monitor session 1 destination interface GigabitEthernet1/0/24 ingress vlan 10
Step 3 — Verify
SW1# show monitor session 1
Expected output:
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi1/0/5
Destination Ports : Gi1/0/24
Encapsulation : Native
Ingress : Disabled
At this point, anything plugged into Gi1/0/24 running Wireshark (or tcpdump on a Linux box) sees a full copy of traffic entering and leaving Gi1/0/5.
Part 2: RSPAN Configuration (Cross-Switch Capture)
Step 1 — Create the RSPAN VLAN on Both Switches
SW1(config)# vlan 999
SW1(config-vlan)# name RSPAN-VLAN
SW1(config-vlan)# remote-span
SW1(config-vlan)# exit
SW2(config)# vlan 999
SW2(config-vlan)# name RSPAN-VLAN
SW2(config-vlan)# remote-span
SW2(config-vlan)# exit
The remote-span keyword is what makes VLAN 999 behave specially — switches will flood traffic tagged with this VLAN without normal MAC learning, since mirrored traffic isn’t meant to be “learned” as if it were a real host.
Step 2 — Ensure the Trunk Between Switches Carries VLAN 999
SW1(config)# interface GigabitEthernet1/0/48
SW1(config-if)# switchport trunk allowed vlan add 999
Repeat the equivalent on SW2’s uplink toward SW1.
Step 3 — Configure the Source Session on SW1 (where the monitored traffic lives)
SW1(config)# monitor session 2 source interface GigabitEthernet1/0/5 both
SW1(config)# monitor session 2 destination remote vlan 999
Step 4 — Configure the Destination Session on SW2 (where the analyzer is connected)
SW2(config)# monitor session 2 source remote vlan 999
SW2(config)# monitor session 2 destination interface GigabitEthernet1/0/24
Step 5 — Verify on Both Switches
SW1# show monitor session 2
SW2# show monitor session 2
On SW1, expect Type: Remote Source Session. On SW2, expect Type: Remote Destination Session.
Part 3: ERSPAN Configuration (Layer 3, GRE-Encapsulated)
ERSPAN is used when the analyzer is on a completely different part of the network reachable only via routing (common with centralized IDS/NDR platforms like Cisco Stealthwatch or a SPAN aggregation appliance). Supported on higher-end platforms (Catalyst 9000 with the right license/hardware, Nexus, ASR).
Source Switch Configuration
SW1(config)# monitor session 3 type erspan-source
SW1(config-mon-erspan-src)# source interface GigabitEthernet1/0/5 both
SW1(config-mon-erspan-src)# destination
SW1(config-mon-erspan-src-dst)# erspan-id 100
SW1(config-mon-erspan-src-dst)# ip address 192.168.50.10
SW1(config-mon-erspan-src-dst)# origin ip address 192.168.10.1
SW1(config-mon-erspan-src-dst)# end
192.168.50.10 is the remote analyzer/collector’s IP; 192.168.10.1 is the source switch’s own routed interface used as the GRE tunnel’s origin.
Destination Side (Analyzer Reachable via Routed Network)
If the destination is another Cisco switch re-presenting ERSPAN traffic to a local port:
SW2(config)# monitor session 3 type erspan-destination
SW2(config-mon-erspan-dst)# destination interface GigabitEthernet1/0/24
SW2(config-mon-erspan-dst)# source
SW2(config-mon-erspan-dst-src)# erspan-id 100
SW2(config-mon-erspan-dst-src)# ip address 192.168.50.10
SW2(config-mon-erspan-dst-src)# end
More commonly, the destination is a purpose-built collector appliance or virtual machine that natively decapsulates ERSPAN/GRE — in that case no destination-side switch config is needed at all, just IP reachability to 192.168.50.10.
Real-World Enterprise Scenario: Feeding an IDS Sensor
A common production pattern is mirroring an entire VLAN or a firewall’s inside interface to a Cisco Secure IDS / Snort / Suricata sensor for passive threat detection:
SW1(config)# monitor session 4 source vlan 10 , 20 rx
SW1(config)# monitor session 4 destination interface GigabitEthernet1/0/24
Using rx only (rather than both) on VLAN sources here specifically avoids doubling the traffic volume the sensor must process, since with VLAN-based sources every ingress frame into that VLAN is already captured regardless of which port it entered on.
Performance and Capacity Considerations
- SPAN destination ports typically shouldn’t run at a lower link speed than the aggregate of the sources feeding them, or frames get dropped under load. Mirroring two full-duplex gigabit sources into one gigabit destination port can oversubscribe it during high traffic bursts — plan destination bandwidth accordingly, or use a 10G destination port for multiple 1G sources.
- Catalyst platforms have a limited number of concurrent monitor sessions (commonly 2-8 local/RSPAN sessions per switch, platform-dependent) — check the specific model’s datasheet before assuming unlimited sessions are available.
- SPAN and RSPAN sessions add negligible CPU load on modern switches since mirroring happens in hardware ASICs, but ERSPAN (GRE encapsulation) can be more resource-intensive depending on platform.
Common Configuration Mistakes
- Forgetting that a SPAN destination port loses its normal switching function entirely — plugging a regular device into a destination port results in that device having no network connectivity.
- Not allowing the RSPAN VLAN on every trunk link between source and destination switches, breaking the mirror silently.
- Using
bothdirection on VLAN-wide sources, which doubles traffic unnecessarily since ingress into a VLAN already implies egress somewhere else in that VLAN. - Exceeding the platform’s maximum simultaneous SPAN session count and having later sessions silently fail or overwrite earlier ones.
- Mirroring a trunk port without realizing 802.1Q tags will appear in the capture, which can confuse an analyzer expecting untagged frames — plan for this in Wireshark/tcpdump filters.
Troubleshooting Checklist
- No traffic seen at the analyzer: confirm
show monitor session <id>shows the session as active, check that the destination interface isn’t administratively down, and confirm no ACL or port-security is blocking traffic on that port. - RSPAN not working across switches: verify VLAN 999 (or your chosen RSPAN VLAN) is allowed on every trunk in the path with
show interfaces trunk, and confirmremote-spanis configured on the VLAN on every switch in the path, not just source and destination. - Traffic seen but incomplete: check whether the session direction (
rx/tx/both) matches what you actually need, and confirm you’re not hitting the platform’s maximum source port/session limits. - ERSPAN not reaching destination: verify basic IP reachability between origin and destination IPs (
ping), and confirm no upstream firewall is blocking GRE (IP protocol 47).
FAQs
Does SPAN affect switch performance for normal traffic? On modern Catalyst hardware, no — mirroring is done in the switching ASIC, so normal forwarding on source ports is unaffected. The exception is oversubscribing the destination port itself, which can cause mirrored frames to be dropped, but this never impacts the original live traffic.
Can I mirror traffic to a port that’s also a normal access or trunk port? No — once configured as a SPAN destination, a port is dedicated to that role and stops participating in normal Layer 2 forwarding, spanning-tree, and (by default) doesn’t accept inbound traffic either.
What’s the difference between SPAN and a TAP? SPAN is a switch feature that copies traffic in software/ASIC logic and can drop frames under oversubscription; a TAP is a physical inline device that copies every bit at the physical layer with zero chance of drops, but requires physical insertion into the cable path and doesn’t scale as easily to monitoring many ports at once.
Can I run SPAN and NetFlow at the same time on the same interface? Yes — they operate independently and are commonly run together, with NetFlow providing lightweight ongoing visibility and SPAN reserved for targeted, deeper investigation when needed.
Summary
SPAN, RSPAN, and ERSPAN all solve the same core problem — getting a copy of switched traffic to an analysis tool that wouldn’t otherwise see it — at increasing levels of geographic reach. Local SPAN handles same-switch capture, RSPAN extends that across switches within a Layer 2 domain using a dedicated VLAN, and ERSPAN goes further still by encapsulating traffic in GRE for delivery across a routed network. In every case, the pattern is the same: define your source (port or VLAN, with direction), define your destination, and verify with show monitor session. Plan destination port bandwidth and platform session limits ahead of time, and you’ll have reliable, production-safe visibility whenever deep packet analysis is needed.
References
- Cisco: Catalyst 9300 Series Switches Configuration Guide — SPAN and RSPAN — https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-x/configuration_guide/span/b_spanrspanerspan_17_1_2013_e_9300_cg.html
- Cisco: Configuring ERSPAN — https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/system_management/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x_chapter_0100.html
- Cisco: SPAN, RSPAN, and ERSPAN Overview and Restrictions — https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html
