Where you tap
decides what you can see.
This is the least glamorous decision in a monitoring deployment and one of the few that is genuinely hard to undo. It determines, months in advance, which questions you will be able to answer.
A SPAN or mirror port is a switch feature that copies traffic to a monitor port; a TAP is a physical device inserted into the link that copies it in hardware. SPAN is free, configurable from anywhere and adequate for most work. A TAP costs money and a maintenance window, and in exchange it cannot be oversubscribed, does not consume switch resources, does not drop under load and does not lose errored frames. Use SPAN by default; use a TAP where the traffic is critical, the link is heavily loaded, or the capture has to be evidential.
Six practical distinctions.
Oversubscription
Mirroring two 1 Gbps links to one 1 Gbps monitor port works until both are busy, and then the switch silently drops what will not fit. A TAP has no such failure mode.
This is the single most common reason a capture is missing exactly the traffic that mattered.
Errored frames
Switches generally discard corrupted frames rather than mirroring them. If you are chasing CRC errors or a failing transceiver, the evidence is dropped before it reaches your capture.
If the investigation is about physical errors, a TAP is not a preference — it is a requirement.
Load on the switch
Mirroring consumes fabric and, on some platforms, CPU. On a device already under pressure, turning on SPAN during an incident can make the incident measurably worse.
Check the platform's behaviour before enabling SPAN on a core device mid-incident.
Timing accuracy
Mirrored packets are queued and forwarded like any other traffic, which perturbs their timing slightly. For most diagnosis this is irrelevant; for microsecond-level work it is not.
If you are measuring latency in microseconds, tap. If you are measuring in milliseconds, mirror.
Change control
SPAN is a configuration change, reversible in seconds and doable remotely. A TAP is a physical insertion that breaks the link while it is fitted. That difference usually decides the deployment plan.
Plan TAP placement into cabling work. Retrofitting one into a live critical link is an outage.
What it says about your evidence
A TAP gives a complete, hardware-guaranteed copy. A SPAN gives a best-effort copy from a device that is entitled to drop it. When a capture is going to be shown to an auditor, an insurer or a supplier, that distinction can matter.
For evidential capture, prefer a TAP and record the placement alongside the data.
Four questions before you place anything.
- 1
List what you need to be able to answer
Placement follows the questions. Perimeter traffic, server-to-server traffic and a specific application's path are three different capture points, and no single one covers the others.
- 2
Check the aggregate rate against the monitor port
Add up the busy-hour throughput of everything you intend to mirror. If it can exceed the monitor port, you have designed in a blind spot.
- 3
Choose TAPs for the links you cannot afford to miss
Usually the internet edge, the data-centre core and any regulated path. Everywhere else, mirror.
- 4
Write down where the capture points are
Six months later, the value of a recording depends entirely on someone knowing what it was recording. This is the step everyone skips.
How this fits a continuous deployment
- The sniffer is passive either way. It takes a copy and adds nothing to the path it is watching, whether that copy comes from a mirror port or a TAP.
- Placement is part of the deployment conversation. It decides what you will be able to answer later, so it is worth an hour up front rather than a regret in six months.
- Coverage can grow. Starting with mirror ports on the paths that hurt and adding TAPs where the evidence has to be complete is a perfectly reasonable order.
Short answers.
What is the difference between a SPAN port and a TAP?
A SPAN, or mirror, port is a switch feature that copies traffic from one or more ports to a monitoring port. A TAP is a physical device spliced into the link itself that duplicates the signal in hardware. SPAN is free and remotely configurable; a TAP cannot be oversubscribed, does not burden the switch, and passes errored frames that a switch would discard.
Can a SPAN port drop packets?
Yes, and this is its main limitation. If the combined traffic being mirrored exceeds the monitor port's capacity — which is easy to arrange without noticing — the switch drops the excess and does not usually make a fuss about it. Your capture is then quietly incomplete during exactly the busy periods you were most interested in.
Does a TAP break the link if it fails?
A passive optical TAP splits the light and has no active components in the path, so it keeps working through a power failure. Copper TAPs are active and normally include relay-based bypass so the link survives a power loss. Either way, insertion itself requires the link to be broken briefly, which is a change-window question.
Do I need a TAP for every link?
No, and it would be an expensive way to start. Most deployments mirror broadly and tap selectively — the internet edge, the data-centre core, and any path where the capture has to be complete or evidential. The rest is well served by SPAN.
Related questions.
Planning where to capture?
It is worth an hour with someone who has done it before. We will walk your topology with you.