Lab Objective
Configure three switches into a traditional StackWise stack using dedicated stack cables, verify a stack master is elected and all members share a single management plane, then intentionally renumber a member and observe its effect on interface naming.
Lab Purpose
StackWise Virtual, covered in the previous lab, uses Ethernet-based SVL links allowing member switches to be located in different racks or even different rooms. Traditional StackWise stacking, by contrast, uses dedicated proprietary stack cables limiting members to close physical proximity, but remains widely deployed and important to understand as a distinct technology with its own master election behavior.
Lab Topology
Switch1 ---- stack cable ---- Switch2 ---- stack cable ---- Switch3
(physically adjacent, connected in a ring
via dedicated StackWise cabling, not
Ethernet interfaces)Task 1: Verify Physical Stack Cabling
Confirm all three switches are connected via dedicated stack cables in a ring topology.
Task 2: Power On the Stack and Observe Master Election
Power on all three switches simultaneously and observe which becomes stack master.
Task 3: Verify the Stack Presents as a Single Management Entity
Confirm a single console session and management IP govern all three physical switches.
Task 4: Examine Interface Naming Convention
Confirm interfaces are named with a stack member number as the first digit (e.g., Gi2/0/1 for a port on member 2).
Task 5: Renumber a Stack Member and Observe the Effect
Change Switch3's stack member number and confirm its interfaces are renamed accordingly after a reload.
Solution and Verification
-- Physical stack cables connect Switch1's
-- stack port to Switch2's, Switch2's second
-- stack port to Switch3's, and Switch3's
-- remaining port back to Switch1's,
-- forming a resilient ring rather than a
-- simple daisy chain-- All three switches powered on simultaneously
Switch# show switch
Switch/Stack Mac Address : 00aa.bb00.3333
H/W Current
Switch# Role Mac Address Priority Version State
-------------------------------------------------------
1 Member 00aa.bb00.1111 1 V02 Ready
2 Member 00aa.bb00.2222 1 V02 Ready
*3 Master 00aa.bb00.3333 1 V02 Ready
-- Master election in traditional StackWise
-- considers priority first (all equal here),
-- then factors including uptime and MAC
-- address -- Switch3 won this particular
-- election, shown by the asteriskSwitch# show running-config | include hostname
hostname Switch
-- A single hostname and single running
-- configuration govern all three physical
-- units, accessed through a single console
-- or management session regardless of
-- which physical switch is actually console
-- cabledSwitch# show interfaces status | include connected
Gi1/0/1 connected
Gi2/0/1 connected
Gi3/0/1 connected
-- The leading digit in each interface name
-- identifies which physical stack member
-- that port belongs to -- Gi2/0/1 is on
-- the switch currently numbered "2" in the
-- stack, regardless of its role (master or
-- member)Switch(config)# switch 3 renumber 4-- After a reload:
Switch# show switch
Switch# Role Mac Address Priority Version State
-------------------------------------------------------
1 Member 00aa.bb00.1111 1 V02 Ready
2 Member 00aa.bb00.2222 1 V02 Ready
*4 Master 00aa.bb00.3333 1 V02 Ready
Switch# show interfaces status | include connected
Gi1/0/1 connected
Gi2/0/1 connected
Gi4/0/1 connected
-- The switch previously numbered 3 is now
-- numbered 4, and every one of its
-- interfaces was renamed accordingly
-- (Gi3/0/1 became Gi4/0/1) -- any ACL,
-- VLAN assignment, or other interface-
-- specific configuration referencing the
-- old interface names would need updating
-- after a renumbering operation like thisKey Takeaway
Traditional StackWise renumbering directly changes every affected member's interface names, unlike StackWise Virtual's switch numbering from the previous lab, which similarly affects interface naming but across an SVL rather than dedicated stack cables — in both stacking technologies, renumbering a member is a disruptive operation worth planning carefully, since any configuration referencing the old interface identifiers (ACLs, port-channel members, VLAN assignments) will silently reference the wrong, now-renamed interface unless updated as part of the same maintenance window.