TAP vs SPAN: Visibility Design Tradeoffs

Every network monitoring or detection tool needs a copy of the traffic. There are two ways to get it: a SPAN/mirror port on a switch, or a physical TAP on the link. They are not interchangeable, and choosing wrong is how you end up with a detection stack that quietly misses the traffic that matters. This is a reference note from doing this across enterprise deployments.

SPAN: convenient, lossy, contended

A SPAN port mirrors traffic from one or more switch ports to a monitor port. It's free — no new hardware — and reconfigurable in software. That convenience is also its weakness:

• It competes for switch resources. SPAN is a low-priority function. When the switch is under load, mirrored traffic is the first thing dropped — silently. You lose visibility exactly when you need it most.
• It can oversubscribe trivially. Mirroring a full-duplex gigabit link (up to 2 Gbps of traffic) to a single gigabit monitor port cannot work. The excess is dropped with no error you'll notice.
• It alters the traffic. SPAN may drop corrupt frames, normalize errors, and reorder packets — so the copy isn't faithful for error analysis.
• It's politically volatile. SPAN sessions are finite and get reassigned during troubleshooting, often without telling the security team.

TAP: faithful, reliable, costs hardware

A physical TAP is a purpose-built device inserted into the link that copies every bit to a monitor output. A passive optical TAP splits light with no power and no logic in the path.

• It's faithful. Every frame, including errors and malformed packets, at full line rate. What's on the wire is what the tool sees.
• It doesn't contend. Copying is the TAP's only job, so there's no "switch is busy" failure mode stealing your visibility.
• It's stable. A TAP isn't a software session someone reassigns. It's cabled infrastructure; the visibility is durable.
• It costs. Hardware, rack space, and a brief link break to install.

The aggregation problem

TAPs give you a faithful copy per link, but then you have many copies and many tools. A duplex copy is two streams; tools usually want one. Multiple TAPs feeding one tool need aggregation; one TAP feeding several tools needs regeneration. This is the job of a packet broker — aggregate, regenerate, filter, de-duplicate, and load-balance — sitting between the TAP layer and the tool rail. Without one, you're hand-wiring a brittle mesh that breaks every time a tool changes.

In-line and the bypass imperative

Out-of-band (a copy) and in-line (the traffic transits the device) are fundamentally different risk postures. Out-of-band can fail without the network noticing. In-line cannot — if the device is in the path and it dies, the link dies with it.

The longer field-notes version of this — including the cutover discipline — is in the enterprise tapping retrospective.

Summary