I want to address the age old argument of SPAN vs TAP. Over the years I’ve read a few articles covering the points you should be familiar with when working with either. Most of the articles cover similar points; SPAN will not forward corrupted packets and that it can drop packets.

What I haven’t seen is material addressing the timing issue as well as a realistic load of approximately 9%. Here's what my video shows...

Timing, Load Testing and Latency with SPAN vs. TAP Ports

Even if I capture 100% of the packets, I’ve always wondering if the timing is accurate. I wanted to determine if the packet delta time is affected and by how much.

The other item I wanted to cover is one of load. Most articles that I’ve reviewed typically test with 90-100% load on a link. Some analysts tell me that since they do not have that much traffic on their monitored link, this is not an issue. I wanted to set up a test with a realistic load, so I chose approximate 9%.

Tony Fortunato's TAP vs. SPAN Comparison

I put together this video reviewing my methodology and results for Network Computing, where I generated traffic using a network analysis tablet and captured the traffic with another, 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 it 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 back to back, the second test introduced a switch, the third test used a TAP, and the last test used a SPAN port.

Summary of the Packet Latency Results:

• Back to Back = 68 - 69 microseconds
• Switch = 56 - 80 microseconds
• TAP = 55 to 80 microseconds
• SPAN Port  = 50 - 88 microseconds

The conclusion of our tests highlight that the SPAN port used created more latency between packets as well as per packet latency where the TAP resulted in very little latency.

Please read the full article I wrote for Network Computing with deeper analysis.

Getting things to work better - bit by bit-
Tony Fortunato
Sr Network Performance Specialist
The Technology Firm

If you want to learn more about Real Network Visualtion Consideration for Professionals, download our free white paper, TAP vs SPAN.