This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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
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:
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.)
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.