For years now we all have read about the difference between data capture off a span/mirror port and an inline network TAP. In fact, many of those comments have come from one of the great moderators of lovemytool.com, Tim O'Neill, the @OldCommGuy who loves the TAP side of the ring.
Packet Pioneer was interested to see the difference between a data stream captured on a network TAP versus a SPAN port. So they 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.
The results were interesting, to say the least: The study showed that Tim O’Neill is correct!
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, they placed a 100Mbps TAP, and placed a hardware analyzer on it to capture. Lastly, they 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.
The throughput test finished with a result of 93.1Mbps sustained for 10 seconds between the two PCs.
Tap Capture Results
Packets captured: 133,126
Delta Time at TCP Setup: 243uSec
SPAN Capture Results
Packets captured: 125,221
Delta time of TCP connection setup: 221 uSec
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!”
If you want to learn more about Real Network Visualtion Consideration for Professionals, download our free white paper, TAP vs SPAN.