When interface counters and logs are not enough, packet analysis can show exactly what crossed a network device. Cisco SPAN technologies copy selected traffic to an analyzer without changing the original forwarding path.
The three common variants solve different placement problems: SPAN keeps the source and analyzer local, RSPAN extends the mirrored traffic across a Layer 2 domain, and ERSPAN carries mirrored traffic across an IP network.
ENCOR v1.2 includes SPAN, RSPAN and ERSPAN under Network Assurance. If a mirrored capture is unexpectedly empty, first verify the selected source interface and traffic direction; with RSPAN, trace the remote-span VLAN across the switches, and with ERSPAN, check the routed encapsulation path to the analyzer. A 350-401 packet-mirroring practice problem can distinguish a wrong source selection from failed mirror transport or analyzer loss. Seeing no packets at the destination alone does not identify which stage failed.
SPAN is the local mirroring model
Switched Port Analyzer, or SPAN, copies traffic from one or more selected sources to a destination used for analysis.
The source can be an interface or another supported object depending on the platform. The destination is the port or analysis endpoint that receives the copied packets.
A common use case is simple:
- a server is connected to one switch
- the engineer needs to inspect the traffic
- a laptop running Wireshark is connected to another port on the same switch
- a local SPAN session mirrors the server traffic to the analyzer port
That is the least complex option when the analyzer can be physically or logically attached to the same switch.
Local SPAN is often the best first choice because it adds the fewest transport dependencies. The source and destination remain on one device, so the engineer does not have to troubleshoot an RSPAN VLAN or an ERSPAN IP path before interpreting the capture.
The source can be chosen to match the scope of the problem. An interface source is useful for one endpoint or uplink. A VLAN source can be useful when the traffic of interest may enter or leave through several ports. Platform support and scale limits differ, so the capture plan should be checked against the actual switch rather than assuming every Catalyst model supports the same session combinations.
SPAN sources and directions must match the troubleshooting question
A mirror session can capture ingress, egress, or both directions depending on configuration and platform capabilities.
That choice matters.
If the engineer is troubleshooting what a host transmitted, ingress traffic on the switch port may be enough. If the question is what the network delivered back to the host, egress traffic also matters.
Mirroring both directions can provide the complete conversation, but it also increases the volume delivered to the analyzer.
The capture design should therefore start with the question, not with “mirror everything.”
Ingress and egress mirroring also have different semantics. Ingress shows what arrives at the switch before the device makes its forwarding decision. Egress shows the copy associated with traffic leaving a monitored interface. If the question involves packet drops, rewriting, or whether a frame ever reached the egress path, choosing only one direction can hide the answer.
Capturing both directions is convenient but can double the mirrored volume. On a busy full-duplex link, the combined source traffic can exceed the capacity of a single destination interface. The production traffic may continue normally while the analyzer silently misses copied packets, so a clean-looking capture is not proof that nothing else occurred.
The destination is for analysis, not normal switching
A SPAN destination is not an ordinary access port while it is being used as a monitor destination.
Cisco documentation emphasizes that the destination is dedicated to receiving mirrored traffic.
That makes operational planning important. Accidentally choosing a production-facing interface as a monitor destination can disrupt normal connectivity.
The copied packets also consume switch resources. Monitoring too many high-volume sources into one destination can oversubscribe the analyzer path and create dropped mirrored packets even while the original production traffic continues normally.
A capture is evidence, but only if the monitoring path can actually carry what you asked it to copy.
The monitor destination should therefore be treated as part of the diagnostic system. Verify its speed, link state, analyzer receive capability, and whether the monitoring session changes normal forwarding behavior on that port. A laptop connected to a 1-Gbps destination cannot faithfully receive a sustained copy of several multi-gigabit sources.
Timestamp quality can matter too. If the objective is to reconstruct a transient problem, synchronize the analyzer and the network’s logging systems so packet timestamps can be correlated with interface events, routing changes, or application logs.
RSPAN extends the capture across Layer 2
Remote SPAN solves the problem where the source and packet analyzer are on different switches but still inside a Layer 2 domain.
Instead of sending the mirrored traffic directly to a local analyzer port, RSPAN uses a special VLAN to transport the copied frames across the switching infrastructure.
That means the inter-switch path must carry the RSPAN VLAN.
The design also means RSPAN inherits Layer 2 dependencies. Trunks, VLAN propagation, spanning tree, and intermediate-switch behavior can affect the mirrored traffic path.
This is a useful contrast with ordinary 802.1Q trunking: RSPAN uses a VLAN as a transport mechanism for copied traffic, but the mirrored traffic itself is an analysis copy rather than a normal production conversation being switched end to end.
An RSPAN VLAN is a transport construct for mirrored traffic and must be carried through the switches between source and destination. That makes the trunk path part of the monitoring design. If the VLAN is pruned, blocked, mis-tagged, or missing on an intermediate switch, the packet analyzer can receive nothing even while the production path remains healthy.
Because the copied traffic traverses the Layer 2 domain, RSPAN also consumes bandwidth on those trunks. A wide capture can become a new load on the same switching infrastructure being investigated. The monitoring architecture should therefore be scoped narrowly enough that it does not create the congestion it is supposed to diagnose.
ERSPAN transports the copy across an IP network
Encapsulated Remote SPAN moves mirrored traffic through a routed network using GRE encapsulation.
That makes ERSPAN useful when the analysis system is not in the same Layer 2 domain.
The source device encapsulates the mirrored traffic so it can cross an IP path toward the ERSPAN destination.
Unlike RSPAN, ERSPAN reaches a remote analyzer over routed IP instead of requiring a dedicated VLAN to carry mirrored frames through a Layer 2 path.
- RSPAN depends on Layer 2 transport
- ERSPAN depends on Layer 3 reachability
ERSPAN encapsulates the mirrored copy so it can cross a routed IP network. That solves the analyzer-placement problem without extending a monitoring VLAN between sites. The routed path, however, now becomes a dependency: source and destination addressing, reachability, MTU, and any platform-specific ERSPAN requirements all matter.
Cisco’s current Catalyst 9000 support guidance also shows that ERSPAN capability and licensing vary by platform; for example, the Catalyst 9200 has documented limitations. Treat ERSPAN as a platform feature to validate, not as a generic command set that is identical on every switch.
Choose the mirror method by analyzer location
The decision can be simplified to topology.
Use SPAN when the source and analyzer are on the same switch.
Use RSPAN when they are on different switches but a suitable Layer 2 path exists between them.
Use ERSPAN when mirrored traffic needs to cross a routed IP network.
That is a better selection rule than treating ERSPAN as automatically “better” because it is more advanced.
Every extra transport layer introduces its own failure modes.
The best method is therefore the simplest one that places the packet copy where the analyzer can consume it. Local SPAN avoids transport complexity. RSPAN is appropriate when Layer 2 continuity already exists. ERSPAN is appropriate when a routed path is the practical way to reach a remote collector.
Do not choose a remote method just because the analyzer happens to be remote today. During a critical incident, temporarily moving the analyzer closer to the source can remove several variables and produce a more trustworthy capture.
Packet mirroring and flow telemetry answer different questions
SPAN technologies preserve packets for detailed inspection.
NetFlow summarizes traffic by flow attributes such as source, destination, protocol, ports and observed byte or packet counts. It can reveal a busy conversation or unexpected traffic pattern without recording a full application payload. If a packet-level hypothesis remains unresolved, a correctly placed authorized capture is still needed; a flow record alone cannot show the contents of a failed handshake.
Those tools complement each other.
NetFlow is efficient for questions such as which endpoints communicated, when, over which ports, and with what volume.
A packet mirror is better when the engineer needs protocol fields, TCP behavior, application details that are visible in the traffic, or exact packet-level evidence.
A common operational workflow is to use flow data to identify the interesting conversation and then use SPAN or ERSPAN to capture the packets needed for deeper analysis.
Packet mirroring also has a fidelity question that flow records do not. A capture can reveal sequence numbers, retransmissions, flags, protocol fields, and payload details that are visible before encryption. But a mirrored copy can still be incomplete because of destination oversubscription, hardware limitations, filtering, or an incorrect source direction.
For long-running visibility, summarized telemetry is usually cheaper to store and search. A common operational pattern is to use counters, assurance data, syslog, and flow telemetry to identify a time window and conversation, then activate a focused mirror session for the exact packet-level question.
Verification should include the monitoring path
A correct configuration is not enough if the analyzer receives nothing.
Verify:
- the session is active
- the intended source is selected
- the direction is correct
- the destination is correct
- the analyzer interface is up
- the RSPAN VLAN is carried through the Layer 2 path where applicable
- the ERSPAN destination is IP reachable where applicable
- the destination path is not dropping the mirrored traffic because of capacity limits
Cisco provides platform-specific commands such as show monitor session to inspect the configured session and operational state.
On Catalyst platforms, show monitor session is a useful first verification because it confirms the session type, sources, directions, and destinations that the software believes are active. If the configuration looks correct but packets still do not arrive, verify the intermediate RSPAN or ERSPAN path and, where appropriate, platform-level programming.
A disciplined capture record should note the source object, direction, destination, start and stop time, and any known capacity limitation. That context makes the resulting PCAP much easier to interpret later and prevents another engineer from assuming the capture was exhaustive when it was intentionally scoped.
Packet capture is a diagnostic tool, not a permanent substitute for monitoring
SPAN is excellent when an engineer needs packet-level truth.
It is less efficient as the only long-term visibility strategy because full packet capture can be high volume and operationally expensive.
Broader network visibility usually combines packet capture with counters, logs, flow records, assurance systems, and active tests.
That layered approach is consistent with Network Assurance: use the lightest data source that answers the question, then move to packet-level evidence when the problem actually requires it.
For ENCOR and for real troubleshooting, packet mirroring is a path-design problem as much as a command problem. Select the smallest source that answers the question, choose ingress or egress deliberately, make sure the analyzer path can carry the copy, and verify every transport dependency introduced by RSPAN or ERSPAN. A packet capture is trustworthy only when the monitoring path itself has been validated.