Mental model
Switches forward frames only out the destination port — they’re efficient that way. But sometimes you need to see the traffic for troubleshooting, security analysis, or compliance recording. Plugging Wireshark into an arbitrary port doesn’t help — that port only sees its own frames.
SPAN (Switched Port Analyzer) is Cisco’s port-mirroring feature. The switch copies traffic from one or more source ports (or VLANs) to a designated destination port. The analyzer plugged into the destination port sees everything happening on the sources.
Three flavors:
| Feature | Where copies go | Use case |
|---|---|---|
| SPAN (local) | Another port on the same switch | Standalone troubleshooting |
| RSPAN (Remote) | A dedicated VLAN spanning multiple switches | Centralized analyzer for a building |
| ERSPAN (Encapsulated Remote) | Wrapped in GRE, sent across the routed network | Cloud analyzers, remote SOC |
SPAN — local
SW1(config)# monitor session 1 source interface GigabitEthernet0/1
SW1(config)# monitor session 1 source interface GigabitEthernet0/2
SW1(config)# monitor session 1 destination interface GigabitEthernet0/24
Now everything traveling on Gi0/1 and Gi0/2 (both directions by default) is also copied to Gi0/24. The destination port is read-only for the analyzer — it stops forwarding normal traffic.
Direction options:
SW1(config)# monitor session 1 source interface Gi0/1 rx ! only inbound
SW1(config)# monitor session 1 source interface Gi0/1 tx ! only outbound
SW1(config)# monitor session 1 source interface Gi0/1 both ! default
You can also mirror entire VLANs:
SW1(config)# monitor session 1 source vlan 10
SW1(config)# monitor session 1 destination interface Gi0/24
RSPAN — across multiple switches
When the analyzer isn’t on the same switch as the source, RSPAN extends SPAN across the network using a dedicated RSPAN VLAN.
! On every switch in the path — create the RSPAN VLAN
SW1(config)# vlan 999
SW1(config-vlan)# remote-span
SW1(config-vlan)# exit
! Source switch
SW1(config)# monitor session 1 source interface Gi0/1
SW1(config)# monitor session 1 destination remote vlan 999
! Destination switch (where the analyzer lives)
SW2(config)# monitor session 1 source remote vlan 999
SW2(config)# monitor session 1 destination interface Gi0/24
The RSPAN VLAN must be allowed on every trunk between source and destination switches.
ERSPAN — across routed networks
When the analyzer is in a different IP subnet (cloud, remote SOC, central data center), RSPAN’s VLAN-trunk requirement won’t work. ERSPAN wraps mirrored traffic in GRE so it can ride over any routed path.
! Source side
SW1(config)# monitor session 1 type erspan-source
SW1(config-mon-erspan-src)# source interface Gi0/1
SW1(config-mon-erspan-src)# destination
SW1(config-mon-erspan-src-dst)# erspan-id 100
SW1(config-mon-erspan-src-dst)# ip address 10.99.99.10 ! analyzer IP
SW1(config-mon-erspan-src-dst)# origin ip address 10.0.0.1 ! sender IP
! Destination side (the analyzer's switch)
SW2(config)# monitor session 1 type erspan-destination
SW2(config-mon-erspan-dst)# destination interface Gi0/24
SW2(config-mon-erspan-dst)# source
SW2(config-mon-erspan-dst-src)# erspan-id 100
SW2(config-mon-erspan-dst-src)# ip address 10.99.99.10
ERSPAN adds GRE header overhead (~50 bytes) — be mindful of MTU on the path. Heavy SPAN traffic over a constrained WAN can saturate.
Verification
SW1# show monitor ! list all sessions
SW1# show monitor session 1 ! detail for one session
SW1# show monitor session 1 detail
Confirm: source ports, destination port, direction, session number. Easy to fat-finger.
Common mistakes
-
Source = destination same port. Configuring a port as both source and destination → switch refuses or behaves weirdly. They must be different ports.
-
Connecting an analyzer expecting normal traffic too. Destination ports stop forwarding normal traffic. Don’t plug a printer into a SPAN destination.
-
Forgetting that the analyzer needs to handle the full traffic volume. Mirroring two 1 Gbps ports → up to 2 Gbps copies to the destination. If the analyzer port is also 1 Gbps, drops happen. Use a faster destination port or sample.
-
RSPAN VLAN not allowed on a transit trunk. The mirror traffic is silently dropped between switches. Always verify the RSPAN VLAN is in the
switchport trunk allowed vlanlist on every transit trunk. -
ERSPAN MTU not configured. GRE overhead pushes mirrored packets over the network’s MTU → fragmentation or drops. Set
mtuappropriately on the ERSPAN destination interface. -
Forgetting that SPAN copies aren’t the same as the original. Some VLAN tag information may be stripped depending on the source-port type (access vs trunk). For exact-fidelity capture, mirror a trunk port and use a SPAN-friendly analyzer.
Lab to try tonight
- One switch. PC-A on Gi0/1 (legitimate traffic). PC-B on Gi0/2 (also legitimate). Wireshark laptop on Gi0/24.
- Configure:
monitor session 1 source interface Gi0/1+monitor session 1 destination interface Gi0/24. - Generate traffic from PC-A. Capture on the Wireshark laptop. Verify you see PC-A’s traffic.
- Add Gi0/2 as a second source. Generate traffic from PC-B. Wireshark sees that too.
- Try plugging an extra normal device into Gi0/24. Note: it can’t communicate normally — destination ports are essentially “Wireshark only.”
- Bonus: RSPAN across two switches. Create the RSPAN VLAN, configure source on SW1 and destination on SW2, verify traffic from SW1 reaches the Wireshark laptop on SW2.
Cheat strip
| Concept | Plain English |
|---|---|
| SPAN | Local port mirroring on one switch |
| RSPAN | Mirror across multiple switches via dedicated VLAN |
| ERSPAN | Mirror across routed networks via GRE encapsulation |
| Source | The port (or VLAN) being monitored |
| Destination | Where the analyzer is connected. Read-only for normal traffic. |
| Direction | rx / tx / both — default both |
monitor session N | The command structure for SPAN sessions |
| Use cases | Wireshark, IDS, security recording, compliance |
| MTU caveat | ERSPAN adds GRE overhead — watch path MTU |