CCNP ENCOR 350-401: How to Configure and Verify SPAN, RSPAN, and ERSPAN

Introduction

Some problems only make sense when you inspect the packets instead of guessing from symptoms. That is why Cisco SPAN, RSPAN, and ERSPAN matter in real enterprise operations and on the CCNP ENCOR 350-401 exam. They are all members of Cisco’s switched port analyzer feature family, but they solve different visibility problems: local monitoring on the same switch, remote monitoring across Layer 2, and remote monitoring across Layer 3.

For ENCOR, Cisco expects you to differentiate them, configure and verify them at a practical level, and troubleshoot the usual failure points. The key idea is simple: a capture is only as trustworthy as the observation point. Mirrored traffic is copied traffic, and what you see depends on where the switch made that copy, how it transported it, and whether the analyzer or collector can actually receive and decode it.

SPAN vs RSPAN vs ERSPAN at a Glance

Fast decision rule:

Same switch = SPAN. Different switch with Layer 2 continuity = RSPAN. Routed path to remote collector = ERSPAN.

Platform Support and Syntax Variations

This is the caveat that saves people from bad change windows: support is highly platform- and release-specific. Do not assume that because a device runs IOS XE it supports every SPAN, RSPAN, or ERSPAN option. Catalyst 9K support differs from older Catalyst families. NX-OS syntax and capabilities differ from IOS XE. VLAN-based SPAN, port-channel SPAN, ERSPAN source support, ERSPAN destination support, and filtering features all vary.

That means two things for the exam and the field. First, understand the transport model and dependencies more than one exact command syntax. Second, I’d always check the configuration guide, release notes, or support matrix for your exact switch model and software release before you touch production. It’s boring work, sure, but it saves you from finding out the hard way that your shiny new feature isn’t actually supported the way you assumed.

The usual trouble spots are pretty predictable, honestly: physical versus logical interfaces, trunks versus access ports, VLAN-based source support, port-channel behavior, routed ports, stack members, and whether the platform can actually originate or terminate ERSPAN. That last one trips people up more often than it should. Even verification commands can vary. Commands such as show monitor session, show monitor session all, show vlan remote-span, and hardware-specific show platform outputs are useful, but not universally identical.

Packet Path Analysis and Observation-Point Logic

I like to break each method into three simple pieces: where the copy gets made, how it moves, and where it finally gets consumed. Keep that mental model straight, and the whole thing gets a lot less mysterious.

With local SPAN, the switch just makes a local copy of the traffic from the source interface or VLAN and hands that copy off to a destination port on the same switch. Nothing fancy there, which is exactly why it’s so useful. With RSPAN, the source switch copies traffic and injects that copy into a dedicated remote-span VLAN, which traverses trunks until another switch maps it to an analyzer port. With ERSPAN, the source device encapsulates mirrored traffic for IP transport to a remote collector or receiver.

Direction matters. On Cisco platforms, rx generally means ingress to the switch on the source, tx means egress from the switch on that source, and both captures both directions. Exact visibility can still vary by platform and ASIC pipeline, especially for switched versus routed traffic.

Also remember what mirroring does not guarantee. Standard SPAN primarily reflects traffic handled in the relevant forwarding path. CPU-generated, punted, exception, or control-plane traffic may be limited or absent depending on platform behavior. Likewise, a single capture point does not prove downstream drops unless you capture at the right places for comparison.

How SPAN Works and What It Really Shows

Local SPAN is the simplest form of traffic mirroring. The switch copies matching frames from a source and forwards those copies to a monitor destination port on the same switch. The original traffic still follows the normal forwarding decision; the mirrored copy is separate from production forwarding.

Supported source types commonly include physical interfaces and, on some platforms, VLANs or port-channels. Support for logical interfaces and exact combinations varies. If you monitor a port-channel, some platforms mirror the logical bundle, while others have caveats around member links and forwarding distribution. That matters when you are trying to understand why only part of a flow appears in the capture.

VLAN-based SPAN is especially platform-dependent. It does not mean “all traffic everywhere” in a universal sense; it means traffic associated with that VLAN as supported by the platform’s forwarding architecture. Tagged frame handling, routed traffic visibility, and source-to-destination restrictions can differ.

SPAN is useful for validating whether packets reach a given observation point, whether markings such as DSCP are present there, whether retransmissions are visible there, and whether one direction is missing there. It does not automatically prove what happened farther downstream.

Destination Port Behavior and Restrictions

A SPAN destination port is generally a receive-only monitor port from the analyzer’s perspective. It does not behave like a normal user-facing switchport and typically does not participate in normal switching. You should not expect to pass production traffic through it, authenticate users on it, or use it as a regular access port.

Depending on platform, destination-port behavior can include restrictions on ingress handling, encapsulation options, speed/duplex combinations, and coexistence with other features. Some platforms support options to preserve VLAN tagging toward the analyzer, while others present traffic differently. If your analyzer expects tagged frames but the platform strips or rewrites them, your interpretation can be wrong even though the session itself is working.

Promiscuous mode on the analyzer NIC is usually required for local SPAN captures. On the analyzer side, verify the selected adapter, driver state, capture filters, and link speed. A perfectly configured SPAN session can still produce an empty trace because the wrong NIC was selected or the analyzer is filtering out the traffic.

Configuring and Verifying Local SPAN

Basic interface SPAN example:

monitor session 1 source interface Gi1/0/10 both monitor session 1 destination interface Gi1/0/24 — that’s the line that tells the switch where to send the mirrored copy.

That copies both inbound and outbound traffic for Gi1/0/10 over to Gi1/0/24, so your analyzer can actually see what’s happening in both directions. If you only need ingress to the switch, use rx. If you only need traffic leaving the switch toward that source, use tx.

Multiple-source example on platforms that support it:

monitor session 1 source interface Gi1/0/10 both monitor session 1 source interface Gi1/0/11 both monitor session 1 destination interface Gi1/0/24 — that’s the line that tells the switch where to send the mirrored copy.

Trunk-source example:

monitor session 2 source interface Gi1/0/48 both monitor session 2 destination interface Gi1/0/25

VLAN-based SPAN example where supported:

monitor session 3 source vlan 120 both monitor session 3 destination interface Gi1/0/26

Verification commands commonly include:

show monitor session 1 show monitor session all show interfaces status

Representative output will always depend on the platform, so I’d treat the example as a guide, not gospel:

Session 1 — assuming the platform reports it that way, of course. Type Local Session Source Ports : Both : Gi1/0/10 Destination Ports : Gi1/0/24 Status : up

If the session looks fine but the capture’s empty, I’d check four basics in order: make sure the source is right, make sure the direction is right, confirm the destination port is actually usable, and then verify the analyzer NIC is really receiving traffic. In my experience, it’s usually one of those four — and usually the first two.

How RSPAN Works

RSPAN extends monitoring across Layer 2 by using a dedicated remote-span VLAN. The source switch copies traffic and places the mirrored frames into that VLAN. The trunks carry that VLAN across the campus, and then the destination switch picks up the RSPAN VLAN and hands the mirrored traffic off to a local analyzer port. That’s the handoff point you care about.

The design rules matter. That remote-span VLAN should be used only for mirrored traffic, not for user data. Mixing the two is asking for confusion later, and maybe a bad day too. It has to be allowed consistently on every trunk in the path. Miss one hop, and the whole thing falls apart. STP state, trunk allowed lists, pruning behavior, and simple VLAN consistency all play into whether the mirrored copy actually reaches the far-end switch. That’s where people get tripped up — the monitor session is fine, but the transport path isn’t.

Don’t treat the RSPAN VLAN like a normal production VLAN. It’s doing a very specific job, and if you start thinking of it like user traffic, you’ll eventually create a mess. MAC learning and forwarding behavior around remote-span VLANs can be platform-specific, so don’t assume every Catalyst behaves exactly the same way. For exam purposes, the dependency you must remember is simple: if the RSPAN VLAN is missing, pruned, blocked, or not configured as remote-span where required, the session fails even though the monitor syntax may look fine.

Configuring and Verifying RSPAN

Create the remote-span VLAN on the relevant switches:

vlan 120 remote-span

Source switch session:

monitor session 10 source interface Gi1/0/10 both monitor session 10 destination remote vlan 120

Destination switch session:

monitor session 10 source remote vlan 120 monitor session 10 destination interface Gi1/0/24

Useful verification commands include:

show monitor session 10 show interfaces trunk show spanning-tree vlan 120 show vlan remote-span

show vlan remote-span is helpful where supported, but not universal. The important checks are that VLAN 120 exists as an RSPAN VLAN where required, is allowed on every trunk hop, and is in a forwarding STP state along the active path.

In a multi-switch campus path, validate every hop. A realistic workflow is:

1. Confirm the source session mirrors into the remote VLAN.
2. Confirm the first trunk allows VLAN 120.
3. Confirm each intermediate trunk carries VLAN 120.
4. Confirm STP is forwarding for VLAN 120.
5. Confirm the destination switch has the remote VLAN source mapped to the analyzer port.

Cleanup guidance: remove the monitor sessions first. Only remove the RSPAN VLAN if you have confirmed it was created solely for that temporary use and is not part of any other monitoring workflow.

How ERSPAN Works

ERSPAN is for remote monitoring across Layer 3. On Cisco platforms, ERSPAN usually carries mirrored traffic inside GRE with ERSPAN-specific headers, but the exact header format, session type, and syntax can vary by platform and software release. That’s one of those details you really don’t want to guess at. Collector compatibility matters a lot, because not every tool decodes every ERSPAN variant the same way. I’ve seen more than one “broken” ERSPAN session that turned out to be a collector problem.

At a high level, the source device makes the mirror, wraps it for IP transport, and sends it off to a remote collector or receiver. Simple idea, but there are enough moving parts to keep you honest. Reachability from the source to the collector matters. ACLs, firewalls, QoS treatment, and MTU matter. Path symmetry is not the key issue for the mirrored stream; the important requirement is that the source can send the encapsulated traffic to the receiver and that the receiver can decode it.

ERSPAN is common in centralized monitoring, remote branch troubleshooting, and security workflows. It is also the method most likely to fail because someone assumed support, syntax, or collector behavior instead of validating it.

Configuring and Verifying ERSPAN

Use platform-qualified guidance here, not blind memorization. Example syntax differs significantly across supported Catalyst and NX-OS platforms. If a loopback is used as the source identity, name it correctly, such as Loopback0, not an invalid shorthand.

Conceptual prerequisites for ERSPAN:

1. The platform supports ERSPAN source or destination roles as needed.
2. The source has IP reachability to the collector.
3. ACLs or firewalls permit the ERSPAN transport method in use.
4. Path MTU can carry the encapsulated mirrored traffic, or you understand the fragmentation risk.
5. The receiver can decode the ERSPAN type your platform sends.

Typical verification workflow:

show monitor session show monitor session all show ip route 10.10.10.50 — I’d use that to confirm the source box actually knows how to get to the collector. ping 10.10.10.50 source 192.0.2.10 — a quick sanity check to prove the path is there from the right source address.

If the platform supports a loopback-origin model, using Loopback0 as the source IP is operationally cleaner because it stays stable as long as routing to it exists.

Collector guidance is critical. ERSPAN receivers are often Linux hosts, packet brokers, security appliances, or tools explicitly configured to receive GRE/ERSPAN traffic. A generic laptop plugged into a local SPAN port is not the same thing as an ERSPAN receiver. On a Linux collector, you can validate arrival with a packet capture command that tells you whether traffic is even making it to the box in the first place. That’s a good early check before you blame ERSPAN.

tcpdump -ni any host 10.10.10.50 — that’s a quick way to see whether packets are showing up on the collector at all.

Then confirm the tool can decode ERSPAN, not just see outer GRE/IP packets.

ERSPAN Transport, MTU, and Fidelity Considerations

ERSPAN adds encapsulation overhead. The outer IP, GRE, and ERSPAN headers all add overhead, so mirrored packets can end up larger than the original frame size. That’s easy to forget until MTU starts causing grief. If the routed path MTU is too small, the mirrored traffic may get fragmented or dropped, depending on the device behavior and the network policy in the path. That’s one of those unglamorous causes that wastes a lot of time if you don’t check it early.

That is why an ERSPAN session can be administratively present yet still produce incomplete captures under load. The source may be sending, but intermediate devices may fragment, rate-limit, or drop the encapsulated copy. This does not necessarily mean production traffic is failing; it means the mirrored copy is losing fidelity.

Security matters too. ERSPAN traffic is generally not encrypted by default. If you send mirrored payloads across untrusted infrastructure, you may expose credentials, tokens, session cookies, sensitive application data, or regulated information. If confidentiality matters, protect the transport with appropriate network design controls rather than assuming ERSPAN itself is secure.

Troubleshooting by Symptom — because honestly, that’s how most of these issues show up in the real world.

Practical runbook: verify the session, verify that source traffic exists, verify the transport path, verify the analyzer or collector, then verify platform support. That order separates configuration problems from transport problems and receiver problems quickly.

Performance and Scale Considerations

Mirroring is not free. Broad captures can stress ASIC replication resources, congest destination ports, saturate RSPAN trunks, overload ERSPAN collectors, or fill capture storage quickly. If you mirror a busy 10G source to a 1G destination, the mirrored copies can drop even while production forwarding remains healthy.

That distinction matters: dropped mirrored traffic does not automatically mean dropped production traffic. To improve fidelity, reduce the mirrored scope, choose a closer observation point, narrow direction, avoid unnecessary VLAN-wide captures, and use a collector or destination with enough capacity. Some platforms support filtering or selective mirroring, but not all do, so verify feature support before relying on it.

Security, Compliance, and Operational Risk

Mirrored traffic is sensitive by definition. It may contain usernames, passwords, cookies, bearer tokens, email contents, voice payloads, internal application data, and regulated information. Limit physical and logical access to analyzer ports and collectors. Document who can start captures, where files are stored, and how long they are retained.

For security investigations, preserve chain-of-custody details: time of capture, source being mirrored, session ID if applicable, collector identity, and retention location. For ERSPAN in particular, remember that the mirrored traffic is typically not encrypted by default, so routed transport across shared or untrusted networks requires additional protection and policy review.

Practical Use Cases

Voice issue: Mirror the phone or uplink observation point and verify RTP directionality and DSCP markings. If you only mirror tx on the wrong interface, one-way audio can look like a network mystery when it is really a capture mistake.

Application timeout: Use local SPAN near the server to confirm SYN, SYN-ACK, resets, or retransmissions. If the server-side capture looks clean, move the observation point upstream rather than assuming the application is fine end to end.

Security investigation: Use ERSPAN to a central collector when the suspicious host is remote and no local analyzer is available. Validate routing, ACLs, MTU, and collector decode before the incident gets urgent.

ENCOR Exam Tips and Scenarios

What Cisco is really testing here is not one perfect syntax block. It is whether you understand the transport method, source and destination roles, dependencies, and verification workflow.

High-yield memory table:

SPAN = local switch.
RSPAN = Layer 2 transport via remote-span VLAN.
ERSPAN = Layer 3 transport via IP encapsulation.

Common exam traps:

1. Treating a SPAN destination like a normal access port.
2. Forgetting that the RSPAN VLAN must be dedicated and carried end to end.
3. Assuming ERSPAN works just because the session exists, without checking routing, MTU, ACL/firewall policy, and collector compatibility.
4. Confusing rx and tx.
5. Assuming IOS XE and NX-OS syntax are interchangeable.

Quick scenario cues:

Analyzer on same switch as the source host? SPAN.
Analyzer on another switch, same Layer 2 campus path? RSPAN.
Collector in a data center across a routed WAN? ERSPAN.

Command recall worth knowing:

show monitor session show monitor session all show interfaces trunk show spanning-tree vlan <id> show ip route ping <destination> source <origin>

Conclusion

Use SPAN for local visibility, RSPAN for remote visibility across Layer 2, and ERSPAN for remote visibility across Layer 3. Then verify in the same order every time: the session, the transport, the analyzer or collector, and the platform support details. If you remember that the mirrored copy is shaped by the observation point and the transport path, you will troubleshoot these features more accurately and answer ENCOR scenario questions with much more confidence.