Taps vs SPANs: A Primer
In today’s IT world, monitoring and capturing network traffic requires more than simply connecting a network analyzer and clicking “Go”. In almost all cases, an additional step is required to access the data that the analysis tool needs.
The two most common network traffic capture methods are taps and SPANs. A quick search on Google shows that “taps vs SPANs” is a much-debated topic, often with a vendor bias toward taps (i.e., since SPAN capabilities are built into the switch, there is no upsell opportunity to using SPAN).
Which network traffic capture methods are best for you and your analysis goals? As we will see, it depends on what you are trying to achieve. In this article, we will take a pragmatic look at both network traffic capture methods, examining the strengths and weaknesses of each, as well as considering specific monitoring scenarios where we would prefer one method over the other. That being said, both traffic methods will allow the network analyzer tool to dig into the data, enabling network engineers to stay ahead of network and application problems.
Network Traffic Capture M
A physical device, a tap enables the network analyzer to literally listen in to the raw network traffic. Because taps present the packet ‘truth’, they are often considered the gold standard for capturing packets. With many varieties of network taps available, there is a network tap for every analysis goal.
Figure 1: A network tap
Taps’ advantages include facilitating line-rate capture, and thus loss-free analysis; preserving accurate packet timing; and not forwarding false information. On the other hand, a tap can only be in one place at a given time. Multipoint capture efforts require multiple taps, which can be a challenge when working with core links.
Network Traffic Capture M
The most popular method for capturing traffic, a SPAN session allows a network analyzer to monitor traffic on an adjacent switch port, without disrupting the stream. SPANs are generally good enough for basic capturing in most cases. Although SPANs cannot guarantee packet forwarding perfection, many analysis goals don’t require it.
Figure 2: A SPAN
SPANs can be configured on the fly and don’t cost anything to deploy; they are literally built into the switch. However, SPANs are notorious for being a “best effort” function, coming at the expense of other core switching capabilities. As a result, timing in the data stream can easily become altered from the original values, resulting in false alarms.
Different (capture) strokes for different (network) folks
SPANs are recommended when capturing traffic on low-bandwidth links and when microsecond-level accuracy is not important. Taps are recommended for 10 Gbps links and above. If packet timing is important to the analysis goal and data rates are at or above 1 Gbps sustained, you should definitely use a tap.
If you need to validate header values or conversation pairs, SPAN capabilities will suffice in most cases. When looking for security breaches or tracking application dependencies, conversation-level data is typically more important than packet timing and a random lost packet can be tolerated. When multi-point captures are necessary, and the number of taps is less than the capture points required, a SPAN can fill in where a tap is unavailable.
Benchmarking SPAN vs Tap
In 2016, Network Computing published an article that showed the measurement differences between using a tap and a SPAN port for packet capture. The test was conducted with a 90 Mbps stream of data and an average packet size of 797 bytes, with the assumption that this would produce an environment under test with average circumstances. A total of 100,000 packets were generated, then captured by hardware-based analyzers from both a SPAN session on a Cisco 3750 switch and a tap. The focus of the test was to measure the difference in latency between packets, rather than focusing on the number of packets lost from the stream due to the low utilization rate of the stream.
Figure 3: TAP results
The line above represents a graph of the amount of latency measured between packets on the data stream. The orange tips on some of these measurements show the additional latency induced by the tap. As we can see, these are infrequent and minimal. As the graphic shows, there is—on a fairly random basis—less than 1 µSec of timing difference from the real packet stream on the wire.
Figure 4: SPAN port results
The graph above displays the additional latency observed on the SPAN port vs. what was measured on the wire itself (shown in blue). This shows that the latency between packets measured on the SPAN was often several µseconds different than what was measured in the true stream. As you can see, there is frequently 5-10 µSec of difference between the real packet stream and the traffic captured.
These test results are significant because they represent a best-case capture scenario in a controlled environment with very low traffic levels. In a production environment with greater device and traffic loads, these results can only be expected to worsen, especially in the case of the SPAN capture.
Monitoring and troubleshooting the problems of today’s IT infrastructure requires packet-level detail. In order to collect that critical data, we need to choose between taps and SPANs as network traffic capture methods.
Which network traffic capture methods are best for you and your analysis goals? Well, as described in this article, it depends. You should make sure to clearly define the task at hand and be realistic about the limitations of the capture method. It is important to weigh, reasonably, whether accurate timestamps are necessary to your goals and if the data rate will present a problem to the SPAN or analyzer. If the link is 10 Gbps or above, tapping may be your only option for usable analysis data.
When it comes down to it, taps present the clear packet truth on the wire, uninhibited by forwarding priorities, buffers, and other traffic demands. Every network engineer should have one in his analysis toolbox.
SkyLIGHT PVX, SPAN, and Taps
SkyLIGHT PVX works with both SPAN and