Table of Contents Link to heading

Why Traffic Mirroring Exists Link to heading

Network analysis tools — packet analysers (Wireshark), IDS/IPS sensors, network performance monitors — need to see a copy of live traffic without being placed inline in the traffic path. Placing an analyser inline introduces a potential single point of failure and requires physical topology changes.

SPAN (Switched Port Analyser) solves this by having the switch itself copy traffic from one or more source ports or VLANs and deliver those copies to a designated destination port where the analyser is connected. The original traffic flow is unaffected.

Note
SPAN copies traffic — it does not intercept or delay it. The source port continues to forward normally. The destination port becomes a dedicated receive-only mirror port and cannot simultaneously carry normal network traffic.

SPAN Variants Compared Link to heading

Feature Local SPAN RSPAN ERSPAN
Source and destination Same switch Different switches, same L2 domain Any location reachable via IP
Transport Internal switch fabric Dedicated RSPAN VLAN (802.1Q) GRE tunnel over IP
Layer L2 L2 L3 (IP encapsulated)
Analyser location Must be on same switch Any switch in the L2 domain Any host reachable by IP
Scalability Limited to one switch Limited to L2 broadcast domain Network-wide, including WAN/cloud
Platform support All managed switches Most Catalyst switches Catalyst 9000, ASR, ISR, Nexus
Encapsulation overhead None None (native VLAN) GRE header added to each packet

Local SPAN Link to heading

Local SPAN mirrors traffic between ports on the same switch. The source can be one or more physical ports, a port channel, or an entire VLAN. The destination is a single physical port connected to the analyser.

SPAN Source and Destination Options Link to heading

Source types:

  • Interface: Mirror traffic on a specific physical port or EtherChannel
  • VLAN: Mirror all traffic on all ports assigned to a VLAN (ingress only for VLAN source)

Traffic direction:

  • rx (ingress): Mirror traffic received on the source port
  • tx (egress): Mirror traffic transmitted from the source port
  • both: Mirror traffic in both directions (default)

Destination constraints:

  • Must be a physical port on the same switch
  • Becomes dedicated to mirroring — loses all normal switching functions
  • Does not participate in STP, CDP, VTP, or any control-plane protocols while configured as SPAN destination
  • Cannot be a source port in the same or different SPAN session

Local SPAN Configuration Link to heading 

! Mirror both directions on Gi0/1 to analyser on Gi0/10
monitor session 1 source interface GigabitEthernet0/1 both
monitor session 1 destination interface GigabitEthernet0/10

! Mirror ingress traffic only on multiple ports
monitor session 2 source interface GigabitEthernet0/2 - 4 rx

! Mirror an entire VLAN (ingress only)
monitor session 3 source vlan 100 rx
monitor session 3 destination interface GigabitEthernet0/10
Tip
When mirroring a high-throughput port (e.g., a 10G uplink) to a 1G destination port, the destination port will drop mirrored packets when the source traffic rate exceeds 1G. SPAN does not buffer — it drops mirror copies silently. Size your destination port capacity to match the expected peak traffic rate on the source.

Remote SPAN (RSPAN) Link to heading

RSPAN extends traffic mirroring across multiple switches in the same Layer 2 domain. Mirrored traffic is tagged with a dedicated RSPAN VLAN and carried across trunk links to a remote switch where the analyser is connected.

The RSPAN VLAN is a special VLAN reserved exclusively for carrying mirrored traffic — it must be created with the remote-span keyword on every switch in the path, and it must be allowed on all trunk links between source and destination switches.

Warning
The RSPAN VLAN carries raw mirrored frames with no MAC learning or STP topology changes occurring on it. Do not assign any access ports to the RSPAN VLAN — it must remain a transport-only VLAN to prevent mirrored traffic from being forwarded as normal data.

RSPAN Configuration Link to heading

Step 1 — Create the RSPAN VLAN on all switches in the path:

vlan 999
 name RSPAN-VLAN
 remote-span

Step 2 — Configure the source switch:

! Source switch: mirror Gi0/1 into RSPAN VLAN 999
monitor session 1 source interface GigabitEthernet0/1 both
monitor session 1 destination remote vlan 999

Step 3 — Configure the destination switch:

! Destination switch: receive from RSPAN VLAN 999, deliver to local analyser port
monitor session 1 source remote vlan 999
monitor session 1 destination interface GigabitEthernet0/10

Step 4 — Ensure VLAN 999 is allowed on all trunk links between switches:

interface GigabitEthernet0/24
 switchport mode trunk
 switchport trunk allowed vlan add 999

Encapsulated Remote SPAN (ERSPAN) Link to heading

ERSPAN encapsulates mirrored traffic in GRE and forwards it as IP packets, allowing the analyser to be located anywhere reachable by IP — including across routed boundaries, WAN links, or in a data centre or cloud environment.

ERSPAN has two types:

  • Type I: Original frame encapsulated directly in GRE (no ERSPAN header)
  • Type II: GRE + ERSPAN header (includes session ID, VLAN, direction, index) — most common
  • Type III: Adds timestamps and enhanced telemetry fields

ERSPAN Configuration Link to heading 

! Source switch (Catalyst 9000 / IOS XE)
monitor session 1 type erspan-source
 source interface GigabitEthernet0/1 both
 destination
  erspan-id 1
  ip address 10.20.30.40        ! IP of the remote analyser/collector
  origin ip address 10.1.1.1   ! Source IP of the ERSPAN GRE tunnel
  ip ttl 64
  ip dscp 46
 no shutdown

On the receiving end (if using a Cisco device as ERSPAN termination):

! Destination switch (ERSPAN termination)
monitor session 1 type erspan-destination
 destination interface GigabitEthernet0/10
 source
  erspan-id 1
  ip address 10.20.30.40
 no shutdown
Note
Most network analysers (Wireshark, Security Onion, commercial tools) can receive ERSPAN encapsulated traffic directly and decapsulate it natively — a dedicated Cisco ERSPAN termination switch is not always required. The analyser host simply needs an IP route to receive the GRE packets from the source switch.

Operational Constraints and Best Practices Link to heading

Session limits: Most Catalyst switches support a maximum of 2–4 concurrent SPAN sessions. Check platform specifications — adding more sessions than the switch supports is silently rejected or causes unpredictable behaviour.

Destination port exclusivity: A SPAN destination port cannot carry any other traffic. Remove it from all VLANs before configuring it as a destination. Any traffic the analyser sends out the port (e.g., management traffic) is discarded by the switch.

Ingress traffic on destination port: By default, the destination port receives mirrored traffic only and drops any traffic sent into it by the analyser. To allow the analyser to send traffic out the same port (for active response or management), enable ingress:

monitor session 1 destination interface GigabitEthernet0/10 ingress vlan 10

VLAN filtering: When mirroring a trunk port, you can limit which VLANs are mirrored to reduce the volume of traffic sent to the destination:

monitor session 1 source interface GigabitEthernet0/24 both
monitor session 1 filter vlan 10, 20, 30
monitor session 1 destination interface GigabitEthernet0/10
Tip
Always use VLAN filtering when mirroring a trunk uplink that carries many VLANs. Mirroring all traffic on a 10G uplink to a 1G destination port will saturate the destination and result in massive packet loss on the mirrored copy — making the capture useless for analysis.

Verification Link to heading 

show monitor session 1
show monitor session 1 detail
show monitor

show monitor session 1 shows the session type, source interfaces/VLANs, destination, and operational status. An Oper Status: Up line confirms the session is active. If the session shows Down, check that the destination port is physically connected and not configured with any conflicting settings (access VLAN, STP, etc.).