TAP into Technology | Garland Technology Blog

Network TAP vs SPAN Port: Putting Them to the Test

Written by Chris Greer | 4/27/17 12:08 PM

For years now we all have read about the difference between data capture off a span/mirror port and a network TAP

Packet Pioneer, Chris Greer was interested to see the difference between a data stream captured on a network TAP versus a SPAN port. So he set up a test with a few PCs, a TAP, a SPAN port, a couple of hardware network analyzers, and a healthy stream of data.

TAP vs. SPAN Test Setup

Packet Pioneer connected two PCs to a basic Cisco Catalyst Switch at 100Mbps. A throughput test using iPerf was configured and run between the two machines. On one of the PCs, he placed a 100Mbps TAP, and placed a hardware analyzer on it to capture. Lastly, he configured a SPAN on the switch to forward all traffic to and from this port to another hardware analyzer.


Below is a basic drawing of the setup.

 

>> Download Now: TAP vs SPAN [Free whitepaper]

Results

The throughput test finished with a result of 93.1Mbps sustained for 10 seconds between the two PCs.

TAP vs SPAN Packets captured Delta Time at TCP Setup
TAP Capture Results 133,126 243uSec
SPAN Capture Results 125,221 221 uSec

 

Conclusion

The SPAN data capture showed almost 8,000 packets missing from the trace. This represents almost 8% of the total packets captured by the analyzer on the network TAP. We should also point out that this was on a 100Mbps interface, not a Gigabit interface, and there were no errored frames. The switch bus was not in a near overloaded state.

Also, the difference in the timing between the TCP SYN and SYN ACK in the two traces shows us that the switch is not treating both the SPAN and Destination ports the same. In fact, it was forwarding traffic to the SPAN port faster than the true destination. While the difference is only 21 uSec, it shows that the switch is affected when SPAN is enabled. It is not as seamless as it would appear, and this delay was under no load test. With the switch loaded with traffic, the losses and timing will show greater differential and also dropped packets.

Considering the results of their test, Chris Greer, a network analyst at Packet Pioneer, said, “I am now a full believer in using a real [network] TAP whenever possible, especially when timing and total view of the data is important!”


Looking to add a visibility solution to your next deployment, but not sure where to start? Join us for a brief network Design-IT consultation or demo. No obligation - it’s what we love to do!