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 loopbacksTask 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 ERSPANSwitch1(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 valueSwitch2(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 portPC-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 networkKey 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.