Catalyst 3850: stack two switches and add a member safely

27 April 2026

In short. Match the IOS-XE version and mode on both switches before they ever see each other. Cable the two stack ports as a ring. Power on the member you want as master first, set switch 1 priority 15 in EXEC mode, then power on the second and set it to 12. Renumber if the slot numbers came out wrong, and reload. show switch and show switch stack-ports tell you whether it worked.

I have two Catalyst 3850s and want one stack with a predictable master

You bought two used WS-C3850-12X48U and want them to behave as one switch with cross-stack port-channels. You have probably also typed switch 1 priority 15 inside configure terminal and been told it is not a command. This is the sequence I use at every site. The reasons the priorities are the same everywhere and the hostname is a full FQDN are in the decision post at the end.

What you need

Two WS-C3850-12X48U, both on IOS-XE 16.12 and both in install mode. Check with show version on each before cabling anything. If they differ, upgrade the odd one out on its own first; there is a separate post on that.
Two StackWise-480 cables. One cable makes a chain with half the bandwidth and no ring redundancy; use two.
A console cable on at least the first switch, because the second will not have a management address until it is a member.
A reload window. Renumbering takes effect only after a reload, and the second switch reloads when it joins.

flowchart TB
  subgraph ST["Stack ring, two StackWise cables"]
    S1["Switch 1<br/>priority 15, master"]
    S2["Switch 2<br/>priority 12"]
    S1 -- "stack port 1 to stack port 2" --> S2
    S2 -- "stack port 1 to stack port 2" --> S1
  end
  C["Jumphost serial console"] -.-> S1

Steps

Confirm both switches match. On each, show version prints a table with a Mode column that reads INSTALL or BUNDLE, and the version string. Both must be identical. A member on a different version will either sit in a boot loop or try to auto-upgrade, and auto-upgrade with several members is not something I rely on.
With both switches powered off, cable the ring: stack port 1 on switch 1 to stack port 2 on switch 2, and stack port 2 on switch 1 to stack port 1 on switch 2. Seat the connectors until the thumbscrews bite; a half-seated StackWise cable is the most common reason a port shows DOWN later.
Power on only the switch you want as master. Let it boot fully and log in on the console. Set its priority in EXEC mode, not in config mode. This is the trap: priority is stored in the stack's ROMMON variables, not in the running configuration, so the command lives outside configure terminal.

sw-a.site.example# switch 1 priority 15
WARNING: Changing the switch priority may result in a configuration change for that switch.
Do you want to continue?[y/n]? [yes]: yes

Power on the second switch. Watch the first switch's console: it will log the new member discovering the stack, the version check, and the member reaching Ready. This takes a few minutes. If the member reloads once on joining, that is normal; if it keeps reloading, the versions did not match, so power it off and go back to step 1.
Set the second member's priority, again in EXEC mode on the master:

sw-a.site.example# switch 2 priority 12

Check the slot numbers. If the second switch came from another stack it may have joined as switch 3, or claimed switch 1 and pushed yours to 2. Renumber from the master and reload the renumbered member:

sw-a.site.example# show switch
sw-a.site.example# switch 3 renumber 2
sw-a.site.example# reload slot 3

Interface names follow the slot number, so get this right before you configure any ports. TenGigabitEthernet2/0/1 means slot 2, and if slot 2 becomes slot 3 later every port-channel member reference breaks.

Set the hostname to the site's full FQDN and save. The prompt then says where you are, which is the point.

sw-a.site.example# configure terminal
sw-a.site.example(config)# hostname sw-a.site.example
sw-a.site.example(config)# end
sw-a.site.example# write memory

Do not add a third member in the same session. One at a time, each after the previous one shows Ready, and each with its version checked first. Two members joining at once is how you get two switches each deciding it is the master of a stack of one.

Verify it worked

show switch is the summary. Both members should be Ready, the master marked with an asterisk, and the priorities as you set them:

sw-a.site.example# show switch
Switch/Stack Mac Address : 0c1e.aaaa.0001 - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Switch#   Role    Mac Address     Priority Version  State
-------------------------------------------------------------------------------------
*1       Active   0c1e.aaaa.0001     15     V07     Ready
 2       Standby  0c1e.aaaa.0002     12     V07     Ready

show switch stack-ports should show every stack port OK. A port in DOWN with the cable in means a bad seat or a bad cable; swap and check again before going further.

show version from the master should now list both switches in the table, same version, same mode. Finally, show interfaces status should list ports from both slots, which confirms the slot numbers you expect.

Gotchas

switch N priority is an EXEC command. Typing it under configure terminal fails, and it is not in show running-config either, so a config push from the repository does not set it. The deploy notes for each site record it separately.
Priority changes take effect at the next election, not immediately. The current master stays master until a reload or a failure. show switch shows the priority straight away, which can mislead you into thinking a failover has happened.
Renumbering does not move configuration. Interface configuration for slot 3 stays written as slot 3 after you renumber it to 2. Do the renumber before any port configuration, or be ready to rewrite it.
Auto-upgrade (software auto-upgrade enable) sounds like the solution to version mismatch. With one member it sometimes works; with more it has left me with a half-upgraded member that would not boot. Upgrade separately, then join.
The stack MAC follows the master by default. stack-mac persistent timer 0 keeps the stack MAC fixed across a master change so your port-channel partners do not see a new system ID mid-failover. Set it once, in config mode, and save.

FAQ

Why 15 and 12 rather than 15 and 1? Any two different values give a deterministic master. Using 12 for the second member leaves room to slot a third member between or below without renumbering priorities everywhere, and the same pair at every site means nobody has to look it up.

Does the second switch need its own configuration first? No, and it should not have one. If it has a startup configuration from a previous owner, it may try to bring it along. Erase it with write erase and reload before cabling, so the stack master's configuration is the only one.

Can I stack two switches on different IOS-XE releases and sort it out after? In principle the master can push its image to the member. In practice, in install mode with several members, I have watched it fail. Match first. It costs one extra upgrade and saves an evening.