SPAN (Switched Port Analyzer) is Cisco's port-mirroring technology that copies traffic from one or more source ports, VLANs, or EtherChannels to a destination port for analysis. RSPAN (Remote SPAN) extends this across switches over a dedicated VLAN, and ERSPAN tunnels the mirrored traffic over Layer 3 using GRE. Most Cisco IOS platforms cap you at 2-4 active sessions per switch, the default capture direction is both (rx and tx), and a destination port stops carrying normal traffic the moment you assign it to a session.
A few years back, an IDS rolled into a distribution layer with executive sponsorship and a six-figure price tag. Two weeks in, the security team noticed near-zero alerts on a network with several thousand users. The cause was one keyword: monitor session 1 source interface gi0/24 rx. That rx meant the SPAN was only mirroring inbound traffic — the half of every conversation that triggers most IDS signatures was never reaching the sensor. A six-figure appliance was sniffing one side of every phone call.
That is SPAN and its remote sibling RSPAN in a sentence: simple to configure, easy to misconfigure, and absolutely critical when something goes wrong because you suddenly need packet captures and you need them now. Most networks have several SPAN sessions running concurrently for IDSs, NDR appliances, APM tools, and the occasional Wireshark capture. Each one is a single keyword away from being useless.
Spanning tree decides which links carry traffic. SPAN decides which traffic gets copied for inspection. The two layers don't compete — they work together — but they fail differently. SPAN failures are quiet: traffic still flows, the configuration looks fine, but the analyzer sees nothing because of one wrong keyword.
EVE-NG solves half that problem by letting you build enterprise-grade network labs in software. CloudMyLab solves the other half by hosting those labs so you don't have to hear your cooling fans scream.
CloudmyLab is EVE-NG's official and only cloud partner.
Here's a how to using a ready-made network topology from EVE-NG's Lab Library, hosted where it belongs: in the cloud.
Lab 1-5 from EVE-NG's Switching series walks you through three distinct port-mirroring scenarios: local SPAN within a single switch, VSPAN sourcing from a VLAN instead of specific ports, and RSPAN across switches using a dedicated mirror VLAN. You'll configure each, validate that traffic actually arrives at your monitoring destination, and discover the surprising number of ways port mirroring can quietly fail without throwing an error.
Here's what you're actually testing:
both when you omit the keyword, which is what you almost always want.The lab specifically highlights the difference between SPAN sessions that work as expected and SPAN sessions that appear to work but quietly drop frames or miss directions. Both look identical in show monitor session output. You only catch the difference by sending known traffic patterns and comparing what arrives at the destination against what you sent — which is exactly the validation the lab forces you to do.
Before configuring anything, here is how the three port-mirroring variants compare on the dimensions that matter operationally:
| Variant | Scope | Encapsulation | Use case | Cisco IOS support |
|---|---|---|---|---|
| SPAN | Single switch (local) | None — raw L2 frames | Sensor or sniffer in the same chassis | All Catalyst, IOSvL2 |
| RSPAN | Across switches (L2 only) | Dedicated RSPAN VLAN over trunks | Centralized analyzer in one closet, sources elsewhere | Most Catalyst, IOSvL2 |
| ERSPAN | Across L3 boundaries | GRE tunnel over IP | Mirror across data centers, sites, or routed cores | Catalyst 9000, Nexus, ASR (not IOSvL2) |
If you're capturing within one switch, SPAN is fine. If your analyzer lives in a different closet but on the same L2 domain, you need RSPAN and a clean trunk path. If you've got a routed core between sources and the analyzer, only ERSPAN survives the trip. CloudMyLab's hosted EVE-NG gives you a multi-switch topology where you can validate SPAN and RSPAN end-to-end before committing to a sensor placement that's hard to change once the appliance is racked.
The Lab 1-5 topology continues the distribution/access design from earlier labs in the series, which matters because RSPAN explicitly requires a multi-switch environment to demonstrate properly.
Core components:
Key configuration elements:
remote-span on every switch in the pathTopology adapted from the EVE-NG Lab Library.
This mirrors what most production deployments look like: a sensor or analyzer in one location, source traffic happening somewhere else, and an RSPAN VLAN ferrying mirrored frames across the campus. The lab's value is letting you prove the whole path works before you commit to a sensor placement that's hard to change once the analyzer is racked.
This workflow assumes you've completed Lab 1-1 or at least know your way around a Cisco CLI. If you're using CloudMyLab's hosted EVE-NG, the topology is pre-loaded and the full lab takes 45-60 minutes. Build local SPAN first, verify it, then move to RSPAN — debugging multiple sessions at once is the fastest way to lose track of which configuration caused which symptom.
On AS-1, identify the source port (say, gi0/1) and the destination port (gi0/24, where your packet capture host connects). Configure the session:
monitor session 1 source interface gi0/1 both monitor session 1 destination interface gi0/24
The both keyword captures rx and tx, which is what you almost always want. (Remember the IDS story.) Verify with show monitor session 1. The source and destination should be listed cleanly. Generate test traffic — pings, file transfer, anything — and confirm the destination port sees both directions.
Now deliberately break it. Change the source to monitor session 1 source interface gi0/1 rx. Run the same test traffic and observe that the destination only sees inbound traffic on gi0/1, not outbound. This is the silent failure mode that ate two weeks of IDS alerts in the intro story. Seeing it once in the lab means you'll recognize it on sight the next time someone reports their sensor is "missing things."
Configure a VLAN-based SPAN session on AS-1:
monitor session 2 source vlan 10 monitor session 2 destination interface gi0/23
This mirrors all traffic in VLAN 10 to gi0/23. Generate traffic between hosts in VLAN 10 and watch it arrive at the destination. Now generate sustained heavy traffic and watch what happens — drops, the moment aggregate VLAN traffic exceeds the destination port's capacity. VSPAN is the easiest way to accidentally oversubscribe a SPAN destination, and seeing the failure mode in the lab means you won't reproduce it in front of a customer.
This is the multi-switch scenario, and it's where most of the interesting failures live. First, create the dedicated RSPAN VLAN on every switch in the path (AS-1, DS-1, DS-2):
vlan 999 remote-span exit
Verify the RSPAN VLAN is allowed on every trunk between source and destination switches. This is the single most common RSPAN failure point — if your trunks have allowed-VLAN restrictions, the RSPAN VLAN won't propagate, and you'll spend an hour wondering why your capture is empty.
On the source switch (AS-1), configure the RSPAN source:
monitor session 3 source interface gi0/2 both monitor session 3 destination remote vlan 999
On the destination switch (DS-2), configure the RSPAN destination:
monitor session 3 source remote vlan 999 monitor session 3 destination interface gi0/24
Generate traffic on gi0/2 of AS-1 and confirm it arrives at gi0/24 of DS-2. If it doesn't, walk the path: is VLAN 999 allowed on every trunk? Is it actually configured as remote-span on every switch? Is the destination switch hearing traffic in VLAN 999 at all (show vlan id 999 and show mac address-table vlan 999)? Each of these has been the answer in real production troubleshooting more times than is comfortable to admit.
Cisco platforms cap simultaneous SPAN sessions tightly — typically 2 source sessions plus 2 destination sessions per switch, though the exact number varies by platform (Catalyst 9000 raises this, ASR drops it). Configure additional sessions until you hit the limit and observe the error messages. Knowing the cap matters when production already has an IDS, an NDR sensor, and an APM tool all asking for SPAN feeds, and someone wants to add a fourth.
Once everything works, save it. Use the EVE-NG snapshot feature to preserve the known-good state. This becomes your reference configuration for production deployment — every parameter that's right is documented, and you can compare future production configs against it line by line when something inevitably stops working.
Running SPAN labs locally is technically possible. Local SPAN doesn't need much, but RSPAN does — at least three switches in a multi-switch path with consistent trunk configurations. That's three IOSvL2 instances plus a capture host, which is enough to make a typical laptop unhappy.
CloudMyLab's hosted EVE-NG removes those constraints (see Lab 1-1 STP & RSTP on EVE-NG for the full breakdown of hosted benefits).
For SPAN and RSPAN specifically, the hosted environment matters because:
Snapshot-and-revert workflow. SPAN configuration is exactly the kind of thing you want to break repeatedly to learn the failure modes. Configure a working session, snapshot, change one parameter, observe the failure, revert, try a different break. By the end of a lab session you'll recognize the symptoms of every common SPAN misconfiguration on sight.
Multi-user packet captures. Have your security engineer connect to the destination port from one location while your network engineer generates traffic from another. Both watch the capture in real time. This is much closer to how production troubleshooting actually works than solo lab sessions.
No oversubscription anxiety. Accidentally configuring a VSPAN that mirrors gigabits to a 100 Mb destination port in production gets you angry users. In the lab, it gets you an interesting demonstration of what a SPAN-induced bottleneck looks like, with zero production impact.
SPAN and RSPAN are the technologies you reach for when you need to actually see what's happening on your network. They're also the technologies most likely to be misconfigured in subtle ways that don't reveal themselves until you genuinely need them.
We'll provision Lab 1-5 from EVE-NG's Lab Library with your specific source/destination requirements. You'll work through every variant — local SPAN, VSPAN, RSPAN — with deliberate failures along the way, before the next security incident asks you to pull packet captures under pressure.
No hardware required. No local resource constraints. Just working SPAN behavior you can verify, document, and use as a reference when you deploy the real thing.
SPAN (Switched Port Analyzer) is Cisco's port-mirroring feature that copies traffic from one or more source ports, VLANs, or EtherChannels to a destination port for analysis. The destination port is typically connected to a packet capture tool, IDS, or network analyzer. The default direction is both, meaning rx and tx are mirrored unless you specify otherwise.
SPAN mirrors traffic within a single switch. RSPAN extends mirroring across multiple switches using a dedicated VLAN over Layer 2 trunks. ERSPAN encapsulates the mirrored traffic in a GRE tunnel so it can cross Layer 3 boundaries — useful for sending captures across data centers or routed cores.
Most Cisco Catalyst platforms support 2 to 4 active SPAN sessions simultaneously, typically split between source and destination roles. The exact limit depends on the platform — Catalyst 9000 series supports more, while smaller switches and IOSvL2 are tighter. Check show monitor session and the platform's data sheet before adding the fourth tool that wants a SPAN feed.
No. Once a port is configured as a SPAN destination, it stops participating in normal switching — it does not run spanning tree, learn MAC addresses, or carry user traffic. It only forwards mirrored frames toward the connected analyzer. This is why you cannot reuse a SPAN destination as a regular access or trunk port without first removing the session.
Ingress (rx) SPAN copies traffic entering the source port. Egress (tx) SPAN copies traffic leaving it. The default direction is both, which captures rx and tx together — almost always what you want. Configuring rx-only or tx-only is the most common silent SPAN failure: the session works, but the analyzer only sees half the conversation.
Yes. This is called VSPAN (VLAN-based SPAN). It mirrors all traffic in a specified VLAN to the destination port instead of selecting individual member ports. VSPAN is convenient for capturing entire segments without tracking port membership, but it makes oversubscribing the destination port easy because aggregate VLAN traffic can far exceed the destination port's capacity.
Use RSPAN when the source ports and the analyzer live on different switches but share the same Layer 2 domain. RSPAN ferries mirrored frames across trunks via a dedicated VLAN, so a single sensor in one closet can monitor sources spread across the campus. Local SPAN cannot cross the chassis boundary; RSPAN can, as long as you keep the RSPAN VLAN allowed on every trunk in the path.
SPAN itself is hardware-assisted on most modern Cisco platforms and adds minimal CPU overhead. The risk is at the destination port, not the switch CPU: if you mirror more aggregate traffic than the destination port can carry, frames are dropped silently. Heavy SPAN configurations also count against forwarding ASIC resources on some platforms, which is why the per-switch session limit exists.