Spans and RSpans

Spans are a pretty common theme in networking these days.  There are all kinds of devices that want to see what’s happening on the network.  The configuration of spans is pretty straight forward, RSPANs are a little less common but are still rather prevalent.  Let’s dive right in…

Spans
Normal span sessions are very, very, very straight forward.  Spans allow you to copy the traffic from one switch port and spit it out another on the same physical switch.  Let’s take a look at how to configure a basic span session. 

Switch(config)#monitor session 1 source ?
  interface  SPAN source interface
  remote     SPAN source Remote
  vlan       SPAN source VLAN

Switch(config)#monitor session 1 source

The first real option we have is whether we are monitoring a VLAN or a physical switch port.  A single span sessions can contain multiple sources but you can not mix VLANs and interfaces in the same session.  More to come on the ‘remote’ option when we talk about RSPAN. 

Switch#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#monitor session 1 source interface gigabitEthernet1/0/1 ?
  ,     Specify another range of interfaces
  –     Specify a range of interfaces
  both  Monitor received and transmitted traffic
  rx    Monitor received traffic only
  tx    Monitor transmitted traffic only
  <cr>
Switch(config)#

So let’s say that I want to span the traffic from gig interface 1/0/1 to 1/0/24.  The span configuration consists of two commands.  The monitor session source command and the monitor session destination command.  As you can see above, we started the configuration for the source.  The first part of the command is straight forward, but then we have some options which I showed with the question mark.  We can specify the direction of the traffic we want to see as well as additional ports or port ranges that we want as the source.  If you just hit enter, it will default to both.  Let’s do that…

Switch(config)#$sion 1 destination interface gigabitEthernet 1/0/24 ?
  ,              Specify another range of interfaces
  –              Specify a range of interfaces
  encapsulation  Set encapsulation for destination interface
  ingress        Enable ingress traffic forwarding
  <cr>

Switch(config)#$sion 1 destination interface gigabitEthernet 1/0/24

Now configuring the destination side of things is similar.  The beginning output got cut off in my example but it starts with ‘monitor session 1’.  As you can see, we also have some options for the destination.   Here we can also specify a set or range of interfaces.  It is important to note here that there are some rules about the types of interfaces that can be used as source and destinations.  A span source can consist of local access ports, routed interfaces, an port-channel, a trunk, or an entire VLAN.  The destination can only consist of a single switch port.  It can NOT be a port-channel or a VLAN.

So that’s all the configuration you need to configure a basic monitor session.  If we plug WireShark into interface gig1/0/24 we’ll see the output from the computer on gig1/0/1…

You’ll also notice that interface gig 1/0/24 has a different state than normal…

Switch#show int gig1/0/24
GigabitEthernet1/0/24 is up, line protocol is down (monitoring)
  Hardware is Gigabit Ethernet, address is 0021.d7c5.f218 (bia 0021.d7c5.f218)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

The interface shows as up/down but it does tell you that the interface is in monitoring mode.  So let’s talk about some of the more advanced options for local span. 

The difference between RX and TX
While this might seem obvious to you, there is really a little more to it than you might expect.  For instance, let’s change out span configuration slightly.  I’m going to create a vlan (20) and assign the interface gig 1/0/1 to it.  I’m also going to create the following configuration…

interface Vlan20
ip address 192.168.0.1 255.255.255.0
ip access-group workstation in
!
ip access-list extended workstation
deny  ip host 192.168.0.50 host 192.168.0.1
permit ip any any

Now, let’s change out monitor session to monitor VLAN 20…

monitor session 1 source vlan 20 rx
monitor session 1 destination interface Gi1/0/24

So let’s start a ping on the workstation to it’s default gateway of 192.168.0.1 and then take a look at the span destination in WireShark…

So as we expected, we are seeing the receive traffic for VLAN 20.  Now, lets change the span source from RX to TX…

Nothing.  Now, let’s take the ACL off the VLAN 20 SVI…

There’s the receive traffic we expected to see.  The difference is probably obvious at this point.  RX copies the traffic as it’s received into the interface before any modification.  TX copies the traffic after things like ACLs, QoS, and other settings are applied. 

Encapsulation
As we saw in the initial configuration, there are some encapsulation options you can use on the monitor destination.  The most common option is the ‘encapsulation replicate’ command.  For instance, take a look at this span configuration…

monitor session 1 source interface Gi1/0/1
monitor session 1 destination interface Gi1/0/24

Interface Gig1/0/1 is a trunk passing traffic to switch 2 on VLAN 20.  Let’s take a look at the capture from Gig1/0/24…

Looks pretty normal, but did you notice that it’s missing a dot1q tag?  Let’s modify the span destination to this…

monitor session 1 destination interface Gi1/0/24 encapsulation replicate

Now if we take a look at the capture, we see the dot1q tag…

I’ve seen some documentation that states that you need to have the destination port configured as a trunk in order to see the dot1q tags, this hasn’t (yet) appeared to be true.  That might be the case for certain platforms so keep that in mind if you are having issues seeing the proper tags.

Another interesting option that exists is the ‘ingress’ option.  I’ve never quite understood why this would be used but I’ll give you an example of how it can be used.  Say for some odd reason that you really need to be able to use your laptop for normal business purposes while also listening to span destination port with wireshark.  Technically, you could configure something like this…

monitor session 1 source interface Gi1/0/1
monitor session 1 destination interface Gi1/0/24 encapsulation replicate        ingress dot1q vlan 10

The interesting part of this is the ‘ingress dot1q vlan 10’.  This tells the switch port to accept incoming frames on the monitor destination switch port.  Not only should it accept these frames, but it should put them onto VLAN 10.  This sounds kind of slick, but there’s a catch.  Span destination ports don’t participate in spanning-tree nor do they participate in MAC learning.  So even if we can pass traffic in, the switch will never learn out source to forward frames back to us.  This can be solved by creating a static MAC entry…

mac address-table static 0008.0291.7e0a vlan 10 interface GigabitEthernet1/0/24

Once we do that, we can start using the port like a normal access port.  For instance, there is a DHCP scope on VLAN 10 so I can get an IP address and communicate on the LAN from the same port that I’m capturing from.  I can see where this might be handy, but I’m not a huge fan of adding static MAC entries for workstations.

RSPANs
The concept of RSPAN is pretty straight forward.  You are basically dumping the traffic you intend to capture/monitor into another VLAN.  That VLAN can then be trunked to other switches.  On a remote switch you can then define another monitor session setting the VLAN you dumped the traffic into as the source, and the destination as a local port. 

Here’s a basic example…

So the data we want to span is on switch 1, VLAN 10, interface fa1/0/12.  Let’s configure that switch first…

Switch1#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch1(config)#monitor session 1 source interface Fa1/0/12
Switch(config)#monitor session 1 destination remote vlan 75
Switch(config-vlan)#vlan 75
Switch(config-vlan)#remote-span
Switch1(config)#end
Switch1#

So here we are spanning int fa1/0/1 (in both directions) to VLAN 75.  We also had to initially configure the VLAN and tell the switch that it was to be used for the remote-vlan purpose.  Next’ we configure switch 2…

Switch2#config t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch2(config)#vlan 75
Switch2(config-vlan)#remote-span
Switch2(config-vlan)#end
Switch2#

Since switch 2 is just a transit switch, we just need to define the VLAN and tell it what it should be used for.  I’m assuming that there aren’t any ‘switchport trunk allowed vlan’ statement on switch 2’s connections to switch 1 and 3 at this point.  Now for Switch3…

switch3#config t
Enter configuration commands, one per line.  End with CNTL/Z.
switch3(config)#monitor session 1 source remote vlan 75
switch3(config)#monitor session 1 destination interface Fa1/0/48
switch3(config)#vlan 75
switch3(config-vlan)#remote-span
switch3(config-vlan)#end
switch3#

Same deal here except this time out source is the remote span VLAN, and the destination is the physical port.   RSPANs ,in my opinion, are as straight forward as normal spans, you just need to make sure to configure the VLANs for that purpose. 

There is one catch with RSPANs  You can’t use the ‘encapsulation replicate’ command with RSPANs.  The reason is simple, the RSPAN process overwrites the tags so the original ones can’t be given at the destination port.  That being said, all traffic coming out of a RSPAN session will be untagged.