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.

StackWise Virtual Link ConfigurationSingle Logical SwitchDual-Active Detection

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

Lab Objective

Configure two physical switches as a StackWise Virtual pair using a dedicated SVL connection, verify they present as a single logical switch with one shared control plane, and confirm a Dual-Active Detection link correctly identifies a split-brain scenario if the SVL itself fails.

Lab Purpose

Unlike HSRP or VRRP, covered earlier in this series, which provide redundancy between two independently managed devices sharing a virtual IP, StackWise Virtual merges two physical chassis into one logical switch with a single control plane, single configuration, and single management point — a fundamentally different redundancy model worth distinguishing clearly from FHRP-based approaches.

Lab Topology

Switch1 ---- SVL (dedicated high-bandwidth
             link, e.g. TenGig1/0/1-2) ---- Switch2

Switch1 ---- DAD link (separate, lower
             bandwidth, e.g. Gi1/0/1) ---- Switch2

Both switches will merge into a single
logical switch identified as "Switch 1"
after configuration

Task 1: Designate Switch Domain and Switch Numbers

Configure a matching StackWise Virtual domain on both switches, with Switch1 as switch 1 and Switch2 as switch 2.

Task 2: Configure the SVL Interfaces

Designate the dedicated high-bandwidth ports as SVL links on both switches.

Task 3: Configure the Dual-Active Detection Link

Configure a separate link as the DAD (Dual-Active Detection) connection, distinct from the SVL itself.

Task 4: Reload Both Switches and Verify They Form a Single Logical Switch

Reload both switches and confirm they present as a single logical entity with one active supervisor role.

Task 5: Simulate an SVL Failure and Verify DAD Prevents a Split-Brain Condition

Shut down the SVL links while leaving the DAD link intact, and confirm the switches correctly detect the dual-active condition rather than both continuing to act as the active switch.

Solution and Verification

Switch1(config)# stackwise-virtual
Switch1(config-stackwise-virtual)# domain 1
Switch1(config)# switch 1 stackwise-virtual link 1

Switch2(config)# stackwise-virtual
Switch2(config-stackwise-virtual)# domain 1
Switch2(config)# switch 2 stackwise-virtual link 1

Switch1(config)# interface tengigabitethernet1/0/1
Switch1(config-if)# stackwise-virtual link 1
Switch1(config-if)# exit
Switch1(config)# interface tengigabitethernet1/0/2
Switch1(config-if)# stackwise-virtual link 1

Switch2 configured identically on its
corresponding TenGig1/0/1-2 interfaces

Switch1(config)# interface gigabitethernet1/0/1
Switch1(config-if)# stackwise-virtual dual-active-detection

Switch2(config)# interface gigabitethernet1/0/1
Switch2(config-if)# stackwise-virtual dual-active-detection

-- The DAD link is deliberately separate
-- from the SVL -- its sole purpose is
-- detecting whether the SVL itself has
-- failed, so it cannot share the same
-- physical path as what it is monitoring

Switch1# reload
Switch2# reload

Switch1# show switch

Switch/Stack Mac Address : 00aa.bb00.1111
                                              H/W   Current
Switch#  Role     Mac Address     Priority Version  State
-------------------------------------------------------
*1       Active   00aa.bb00.1111     1       V02     Ready
 2       Standby  00aa.bb00.2222     1       V02     Ready
-- Both physical switches now present as
-- a single logical "Switch," with one
-- Active and one Standby role -- a single
-- running-config and a single management
-- IP now govern both physical chassis

-- Simulating SVL failure while DAD remains up:

Switch1(config)# interface range tengigabitethernet1/0/1-2
Switch1(config-if-range)# shutdown

Switch2# show switch stack-ports

... SVL link down detected ...

Switch2# show logging | include DAD

%STACKMGR-4-DAD_DETECTED: Dual-active
condition detected via DAD link -- switch 2
transitioning to recovery mode
-- The DAD link successfully detected that
-- both switches might otherwise believe
-- themselves to be Active simultaneously
-- once the SVL failed -- one switch
-- automatically enters a recovery/
-- shutdown-of-non-critical-ports mode to
-- prevent both halves from actively
-- forwarding traffic as independent,
-- conflicting switches

Key Takeaway

StackWise Virtual's single logical switch model means a single configuration, a single management IP, and a single control plane spanning two physical chassis — a fundamentally different redundancy approach from the FHRP protocols (HSRP, VRRP, GLBP) covered earlier in this series, which keep two independently configured devices synchronized via a shared virtual IP; the dedicated DAD link exists specifically to prevent the dangerous split-brain scenario where an SVL failure could otherwise cause both physical switches to simultaneously believe they are the sole active member.

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

مقالات مرتبط

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.

ادامه