Ruckus ICX Stacking: stack enable, Secure Setup and Roles

Ruckus ICX switches stack with a two-command workflow that is unusual compared to
Cisco or Juniper: stack enable on the unit you want in charge, then
stack secure setup, which actively walks the stacking cables, discovers the
neighbours and asks you to confirm them. The switched-on units reboot into the stack with a
default port configuration. This article covers the full sequence, the licence and port
requirements that gate it, the election and priority model, and the verification commands that
prove the stack is healthy rather than merely formed.

Prerequisites: Licences and Stacking Ports

ICX stacking does not always use dedicated ports. On models such as the ICX 7250, stacking
runs on ports in the second slot — for example 1/2/1 and 1/2/3 — which require the 10 GbE
on-demand licence to be enabled. The relevant licence for stacking is often the two-port
variant, so you may not need the full eight-port licence.

# Check what is licensed before you plan the cabling
show license
show license capacity

Requirements to satisfy before starting:

• Stacking-capable ports on the intended units, licensed if required
• Correct stacking cables — the vendor-specific high-bandwidth cables, not generic DACs
  unless the model explicitly supports them
• Units powered off during initial cabling, or brought up deliberately one at a time
• All units at compatible firmware levels

Step 1: Enable Stacking on the Intended Active Unit

SSH@3K_ICX> enable
SSH@3K_ICX# configure terminal
SSH@3K_ICX(config)# stack enable

stack enable instructs the unit to participate in stacking and, as a side
effect, disables optical monitoring on the ports used for stacking. If those ports previously
carried traffic, they will not any more — plan the change.

SSH@3K_ICX(config)# exit
SSH@3K_ICX# write memory

Step 2: Discover the Other Units

SSH@3K_ICX# stack secure setup

This command runs from privileged EXEC mode and actively probes the stacking cables to find
candidate members, then prompts you to include them:

Found the following units:
  unit 2  ICX7250-48   (connected on 1/2/21 <-> 2/2/21)
  unit 3  ICX7250-48   (connected on 2/2/23 <-> 3/2/21)
Do you accept the topology? [yes/no]

Answer yes and the process assigns unit IDs, sets the local unit's stack priority to 128,
runs an election, and instructs the other units to reboot into the stack with default port
configurations. Existing configuration on the non-active units is effectively reset for ports —
do this before you build out access ports, not after.

SSH@3K_ICX# show stack

Expected output shows all units present, the active unit identified, and the topology
(port-to-port connections). The standby unit is elected within about a minute; the output tells
you how many seconds remain until the election completes.

Step 3: Understand the Roles

• Active — runs the control plane, owns the stack MAC address. The unit that
  ran stack secure setup gets priority 128 and therefore wins the election.
• Standby — synchronised, ready to take over. Hitless failover is enabled by
  default in current code, which means the standby inherits the stack MAC, IP addressing and
  configuration so the rest of the network does not have to relearn anything.
• Member — forwarding only.

The shared stack MAC is the important design detail: access switches and upstream routers
keep the same ARP and MAC entries after a failover, so an active-unit failure is a short
convergence event rather than a complete relearn.

Step 4: Tune Priorities for Deterministic Failover

SSH@3K_ICX(config)# stack unit 1
SSH@3K_ICX(config-unit-1)# priority 200
SSH@3K_ICX(config-unit-1)# exit

SSH@3K_ICX(config)# stack unit 2
SSH@3K_ICX(config-unit-2)# priority 150
SSH@3K_ICX(config-unit-2)# exit

SSH@3K_ICX# show stack

Higher priority wins. Give the intended active and standby distinctly higher values than
the members so a newly added unit (default priority 0) can never take over.

Step 5: Verify and Monitor

SSH@3K_ICX# show stack
SSH@3K_ICX# show stack detail
SSH@3K_ICX# show stack port
SSH@3K_ICX# show stack neighbors
SSH@3K_ICX# show running-config | begin stack
SSH@3K_ICX# show interface ethernet 1/2/21

Then verify from the data plane, not just the control plane:

# From a downstream device
ping <stack-management-ip> repeat 100
show mac-address-table | include <downstream-mac>     # should be reachable via the stack

• A unit that shows in show stack but not in show stack port has a
  cable or port problem on one leg of the ring.
• Ring topology is preferred: a single cable failure does not split the stack. Verify the
  topology field actually reports a ring.
• Watch for a unit repeatedly rejoining — that is usually an under-rated or faulty stacking
  cable, not a firmware issue.

Operating a Stack

• Configuration is stack-wide. Interface commands use unit/slot/port notation —
  ethernet 2/1/3 is unit 2, slot 1, port 3. Confusing a member's port numbering with
  the standalone convention is the usual cause of an accidental shutdown.
• Firmware upgrades are stack-wide and reboot members in sequence. Schedule the window even
  though failover is hitless.
• Keep a physical record of unit IDs and cabling. Replacing a failed unit requires the
  replacement to take the same unit ID, and that is far easier with a diagram.
• Spanning tree should treat the stack as one bridge; per-port edge protection still applies
  and is worth configuring —
  Extreme EXOS stacking configuration guide and ArubaOS-CX VSF stack member roles show how the same problems are solved on adjacent platforms, and LACP fallback and static LAG configuration covers bonding across stack members towards downstream devices.

原文链接：https://rgnets.com/manual/network/wired/ruckus