SPAN Port Vs. TAP: The Latency Impact

I thought this would be a perfect time to cover the classic "SPAN vs. TAP" topic since SPAN ports are used for network analysis more often in the field than ever before. This is mainly due to their convenience and because the destination host’s connection isn’t impacted when we want to monitor its traffic.

For those of you who may not be familiar with the topic, it's pretty straightforward: Frames that are captured from a SPAN or mirror port will have different characteristics compared to the destination port. Specifically, I am referring to inter-frame timings and dropped frames.

In certain cases, I do not think this is an issue. For example, if you are monitoring a typical client to perform an application baseline, or monitoring a WAN link to determine application usage, dropping some packets or not having a true delta time isn’t as critical.

Other articles that compare spanning technology vs. TAPs focus on the packet loss issue. I wanted to approach this from a different angle by analyzing how a span port affects packet timing. I also wanted to do this without causing a 100% load on the port. I‘ve heard some network analysts say that since their ports have low utilization, they believe this issue doesn’t apply to them. I performed some of my own tests to provide my two bits worth regarding this topic, and put together a video on my findings:

Before reviewing the test scenario and results, let's cover some pros and cons of using a SPAN port. Here are the advantages:

And the drawbacks:

A TAP is a hardware device that allows you to capture packets flowing between a device and its switch port. Here are some of the pros of using a TAP:

The downsides include:

Test scenario

I generated traffic using a Fluke Networks (now NetScout) OptiView XG network analysis tablet and captured the traffic with another OptiView XG, and in some cases a third one. I chose to only generate a 9% load and a 757-byte frame to most closely resemble the average load and frame size you would see on a gigabit port. My logic here is that if these test parameters cause an issue, then a greater load only gets worse. I chose OptiView since it can capture with a 10-nanosecond resolution, and I used packet slicing to reduce the total trace file size.  For my tap, I used a Garland Technology P1GCCAS 1Gb Copper TAP.

I filtered the remaining trace file by the IP identifier since the OptiView keeps this value constant for all packets. I then converted the filtered trace file to a CSV file using Wireshark and charted the filtered output’s delta time using Excel.

The order of the tests are quite important for me. The first test was a baseline of two OptiViews back to back, the second test introduced a switch, the third test used a TAP, and the last test used a SPAN port.

Here is a summary of the packet latency results:

The test results show  that a SPAN port created more latency between the packets and additional latency when a packet was received. In conclusion, you should be aware of your SPAN port limitations and where TAPs might complement your toolbox.

interop-las-vegas-small-logo.jpg

Learn more about network troubleshooting in the live workshop The Killer Toolset Every Network Engineer Needs at Interop Las Vegas this spring. Don't miss out! Register now for Interop, May 2-6, and receive $200 off.