Hands-On Lab: Interconnecting MST and Rapid PVST+ Regions

This hands-on lab connects an MST region to a switch still running Rapid PVST+, verifying MST's built-in interoperability correctly represents the PVST+ switch's per-VLAN topology at the region boundary without requiring every switch in the network to migrate simultaneously.

MST to Rapid PVST+ InteroperabilityCIST BoundaryMixed STP Mode Migration

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Connect an MST region configured in an earlier lab to a separate switch still running Rapid PVST+, verify a stable boundary forms between the two spanning-tree modes without creating a loop, and confirm VLAN-specific topology information is correctly translated across that boundary.

Lab Purpose

Migrating an entire production network to MST simultaneously is rarely practical. MST was deliberately designed with backward compatibility in mind, allowing an MST region to interoperate directly with switches still running Rapid PVST+, supporting a gradual, switch-by-switch migration rather than requiring a disruptive flag-day cutover.

Lab Topology

Switch1, Switch2 (MST region "REGION1",
  configured in an earlier lab)
  ---- Gi1/0/2 ---- Switch3 (still running
                    Rapid PVST+, not part
                    of the MST region)

VLANs 10 and 20 exist on all three switches

Task 1: Verify Switch3's Current Mode

Confirm Switch3 is running Rapid PVST+, unchanged from earlier labs, while Switch1 and Switch2 remain in MST mode.

Task 2: Connect Switch3 to the MST Region

Ensure Switch2's interface toward Switch3 is properly trunked carrying VLANs 10 and 20, forming the boundary link.

Task 3: Verify the Boundary Forms Without a Loop

Confirm Spanning Tree on both sides correctly identifies a consistent root and no loop forms across the boundary.

Task 4: Verify Per-VLAN Topology Information Crosses the Boundary

Confirm Switch3, running Rapid PVST+, correctly sees consistent root bridge information for each of its individual VLAN instances, derived from the MST region's internal calculation.

Solution and Verification

Switch3# show spanning-tree summary | include Mode

Spanning tree enabled protocol rstp
-- Confirms Switch3 remains on Rapid PVST+,
-- unchanged

Switch2(config)# interface gigabitethernet1/0/2
Switch2(config-if)# switchport mode trunk
Switch2(config-if)# switchport trunk allowed vlan 10,20

Switch2# show spanning-tree mst 0

##### MST0    vlans mapped:   1-9,51-4094
Bridge   address 00aa.bb00.2222  priority 32768

Interface        Role Sts Cost      Prio.Nbr  Type
Gi1/0/2           Desg FWD 20000     128.2     P2p Bound(RSTP)
-- "Bound(RSTP)" explicitly marks this port
-- as a boundary port between the MST region
-- and a neighboring RSTP/PVST+ switch --
-- MST automatically recognizes and handles
-- this mixed-mode boundary

Switch3# show spanning-tree vlan 10

VLAN0010
  Spanning tree enabled protocol rstp
  Root ID    Priority    32768
             Address     00aa.bb00.2222
  -- Switch3 correctly identifies Switch2
  -- as root for VLAN 10, even though
  -- Switch2 does not run a separate VLAN 10
  -- instance internally -- MST derives
  -- this from its internal Instance 0 (IST)
  -- calculation and presents it correctly
  -- to the PVST+ neighbor

Switch3# show spanning-tree vlan 20

VLAN0020
  Spanning tree enabled protocol rstp
  Root ID    Priority    32768
             Address     00aa.bb00.2222
  -- Identical root information correctly
  -- presented for VLAN 20 as well, despite
  -- VLAN 20 being mapped to MST instance 1
  -- rather than 0 within the region itself

Switch2# show spanning-tree mst 0 detail | include loop|inconsistent

-- (no output -- no loop or inconsistency
--  detected at the boundary)

Key Takeaway

The "Bound(RSTP)" designation on a boundary port confirms MST is actively translating between its internal instance-based topology and the per-VLAN topology a Rapid PVST+ neighbor expects — this built-in interoperability is precisely what allows organizations to migrate to MST incrementally, switch by switch, rather than requiring every device in the network to convert simultaneously in a single high-risk maintenance window.

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

مقالات مرتبط

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.

ادامه