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.

RSPAN VLAN ConfigurationCross-Switch Traffic MirroringRemote Monitoring Session

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure an RSPAN VLAN carried across a trunk between two switches, mirror traffic from a source port on Switch1 into that RSPAN VLAN, and verify a capture device connected to Switch2 — with no direct physical connection to the monitored port — receives a copy of the mirrored traffic.

Lab Purpose

The local SPAN lab covered earlier in this series required the capture device to be physically connected to the same switch as the monitored port. RSPAN removes this constraint by carrying mirrored traffic across a special-purpose VLAN over a trunk, allowing centralized packet capture from any switch in the network without needing a laptop physically present at every switch being monitored.

Lab Topology

Switch1
  Gi1/0/1 ---- PC-A (traffic to monitor)
  Gi1/0/24 ---- trunk to Switch2

Switch2
  Gi1/0/24 ---- trunk to Switch1
  Gi1/0/10 ---- Capture-Laptop (running
                Wireshark)

RSPAN VLAN: 999 (dedicated, carries no
            normal user traffic)

Task 1: Create the RSPAN VLAN on Both Switches

Create VLAN 999 on both switches, explicitly marked as an RSPAN VLAN.

Task 2: Ensure the RSPAN VLAN Is Allowed on the Trunk

Confirm VLAN 999 is permitted across the trunk connecting the two switches.

Task 3: Configure the Source Session on Switch1

Configure a monitor session on Switch1 with Gi1/0/1 as the source and the RSPAN VLAN as the destination.

Task 4: Configure the Destination Session on Switch2

Configure a monitor session on Switch2 with the RSPAN VLAN as the source and Gi1/0/10 as the destination.

Task 5: Verify Traffic Is Mirrored Across Switches

Generate traffic on PC-A and confirm the capture laptop on Switch2 receives a copy.

Solution and Verification

Switch1(config)# vlan 999
Switch1(config-vlan)# remote-span

Switch2(config)# vlan 999
Switch2(config-vlan)# remote-span

-- "remote-span" marks this VLAN
-- specifically for RSPAN traffic --
-- switches automatically prevent normal
-- MAC learning and regular traffic
-- flooding within an RSPAN VLAN, since
-- its sole purpose is carrying mirrored
-- copies

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# switchport trunk allowed vlan add 999

Switch2(config)# interface gigabitethernet1/0/24
Switch2(config-if)# switchport trunk allowed vlan add 999

Switch1(config)# monitor session 1 source interface gigabitethernet1/0/1
Switch1(config)# monitor session 1 destination remote vlan 999

-- Unlike local SPAN's destination
-- interface, here the destination is the
-- RSPAN VLAN itself -- mirrored traffic
-- is flooded into this VLAN and carried
-- across the trunk to reach Switch2

Switch2(config)# monitor session 1 source remote vlan 999
Switch2(config)# monitor session 1 destination interface gigabitethernet1/0/10

-- Switch2's session pulls FROM the RSPAN
-- VLAN as its source, and sends that
-- traffic to the local capture port

Switch1# show monitor session 1

Session 1
---------
Type                   : Remote Source Session
Source Ports           :
    Both               : Gi1/0/1
Dest RSPAN VLAN        : 999

Switch2# show monitor session 1

Session 1
---------
Type                   : Remote Destination Session
Source RSPAN VLAN      : 999
Destination Ports      : Gi1/0/10

PC-A> ping 192.168.1.1

-- Meanwhile, on Capture-Laptop connected
-- to Switch2's Gi1/0/10, running Wireshark:

Wireshark capture shows:
  ICMP Echo Request from PC-A's MAC/IP
  ICMP Echo Reply destined to PC-A's MAC/IP
-- The capture laptop, physically connected
-- to an entirely different switch than
-- PC-A, still receives a complete copy of
-- PC-A's traffic -- the mirrored frames
-- traveled across the trunk inside VLAN
-- 999 to reach it

Key Takeaway

RSPAN splits a single SPAN session, covered in an earlier lab, into two coordinated halves — a source session on the switch where the monitored port lives, and a destination session on the switch where the capture device is connected — bridged by a dedicated RSPAN VLAN carried across an ordinary trunk, letting network monitoring be centralized at one or a few capture points rather than requiring physical presence at every switch of interest.

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 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.

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