NETWORKING

  • 04/13/2016
    7:00 AM
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

SPAN Port Vs. TAP: The Latency Impact

Tony Fortunato analyzes how a mirror port affects packet timing compared to a TAP.

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:

  • Low cost, if your switch supports it
  • Remotely configurable
  • The monitored host is not physically disconnected

And the drawbacks:

  • Port errors are dropped
  • If port utilization exceeds the SPAN port, packets will be dropped
  • Increases load on switch CPU
  • Will affect packet timings
  • Different vendors support different syntax and number of SPAN ports

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:

  • Captures hardware or port errors
  • Does not drop packets

The downsides include:

  • Additional cost
  • Another physical device to bring if you are using it as a portable troubleshooting tool
  • Requires sufficient rack space and power
  • The physical connection between the devices must be physically broken to insert the TAP
  • When dealing with fiber, you need to know the connection details you're monitoring, such as single-mode or multi-mode, wavelength and the interface used (MTP, LC, etc.)

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:

  • Back to back = 68–69 microseconds, with a variance of one microsecond
  • Through switch = 56-80 microseconds, with a variance of 24 microseconds
  • TAP = 55-80 microseconds, with a variance of 25 microseconds
  • SPAN port = 50-88 microseconds, with a variance of 38 microseconds

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.

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.


Comments

"SPAN port and CPU?"

Why will using SPAN port affect the CPU? I thought SPAN traffic is done by HW and there is no CPU involved.

Netflow traffic will need CPU intervention and it does affect switch's CPU performance.

Re: "SPAN port and CPU?"

Hi - Tony is currently unable to reply on the site, so I'm posting his response:

Great question. I can tell you that I have personally seen clients set up a span port which results in major issues that were a related to an overloaded CPU. I honestly do not know why and it doesn’t always happen, but thought it was a point worth mentioning as something to look out for.
I also agree with your NetFlow comment which does affect a switch’s CPU performance.

SPAN Port Vs. TAP: The Latency Impact

Tony great article! As a network tap manufacturer, we often see this question and you’ve indentified many of the common benefits of both SPAN and tap usage for network monitoring. Not all taps are created equal, since some of our copper taps have latency which can range from 0.5 us to 5 us. Fiber taps obviously have much lower statistics and can be as low as 5 ns. Another latency consideration when using network taps is the size of the buffer in the tap. Some taps use very large buffers to prevent loss of packets when traffic spikes or bursts appear in the network. While these buffers can help prevent packet loss, they may introduce significant latency on the monitoring side of the tap. Make sure to lab test any product before standardizing it for your network.

Re: SPAN Port Vs. TAP: The Latency Impact

From Tony: Thanks for the great feedback. All good points to keep in mind.

catch me live

I will be reviewing this topic and article Monday, May 2, 9:30 AM PDT https://plus.google.com/u/0/b/115255534453794235968/events/c30ubtvirl59i...