Imagotype-NetworkDataPedia (1)_edited.pn

NetworkDataPedia © 2018-2020  |  Editorial Team   |   Privacy Policies  |  Contact Us          Website built by DYCMarketing 

Is SPAN Port really so bad? (by Chris Greer)

February 1, 2016

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 Oldcommguy)

Here at Packet Pioneers 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!

 

Share on Facebook
Share on Twitter
Please reload

Sponsored By:

Viavi

Display_LoveMyTool_170x400.png
Recent Posts

November 12, 2019

Please reload