Packet Broker | July 29, 2022
Does it Really Matter?
SPAN Ports are tempting, but not a good idea.
Underload, SPAN Ports can drop packets and you wouldn’t know.
I was reading through a new report, Network Visibility Architecture for the Hybrid, Multi-Cloud Enterprise, published by Enterprise Management Associates the other day. What I read was quite shocking–especially on p. 13 of the report. There has been a significant increase in the use of SPAN port by enterprise IT teams in the last 4 years. According to the report, approximately 31% of enterprises use SPAN as their primary form of network packet data access. This is bad because while SPAN ports were designed to create to increase network visibility but quite often end up decreasing visibility and you may have no idea it’s happening.
This begs the question—how do I get the right data access? The best source of data is from a network tap. A tap makes a complete copy of ALL the data passing through it. It is a passive device, so it does not alter any of the data and has a negligible effect on transmission time.
Taps are great because they are “set and forget”. You simply plug the device into the network with a one-time disruption and you are done. No programming is required. Best of all, you can place taps anywhere in the network that you need data from – ingress, egress, remote offices, etc. The one drawback to using taps is that if you install lots of them (which you will want to do), the amount of data feeds can overload the input ports to your tools. However, this issue is easily resolved by installing a network packet broker (NPB) to aggregate the data from the taps, filter the data as necessary, and then send that data on to security and performance tools.
- The mirroring port (also referred to as a SPAN port) on your network switches is an alternative to a tap. However, this is not recommended for several reasons. One reason is that these ports are active devices, i.e., they can materially change data packet characteristics as the packets flow through the device. This is especially important when using data from these ports to diagnose problems.
- In addition, bad data packets (e.g., malformed packets) are dropped by the SPAN port and you won’t know it until you look for them. This ends up giving you a “digital view” of the situation, i.e., everything is fine and then there is a problem. Missing packets that could show degradation prior to data loss (which could have been useful to create a quicker diagnosis) is missing, along with any context as to what was happening before the problem began. Bad frames (caused by a faulty NIC) can also be dismissed by SPAN ports and not passed on to diagnostic tools.
- A third reason that SPAN ports are not recommended is because they require active programming. You have to physically program the port every time you want to make a copy of data traffic. Any time there is a change, you have to manually change the programming for that port using CLI or a tool like that. A study performed by ZK Research a few years back showed that 20% or more of SPAN ports are programmed incorrectly, i.e., you are missing data or getting the wrong data from what you had originally wanted.
- With a good packet broker, capturing monitoring information is much easier. You have graphical interface, like the ones used in the Keysight Vision ONE packet broker, that make it fast and easy to program the port. All you need is a minute or two – it’s that fast. It is also a common practice for network engineers to span VLANs across gigabit ports. In addition to the need for additional ports that may be available in one switch, it is often difficult to “combine” or match packets to a particular originating link. So, while spanning a VLAN can be a great way to get an overall feel for network issues, pinpointing the source of actual problems becomes difficult.
- Lastly, SPAN ports have a low priority for CPU resources on a switch.
This means that if the CPU of the Layer 2/3 switch gets heavily loaded and has to end up shedding load (before it crashes), SPAN ports are one of the first devices to be cut off. So, when things are going bad on your switch (and your network) and you really need troubleshooting data for security or performance issues, you strand the very real possibility of losing that data and your monitoring solution “going dark.”
In the end, optimum data capture can be achieved using a tap and NPB.
This results in a faster mean time to repair (MTTR). To get more information on the Tap versus SPAN discussion
