A switch normally sends each frame only to its destination — which is why you can't just plug a laptop in and see traffic. SPAN mirrors chosen ports or VLANs to an analyzer port so you can. Local SPAN, RSPAN across switches, and ERSPAN over IP — plus the oversubscription trap that makes captures lie.
Switches learn where each MAC lives and forward frames only there — great for performance, inconvenient when you need to watch traffic that isn't destined for you. SPAN (Switched Port Analyzer) is the built-in answer: tell the switch to duplicate the frames from one or more source ports or VLANs onto a destination port, where a Wireshark laptop, an IDS sensor (Snort/Suricata/Zeek), or a DPI appliance can see everything. No hardware tap, no cabling change.
Three flavours cover the distances: local SPAN when the analyzer is on the same switch, RSPAN when it's on a different switch (the copy rides a dedicated VLAN across trunks), and ERSPAN when it's across a routed network (the copy is GRE-encapsulated over IP). This is where our two hats meet — the same mirror we set up for a customer's IDS is the one we ask for during incident response to see what an attacker is actually doing on the wire. One gotcha, oversubscription, makes the difference between a capture you can trust and one that silently lies; it gets its own section.
01
The simplest case: source and analyzer on one switch. Two lines — a source and a destination — and you're capturing.
# Mirror BOTH directions of Gi0/1 to the analyzer on Gi0/24 SW1(config)# monitor session 1 source interface GigabitEthernet0/1 both SW1(config)# monitor session 1 destination interface GigabitEthernet0/24 SW1(config)# end # Or mirror an entire VLAN's traffic (great for an IDS watching a segment) SW1(config)# monitor session 2 source vlan 10 rx # rx = received only SW1(config)# monitor session 2 destination interface GigabitEthernet0/23 # Confirm the session SW1# show monitor session 1 Session 1 Type : Local Session Source Ports Both : Gi0/1 Destination Ports : Gi0/24
Once an interface is a SPAN destination, it does one thing: spit out mirrored frames. It drops incoming traffic and no longer participates in the network — so don't SPAN to a port that a real device (or your own management path) relies on, and don't be surprised when the analyzer laptop can't reach the internet through it. Plan a dedicated port. Also note both mirrors tx+rx, which can double the volume — see oversubscription (section 04). Use rx or tx when you only need one direction.
02
When the analyzer sits on a different switch, RSPAN carries the mirrored copy over a dedicated VLAN that rides your existing trunks. A source session on one switch, a destination session on the other, joined by a special RSPAN VLAN.
# On EVERY switch in the path, define the special RSPAN VLAN SW1(config)# vlan 199 SW1(config-vlan)# remote-span SW1(config-vlan)# exit # (and allow VLAN 199 on the trunks between the switches) # SOURCE switch — mirror the port INTO the RSPAN VLAN SW1(config)# monitor session 1 source interface GigabitEthernet0/1 both SW1(config)# monitor session 1 destination remote vlan 199 # DEST switch (SW2) — pull the RSPAN VLAN OUT to the analyzer port SW2(config)# monitor session 1 source remote vlan 199 SW2(config)# monitor session 1 destination interface GigabitEthernet0/24
RSPAN silently fails if any switch on the path between source and destination is missing the remote-span VLAN or doesn't allow it on the interconnecting trunks. The mirror traffic just doesn't arrive and there's no obvious error — you sit at the analyzer seeing nothing. Define the RSPAN VLAN on every switch in the path and add it to each trunk's allowed list (the allowed-VLAN discipline again). RSPAN traffic also consumes real bandwidth on those trunks — a busy source port's mirror competes with production traffic on the uplinks.
03
When the analyzer is L3 hops away — a central SOC, a cloud IDS — ERSPAN wraps the mirrored frames in GRE and routes them over IP. Router/L3-switch feature; the shape is similar with source and destination IPs.
R1(config)# monitor session 1 type erspan-source R1(config-mon-erspan-src)# source interface GigabitEthernet0/1 both R1(config-mon-erspan-src)# destination R1(config-mon-erspan-src-dst)# erspan-id 101 R1(config-mon-erspan-src-dst)# ip address 10.50.0.10 # the collector R1(config-mon-erspan-src-dst)# origin ip address 10.1.0.1 # this router R1(config-mon-erspan-src-dst)# no shutdown R1(config-mon-erspan-src-dst)# end # The collector (or a matching ERSPAN-destination session) decapsulates # the GRE and hands the original frames to the analyzer. Now you can mirror # a branch's traffic to an IDS at HQ — across the WAN.
04
The gotcha that makes captures lie. A 1 Gbps destination port cannot carry more than 1 Gbps of mirrored traffic — and mirroring several busy ports (or both directions of one) easily exceeds that. The switch quietly drops the overflow, and your capture is missing packets you'll never know about.
# Example: mirror 4 ports, "both" directions, each ~600 Mbps at peak.
# 4 ports x 600 Mbps x 2 directions = 4.8 Gbps of mirror traffic
# ...into a single 1 Gbps destination port. ~80% is DROPPED.
# Your IDS sees a fraction of reality and reports "all clear" — falsely.
# Check whether the destination is overrun (drops climbing = trouble):
SW1# show interfaces GigabitEthernet0/24 counters | include Discard|drop
SW1# show monitor session 1
Three ways to keep a capture honest. Narrow the source — mirror one port or one direction (rx/tx), not everything both. Use a faster destination — a 10G analyzer port for aggregated sources. Or filter — some platforms support monitor session … filter vlan or ACL-based SPAN to copy only the traffic you care about. For serious full-fidelity capture (line-rate forensics, high-throughput IDS), a dedicated hardware network tap beats SPAN — it can't oversubscribe and doesn't compete with switch resources. SPAN is perfect for troubleshooting and moderate IDS feeds; know its ceiling before you trust a "nothing found."
05
Confirm the session, watch for drops, and — importantly — remove the session when you're done. A forgotten SPAN quietly burns a port and switch resources for months.
| Command | Does |
|---|---|
| show monitor session all | Every SPAN/RSPAN/ERSPAN session — including ones you forgot. |
| show monitor session 1 | Sources, destination, direction for one session. |
| show interfaces Gi0/24 counters | Destination drops — the oversubscription check. |
| no monitor session 1 | Tear it down and give the port back. |
| no monitor session all | Remove every session at once (cleanup). |
Switches cap the number of active SPAN destination/source sessions (often just two), so an old forgotten session can block you from creating the one you need now — show monitor session all first. And a SPAN destination is a security exposure: anyone with access to that port sees mirrored traffic. Treat it like a tap — physically secured, removed after the engagement, and never left connected to an unattended jack. "Temporary" mirrors have a way of becoming permanent surprises in someone else's audit.
06
RouterOS mirrors too, via a switch/bridge setting or a sniffer stream; the mental model matches.
| MikroTik / RouterOS | Cisco IOS |
|---|---|
| /interface ethernet switch (mirror-source/target) | Local SPAN (monitor session) |
| /tool sniffer streaming to a remote host | ERSPAN (GRE to a collector) |
| Mirror to a port for Wireshark | SPAN destination interface |
| Switch-chip mirror limits | SPAN session limits + oversubscription |
Takeaways
remote-span VLAN on the trunks), ERSPAN (across a routed network via GRE-over-IP).show monitor session all, secure the destination like a tap, and remove sessions when done.NOCTIS sets up SPAN/RSPAN feeds into intrusion detection and captures for troubleshooting and incident response — sized so the mirror doesn't drop what matters. From the team that also knows what an attacker's traffic looks like on that wire.
Book a Discovery Call →