Author Profile - Chris Greer is a Senior Network Analyst for Network Protocol Specialists, a Seattle based Network Consulting company. Chris has 10 years of experience in analyzing and troubleshooting networks. He regularly assists companies in tracking down the source of network and application performance problems using a variety of protocol analysis and monitoring tools including Wireshark. When he isn’t hunting down problems at the packet level, he can be found teaching various analysis workshops at Interop and other industry trade shows. Chris also delivers Fluke Networks public courses and protocol analysis themed webcasts. He can be contacted at chris (at) nps-llc (dot) com.
Is capturing data off a SPAN port really so bad?
Author's Note: This study is approved of by the Oldcommguy™!
For years now we all have read about the difference between capturing off a span/mirror port and an inline tap. In fact, many of these comments have come from one of the great moderators of this very site who loves the TAP side of the ring. (His name rhymes with Kim ☺ or Oldcoomguy)
Here at NPS though we were interested to see just how bad it is when a data stream is captured on a tap vs. a SPAN port. So we setup a test with a few PCs, a tap, a SPAN port, a couple hardware analyzers, and a healthy stream of data. The results were interesting to say the least! The problem is that the study showed that the Oldcommguy is correct!
Test Setup
We 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, we placed a 100Mbps tap, and placed a hardware analyzer on it to capture. Last, we 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.
Results
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
Conclusion
The SPAN capture showed almost 8,000 packets missing from the trace. This represents almost 8% of the total packets captured by the analyzer on the 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.
I’m now a full believer in using a Tap whenever possible, especially when timing is important!
Keep on Capturing but do it the right way!
Editor's Note - Please refer to the following LoveMyTool articles comparing SPAN Ports and Taps.
SPAN Port or TAP? CSO Beware (by Tim O’Neill)
SPAN Port or TAP? Sharkfest Video (by Betty DuBois)
Continue reading other LoveMyTool posts by Chris Greer »
Recent Comments