Offensive Security Researcher & Quantum Cryptography Analyst

How to Implement Port Mirroring (SPAN) on Cisco Switches for Traffic Analysis

Abdul Wahab Junaid
How to Implement Port Mirroring (SPAN) on Cisco Switches

How to Implement Port Mirroring (SPAN) on Cisco Switches

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

Fundamentals: Ingress, Egress, and Both

Every SPAN session lets you choose direction per source:

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

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

Common Configuration Mistakes

Troubleshooting Checklist

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

Exit mobile version