Troubleshoot Your Network With Cisco SPAN Ports

By Charlie Schluting | Aug 20, 2008 | Print this Page

Charlie SchlutingThe Cisco Switch Port Analyzer, or SPAN, enables advanced network troubleshooting and the implementation of robust monitoring solutions. Port mirroring, as it's also called, is required to deploy in-depth network monitoring. A SPAN port can be configured many ways, and it's tricky to get right. Let us show you how.

SPAN ports are configured to allow a network monitoring device to "see" all traffic. Ethernet switches don't send traffic to ports unless the traffic needs to go there, so monitoring network traffic on all ports at once is impossible without SPAN. SPAN ports aren't used to place special man-in-the-middle services between your network and the Internet. SPAN ports are one-way only. The port that is receiving copies of all network traffic can indeed send its own data back out if the SPAN port is configured properly, but it does not allow the monitoring device to interrupt the normal traffic flow.

SPAN is safe, but you may have heard otherwise from a disgruntled engineer who accidentally took down a network the first time he tried using it. After getting the terminology out of the way, we'll show you how to configure a SPAN port and then explain why things often go wrong.


The port that receives the copy of all traffic, also referred to as the destination port when configuring SPAN.
Remote SPAN, which enables you to copy traffic to a special VLAN, which houses one or more network analyzers connected to a different physical switch
Reflector Port
A port that copies RSPAN packets onto the RSPAN VLAN.
Ingress Traffic
Traffic that is entering a switch; egress traffic is leaving.


The following example will demonstrate how to configure a single SPAN session on a Cisco Catalyst switch. The specifics are different between different switch models, so be sure to check the Cisco documentation.

You must first configure source ports. Source ports are ports whose data will be copied, and sent to the destination, or SPAN port.

 monitor session 1 source interface Gi1/0/1 - 28 rx

The above command will create a new SPAN session called "1" and configure ports 1-28 on the first switch in the stack as a source port. The training "rx" means that ingress traffic is what's replicated.

Ports can also be skipped, and you can add additional ports with another "source" command:

 monitor session 1 source interface Gi3/0/1 - 4 rx

Now that we've defined a few sources, we must now define where the traffic should be sent.

 monitor session 1 destination interface Gi2/0/22

Defining an interface as the destination port, we have now just enabled this SPAN session. A server attached to Gi2/0/22 will now see all ingress traffic on the ports specified. Sources can be quite diverse, including RSPAN VLANs, which would be defined as: monitor session 1 source vlan 555

The mixing of SPAN and RSPAN ports may or may not be supported on your device. In fact, RSPAN isn't supported on all devices, so check the documentation to verify support for your particular equipment.


Configuring SPAN ports frequently results in losing connectivity with the connected monitoring device. Special attention needs to be paid to the ingress and egress concepts, and that the ports are configured properly. To receive ingress traffic on a destination port (so you can communicate with the attached device), configure the session thusly:

 monitor session 1 destination interface Gi2/0/22 encapsulation replicate

The command "encapsulation ingress vlan" can also be used to specify which vlan ingress traffic will be allowed on. Setting "encapsulation replicate," however will allow the connected host to receive ingress traffic on all VLANs. This is useful if the attached device supports 802.1q and wishes to have multiple interfaces in multiple VLANs.

The best practice, however, is to only use the SPAN port to receive data. This means that your monitoring device should have two network connections: one to receive SPAN traffic, the other configured to act as your management interface. Spanning tree is disabled (always forwarding) on SPAN ports, so be cautious if configuring ingress traffic support.

Capacity planning is important as well. If we wish to configure an RSPAN VLAN, special care is needed to ensure that VLAN doesn't escape onto unwitting switches. Your RSPAN VLAN should only extend as far as necessary between devices so that it can reach the destination monitoring port. Depending on the amount of traffic you normally see, it's likely that the RSPAN VLAN will also need dedicated gigabit links to support the traffic.

SPAN ports do not run spanning tree, so loops are very easy to create. You may think that setting a destination port to a trunk port is a good idea, after all, you can just create another SPAN session on the other switch that's connected via the trunk. Unfortunately, this is the most common way people create a bridging loop with SPAN sessions. Data gets re-injected back into the trunk when you do this, because there's no spanning tree to block this type of loop. The proper solution is to use RSPAN, if this is the desired architecture.

Finally, the big question, is whether or not SPAN sessions will slow down normal traffic on your network. Luckily, the answer is, "no." Because of the architecture of switches, copying a packet to one port is just as fast as copying it to two. Of course, you can easily run into performance problems with RSPAN if the session starts to saturate a link, but a standard single-device SPAN session does not impact performance.

SPAN ports are invaluable tools. You can create a quick SPAN or RSPAN session to troubleshoot network problems between two devices. If connected hosts don't have the ability to run tcpdump, some times the only way to solve a problem is to mirror a port and decipher the traffic.

When he's not writing for Enterprise Networking Planet or riding his motorcycle, Charlie Schluting is the Associate Director of Computing Infrastructure at Portland State University. Charlie also operates, and recently finished Network Ninja, a must-read for every network engineer.