Summary Explains how a Meraki MS stack elects its Active member, how port numbering differs between classic MS and Meraki-managed Catalyst switches, why the dashboard member number and the IOS-XE interface number disagree, why port configuration cannot migrate between members on reboot, and what happens to a three-switch stack when a member fails.
Anyone coming from Catalyst StackWise arrives with two expectations that do not hold on Meraki MS.
The first is that stack members receive persistent numbers — switch 1, switch 2, switch 3 — which can be set manually and which survive reboots. Meraki has no equivalent. There is no member number to assign, no stack priority to configure, and no switch renumber command. What Meraki has instead is a role election that produces one Active member and a set of Members.
The second is that stacking renumbers the ports into a single continuous scheme — GigabitEthernet1/0/1, GigabitEthernet2/0/1, and so on. On classic MS switches Meraki does not do this either: each switch keeps its own identity and its own ports numbered 1 to N, exactly as it was before stacking.
Both differences follow from the same design decision: on Meraki the stack is a data-plane construct, while management remains per-switch in the dashboard.
Meraki-managed Catalyst switches are the exception to the second point, and they are the source of most of the confusion in this area. They keep their IOS-XE interface names, switch number included — but that number is not the same thing as the dashboard's stack member number, and the two routinely disagree. This is covered under Port Numbering below.
| Type | What it is | Models |
|---|---|---|
| Virtual stacking | A management convenience — filter and configure ports across many switches at once. No physical link, no redundancy. | All MS models |
| Physical stacking | Dedicated rear stacking ports joined by stacking cables. Provides data-plane redundancy. | MS210, MS225, MS250, MS350, MS355, MS390, MS410, MS450, C9300/L/X |
| Flexible stacking | No dedicated stack ports; any front SFP+ or QSFP+ port can be designated as a stack port. 10 Gb/s minimum. | MS420, MS425 |
Up to eight switches can be stacked. Only like models may be stacked together, with two exceptions: MS210 and MS225 can share a stack, and the C9300X is backward compatible with the C9300 series.
Virtual stacking is worth separating out clearly because the name misleads. It gives no redundancy whatsoever — it is a dashboard filter that lets you push a port configuration to hundreds of ports at once regardless of where those switches physically sit.
Stacking cables are connected in a ring. With all switches powered off and links disconnected, the pattern is that each switch's stack port 1 connects to the next switch's stack port 2, and the last switch closes the loop back to the first.
For three switches:
SW1 stack port 1 ----> SW2 stack port 2
SW2 stack port 1 ----> SW3 stack port 2
SW3 stack port 1 ----> SW1 stack port 2 <-- closes the ring
+---------------------------+
| |
v |
+----------+ |
| SW1 | |
+----------+ |
| |
v |
+----------+ |
| SW2 | |
+----------+ |
| |
v |
+----------+ |
| SW3 |---------------------+
+----------+
Power on all three and allow several minutes for firmware download — the switches may reboot during this. Once the power LEDs are solid, the dashboard will usually detect and auto-provision the stack. If it does not, the stack can be created manually under Switching > Monitor > Switch stacks.
⚠️ Close the Ring: A stack cabled as a chain rather than a ring will function, but it has no redundancy in the stacking path. The consequence in a three-switch stack is severe and is covered in the failure section below. Closing the ring costs one extra cable and is the single most valuable thing you can do for stack resilience.
Only one uplink is required to bring the stack up. Additional uplinks can and should be added afterwards.
One switch acts as the Active member, handling stack-wide functions such as spanning tree. The election follows two rules:
| Condition | Outcome |
|---|---|
| All members powered up at roughly the same time | The switch with the lowest MAC address becomes Active |
| Members powered up at different times | The switch with the highest uptime becomes Active, regardless of MAC address |
The Active switch remains Active until it is rebooted, or until an event forces a re-election — reconnecting stack ports, for example. There is no preemption: a switch with a lower MAC address rejoining the stack will not take the role back.
The practical consequence is that the Active member is not predictable from the rack layout. After a power outage where all three come up together, it will be the lowest MAC. After replacing the top switch, it will be whichever of the other two has been running longest. Do not assume the top switch in the rack is Active.
From MS 15.18 onward the role is shown on the switch details page under Switching > Monitor > Switches, in the switch stack section of the left-hand column:
| Role | Meaning |
|---|---|
| Active | Runs the stack-wide control functions |
| Standby | Takes over if the Active fails — MS390 and Catalyst stacks only |
| Member | Ordinary member |
On MS models other than the MS390, there is one Active and everything else is a Member. There is no Standby, so recovery from an Active failure is an election rather than a pre-warmed handover.
Port numbering works differently on classic MS switches and on Meraki-managed Catalyst switches. The two need to be treated separately.
Stacking does not renumber anything. Each switch keeps its own ports numbered 1 to N.
A port is identified by the pair of the switch it belongs to and its port number on that switch. In the dashboard there are two routes to a port, and both preserve this:
Switching > Switches, select a switch, then the Ports tab — shows that switch's ports, 1 to N.Switching > Switch ports — lists every port in the network, with a column identifying which switch each belongs to.The detailed port view labels the column simply "Port #", described as the port number on the switch. There is no member prefix and no stack-wide sequence.
So in a three-switch stack of MS250-48s, you do not get ports 1 to 144. You get three switches each with ports 1 to 48, distinguished by switch name:
Catalyst StackWise Meraki MS stack
------------------ ---------------
GigabitEthernet1/0/1 ... 1/0/48 SW-FLOOR1-A port 1 ... 48
GigabitEthernet2/0/1 ... 2/0/48 SW-FLOOR1-B port 1 ... 48
GigabitEthernet3/0/1 ... 3/0/48 SW-FLOOR1-C port 1 ... 48
This has a useful side effect. Because port identity is tied to the switch rather than to a position in the stack, it does not shift when the Active role moves or when a member is replaced. A patch schedule written against switch name and port number stays accurate through a member swap.
It also means naming the switches properly matters. SW-FLOOR1-A is a usable reference; three switches left at their default serial-derived names are not.
Catalyst switches managed from the dashboard — C9300-M, C9300X-M, C9300L-M and the MS390, whether factory Meraki mode or converted — behave differently. They retain their IOS-XE interface names, switch number and all:
GigabitEthernet1/0/1 ... 1/0/48
GigabitEthernet2/0/1 ... 2/0/48
GigabitEthernet3/0/1 ... 3/0/48
The leading number is the StackWise switch number held by that physical unit. It is assigned when the switch first joins a stack and it persists with the hardware.
The problem is that this is a completely separate numbering system from the stack member number the dashboard displays, and the two are not synchronised. There are in fact three numbering schemes in play, and none of them is guaranteed to agree with the others:
| Scheme | Where it appears | Assigned by |
|---|---|---|
| Physical position | The rack | Whoever racked it |
| Dashboard stack member number | Switch stacks page, member list | Meraki cloud at provisioning |
| IOS-XE switch number | The interface name, Gi<N>/0/X |
StackWise, persists with the hardware |
⚠️ Member Number and Interface Number Are Not the Same: A switch shown in the dashboard as stack member 3 can carry interfaces named
GigabitEthernet2/0/X, while physically sitting second in the rack. All three references are valid and all three are different. When communicating about a port, state which scheme you are using, or give the switch name and the full interface name together.
StackWise switch numbers are sticky. A unit that was switch 5 in a previous stack keeps the number 5 when it is moved, unless something renumbers it. Meraki assigns its own member numbering independently of that.
The clearest illustration is splitting a stack. Take an eight-member stack numbered 1 to 8 in IOS-XE and split it into two stacks of four. The second stack does not restart at 1 — its members remain 5 to 8, so the first switch in that new stack presents ports as GigabitEthernet5/0/1 onward.
On a locally managed switch this would be corrected with switch renumber. That command is not available to you on a Meraki-managed Catalyst, so the mismatch cannot be tidied up from either side. It has to be lived with and documented.
Configuration binding is unaffected by any of this. The Meraki cloud uses the switch serial number as the unique identifier for management, not the stack number or the member number. Member numbers are only meaningful within a single stack and are discarded and re-provisioned when a switch joins a different one.
So the confusion is a labelling and communication problem rather than a configuration-integrity problem. The port configuration is still firmly attached to a specific physical switch, as covered in the next section.
This is the question anyone with Catalyst experience asks, and it deserves a direct answer because the Catalyst equivalent is a genuine hazard. On StackWise, switch numbers can be reassigned, and a provisioning mismatch really can leave GigabitEthernet2/0/1 pointing at different hardware than it did before.
Consider a three-switch stack configured like this:
SW-A port 1 -> VLAN 1
SW-B port 1 -> VLAN 2
SW-C port 1 -> VLAN 3
If the whole stack is power-cycled and a different member wins the Active election, does VLAN 2 end up on a different physical switch?
No. Port configuration is bound to the switch's serial number, not to a position in the stack. Each switch is an independent object in the dashboard, identified by serial, carrying its own name and its own ports. After the reboot, VLAN 1 is still on port 1 of SW-A, whichever member happens to be Active.
The deeper reason is that the premise does not apply. On Meraki there is no stack member number, so there is no positional index for configuration to be attached to in the first place. Nothing exists for an election to reshuffle. The Active role is a control-plane role governing stack-wide functions such as spanning tree — it does not own, hold, or redistribute port configuration.
The clearest evidence for this is the replacement workflow. If configuration followed stack position, swapping new hardware into a position would inherit that position's configuration automatically and no further action would be needed. Instead, Meraki requires the old switch's configuration to be explicitly cloned onto the replacement. That step only makes sense if configuration belongs to the device.
So the things that genuinely can move a port configuration between physical switches are all deliberate operator actions:
None of these can be triggered by a reboot, a power cut, or an Active re-election.
The MS390 and the Meraki-managed Catalyst models — C9300-M, C9300X-M and C9300L-M, whether shipped in Meraki mode or converted to it — behave differently from classic MS switches in several ways that matter operationally.
Underneath the Meraki management layer these are IOS-XE switches running StackWise, and IOS-XE maintains its own switch numbers. Those numbers are visible in the interface names and, as covered under Port Numbering, do not correspond to the dashboard's stack member numbers. They are not what dashboard port configuration is keyed to, so the conclusion in the previous section still holds: configuration stays with the serial.
The switch renumber command is not available on a Meraki-managed Catalyst, so a mismatched IOS-XE switch number cannot be corrected in place.
| Behaviour | Classic MS | MS390 / C9300-M |
|---|---|---|
| Reboot one member from the dashboard | That member only | Reboots the entire stack |
| Factory reset one member | That member only | Affects the entire stack |
| Standby role | None — cold election on Active failure | Standby exists and is pre-warmed |
| Management IP | Per switch | One IP for the whole stack, displayed on every member |
| Local status page | Per member | Redirects to the Active regardless of which member you are connected to |
| Recovery after Active failure | Short interruption | Several seconds before traffic resumes |
Two of these are worth calling out.
The reboot row is the one that causes incidents. Selecting Reboot device against what appears to be a single member of an MS390 or Catalyst stack will take the whole stack down, not just that switch.
The recovery delay has a specific cause. On these platforms the Meraki management container has to reinitialise on the newly promoted member, which is why traffic can take several seconds to resume rather than the sub-second failover a pure StackWise stack would give. The Standby role exists to reduce this, but it does not eliminate it.
On management addressing, note that with static IP addressing the management IP cannot be set individually per member. All members display the Active switch's address, and changing it applies to the Active and is reflected across the stack.
⚠️ Sourcing for the Serial-Binding Behaviour: That configuration is keyed to the serial rather than to the stack or member number is stated in Cisco Community discussion by Meraki Community All-Stars and is consistent with the replacement workflow and with observed dashboard behaviour, but it is not spelled out in official Meraki documentation for Catalyst-in-Meraki-mode. If a design decision depends on it, confirm with Meraki support and record the case number.
Also note that the IOS-XE switch number embedded in the interface name is not a reliable way to identify which physical unit you are looking at, for the reasons set out under Port Numbering. Use the switch serial or dashboard name when precision matters.
Take a stack of three — SW1, SW2 and SW3 — cabled as a full ring, with SW1 currently Active.
Say SW2 loses power or fails outright.
This switch's current stack members differ from the dashboard configuration, which is the expected alert for a failed or powered-off member. Ring intact — SW2 fails Chain — SW2 fails
---------------------- -----------------
SW1 <--------+ SW1
| | |
X SW2 | X SW2
| | |
SW3 --------+ SW3
SW1 and SW3 stay connected SW1 and SW3 are isolated
via the closing cable. from each other. The stack
Stack continues, degraded. partitions.
That contrast is the whole argument for the ring. In a chain, losing the middle switch of three does not just cost you SW2's ports — it severs SW1 from SW3.
Say SW1 fails instead.
This is the failure that catches people out, and it is not really a stacking problem at all.
A stack needs only one uplink to come up, and it is common for a stack to be commissioned that way and left. If that single uplink is on SW2 and SW2 fails, SW1 and SW3 are still perfectly healthy and still stacked — and the entire stack is cut off from the rest of the network.
Spread uplinks across at least two members once the stack is operational. Ideally put them on different members and aggregate them.
With a full ring, a single stacking cable failure degrades the ring to a chain. All three switches remain in the stack and all ports keep working. The stack is now running without stacking redundancy, so this should be treated as an urgent fix rather than a non-event — a second failure will partition it.
Physically power cycling any stack member, on any platform, can also make other members briefly unreachable while the management plane reinitialises.
Certain features run one instance per logical switch. When standalone switches are combined into a stack, their individual instances are discarded and must be reconfigured on the stack:
Capture these before stacking. Losing an STP priority silently is an easy way to move the root bridge somewhere unintended.
The dashboard provides a clone-and-replace workflow that copies the failed switch's port configuration onto the replacement, under Switching > Monitor > Switch stacks, on the Clone and replace member tab.
The sequence that matters:
Organization > Inventory and add it to the same network.Two constraints apply when adding a member to an existing stack. The total VLAN count across the stack must not exceed 1000, counted as the sum of allowed VLANs across the members rather than the number of distinct VLANs. And any Layer 3 interfaces must be removed from the incoming switch before it joins a stack that already has Layer 3 interfaces, or the operation is rejected.
| Alert | Cause |
|---|---|
| This switch's current stack members differ from the dashboard configuration | A member has failed or is powered off, or not all members are connected via their stacking ports |
| This switch is not connected to a stack | Configured in the dashboard as a stack member but not physically stacked |
| This switch does not have a stack configuration | Physically stacked but not configured as a stack member in the dashboard |
Where the cabling and configuration are correct, these alerts can take up to an hour to clear.
switch renumber in Meraki-managed mode, and the serial-as-unique-identifier behaviour. Community discussion rather than official documentation.