When to use a SPAN/mirror port
The advantage of using a SPAN/mirror port is its cost, as a SPAN/mirror port is included for free with nearly every managed switch. A SPAN/mirror port is also remotely configurable, allowing you to change which ports are mirrored from the switch management console.
There are some limitations in using a SPAN/mirror port. Limitations of a SPAN/mirror port stem from the aggregation necessary to merge full-duplex network traffic into a single receive channel. For examples, when traffic levels on the network exceed the output capability of the SPAN/mirror port, the switch is forced to drop packets. Another reason that a SPAN/mirror port may not be the right choice is because Layer 1 and 2 errors are not mirrored and therefore never reach the analyzer. When performing network troubleshooting, seeing these errors can be important.
When monitoring with a SPAN/mirror port on a switch, the switch does three things:
Copies both the send and receive data channels
Reconstructs an integrated data stream from the two channels
Routes the integrated signal to the send channel of the SPAN/mirror port
Each of these activities burdens the switch’s internal processor. These demands on the switch’s CPU have implications for both your monitoring equipment and general network performance. Using a SPAN/mirror port to capture network traffic for analysis presents the following risks:
As total bandwidth usage for both channels exceeds the capacity of the outbound link to the analyzer, the excess traffic is dropped from the analyzer stream. There simply is not enough bandwidth to transmit both sides of the full-duplex traffic across a single standard interface.
The switch’s CPU must act as both a network switch and a packet-copier. The switch’s CPU must also integrate the two data streams (send and receive) together correctly. Both packet copy/re-direction and channel integration is affected by switch load. This means the SPAN/mirror port may not deliver accurate captures when the switch is under heavy load. Monitoring a 10/100 network through a Gigabit SPAN/mirror port and analyzer does not alleviate these concerns. Also, there is no notification when the SPAN/mirror port is dropping packets or delivering inaccurate time stamps.
A SPAN/mirror port can deliver satisfactory results when used to monitor lightly used, non-critical networks. If network utilization exceeds the capacity of the outbound (analyzer) link, packet loss results—which invalidates many types of analysis, and makes monitoring for certain kinds of network activity impractical. For example, you might miss a virus signature because packets are being dropped. When analyzing a transaction or connection problem, the analyzer may detect problems where none exist because expected packets are being dropped by the SPAN/mirror port. Hardware and media errors will also be impossible to troubleshoot through a SPAN/mirror port, as these errors are not mirrored to the analyzer.
Cloning your SPAN/mirror port
You can still access your SPAN/mirror port even if all of your SPAN/mirror ports on your switch are used. This is fairly common, and you can use a TAP to produce two copies of the SPAN/mirror port.
By cloning a SPAN/mirror port you get the benefits of a duplicate copy of the traffic and no security risk.
 
Figure 2: Cloning your SPAN/mirror port
NI nTAPs 'SPAN splitting' PNG [hdot24]NI nTAPs 'SPAN splitting' PNG [hdot24]
 
Joining SPAN/mirror ports
If you have a primary switch and a failover switch, you can connect both of them to the Aggregator TAP. Connect one of them to Link A and the other to Link B.
It does not matter whether the primary switch is connected to Link A or Link B, and you do not need to know which one is “live.” The Aggregator TAP joins the active and inactive SPAN/mirror port session together and sends the result to the analyzer. Regardless which switch is primary, the Aggregator TAP sends the SPAN/mirror port data from that switch to the analyzers.
 
Figure 3: Joining SPAN/mirror ports
NI nTAPs 'SPAN joining' PNGNI nTAPs 'SPAN joining' PNG