Configuring ERSPAN (Encapsulated Remote SPAN) for Remote Packet Capture FAQ: Expert Answers to Technical & Deployment Questions

Overview & Thematic Scope

ERSPAN (Encapsulated Remote SPAN) enables network engineers to transport mirrored traffic across Layer 3 boundaries for remote packet analysis, intrusion detection, and performance monitoring. This FAQ addresses the most common pre-sales and post-sales questions about ERSPAN configuration, covering encapsulation mechanics, deployment best practices, and troubleshooting in enterprise and datacenter environments.

Frequently Asked Questions

Q1: What is ERSPAN and how does it differ from local SPAN?

ERSPAN (Encapsulated Remote SPAN) is a Cisco-developed protocol that encapsulates mirrored traffic in GRE (Generic Routing Encapsulation) and routes it over an IP network to a remote destination. Unlike local SPAN, which copies traffic to a port on the same switch, ERSPAN allows packet capture across Layer 3 boundaries, enabling centralized monitoring in distributed networks. It uses a special ERSPAN header within the GRE payload to preserve original VLAN, priority, and timestamp information.

Q2: Which platforms and software versions support ERSPAN configuration?

ERSPAN is supported on most Cisco Catalyst, Nexus, and ASR platforms, as well as select third-party switches that implement the protocol. On Cisco IOS, use the monitor session type erspan-source command; on NX-OS, use monitor session with type erspan-source. Version 1 (Type II) is widely supported, while ERSPAN Type III adds timestamping and is available on newer Nexus and Catalyst 9000 series. Always verify platform-specific documentation for exact syntax and hardware limitations.

Q3: How do I configure an ERSPAN source session on a Cisco switch?

Configure an ERSPAN source session by defining the source interfaces or VLANs, specifying the destination IP address of the capture target, and setting the ERSPAN session ID. Example on IOS: monitor session 1 type erspan-source, source interface Gi1/0/1 both, destination, erspan-id 1, ip address 192.0.2.10, origin ip address 192.0.2.1. On NX-OS: monitor session 1 type erspan-source, source interface Ethernet1/1 both, destination, erspan-id 1, ip address 192.0.2.10, origin ip address 192.0.2.1. Ensure the destination IP is reachable and the egress interface supports the encapsulated MTU.

Q4: What MTU considerations apply to ERSPAN encapsulated traffic?

ERSPAN adds a GRE header (4 bytes), an outer IP header (20 bytes), and an ERSPAN header (8 bytes for Type II, 12+ bytes for Type III), increasing packet size by at least 32 bytes. If the original packet is 1500 bytes, the encapsulated packet becomes 1532 bytes, requiring an MTU of at least 1554 bytes on the transport path to avoid fragmentation. Configure jumbo frames (MTU 9216) on all transit interfaces and the destination capture device to prevent drops and ensure reliable capture of full-sized packets.

Q5: How does ERSPAN handle packet loss and latency during remote capture?

ERSPAN uses best-effort UDP-like delivery over GRE; it does not retransmit lost packets, so network congestion or policers can cause capture gaps. Latency depends on the path between source and destination—typically sub-millisecond in datacenter fabrics but can increase over WAN links. To minimize loss, use dedicated QoS queues, avoid oversubscribed uplinks, and monitor interface counters for drops. For time-sensitive analysis, ERSPAN Type III provides hardware timestamping to improve accuracy.

Q6: Can ERSPAN be secured to prevent unauthorized packet capture?

Yes. Secure ERSPAN by restricting source and destination IPs via ACLs, using dedicated VRF or management VLANs for transport, and enabling encryption where supported. Some platforms support ERSPAN over IPsec or MACsec for confidentiality. Additionally, disable ERSPAN sessions when not in use, audit configuration changes, and limit CLI access to authorized engineers. Note that ERSPAN itself does not encrypt payloads; encryption must be applied at the transport layer.

Q7: What are common ERSPAN configuration errors and how do I troubleshoot them?

Common errors include unreachable destination IP, MTU mismatch causing fragmentation, incorrect ERSPAN ID mismatch between source and destination, and source interface not in the correct VLAN. Troubleshoot by checking show monitor session all for session state, verifying IP reachability with ping, confirming MTU with show interface, and inspecting capture device logs for GRE decapsulation errors. Ensure the destination device supports ERSPAN decapsulation and has the correct ERSPAN ID configured.

Q8: Does ERSPAN support high-availability and redundancy for critical capture?

ERSPAN itself does not provide built-in redundancy, but you can achieve high availability by configuring multiple ERSPAN destinations or using redundant source switches with VPC/M-LAG. Some platforms support ERSPAN destination redundancy via anycast IP or load balancing across capture appliances. For mission-critical monitoring, deploy dual ERSPAN sessions to separate collectors and use link aggregation or ECMP to distribute traffic. Always test failover scenarios to ensure continuous capture during link or device failures.