There’s a bit of unexpected behaviour on ProCurve switches when configuring port mirroring if you come from a Cisco background. Ports that are configured as a destination for port mirroring are still actively participating in their configured broadcast domain(s). I have witnessed the most severe possible consequence in the form of a bridging loop on two core switches. For that reason, I see a warning as due diligence.
Here is the thing: if you configure a ProCurve switch for port mirroring, you choose a source port and a destination port. If you come from a Cisco background, then you would expect the destination port to become ONLY a destination port for the port mirror as the result of your configuration, and nothing else. If you configure port mirroring on the ProCurve switch, the destination port will still be actively participating in any broadcast domains that it is configured to use. By itself, this is not immediately a threat to the stability of your network, although it might pose a security risk. Now imagine a scenario where you are hooking up a device to multiple switches for monitoring. If that device were to have a configuration error, a bug, or any other problem that causes it to forward frames across the connected interfaces, you have now formed a bridging loop!
Depending on a couple of factors like your spanning tree configuration, the specific port’s configuration as it relates to spanning tree (like PortFast) and the behaviour of the monitoring box, you either get lucky, get screwed for the native VLAN, or get screwed for every VLAN that’s tagged on both port mirror destination ports.
Armed with the info given above, there is an easy solution to prevent this when using port mirroring on ProVision switches:
This approach will prevent any unintended traffic from crossing your mirror destination.