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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه