Configuring RSPAN on Cisco Catalyst Switches

I recently wrote a post on configuring port mirroring (SPAN) on Cisco Catalyst switches.  SPAN (switched port analyzer) allows you to mirror traffic from a source or multiple sources on a switch to a destination interface or interfaces on the same switch.  RSPAN (remote SPAN) takes this a step further and allows you to mirror traffic to an interface on a remote switch or switches.

RSPAN

RSPAN configuration is relatively simple and builds upon existing SPAN functionality and configuration syntax.

• Create an RSPAN VLAN on the source switch, destination switch, and all switches in the transit path.
• Take traffic from a specified source on switch A, and mirror it to an RSPAN VLAN.  
• Then, on switch B, use traffic from this VLAN as the source and mirror it to a physical interface

As shown below, traffic mirrored from the switch on the right to the switch on the left can traverse other switches as long as there is end to end L2 connectivity between them (ie. the RSPAN VLAN exists on all switches).

Basic RSPAN configuration is as follows:

! All switches
vlan X                                
 remote-span 

! Source switch
monitor session SESSION-NUMBER source INTERFACE(S)|VLAN(S)|CPU {TX|RX|BOTH}
monitor session SESSION-NUMBER destination remote vlan RSPAN-VLAN

! Destination switch
monitor session SESSION-NUMBER source remote vlan RSPAN-VLAN
monitor session SESSION-NUMBER destination interface INTERFACE

Using the above configuration syntax, you can configure multiple source sessions and multiple destination sessions for the same RSPAN VLAN.  Put another way, you can put traffic into the RSPAN VLAN from anywhere in your L2 domain, and then pull all of this traffic out of the RSPAN VLAN from anywhere else in the L2 domain except the switch that sourced the traffic.  However, keeping RSPAN sessions separate requires separate RSPAN VLANs.

Keep in mind just because you can do something doesn't mean you should.  In most use cases it is probably best to limit an RSPAN session to a a single source and destination for a specific troubleshooting purpose, so you're not sending large volumes of mirrored data across uplinks between switches.  It is also important to note that RSPAN mirrored traffic is inherently less accurate than SPAN or a network tap, and for network traffic that requires precise timing, RSPAN may not be accurate enough.  For more info on potential downsides of RSPAN, check out this blog post.

Here is a basic RSPAN config to mirror data from f0/1 on SW1 to f0/1 on SW3.  This assumes the switches are already trunked from SW1->SW2->SW3.

Create RSPAN VLAN 1000.  Mirror ingress and egress traffic from f0/1 to VLAN 1000.

SW1(config-vlan)#vlan 1000   
SW1(config-vlan)#remote-span
SW1(config)#monitor session 1 source interface f0/1 both
SW1(config)#monitor session 1 destination remote vlan 1000

Create RSPAN VLAN 1000.

SW2(config-vlan)#vlan 1000   
SW2(config-vlan)#remote-span

Create RSPAN VLAN 1000.  Mirror traffic from VLAN 1000 to f0/1.

SW3(config-vlan)#vlan 1000   
SW3(config-vlan)#remote-span
SW3(config)#monitor session 1 source remote vlan 1000
SW3(config)#monitor session 1 destination interface f0/1

SW1 verification:

SW1#show monitor session 1
Session 1
---------
Type                   : Remote Source Session
Source Ports           : 
    Both               : Fa0/1
Dest RSPAN VLAN        : 1000


SW1#

SW3 verification:

SW3#show monitor session 1
Session 1
---------
Type                   : Remote Destination Session
Source RSPAN VLAN      : 1000
Destination Ports      : Fa0/1
    Encapsulation      : Native
          Ingress      : Disabled


SW3#

That's it!  We just mirrored all traffic from interface f0/1 on SW1 through SW2 and out interface f0/1 on SW3.  As always, there may be platform specific limitations and caveats so be sure to reference documentation for your specific use case.  For example, on the 3560G used for testing, I was not able to use the "encapsulation replicate" monitor destination parameter on the source switch, so all traffic was sent untagged, even though the source port was a dot1q trunk.  In another blog post I will be covering ERSPAN (encapsulated remote SPAN) to send mirrored traffic across a routed link.


CCIE R&S v5.0/5.1 exam topic: 2.1.g [i] SPAN, RSPAN, ERSPAN