SPAN, RSPAN, and ERSPAN: Packet Mirroring Explained

Eventually every network problem reaches the point where you have to see the actual packets. Counters lie by omission, logs tell you what the device thought, and NetFlow tells you a conversation happened without telling you what was in it. Port mirroring is how you get the packets themselves onto a machine running Wireshark.

SPAN, RSPAN, and ERSPAN are three answers to the same question, separated by how far the analyzer sits from the traffic. This article configures all three on real Cisco gear and captures the ERSPAN packets arriving at a real Linux host. It extends the IP Services cluster guide.

The Three, in One Sentence Each

SPAN (local)

Copy traffic to another port on the same switch. Analyzer must be plugged into that switch.

TransportNone. Raw copy.

RSPAN

Copy traffic into a special VLAN that is trunked to another switch, where the analyzer sits.

TransportLayer 2 (a VLAN)

ERSPAN

Wrap the copies in GRE and route them anywhere in the IP network. Analyzer can be in another building.

TransportLayer 3 (GRE/IP)

The progression is purely about distance. Local SPAN needs the analyzer on the same box. RSPAN gets it onto a different switch in the same layer 2 domain. ERSPAN gets it anywhere you can route a packet, which in practice means a central capture server for the whole estate.

Local SPAN

Two lines. A source (what to copy) and a destination (where to put the copies):

SW1(config)# monitor session 1 source interface Ethernet0/1 both
SW1(config)# monitor session 1 destination interface Ethernet0/2

SW1#show monitor session 1
Session 1
---------
Type                     : Local Session
Source Ports             :
    Both                 : Et0/1
Destination Ports        : Et0/2
    Encapsulation        : Native

The both keyword captures ingress and egress. You can also say rx or tx, and you should when you can, because capturing both directions on a busy port means the destination port has to carry the sum of both, and it will drop what it cannot fit.

The three rules that bite people

The destination port stops being a normal port. It leaves the switching fabric: it will not forward, will not learn MACs, and drops anything the analyzer transmits into it. If you were using it for something, you are not anymore.
Oversubscription is silent. Mirroring two gigabit ports (both directions) into one gigabit destination means up to 4 Gbps into a 1 Gbps hole. The switch drops the excess without telling you, and your capture has holes in exactly the busy moments you care about.
Session limits are low. Most Catalyst platforms allow only two local SPAN sessions. This is a hardware constraint, not a licensing one.

You can also mirror an entire VLAN (source vlan 10) rather than a port, which is often what you actually want, and mirror a port-channel by naming the port-channel interface.

RSPAN: Across the Layer 2 Domain

RSPAN carries the mirrored traffic in a dedicated VLAN. That VLAN must be flagged as an RSPAN VLAN, which stops the switch from doing normal things to it (learning, flooding to unrelated ports):

SW1(config)# vlan 999
SW1(config-vlan)#  name RSPAN-VLAN
SW1(config-vlan)#  remote-span
!
SW1(config)# monitor session 3 source interface Ethernet0/1 rx
SW1(config)# monitor session 3 destination remote vlan 999

SW1#show monitor session 3
Session 3
---------
Type                     : Remote Source Session
Source Ports             :
    RX Only              : Et0/1
Dest RSPAN VLAN          : 999

SW1#show vlan remote-span

Remote SPAN VLANs
------------------------------------------------------------------------------
999

On the far switch, the mirror image: a session whose source is the RSPAN VLAN and whose destination is the analyzer's port.

SW2(config)# monitor session 3 source remote vlan 999
SW2(config)# monitor session 3 destination interface Ethernet0/5

The requirements are strict and unforgiving:

The RSPAN VLAN must exist on every switch in the path, and be marked remote-span on each.
It must be allowed on every trunk between them. VTP pruning will happily prune it and break your capture.
It carries a copy of everything you mirrored, so it eats real bandwidth on those trunks. Mirroring a busy port across a congested trunk is a way to cause an outage while investigating one.

RSPAN is the awkward middle child: more reach than SPAN, far more fragile than ERSPAN, and confined to one layer 2 domain either way. If you have a routed network, skip to ERSPAN.

ERSPAN: Mirror Anywhere

ERSPAN wraps each mirrored frame in GRE and sends it as a routed IP packet. The analyzer can be anywhere you can reach.

A platform note first, honestly. The IOL-XE and IOL-L2 images used elsewhere in these labs do not support ERSPAN. Both reject the command outright:

R1(config)# monitor session 10 type erspan-source
                              ^
% Invalid input detected at '^' marker.

So the ERSPAN work below runs on a Catalyst 8000v (IOS XE 17.18.02), which does support it. If you are labbing this and the command is rejected, it is your platform, not your syntax.

The source session:

R3(config)# monitor session 1 type erspan-source
R3(config-mon-erspan-src)#  source interface GigabitEthernet1 both
R3(config-mon-erspan-src)#  no shutdown
R3(config-mon-erspan-src)#  destination
R3(config-mon-erspan-src-dst)#   erspan-id 100
R3(config-mon-erspan-src-dst)#   ip address 192.168.99.100
R3(config-mon-erspan-src-dst)#   origin ip address 192.168.99.3

Note no shutdown. ERSPAN sessions are created administratively down. Forgetting this line produces a session that looks perfectly configured and sends nothing, which is a genuinely infuriating twenty minutes.

R3#show monitor session 1
Session 1
---------
Type                     : ERSPAN Source Session
Status                   : Admin Enabled
Source Ports             :
    Both                 : Gi1
Destination IP Address   : 192.168.99.100
MTU                      : 1464
Destination ERSPAN ID    : 100
Origin IP Address        : 192.168.99.3

Three fields matter:

erspan-id 100Identifies this stream. Lets one collector receive mirrors from many sources and tell them apart. Must match on the destination session.

ip addressWhere the GRE packets go. Must be routable from the source.

MTU 1464The GRE + ERSPAN headers eat the difference. Mirrored frames larger than this get truncated or dropped.

That MTU line is the single biggest operational gotcha in ERSPAN. A full-size 1500-byte frame plus GRE and ERSPAN headers exceeds 1500 on the transit path, so unless the path supports jumbo frames, your captures of large packets will be truncated. If you are hunting an MTU problem with ERSPAN, be very careful about what you conclude.

The platform confirms the encapsulation it will use:

R3#show platform hardware qfp active feature erspan state
ERSPAN State:
  Status    : Active
Capabilites:
  Max sessions : 1032
  Encaps type  : ERSPAN type-II / ERSPAN type-III
  GRE protocol : 0x88BE         / 0x22EB
  MTU          : 1464           / 1452

GRE protocol type 0x88BE is ERSPAN Type II, 0x22EB is Type III. Type III adds finer-grained timestamps; Type II is the default and what nearly everything uses.

Proof: the mirror arriving at a real host

Configuration is a claim. Here is the evidence. The analyzer is a Debian box at 192.168.99.100, and while it is being pinged (so there is traffic to mirror), it runs tcpdump filtering for GRE:

j@llmbits:~$ sudo tcpdump -i ens224 -n 'proto gre' -v
listening on ens224, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:08:16.890159 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto GRE (47), length 134)
    192.168.99.3 > 192.168.99.100: GREv0, Flags [sequence# present], seq 7, length 114
	gre-proto-0x88be
18:08:16.890372 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto GRE (47), length 134)
    192.168.99.3 > 192.168.99.100: GREv0, Flags [sequence# present], seq 8, length 114
	gre-proto-0x88be
18:08:16.890900 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto GRE (47), length 212)
    192.168.99.3 > 192.168.99.100: GREv0, Flags [sequence# present], seq 9, length 192
	gre-proto-0x88be
4 packets captured

That is ERSPAN working, end to end, on a real wire. The router at 192.168.99.3 is encapsulating every mirrored frame in GRE with protocol type 0x88be and shipping it to the analyzer. The sequence numbers let the receiver detect dropped mirror packets, which is genuinely useful: if your capture has gaps, the sequence gaps tell you the mirror dropped them rather than the network.

Wireshark decodes ERSPAN natively. Point it at this interface, and it will strip the GRE and ERSPAN headers and show you the original mirrored frames as if you had captured them on the source port.

Choosing Between Them

Laptop is in the rackLocal SPAN. Two commands, zero complications.

Analyzer on another switch, flat L2RSPAN. Watch your trunks and VTP pruning.

Central capture server / IDS farmERSPAN. The only one that crosses a routed boundary. Mind the MTU.

You need volume, not packetsNot SPAN at all. Use NetFlow. Mirroring a 10G link to answer "who is using bandwidth" is absurd.

FAQ

Why is my SPAN destination port not passing normal traffic?

Because that is the design. A SPAN destination leaves the switching fabric entirely. It only spits out copies. This is not a fault.

My capture has gaps under load. Why?

Oversubscription. You are mirroring more traffic than the destination port can carry, and the switch drops the excess silently. Mirror one direction, filter to a VLAN, or use a faster destination port.

Can I mirror to a port on a different switch without RSPAN?

No, not with local SPAN. That is precisely what RSPAN and ERSPAN exist to solve.

Does ERSPAN encrypt the mirrored traffic?

No. GRE is encapsulation, not encryption. You are shipping copies of production traffic, in clear text, across your network. Treat the ERSPAN path as sensitive and consider whether it should ride a dedicated VRF or an IPsec tunnel. See the GRE cluster guide.

How many sessions can I run?

Platform-dependent and usually small for local SPAN (often two). ERSPAN on a Catalyst 8000v advertises up to 1032 sessions, as the platform output above shows. Check your specific hardware.

Key Takeaways

SPAN, RSPAN, ERSPAN differ only in how far the analyzer can be: same switch, same layer 2 domain, anywhere routable.
A SPAN destination port is removed from the switching fabric. It forwards nothing and learns nothing.
Oversubscribing a destination port drops mirrored packets silently. Your capture will have holes exactly when the network is busy.
RSPAN needs its VLAN marked remote-span and allowed on every trunk in the path. VTP pruning will break it.
ERSPAN sessions are created shut. no shutdown or nothing leaves the box.
ERSPAN's GRE overhead cuts the usable MTU to 1464. Large mirrored frames get truncated.
Neither IOL-XE nor IOL-L2 supports ERSPAN. Use a Catalyst 8000v, a Catalyst 9000, or real hardware.
ERSPAN is not encrypted. You are routing copies of production traffic in the clear.

Next: conditional debugging for when you need the router's view rather than the packets, or the IP Services cluster guide.

SPAN, RSPAN, and ERSPAN: Packet Mirroring on Cisco Switches