The wrong way — and why it stops working at site #6
Here is how most new admins manage a multi-site Meraki estate. They build site #1 in the dashboard by hand. Then they open site #2 and copy the firewall rules, the SSIDs, the VLANs, the traffic-shaping rules — click by click. By site #6 something slips. One site has an old DNS server. Another missed a firewall rule. Three months later, a security audit finds config drift across forty sites and nobody knows which one is "correct".
This manual approach feels productive but it does not scale. The fix is to stop configuring sites and start configuring a template. You write the rules once, bind every site to it, and the dashboard keeps all of them in sync for you. That single mental shift — from "manage sites" to "manage one template + exceptions" — is what this lesson is about.
Sneha inherits 38 retail Meraki networks built by three different engineers over two years. No two are identical. Her first job is not to fix all 38 — it is to build ONE template that captures the "golden" retail config, then bind the cleanest sites first and watch them snap into line.
If Sneha changes a Layer-3 firewall rule on the template, how many of the 38 bound sites need a manual edit afterwards?
A configuration template in Meraki is best described as…
You apply a tag called south-zone to twelve networks. What is the most common use of that tag?
Rolling new firmware to 200 sites at 9 AM Monday, all at once, is…
The five ideas you must own
Tap each card to flip it. These five concepts carry the whole lesson — and most of the ECMS 500-220 "Implementing" and "Operating" domains.
A shared base config. Build it once. Plan one template per site type (Retail, Branch, Warehouse) — never one mega-template.
A site linked to a template. It inherits the template's config and stays in sync. Unbind it and you lose inherited config.
A per-site exception. Editing a setting on the site (not the template) overrides it locally. Template updates won't clear it.
A label on a network or a device. Drives Summary Reports, policy scope and bulk actions. No spaces/commas, case-sensitive.
① Templates & binding — the change-ripple
Imagine Sneha edits the content-filtering rule on the Retail-Golden template at Organization > Monitor > Configuration templates. Watch what the dashboard does behind the scenes — every bound site picks up the change without her touching them.
▶ Watch one template change reach 38 sites
Click Play. Each stage lights up as the change propagates.
Meraki's own best-practice guide says it plainly: have one template network for each type of site. Don't try to make a single template fit retail stores, warehouses and HQ. Build Retail-Golden, Warehouse-Golden, Branch-Golden. Each is small, readable and safe to change.
Rahul has 200 branches on one template. A VP asks to block a website for the south region only. He almost edits the template — which would block it for all 200. Instead he tags the 40 south branches south-zone and scopes a group policy by tag. Forty sites change; the other 160 don't even notice.
Sneha edits a firewall rule on the Retail-Golden template. Goa Store earlier got a manual local override on that exact rule. After her edit, what does Goa Store enforce?
② Overrides & VLAN subnetting — where inheritance stops
Templates are powerful precisely because they have an escape hatch: local overrides. But the escape hatch has sharp edges. Two rules you must memorise:
Rule 1 — overrides are sticky. A local change on a site overrides the template. Later updates to the same setting on the template will not clear that override. To wipe an override you must unbind and rebind the network.
Rule 2 — unbinding deletes config. Per Meraki docs, when you remove a network from a template, the local overrides and all template-related configuration are lost. So "unbind to clean up" can wipe firewall rules and VLANs you still need. Clone first.
Symptom you see: you unbind a site to "fix a stuck override", and suddenly its firewall rules, VLAN subnets and traffic-shaping are blank. Cause: unbinding removes inherited config AND overrides together — it does not "promote" the effective config into a standalone one. Fix: before any unbind, clone the network or export the config so you have a rebuild source.
Same vs Unique subnetting
When a template defines a VLAN, you choose how each bound site gets its subnet, under Security & SD-WAN > Configure > Addressing & VLANs:
Symptom you see: you try to change a VLAN from Same to Unique subnetting and the dashboard silently refuses or errors without a clear reason. Cause: existing DHCP reservations on that VLAN block the change. Fix: delete the DHCP reservations on every VLAN first, switch subnetting to Unique, then re-add the reservations. This one cost a community admin an afternoon — now it won't cost you one.
You override a bound site's VLAN 10 subnet to 172.16.50.0/24, but the template's VLAN 10 pool is 10.0.0.0/8. Will the override stick?
172.16.50.0/24 is outside 10.0.0.0/8, so it is rejected. Pick a subnet inside the pool — say 10.50.0.0/24 — and it sticks. And remember: you can change the subnet, never the VLAN ID.Priya at HCL wants to clear a stuck local override on a bound site so it follows the template again. What is the safe way?
③ Tags at scale — your label-driven control plane
Templates handle the shared config. Tags handle grouping and targeting. A network tag labels an entire network; a device tag labels one device. Together they let you slice your estate any way you like — by region, store size, device role or maintenance window.
Sneha tags every flagship store network tier1-flagship and every drive-thru AP outdoor-ap. Now she can build a Summary Report for just flagship traffic, scope an SSID to only outdoor APs, and tell her manager "all 12 tier-1 stores" without listing them by hand.
Device tags allow no spaces and no commas, and they are case sensitive. So South-Zone, south-zone and south_zone are three different tags — and your policy will silently miss two-thirds of your sites. Decide on lowercase-with-hyphens (south-zone, tier1-flagship, outdoor-ap) on day one and document it. At real scale, apply tags via the Dashboard API so a new device is tagged the moment it is added — manual tagging always drifts.
A group policy is scoped to tag byod. An engineer tags new APs BYOD (capital). Do those APs get the policy?
BYOD ≠ byod, so the policy never matches the new APs and they fall back to default behaviour. This is one of the most common "but I tagged it!" tickets at scale. Normalise tag case in your onboarding script.You need a Summary Report covering only your 40 south-region stores. The cleanest approach is to…
④ Change management — don't break 200 sites at once
At one site, a bad change is a bad day. At 200 sites, a bad change is an incident, a war-room and a post-mortem. Operations-grade Meraki means treating every change like a deployment: stage it, watch it, be able to roll it back.
Staged firmware — the ring model
Meraki groups firmware into three stages: Beta (early testing), Generally Available (production-ready) and Recommended Release (most proven). The operations move is to ride those rings deliberately.
▶ Stage a firmware rollout across the estate
A new MX release lands. Watch a safe operator move it ring by ring instead of all at once.
Drift detection — the audit that saves audits
Even with templates, drift creeps in: someone adds a local override "just for now" and forgets. The discipline is to audit each bound site's effective config against the template, and to flag any override that nobody can justify. At scale, this means treating templates like code — version them, review changes, and use the API to detect drift automatically.
After any estate-wide change, check three things: (1) the change appears on a bound site, not just the template; (2) no unexpected new local overrides crept in; (3) the firmware ring on a sample site matches your plan. Confirm on a real site in the dashboard — not from the template view alone, which can look correct while sites lag.
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from Meraki docs + community Q&A. For complex prod issues, paste your template name + bound-network list into chat.techclick.in.
📝 Wrap-up — seven more
You've already answered 3 inline. Seven left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
Common mistakes & pro tips
Symptom you see: you change a setting for one problem store and three other stores break the next morning. Cause: you edited the shared template, so the change hit every bound site. Fix: for one-off needs, set a local override on that site or scope by tag — never touch the template for a single-site exception.
Symptom you see: a tag-scoped policy or SSID applies to most sites but mysteriously skips a handful. Cause: those sites/devices were tagged with a different case (Outdoor-AP vs outdoor-ap). Fix: normalise tags to one lowercase convention and apply via API so onboarding never drifts.
1. Name templates by site archetype, not by location — Retail-Golden beats Mumbai-template. 2. Keep a beta network of each size so firmware bakes on realistic hardware. 3. Tag early — Summary Reports only collect data from the moment a tag is applied. 4. Before any unbind, clone the network as a rebuild safety net. 5. Treat templates like code: version, review, and use the API for drift detection at scale.
📖 Glossary — the words that matter
- Configuration template
- A shared base config that many site networks bind to and inherit, kept in sync from one place.
- Bound network
- A site network linked to a template; it inherits the template's config automatically.
- Local override
- A per-site exception set on the network itself; it overrides the template and is not cleared by template edits.
- Same / Unique subnetting
- Template VLAN options: Same shares one subnet across sites (no inter-site VPN); Unique gives each site its own subnet from a pool.
- Network tag / Device tag
- Labels on a whole network or a single device used to scope reports, policies, SSIDs and bulk actions.
- Staged Upgrade
- A firmware rollout split into groups/rings you can schedule, defer and roll back to control blast radius.
- Config drift
- The gradual divergence of site configs from the intended template baseline, usually from forgotten overrides.
🧠 Explain it back (self-explanation)
In your own words, write the one-sentence rule that decides whether you edit the template or set a local override. Typing it locks it into memory better than re-reading.
👩🏫 Teach a friend
Explain to a teammate in two lines: why does unbinding a network from a template wipe its config, and what must you do before you unbind? If you can teach it, you own it.
⏰ Spaced recall — beat the forgetting curve
You'll forget ~70% of this in a week unless you revisit. Drop your email and we'll send 3 quick recall questions on this lesson in 7 days. No spam — one nudge, then it's gone.
📚 Sources
- Cisco Meraki Docs — Managing Multiple Networks with Configuration Templates. documentation.meraki.com
- Cisco Meraki Docs — MX Templates Best Practices (Same/Unique subnetting, can't override VLAN ID, unbind data loss). documentation.meraki.com
- Cisco Meraki Docs — Manage Tags (network vs device tags, no spaces/commas, case-sensitive, Summary Report paths). documentation.meraki.com
- Cisco Meraki Docs — Best Practices for Meraki Firmware & MS Firmware Upgrades / Staged Upgrades. documentation.meraki.com
- The Meraki Community — Configuration Template VLAN Setup & Modifying VLAN for a network bound to template (DHCP-reservation gotcha, override behaviour).
- Hummingbird Networks — Meraki Tags and Templates for Smarter Network Operations (config drift, treat-templates-as-code at scale).
- Cisco — Engineering Cisco Meraki Solutions (500-220 ECMS) Exam Topics. learningnetwork.cisco.com
What's next?
You can manage Meraki at scale in the dashboard now. Next we go fully hands-off: the Dashboard API to read and write config in bulk, webhooks for real-time events, action batches for atomic mass changes, and Terraform to manage your whole estate as code.