.png?width=40&height=40&name=search%201%20(1).png){kind=small}
Visibility 101
See all 7 deployment scenarios — full diagrams, architecture details, free PDF
Get All 7 Scenarios
→
A Field Guide
SPAN, done
right.
Switch port mirroring is everywhere. It's also misunderstood, misconfigured, and quietly leaving production networks exposed. Here's how to use it safely and when to reach for something better.
3
Best Practices
7
Real-World Scenarios
10M–100G
Bandwidth Coverage
[ 01 ] The Premise
Out-of-band tools, IDS, NDR, APM, SIEM, network analyzers, OT security sensors only work when they receive copies of your network traffic. Without that visibility, they monitor and protect nothing.
SPAN is the most common way to get that traffic. It's already built into your switches. It's free. And it's been the default since Cisco introduced it in the mid-90s.
But SPAN ports drop packets under load, run at lower priority than production traffic, and critically, they create a potential pathway back into your production network if your monitoring tool is ever compromised.
The three best practices that follow address each of those failure modes.
Best Practice 01
Protect the SPAN port from itself.
The Risk
A SPAN port is technically a two-way connection. Even though you only intend it to send traffic out to your monitoring tool, nothing physically prevents traffic from being injected back into your switch. If your tool is ever compromised, that SPAN port becomes a doorway into your production network.
The Fix
Place a Hardware Data Diode between the SPAN port and your tool. The diode physically enforces one-way data flow, copies of traffic move from switch to tool, but it is physically impossible for anything to travel back. This is essential in OT environments and any critical network where SPAN is your only connection option.
FIG. 01 / DIODE
ONE-WAY FLOW
Best Practice 02
Aggregate many SPANs into one clean feed.
FIG. 02 / NPB
8 → 1
The Risk
Most out-of-band tools have one or two input ports. Your network has SPAN traffic coming from dozens of switches. The math doesn't work, you either buy more tools (expensive) or you find a way to consolidate inputs.
The Fix
Use a SPAN Aggregator or Network Packet Broker to combine multiple SPAN inputs into a single feed. Three options depending on scale:
- Small ⁄ Up to 8 SPANsSPAN aggregator with built-in data diode design. Combine securely into one tool feed.
- Mid ⁄ 9+ SPANs10-port Network Packet Broker. Aggregates and feeds one or more tools.
- Mixed Speeds ⁄ 1G–100GAdvanced-features NPB. Adds load balancing, filtering, deduplication, packet slicing, time stamping, and media conversion.
Best Practice 03
Remote SPAN links are not out of reach.
The Risk
Your monitoring and security tools live at the data center. But you also need visibility into branch offices, remote plants, and distributed OT environments, places where deploying duplicate tools at every site isn't realistic, financially or operationally.
The Fix
Use a Network Packet Broker with Layer 2 GRE tunneling. An NPB at the remote site aggregates and encapsulates the local SPAN traffic, tunnels it across the network to a second NPB at the main site, which decapsulates and forwards everything to your centralized tool. Full remote visibility, no duplicated infrastructure.
FIG. 03 / L2 GRE
REMOTE → MAIN
[ Editorial Note ]
"SPAN is a usable technology if used correctly. Starting now is better than operating blindly."
— Garland Technology, on the right way to deploy SPAN
When SPAN is the right call.
SPAN works well for low-bandwidth, application-layer use cases, conversation analysis, application flow monitoring, and reporting where you don't need every single packet and microsecond timing isn't critical.
For those workloads, SPAN is reliable, cost-effective, and already built into your switches. There's no reason to over-engineer it.
For high-throughput security inspection, packet-level forensics, or any environment where dropping a packet matters, pair SPAN with the protections above, or consider a dedicated network TAP instead.
The bottom line: starting with SPAN is better than operating blindly. Just deploy it thoughtfully.