For my sins, I have spent a modest amount of time testing how well a few switches did port mirroring. The depressing result was that neither of the switches I tested had port mirroring that worked really well for our needs, but on the other hand it has given me an appreciation for the issues that port mirroring can have.

(We use port mirroring for simple network traffic volume monitoring, and we would like to be able to use it for network debugging; at the time I was investigating if we could use some cheap switches for either purpose, instead of having to dedicate some of our relatively expensive 24-port gigabit switches to the task.)

Two problems stick in my mind:

• one switch would every so often de-VLAN a frame on the mirroring port; a frame that I knew had gone into the switch with a VLAN tag on it would come out the mirroring port without the VLAN tag, as an untagged frame.

  (Other traffic was mirrored with VLAN tags intact, which is what we need.)

• one switch choked the total bandwidth of the port being mirrored down to whatever the monitoring port could support; frames that could not be mirrored to the monitoring port were just dropped instead of passed through. The net result was that the port's total bandwidth (send plus receive) was reduced to half of what it would be without port mirroring turned on.

This very nicely illustrates the perils of port mirroring, because while the first switch had a bug, the second switch was making a rational design decision. If you were using port mirroring for security monitoring, you would not want an attacker to be able to sneak packets past you because he has saturated your monitoring point, so dropping frames that cannot be mirrored is the right decision. But we have different priorities; preserving our internal NAT firewall's total bandwidth is more important to us than having our traffic monitoring box see every last packet.