Keith Bromley
Sr. Manager, Product Marketing at Ixia

SPAN Port: The ABCs of Network Visibility

August 10, 2017 by Keith Bromley

A common way of capturing network data for monitoring purposes involves the use of switched port analyzer (SPAN) ports, also called mirroring ports. These ports are typically available from a network routing switch. The technology was created by Cisco Systems as a way to access data transiting their network routing and data center switches. While newer technologies, like Taps, are eclipsing this technology, SPAN ports are still used by some IT personnel.


A SPAN port should not be confused with a SPAN session. A SPAN session is a CLI monitor command, or set of commands, used to create a basic filter using the SPAN port. The SPAN port is still the main monitor access mechanism for the switch bus.


Purpose of SPAN Ports


Originally, SPAN ports were a very viable monitoring technology. For instance, when we only had 10 Mbps links and a robust switch (like the ones from Cisco), engineers could almost guarantee that they could see every packet going through the switch. With 10 Mbps fully loaded at around 50% to 60% of the maximum bandwidth, the switch backplane could easily replicate most of the frames. Even with 100 Mbps, one could be successful at acquiring most of the frames for analysis and monitoring. And if a frame or two was lost, it was no big deal.


This has all changed with 1 Gigabit to 100 Gigabit technologies; starting with the fact that the maximum bandwidth is now twice the base bandwidth. A full duplex Gigabit link is now 2 Gigabits of data and a 100 Gigabit FDX link is now 200 Gigabits of potential data. No switch or router can handle replicating/mirroring this amount of data for all of its ports, plus still handle its primary job of switching and or routing. It is impossible to pass all frames (good and bad, including full duplex traffic) with any real-time correlation from a SPAN port. For this reason, SPAN ports are NOT acceptable for most of today’s security monitoring applications and modalities – too much of the pertinent data can be lost.


Typical Use Cases


At the same time, there are many monitoring events which can successfully use spanning as the packet access technology. SPAN ports can be used for the inventory of addresses and other non-time sensitive monitoring. These monitoring events are looking for low bandwidth application layer events like:

  • Conversation or correction analysis
  • Application flows
  • And applications where real-time (and knowing real delta times like voice and video flows) is not an important factor or requirement 

The monitoring requirements just mentioned utilize a small amount of bandwidth and packet grooming. This means that packet drops do not affect the quality of the reports and statistics. The reason for their success is that they keep within the parameters and capability of the SPAN ports ability. These specific applications do not need every frame for their successful reporting or analysis. In other words, if used correctly, SPAN ports are a usable technology as part of a well-managed methodology.




While SPAN ports make a mirrored copy of network data, there are a host of issues associated with them. This needs to be factored in to your monitoring strategy. Here are some things to keep in mind when using SPAN ports:


The use of SPAN ports creates the following issues:

  • Duplicate data packets are typically created which reduces the efficiency of your monitoring tools
  • Missing data (Layer 1 data, corrupted and malformed packets, bad CRC, Interframe gap, and other data odditities) is not forwarded on to SPAN ports. Therefore, SPAN access is not suitable for real time protocol (RTP) monitoring, capture, and analysis, especially in modern mean opinion score (MOS) and quality of experience (QoE) strategies.
  • SPAN ports only provide summarized data
  • SPAN ports change the time stamps of packets
  • SPAN ports have been shown to be hackable (so they can be a security risk)
  • SPAN ports require CLI programming

SPAN ports themselves are one of the reasons you can develop network blind spots – Depending upon how you set up the filtering (i.e. what traffic you decide to make a copy of and route to the SPAN port), you may be collecting the wrong data and/or accidentally clipping (i.e. dropping) data you are actually interested in.

A Cisco white paper on SPAN port usability and the use of SPAN port for LAN analysis, warns that “the switch treats SPAN data with a lower priority than regular port-to-port data.” In other words, if any resource under load must choose between passing normal traffic and SPAN data, the SPAN port loses out and the mirrored frames are arbitrarily discarded. This rule applies to preserving network traffic in any situation. For instance, when transporting Remote SPAN (RSPAN) traffic through an Inter Switch Link (ISL), which shares the ISL bandwidth with regular network traffic, the network traffic takes priority. If there is not enough capacity for the remote SPAN traffic, the switch drops it. Knowing that the SPAN port arbitrarily drops traffic under specific load conditions, what strategy should users adopt so as not to miss frames? According to the Cisco paper, “the best strategy is to make decisions based on the traffic levels of the configuration and when in doubt to use the SPAN port only for relatively low-throughput situations.” To sum it up, you’re not seeing a complete copy of the traffic on your network.

SPAN/MON port access is not a passive technology – While some people try to call SPAN port technology a passive data access solution, passive means “having no effect” and spanning port (mirroring) technology does have measurable effect on the data. Here are some of the ways that a SPAN session modifies monitoring data:

  • Spanning changes the timing of the frame interaction (what you see is not what really happened)
  • The spanning algorithm is not designed to be the primary focus (main function) of a network switch, like switching or routing is. So the first priority is not spanning and if replicating a frame becomes an issue, the hardware will temporarily stop the SPAN process.
  • If the speed of the SPAN port becomes over-loaded, frames are dropped
  • A SPAN port drops all packets that are corrupt as well as those that are below the minimum size. So, all of the frames are not passed on, No interframe data is passed, either. All of these events can occur without any notification being sent to the user. This means there is no guarantee that one will get all of the data required for proper analysis.

SPAN ports are NOT freeSPAN ports are often thought of as a “free” way for IT personnel to access monitoring data because most switches provide two or more SPAN ports free of charge. However, proper spanning (even if the port can handle the load) requires that a network engineer configure the switches. This is a manual process which uses a command line interface (CLI) and often requires significant time to create and validate the command. This takes away from the more important tasks that network engineers have. The “free” component is quickly eliminated when programming costs are factored in.


The use of SPAN ports will probably cause a delay in troubleshooting activities – Since the network switch has to be touched to configure SPAN port sessions, this can affect the network if a command is entered incorrectly or the switch ports are touched. SPAN programming can also require Change Board approval, which introduces data capture delays. In addition, many network configuration changes can become a political issue due to creating contention between the IT teams, the security teams, and the compliance teams.


There may be legal ramifications to the use of SPAN ports for data collection – The fact that a SPAN port is not a passive data access technology or even entirely non-intrusive can be a problem, particularly for data security compliance monitoring or lawful intercept. SPAN ports, unlike taps, are also addressable devices and can therefore be hacked. Since there is no guarantee of absolute fidelity either in time or actual packets, it is possible, and even likely, that evidence gathered by the SPAN port monitoring process will be challenged in a court of law when used for lawful intercept.


More Information on SPAN Ports


If you want more information SPAN ports, Taps, and Ixia’s NPB solution, read this whitepaper and check out the material available here.