8

If I'm sending traffic from host A to B by a switch, will enabling a mirror/SPAN port increase the time it takes for my frames to get from A to B?

Nb: I'm not worried about the time it takes for the mirrored frame to reach my monitoring host. Just wondering if it will affect the network performance in a time-critical environment.

Has anyone tested this? (I would also welcome any links to a post/paper on this)

  • 1
    In short, no. This sort of thing happens all the time with frames that have unknown destinations or are broadcasts. Typically, duplication and forwarding are done in hardware at wire speed. – Ron Maupin Jun 5 '15 at 15:41
  • 1
    As Ron Maupin has already noted, in general no. However, no one could make this blanket statement with any assurance across all vendors and platforms. Could you narrow this down? – YLearn Jun 5 '15 at 15:55
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 11 '17 at 17:07
7

Typically, according to Cisco, "The impact on the high-speed switching fabric is negligible".

This of course depends on your switch, its fabric and the load on the switch itself. The port that is being sent the copied data could drop packets however, if it's oversubscribed too heavily. Personally, I've never experienced any sort of detriment by using mirroring or SPAN.

Here's a doc from Cisco directly about the subject on some of their cat lines: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html#anc48

  • 1
    Perhaps one thought to add to this: Be more cautious with "RSPAN" or remote mirroring. Forwarding a lot of mirrored traffic through your network could easily overload your links. As stevieb said, if you do SPAN/port-mirror on the same device to a dedicated mirror port you should be fine. – Sebastian Wiesinger Jun 6 '15 at 11:17
3

It is possible to affect the sources (i.e. monitored ports) if the aggregate traffic exceeds the capability of the destination (i.e the monitoring port). I don't have the reference I was initially thinking of, but here's another: Back pressure from a SPAN port.

So imagine you have server on a ten-gig port that you want to SPAN to a packet capture device (or IDS/IPS, etc.). The monitoring device is also on a ten-gig interface.

Remember that when you set up a SPAN, you have the option of SPANning transmit (out of the switch interface towards the server), or receive (from the server into the switch) , or both. Normally we would want to see both sides of a conversation, so we'd choose to SPAN both the transmit and received.

Now imagine that the server is very busy, and both it's transmit and receive streams are quite full, consistently above 5-gig in each direction.

You now want to send TWO, greater-than-5-gig streams to the monitoring device via the SPAN destination port. The total traffic being sent towards the SPAN destination is greater than 10-gig. But, that interface is ONLY 10-Gig towards the monitoring device. So what happens? I recall that Cisco's docs said that initially, packets would be dropped from the transmit buffer of the interface towards the monitoring device (i.e. the SPAN destination transmit buffer). However, in the case of long-duration, sustained traffic streams, eventually the ability of the switch to drop excess traffic from the transmit buffer will be exhausted (which does not, and did not at the time, make sense to me), and then the switch will begin to use other mechanisms to decrease the flow, including 'back pressure' using 802.3x PAUSE frames being sent to the source ports.

And you have now impacted your source traffic. Bad things happen.

This problem is/was especially significant to a large, high-speed very low latency network, that had many sources for the SPAN. Which was a major consideration and resulted in replacing the use of SPAN sessions having many sources for optical TAPS, feeding aggregation switches with inbound ACLs (filtering for interesting traffic), then trunking that inbound traffic to multiple 10-Gig specialized packet consumers (for data archive and analysis needs).

Moral of the story: if you are intending to use many SPAN sources, be confident that the aggregate bandwidth of BOTH tx and rx is less than the bandwidth to your capture device.

Here's a decent treatise on using SPAN ports

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.