Configuring Port Mirroring (SPAN) on Cisco Catalyst Switches

So you have a network issue.  Or perhaps you don't, but you need to help find the root cause of a performance issue and conclusively show that it's not network related.  In either case, packet analysis is your friend.

At times, it can be convenient (and effective) to capture directly on an affected server or host.  However, you may not always be able to access the affected device.  Even you can, capturing from the affected device is not always the best option due to TCP segmentation offload, checksum offload, and a number of other factors.  (These are outside of the scope of this post, but Kary over at packetbomb.com has a ton of great content on packet analysis including why you shouldn't capture on a host.  See here.)

A network tap is the best solution when absolute precision is required.  However, this can be impractical and is often overkill.  This is where port mirroring comes into play.  Cisco gear provides a number of ways to mirror traffic from a specified source (or sources) and get frames from point A to point B for analysis. 

SPAN

SPAN (switched port analyzer) is Cisco's implementation of port mirroring.  It is used to mirror traffic from a switch to a destination interface on the same switch.  However, SPAN allows us to do much more than just mirror a single port.

Basic SPAN configuration is as follows:

monitor session SESSION-NUMBER source INTERFACE(S)|VLAN(S)|CPU {TX|RX|BOTH}
monitor session SESSION-NUMBER destination interface INTERFACE [ENCAPSULATION/INGRESS]

• Start a "monitor session" to mirror data from a specified source.  
• Specify a session number.  This is locally significant.
• Define a source.  On most platforms, this can be a single interface, multiple interfaces, port-channel, port-channel member interface, source VLAN, or multiple source VLANs.  
• On higher end platforms you can also select the CPU as the SPAN source.  This can be extremely useful for troubleshooting high CPU issues.
• Specify whether or not you want to mirror ingress traffic, egress traffic, or both.
• Start a "monitor session" to mirror data to the destination.  
• Specify the session number that corresponds to the source session.
• Define a destination interface.
• Optionally, select encapsulation or ingress options.
• Encapsulation options are dot1q, isl, or replicate (platform dependent).
• Generally you would choose "replicate" to replicate the encapsulation of the source interface if you need to see tagged traffic or L2 control traffic such as CDP, STP BPDUs, VTP, DTP, etc.
• Ingress options are dot1q, isl, untagged, or vlan (platform dependent).
• Generally you would use "vlan" to place untagged ingress traffic from your monitor destination into the specified VLAN.
• This allows monitor devices connected to the switch with a single NIC to send and receive traffic through the monitor destination port while receiving monitor destination traffic.

Here are a few examples:

Mirror f0/1 ingress and egress traffic to f0/2 (basic port mirroring).

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

Mirror vlan 10 ingress and egress traffic to f0/1 and f0/2.

SW1(config)#monitor session 1 source vlan 10 both
SW1(config)#monitor session 1 destination interface f0/1
SW1(config)#monitor session 1 destination interface f0/2

Mirror port-channel 1 egress traffic to f0/3 preserving encapsulation of mirrored traffic.

SW1(config)#monitor session 1 source interface port-channel 1 tx
SW1(config)#monitor session 1 destination interface f0/3 encapsulation replicate

Mirror f0/1 ingress and egress traffic as well as f0/2 ingress traffic to f0/3.  Preserve encapsulation of mirrored traffic.  Allow untagged ingress traffic from the destination port and place it in VLAN 8.

SW1(config)#monitor session 1 source interface f0/1 both
SW1(config)#monitor session 1 source interface f0/2 rx
SW1(config)#monitor session 1 destination interface f0/3 encapsulation replicate ingress untagged vlan 8

Verification:

SW1#show monitor session 1
Session 1
---------
Type                   : Local Session
Source Ports           : 
    RX Only            : Fa0/2
    Both               : Fa0/1
Destination Ports      : Fa0/3
    Encapsulation      : Replicate
          Ingress      : Enabled, default VLAN = 8
    Ingress encap : Untagged


SW1#

There are a number of caveats and restrictions listed in the Cisco documentation.  However, here are a few that are notable:

1. You can't mix a source port and a source VLAN.
2. SPAN config temporarily overrides all config on a port.  When the monitor session is removed, the original config becomes active again.
3. Be careful not to overload your destination port.  You could do this very easily mirroring an entire VLAN to a destination port.
4. Ingress SPAN traffic (RX) shows all frames as they are received, prior to undergoing any changes by VACLs, QoS, etc.
5. Egress SPAN traffic (TX) shows all frames as they are sent after undergoing all changes by VACLs, QoS, etc.

It is also important to note the ingress parameter does NOT work on a number of platforms (Catalyst 2940, 2950, 2955, 2970, 3550 and 3750).  The switch will accept the config but reject the ingress traffic.  This is not properly documented in a number of Cisco references.

This document states ingress traffic on a monitor destination can be configured on these platforms:
https://supportforums.cisco.com/document/13891/how-configure-port-monitoring-span-catalyst-2940-2950-2955-2970-3550-or-3750-series

This document clarifies the behavior and states ingress traffic on a monitor destination will not work on these platforms:
https://supportforums.cisco.com/document/19196/limitations-span-and-rspan-cisco-catalyst-2950-3550-3560-and-3750-swtiches

So that's the basics of SPAN on Cisco Catalyst switches.  As always, it is best to reference platform specific documentation for your particular use case.  However, what if your use case involves mirroring traffic to an interface on a switch other than the switch you are capturing on?  That's where RSPAN (remote SPAN) and ERSPAN (encapsulated remote SPAN) come into play.  I will be covering these in another blog post.

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