Benefits & Limitations of SPAN Ports

A mirror or SPAN (switch port analyzer) port can be a very useful resource if used in the correct way. SPAN ports are typically found on network switch gear and the feature is used to send a copy of network packets seen on one switch port (or an entire VLAN) to another switch port. A SPAN port is very much like a phone tapping device; users on the network have no idea that their conversations are being listened to.

Benefits

  • Two SPAN ports available on most managed switches
  • Gain visibility into what is happening on the LAN and WAN
  • Access to packet payloads which can be used for application decoding
  • Better data for troubleshooting (website names, latency values, file names, etc…)

Limitations

  • Groomed data (change timing, add delay)
  • Monitoring device may miss packets due to port over-subscription
  • Bad packets are dropped and will not be seen on a SPAN port

Once you understand the concept of a SPAN port, the next challenge is where to set them up. The answer to this can depend on what your requirements are. For example, if you want to do deep packet inspection on all traffic going to and from the Internet, you should only SPAN traffic going to and from your firewall and/or proxy servers. For most applications, the network core is an ideal location for a SPAN port. You just need to make sure you don’t overload the SPAN port by trying to monitor too many ports or VLANs.

I often get asked the question, “Will a SPAN port cause any problems on a network?” The most common problem I come across is when the total amount of traffic aggregated from the source ports exceeds the physical limitations of the destination port. This will result in some dropped packets on the destination port. However, this does not cause any switch performance degradation or disruption or traffic flow on the source ports. The only affected port is the destination port, and it drops packets on a first in first out (FIFO) basis once the egress buffer limit is exceeded.

SPAN port features vary among switch vendors. Because of this, the impact SPAN has on switch operation can vary. On the Cisco Catalyst 5500/5000 and 6500/6000 series switches, a packet received on a port is transmitted on the internal switching bus. Every line card in the switch starts storing this packet in its internal buffers. At the same time, the Encoded Address Recognition Logic (EARL) receives the header of the packet and computes a result index that it sends to all the line cards via the result bus. Whether one or several ports eventually transmit the packet has absolutely no influence on the switch operation. Therefore, considering this architecture, the SPAN feature has no impact on the performance.

Setting up a SPAN port is one thing, making sense of the data it provides is another. There are many free and commercial applications that use SPAN ports as a source. At the free end of things, you could use something like Wireshark. It is one of my favorite troubleshooting tools and is ideal for issues associated with a specific host or network port. It does become difficult to use when you are monitoring many ports or VLANs, as it can be easy to get overwhelmed with data. In this case, you may need to look at installing an appliance or application which will extract specific information from the data packets. Most systems which use a SPAN port will have a least 2 network cards: one for management, and one for the SPAN port. The information captured can then be used to troubleshoot application, user, and network issues.

Most switches will give you the option of creating two SPAN ports. While this may be enough for most networks, you may end up with a situation where no SPAN ports are available. In these cases, you could consider a network TAP (test access point). A passive network TAP operates by duplicating data from one port to one or more others. It operates like SPAN except it gives you the advantage of 100% visibility, no dropped packets and no delay. Another way of increasing SPAN ports is to get a dedicated switch to send the SPAN traffic to; this dedicated switch will then give you the option of creating two more SPAN ports from the single SPAN source. Just watch out for any topology changes with a configuration like this.

About Darragh Delaney

Darragh Delaney is head of technical services at NetFort. As Director of Technical Services and Customer Support, he interacts on a daily basis with NetFort customers and is responsible for the delivery of a high quality technical and customer support service.

Darragh has extensive experience in the IT industry, having previously worked for O2 and Tyco. His User and Network Forensics blog. for Computer World focuses his experiences of network management and IT security in the real world. In his current role Darragh is regularly on site with network administrators and managers and this blog is a window into the real world of keeping networks running and data assets secure.

He shares network security and management best practices on the NetFort blog. Follow Darragh on Twitter @darraghdelaney and NetFort Technologies @netfort. You can also contact him at [email protected]

  • Lucas

    Too much SPAN Ports would never be enough..

  • cryptochrome

    Nice post, thank you. I am going to show this to all people who believe a span port is a viable tool to troubleshoot packet loss.

  • Net Guy

    Good post — but high bandwidth span ports can affect the cpu. Also congested span destination ports can affect the source ports (especially on a 6500). The cisco docs reference this, and I’ve personally seen a 40Gbps span kill a 6500. I’ve also seen congested span destination slow down the source ports (which the docs refer to). The only way around that is to switch to VACL — hardware all the way.

    • http://www.facebook.com/profile.php?id=725486958 Darragh Delaney

      Thanks for your comments. Would you have links for those Cisco docs, would like to learn a bit more about this. The biggest problem I see with SPAN ports is when people try and SPAN everything. Client VLANs, server VLANs and all others. They end up with too much data and over subscribed ports.

      • net-guy

        I missed this reply. You’re right about people trying to span everything. Seen that too. The usual performance impacts come from over subscription like you mentioned or transmit/egress span (I’ve seen both). It takes a bit to get there, they have to be high bandwidth spans. Try to span ‘outbound’ high bandwidth and you’ll kill CPU. You’ll find it at the following link under “Before enabling span..”
        http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/span.html

        There is another doc I can’t find at the moment that refers to source ports slowing down when the destination is congested (since there is a traffic jam and it has to copy). You referenced that already with mismatched speed / oversubscribed. Great post!

  • David

    Nice post Darragh, looked at come of the other comments about bandwidth and cpu probs with SPAN but doesnt detract from the post.

  • Snowscan

    SPAN can affect production traffic on the Nexus 5K if you oversubscribe your SPAN interface (let’s say you monitor one of your 10G uplink and copy the traffic to a 1G port). You’ll want to look at the command “switchport monitor rate-limit”. I got burned by this once…

    • Daniel T

      Yes, I can second this. Be very careful about defining a VLAN as source for your SPAN session, if the resulting source traffic is more than the destination port can handle. The result will be that the entire VLAN will be throttled to the speed of your SPAN destination. You most likely do not want this.

  • Marc Abel

    Take a look at what Arista is doing with SPAN, allowing you to filter and do tap aggregation. Cool stuff they call danz.