Choosing between a SPAN, Aggregator, or full-duplex TAP
10 10/100 Copper nTAP (7 Feb 2018) — Archive/Non-authoritative version
TAP
SPAN/mirror port
of a TAP and none of the
disadvantages of a SPAN port.
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.
