One wrong assumption that breaks every new Meraki engineer
New L1 engineers open the Meraki dashboard and assume a switch stack is "just cabling a few switches together." It is not. A stack becomes one logical device — one config surface, one set of SVIs, shared spanning-tree. Cable it wrong and you don't get a faster switch; you get a loop, a split stack, or a silent black hole.
The second wrong assumption is sneakier: that an ACL blocks traffic by default like a firewall does. On Meraki MS, the opposite is true — the final, invisible rule is Permit Any Any. Forget that, and your "lockdown" ACL lets everything through. We'll unlearn both myths, the visual way.
In plain words: stacking is like turning five separate billing counters into one long counter with one manager — customers (packets) get served faster and if one staffer leaves, the others carry on. An SVI is the "you-are-here gateway desk" for each floor (VLAN). An ACL is the security guard's checklist — but this guard's last line says "if not on my deny list, let them in." QoS is the VIP queue at a temple — devotees with a VIP pass (DSCP tag) skip ahead when it's crowded.
Architect lens: design the access layer as stacked pairs/rings for deterministic failover and a single management object per IDF; push L3 termination as far down as the model budget allows (collapsed-core vs three-tier). Treat the Permit-Any-Any default as a posture decision — explicit-deny-then-permit at the distribution edge, and remember ACL and QoS share a 32-entry L4-port-range budget per switch, so spend it deliberately.
Warm-up — predict before you read
Three quick gut-checks. Wrong answers are the whole point — they show you exactly what to fix.
A colleague says "just add a deny rule, Meraki blocks the rest automatically like a firewall." On a Meraki MS, is that right?
You enable L3 on an MS stack and the management IP 10.10.10.250 stops responding. Your first SVI is VLAN10 → 10.10.10.1/24. Likely cause?
10.10.10.250 sits inside 10.10.10.0/24 — the same subnet as the SVI — so polling/pinging the mgmt IP drops. Move mgmt to a separate subnet.Voice calls stutter only when the office uplink is busy. Which Meraki MS feature fixes it?
The vocabulary, in six taps
Flip each card. These six terms appear in every Meraki switching ticket and ECMS question.
Up to 8 switches joined by rear stack cables into one logical switch, ideally in a ring so any single cable failure is survivable.
Switched Virtual Interface — a per-VLAN gateway IP on the switch. Only VLANs with an SVI can be routed. MTU is fixed at 1500.
Each packet judged alone, top-down, first-match. No return-flow memory. Final implicit rule = Permit Any Any. Max 128 per network.
DSCP (L3 marking) maps to a CoS egress queue 0–5. Queues 6 & 7 are reserved for control protocols. Higher queue = more bandwidth under congestion.
The switch's cloud check-in IP — separate from every SVI. On an L3 stack it must not overlap an SVI subnet, or it goes dark.
The center of the spanning tree. Set your chosen root to priority 4096. Beware: templates don't push priority to stacks — they keep 32768.
① Stacking — eight switches, one brain
Picture an IDF rack at Infosys Pune with three MS350s. Cabled as standalone units, that's three configs, three failure domains, three things to patch. Sneha instead cables them into a ring stack — now it's one logical switch in the dashboard.
Switching > Monitor > Switch stacks she selects all three and clicks Create. The switch with the lowest MAC auto-elects as Active; the rest become members.Two stacking flavours. Most MS models use physical stacking over dedicated rear ports. The MS420/MS425 also support flexible stacking, where any SFP+ port (minimum 10 Gb/s) becomes a stack port — handy when switches sit in different racks. Pick the cable speed by model: 40 G on MS210/225/250/350/410/425, 100 G on MS150/355/450, and 480 G on the MS390 and cloud-managed Catalyst 9300.
Sneha's three-switch stack is cabled 1→2→3 but she forgot to cable 3 back to 1 (a chain, not a ring). Switch 2's stack cable later fails. What happens?
A stack gives you two redundancies for free: Layer-3 gateway redundancy (the SVIs survive the loss of the active member) and Layer-2 dual-homing (a downstream device can uplink to two different stack members and stay up). One uplink to the stack reaches every member.
What you see: one member greyed out in Switching > Monitor > Switches, occasional stack re-convergence reboots.
Cause: usually a half-seated or wrong-speed stack cable, or a firmware mismatch between members. Fix: ensure all members run the same firmware before stacking, re-seat both ends of each stack cable, and confirm the ring is physically closed. Remember every MS member (except MS390/Catalyst, which share one) needs its own management IP.
Sneha needs to stack two MS425s that live in adjacent racks with no rear-port reach between them. What's her cleanest option?
② Layer-3 / SVIs — when the switch becomes the router
Without L3, every VLAN needs the MX (or an external router) to talk to another VLAN — traffic hairpins up and back down. Enable an SVI on the switch and VLAN-to-VLAN traffic routes locally at line rate. Path: Switching > Configure > Routing & DHCP.
SVI-Servers, subnet 10.20.20.0/24, interface IP 10.20.20.1. Clients on VLAN 10 (gateway 10.10.10.1) can now reach the servers without touching the MX. The golden rule he repeats: only VLANs that have an SVI can route, and the interface IP can never equal the management IP.▶ Watch inter-VLAN routing on the SVI
Click Play. A laptop on VLAN 10 reaches a server on VLAN 20 — routed entirely on the MS stack.
10.20.20.10 is directly connected via SVI VLAN20 (10.20.20.1)
Model tiers matter. MS150 / MS210 / MS225 do basic L3 — SVIs, static routes, DHCP relay — but no OSPF. MS250 and up add OSPFv2, DHCP server and VRRP warm-spare. The MS390 and Catalyst 9300 add routed ports, IPv6 L3 and BGP. A static route's next hop must live in a subnet that already has an L3 interface, and a default route can't point to an SVI on the same switch (routing loop).
Switching > Configure > Routing & DHCP > Add interface Name: SVI-Servers VLAN: 20 Subnet: 10.20.20.0/24 Interface IP: 10.20.20.1 # NOT the management IP Default gateway:10.20.20.254 # MX/uplink — first interface only DHCP: Relay -> 10.99.0.5
Interface VLAN Subnet Interface IP Status SVI-Servers 20 10.20.20.0/24 10.20.20.1 routing SVI-Clients 10 10.10.10.0/24 10.10.10.1 routing Note: brief service blip while L3 hardware tables rebuild.
Classic Meraki MS switches (every model except MS390) cannot ping their own L3 interface, and once L3 is on, the switch prioritises forwarding over answering ICMP. So a failed ping from the switch to its own SVI is expected, not a fault. Test routing from a real downstream client instead — that's the only valid proof.
Rahul sets the VLAN10 SVI to 10.10.10.1/24 and also leaves the stack's management IP as 10.10.10.250/24. Commit succeeds. What breaks, and when?
10.10.10.250 overlaps the SVI subnet 10.10.10.0/24. On an L3 stack, that overlap causes packet loss when the cloud pings/polls the mgmt IP — the switch may even flap "offline" in the dashboard while still forwarding user traffic fine. Fix: put the mgmt IP on a dedicated, non-routed subnet.A team needs OSPFv2 between the access stack and the core. Their access switches are MS225s. What must change?
③ ACLs — the rule that's permissive by default
Meraki MS ACLs are stateless: each packet is judged on its own, with no memory of the return flow. Rules run top-down, first match wins, on ingress, and apply network-wide to every switch. The trap: the final, invisible rule is Permit Any Any. So an ACL with only "allow" rules and no explicit deny changes nothing — everything was already allowed.
▶ Watch a packet fall through the ACL
Guest-VLAN packet aimed at the server subnet. Watch which rule matches first.
10.30.30.0/24 · dst any · dst-port 443 → no match (port 445 ≠ 443)
10.30.30.0/24 · dst 10.20.20.0/24 → MATCH → DROP
# Rules run top-down, first match wins. Order matters! 1 allow TCP src 10.30.30.0/24 dst any dport 443 # guest HTTPS out 2 deny any src 10.30.30.0/24 dst 10.20.20.0/24 # block servers 3 deny any src 10.30.30.0/24 dst 10.10.10.0/24 # block staff VLAN # (implicit) Permit Any Any <- everything else still allowed
Guest 10.30.30.55 -> 10.20.20.10 : DROPPED (rule 2) Guest 10.30.30.55 -> 1.1.1.1:443 : ALLOWED (rule 1) Guest 10.30.30.55 -> 8.8.8.8:53 : ALLOWED (implicit permit)
What you see: you allowed outbound but replies seem dropped, or a rule blocks more than intended.
Cause: MS ACLs are stateless — there's no automatic return-flow allow, and the VLAN field matches the source VLAN on ingress. Fix: reason about each direction separately, and keep narrow allows above broad denies. Cap: max 128 ACLs per network, and L4 port-range rules share a 32-entry budget with QoS.
Priya's ACL has the deny-to-servers rule placed below a broad allow any src 10.30.30.0/24 dst any rule. Guests still reach the servers. Why?
④ QoS — keeping voice clean when the pipe is full
QoS does nothing on an idle network — it only matters under congestion. On Meraki MS you define network-wide QoS rules at Switching > Configure > Switch settings. Each rule matches traffic (protocol, VLAN, source/dest port) and tells the switch whether to trust, set or modify the DSCP value, then maps it to a CoS egress queue.
Eight egress queues exist, but you only assign 0–5; queues 6 and 7 are reserved for L3 and L2 control protocols. When the uplink congests, higher-numbered queues get a bigger slice of bandwidth. Voice (DSCP EF / 46) goes in a high queue; bulk backup traffic stays low.
▶ Watch voice jump the queue under congestion
A VoIP packet and a backup-traffic packet arrive together on a congested uplink.
A team tags VoIP with DSCP EF but tries to assign it to CoS queue 7 in the dashboard. It won't save. Why?
A 2025 advisory flags CVE-2025-20352 — an SNMP stack-overflow exploited in the wild. It hits MS390 and Catalyst 9300 on Meraki CS 17 and earlier. Your access stack is MS350 + one MS390. What's your move?
Organization > Firmware upgrades. Always check whether an advisory's affected models actually exist in your network before you panic — or relax.Common mistakes & the fixes that save your evening
What you see: an unexpected switch became RSTP root; convergence got slower. Cause: STP bridge-priority set in a switch profile only propagates to standalone switches; stacks keep the default 32768. Fix: set priority 4096 directly on the stack and re-check the elected root. Also: never let an MS be root when bridging into a PVST+ fabric — it drops to legacy STP mode.
1. Keep the management VLAN/subnet completely separate from every SVI subnet — the #1 silent L3 outage. 2. Order ACLs specific-deny-first, broad-allow-last, and remember the implicit Permit Any Any. 3. Validate routing from a real downstream client, never by pinging the switch's own SVI (classic MS can't, and L3 deprioritises ICMP anyway).
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from Cisco Meraki documentation + community threads. For live prod issues, share your Switching > Monitor > Switch stacks view and ACL list at chat.techclick.in.
📝 Wrap-up — six more
You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
🗣 Explain it back (self-explanation)
In your own words: why does a Meraki MS ACL with only "allow" rules change nothing — and what one rule fixes it? Type it, then teach it to a teammate today. Teaching cements memory faster than re-reading.
⏰ Lock it in — spaced recall
Memory fades without revisiting. Opt in and we'll nudge you to re-test this lesson in 3 days and again in 10 — the spacing that beats cramming.
📖 Glossary
- SVI (Switched Virtual Interface)
- A per-VLAN Layer-3 gateway IP on the switch. Only VLANs with an SVI can be routed; SVI MTU is fixed at 1500.
- Physical / flexible stacking
- Joining up to 8 switches into one logical unit — over rear stack ports (physical) or over an SFP+ port at ≥10 G (flexible, MS420/MS425).
- Stateless ACL
- An access list that judges each packet independently, top-down, first-match, with no return-flow memory; ends in an implicit Permit Any Any.
- DSCP
- Differentiated Services Code Point — a 6-bit Layer-3 priority marking (e.g. EF/46 for voice) the switch can trust, set, or remap.
- CoS queue
- On Meraki MS, the egress queue number (0–5 assignable; 6–7 reserved) that determines bandwidth share under congestion.
- Warm spare (VRRP)
- Two L3 switches acting as redundant gateways via VRRP; slower failover than a stack and two separate management surfaces.
📚 Sources
- Cisco Meraki Documentation — Switch Stacks (max 8, ring topology, cable speeds, active election, per-member mgmt IP). documentation.meraki.com
- Cisco Meraki Documentation — MS Layer 3 Switching and Routing (SVI fields, model tiers, OSPFv2/BGP support, mgmt-IP-overlap rule, hardware-table flush). documentation.meraki.com
- Cisco Meraki Documentation — Switch ACL Operation (stateless, top-down first-match, implicit Permit Any Any, 128-ACL cap, ingress VLAN). documentation.meraki.com
- Cisco Meraki Documentation — QoS / MS Switch Quality of Service Defined (DSCP→CoS queue 0–5, queues 6–7 reserved, Switch settings path). documentation.meraki.com
- Cisco Meraki Documentation — Configuring & Determining the RSTP/STP Root Bridge + Meraki Community (template doesn't push STP priority to stacks; set root to 4096; PVST+ legacy mode). community.meraki.com
- Cisco / Eclypsium advisory — CVE-2025-20352 SNMP stack-overflow, MS390 & Catalyst 9300 on Meraki CS 17 and earlier, exploited in the wild (2025).
- Cisco Learning Network — 500-220 ECMS (Engineering Cisco Meraki Solutions) Exam Topics, MS switching objectives. learningnetwork.cisco.com
What's next?
You can switch and route. Next we move to the edge: the Meraki MX security appliance — how AutoVPN builds a full mesh with one click, hub-and-spoke topologies, and where SD-WAN+ steers traffic over the best path.