Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

ERSPAN GRE EncapsulationLayer 3 Traffic MirroringCross-Routed-Domain Monitoring

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure ERSPAN on a source device to encapsulate mirrored traffic inside GRE and route it across a Layer 3 network to a remote destination device, verifying a capture tool connected far beyond the reach of any single trunk still receives the mirrored traffic.

Lab Purpose

RSPAN, covered in the previous lab, is still fundamentally constrained to a single Layer 2 domain — the RSPAN VLAN must be trunked hop-by-hop across every intermediate switch. ERSPAN removes this constraint entirely by encapsulating mirrored traffic inside GRE, discussed earlier in this series, allowing it to be routed across any Layer 3 topology to a destination anywhere reachable by IP.

Lab Topology

Switch1 (ERSPAN source)
  Gi1/0/1 ---- PC-A (traffic to monitor)
  Loopback0: 10.0.0.1/32 (ERSPAN source IP)

Switch2 (ERSPAN destination, several routed
         hops away from Switch1, no direct
         Layer 2 trunk between them)
  Loopback0: 10.0.0.2/32 (ERSPAN destination IP)
  Gi1/0/10 ---- Capture-Laptop

Underlay routing already provides
reachability between the two loopbacks

Task 1: Verify Underlay Reachability

Confirm the two loopback addresses can reach each other across the routed network.

Task 2: Configure the ERSPAN Source Session on Switch1

Configure a monitor session with Gi1/0/1 as the source, encapsulating into ERSPAN with a unique flow ID and the destination IP.

Task 3: Configure the ERSPAN Destination Session on Switch2

Configure a monitor session on Switch2 receiving ERSPAN traffic with the matching flow ID and forwarding it to the local capture port.

Task 4: Verify Traffic Is Mirrored Across the Routed Network

Generate traffic on PC-A and confirm the capture laptop connected to Switch2 receives it, despite the two switches having no direct Layer 2 connection.

Task 5: Examine the Encapsulation on the Wire

Confirm the mirrored traffic actually traverses the network as GRE-encapsulated IP packets between the two loopback addresses.

Solution and Verification

Switch1# ping 10.0.0.2 source loopback0

!!!!!
Success rate is 100 percent (5/5)
-- Underlay reachability confirmed before
-- configuring ERSPAN

Switch1(config)# monitor session 1 type erspan-source
Switch1(config-mon-erspan-src)# source interface gigabitethernet1/0/1
Switch1(config-mon-erspan-src)# destination
Switch1(config-mon-erspan-src-dst)# erspan-id 100
Switch1(config-mon-erspan-src-dst)# ip address 10.0.0.2
Switch1(config-mon-erspan-src-dst)# origin ip address 10.0.0.1

-- erspan-id acts as a session identifier
-- distinguishing multiple concurrent ERSPAN
-- sessions traveling between the same or
-- different device pairs -- both ends must
-- agree on this value

Switch2(config)# monitor session 1 type erspan-destination
Switch2(config-mon-erspan-dst)# destination interface gigabitethernet1/0/10
Switch2(config-mon-erspan-dst)# source
Switch2(config-mon-erspan-dst-src)# erspan-id 100
Switch2(config-mon-erspan-dst-src)# ip address 10.0.0.2

-- The destination session listens for
-- ERSPAN traffic addressed to its own
-- loopback (10.0.0.2), matching the
-- configured erspan-id, then de-encapsulates
-- it and forwards the original frames out
-- the local capture port

PC-A> ping 192.168.1.1

-- Capture-Laptop connected to Switch2,
-- running Wireshark:

Wireshark capture shows:
  ICMP Echo Request from PC-A's MAC/IP
  ICMP Echo Reply destined to PC-A's MAC/IP
-- Despite Switch2 being several routed
-- hops away with no shared VLAN or trunk
-- at all connecting it to Switch1, the
-- capture laptop still receives a complete
-- copy of PC-A's traffic

-- Examining raw traffic on an intermediate
-- router along the path (conceptual):

IntermediateRouter# show ip traffic | include GRE
-- GRE packets observed flowing from
-- 10.0.0.1 to 10.0.0.2 -- confirming the
-- mirrored Ethernet frames are riding
-- inside GRE-encapsulated IP packets,
-- exactly as GRE tunnels covered earlier
-- in this series encapsulate other traffic
-- types for routing across an IP network

Key Takeaway

ERSPAN's use of GRE encapsulation, the same tunneling mechanism covered earlier in this series for extending Layer 2 or building point-to-point overlays, is what liberates remote traffic mirroring from any Layer 2 adjacency requirement entirely — RSPAN from the previous lab still needed a trunked path for its dedicated VLAN, while ERSPAN needs only ordinary IP reachability between source and destination, making it the correct choice whenever the monitored traffic and the capture point are separated by a routed, multi-hop Layer 3 network.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue

Hands-On Lab: Configuring StackWise Virtual

This hands-on lab configures two physical switches into a single logical StackWise Virtual switch using a dedicated Stackwise Virtual Link, verifying both members present as one control plane and that a member failure triggers predictable failover behavior.

Continue