Cisco Meraki Large Scale Design Best Practice

General design principles

• Make the organization boundary deliberate. An organization is a management and licensing container; it also defines the scope of the Meraki SD-WAN domain.
• Make the network boundary reflect a real operational boundary such as a site, LAN, roaming domain, or product-specific configuration set.
• Standardize repeatable configuration with templates or golden networks, then use tags and API automation to express controlled variation.
• Treat template changes, firmware changes, administrator changes, and automation changes as production changes with an owner, a test path, and a rollback or recovery plan.
• Keep source records for configuration intent, addressing, ownership, exceptions, and validation results outside the dashboard so the deployment remains operable during an access or cloud-management outage.

Target audience 

• Enterprise network architects planning multi-site Meraki deployments 
• IT operations teams managing thousands of Meraki devices 
• Managed service providers designing multi-tenant Meraki environments 
• Network engineers integrating Meraki into existing Cisco Catalyst or third-party switch fabrics

Cloud connectivity and firewall policy

A device must reach the Meraki cloud through the firewalls and routers between the device and the internet. The authoritative destination list, ports, and purposes are available in the Dashboard under Help > Firewall info. Use that page as the source for allow-list changes because destinations and service requirements can change.

• Permit the outbound connections listed by Help > Firewall info for the applicable Meraki service and region.
• Confirm that stateful inspection, TLS inspection, proxy behavior, DNS resolution, and certificate handling do not interrupt the device management tunnel.
• For stateless firewalls or asymmetric paths, configure the corresponding return traffic explicitly.
• Test cloud reachability from each site archetype before shipping a zero-touch deployment. A device that cannot reach the cloud cannot retrieve its intended configuration or report health and will be marked offline.

Configuration resilience

Meraki devices store their active configuration locally and continue forwarding traffic when cloud connectivity is temporarily unavailable. The loss of dashboard connectivity still prevents configuration changes, firmware operations, and current telemetry from being exchanged. Design local forwarding and failure handling so the site remains safe and useful during an extended management-plane outage.

The dashboard protects against some invalid changes by marking a new configuration safe only after the device has remained connected for the documented validation interval. Do not treat this behavior as a substitute for testing. Stage high-blast-radius changes in an unbound network, a pilot group, or a maintenance window with an explicit recovery path.

Device limits

Maximum Recommended Scaling Guidelines

Devices per Network limits

Choosing a single or multiple organizations

Use one organization when the deployment can share the same licensing model, administrator governance, firmware coordination, templates, and Auto VPN domain. A single organization reduces duplicated configuration and makes cross-site reporting and automation easier.

Use multiple organizations when a boundary changes the operational, legal, or security model. Common drivers include regional data sovereignty, separate business units, distinct service-provider tenants, separate SD-WAN domains, and a deployment that would otherwise exceed the organization scale guidance.

Data sovereignty and latency across multiple geographic regions

If your business exists in more than one of the regions of The Americas, Europe, Asia/Pacific, China, then consider having separate organizations for each region. Each dashboard organization is hosted in a specific region, and your country may have laws about regional data hosting, such as GDPR compliance and other data sovereignty laws. Latency on management traffic could also be a deciding factor on where to host your organizations.  

In addition to regionally organizations within Cisco Meraki’s global service, dedicated services exist for US Government (FedRAMP Class C (Moderate) Certification), Canada, China, and India geographies. These services are isolated from the global service within its own servers and datastores for enhanced privacy and security. Separate login accounts must be created for each individual service, with no connection between any service. 

Meraki’s services can be accessed via the following sites:

Multi-organization governance

• Assign an owner, service region, business purpose, SD-WAN relationship, and support escalation path to every organization.
• Keep organization names, network names, tags, templates, and administrator groups consistent enough for search and automation, while retaining the region or business boundary in the name.
• Maintain parallel templates and firmware standards deliberately. Templates and firmware coordination are organization-scoped and do not automatically create parity across organizations.
• Claim hardware by order number into the intended organization when possible. Confirm regulatory domain and shipping-country requirements for wireless hardware before ordering.
• Use Global Overview or an approved reporting and automation layer for fleet visibility; do not assume that a user who can see several organizations has a single shared configuration scope.

Summary of licensing models

Licensing fit

Administrator roles

Custom roles (currently in BETA testing) 

In many companies, different parts of the network may be managed by different teams, and it may be undesirable to have an administrator have full access to a network. With custom roles, we can now fine-tune administrator permission to specific product families. Currently, restricting administrator to Security & SD-WAN, Switching, and Wireless networks within a combined network is available.  This functionality can be enabled in the Early Access menu today. 

Improvements to role-based access control is ongoing. Reach out to your Cisco account management team for more information. 

SAML and API access

Separate human identity from application identity. SAML/SSO controls how administrators sign in to the Meraki Dashboard; API authorization controls how an integration calls the Dashboard API. Where the organization and application support OAuth 2.0, an appropriately authorized SAML/SSO administrator can approve the application grant without exposing a personal API key. Use the least-privileged model that matches the automation.

• OAuth 2.0 app-scoped access — Use this for third-party applications and organization-wide automation. Register the application, request only the required OAuth scopes, and have an appropriately authorized organization administrator approve the grant. OAuth access tokens are time-limited and refreshed through the OAuth flow; protect refresh tokens as credentials. A personal Dashboard API key is not required.
• API-key admin-scoped access — Use this for personal scripts or tasks that must execute with a specific administrator’s role. An API key inherits the permissions of the administrator who owns it. SAML/SSO administrators cannot generate personal API keys, so create a dedicated local administrator only when API-key authentication is required; assign the minimum organization or network scope, store the key in a secrets manager, and rotate or revoke it on a defined schedule.

Refer to the Configuring SAML Single Sign-on for Dashboard and OAuth 2.0 Integration articles for detailed instructions on how to set up SAML/SSO and OAuth 2.0 login.

Templates versus cloning

Template design

For every template, document a configuration design that states what the template owns, what the site may override, and what must be validated after a change. At minimum, include site archetype, SSIDs, VLAN names and purpose, subnetting mode, baseline security policy, standard port profiles, firmware intent, tags, and the list of approved local overrides.

• Use one template per site archetype rather than one universal template with many conditional exceptions.
• Use unique subnetting for VLANs that participate in site-to-site VPN. Use the same subnetting only where identical addressing is intentional and VPN overlap is not required.
• Test template changes in a staging network and a pilot group before broad rollout. A template change can affect every bound network.
• Review local overrides periodically. Overrides are useful for exceptions, but uncontrolled overrides turn the effective configuration into an undocumented fork.

Tags and naming

Tags can identify networks, devices, switch ports, and Systems Manager devices. Use a short documented taxonomy for geography, site archetype, lifecycle, service tier, compliance scope, and operational ownership. Apply tags during provisioning and use them as inputs to access scope, firmware groups, API filters, and reporting.

Network cloning

Create device-free golden networks for repeatable site provisioning when the desired result is a static starting point. Keep the golden network under change control, verify the clone output, and apply site-specific values through a documented checklist or API. A clone is not a synchronization relationship; changes to the golden network do not update networks that were cloned earlier.

IOS-XE Catalyst switches on the Meraki Dashboard

IOS-XE Catalyst switches can be managed on the Meraki Dashboard using two different modes.

Spanning-tree interoperability

Meraki MS switches use a single RSTP spanning-tree instance and interoperate with common Cisco spanning-tree protocols, but the interoperability behavior determines where the root bridge can be placed and which VLANs must remain on trunks.

Mixed Catalyst and Meraki L2 STP considerations

• Prefer converting a Catalyst environment to a single-instance MSTP design before inserting MS switches into a PVST+ or Rapid PVST+ path.
• If PVST+ or Rapid PVST+ remains, run a spanning-tree instance on VLAN 1 across the relevant switches and allow VLAN 1 on every interconnecting trunk so BPDUs can be seen by the MS switch.
• Configure the Catalyst and MS ports as matching 802.1Q trunks. A port-type mismatch can cause PVST simulation or port-inconsistency blocking.
• Keep the Catalyst distribution or core layer as the STP root. Do not make an MS switch the root bridge in a mixed PVST+ environment.
• After changes, verify the root bridge, blocked ports, VLAN 1 allowance, trunk mode, native VLAN, and the expected forwarding path for every redundant link.

Layer 2 boundaries and link aggregations

Keep Layer 2 domains bounded by a deliberate access, distribution, or building boundary. Use link aggregation where the switch models and upstream design support it, and verify that the member links terminate in a compatible logical system. The goal is a predictable failure domain; more physical links do not automatically improve convergence or eliminate the need for spanning tree.

MCG Campus Gateway

Use an MCG Campus Gateway when a large campus needs centralized wireless traffic termination from cloud-managed access points. The MCG tunnels SSID traffic from APs to a central gateway, allowing client VLANs to remain in the core instead of being extended across the access layer, while supporting client roaming across Layer 3 boundaries without interrupting sessions. It also provides a scalable, highly available design with fewer wired-side changes because the APs and gateway only need IP reachability across the existing network underlay. For smaller or simpler sites, locally switched MR deployments may be easier to operate; MCG is most valuable when centralized policy, large-scale roaming, segmentation, and campus-wide wireless scalability justify the additional gateway layer.

Wireless Controller monitoring

Wireless Controllers are represented in the Meraki Dashboard primarily for monitoring and operational visibility. Dashboard can provide controller health, interface status, high-availability state, associated access points, client information, and relevant events; however, the Wireless Controller remains a monitor-only device rather than a Dashboard-configured product. Do not include Wireless Controllers in cloud configuration templates or standard Dashboard firmware-upgrade workflows. Manage configuration and software lifecycle activities through the controller’s supported local or external management process.

Roaming-domain sizing

Start with a building or another physical area with a clear RF boundary as the smallest roaming domain. Place RF-neighbor APs in the same Meraki network and the same management VLAN where the design requires fast roaming. APs must be able to exchange client PMK information between APs using source port 23541 to destination port 35213.

The same-VLAN choice can expand the broadcast domain across access switches or buildings. Balance roaming continuity against MAC and ARP scale, DHCP scope size, broadcast and multicast exposure, failure containment, and security segmentation. A roaming domain should be designed from both the RF map and the wired topology.

SSID and VLAN design

• Keep the SSID set small. Every enabled SSID adds management-frame overhead and reduces airtime available for client traffic.
• Use a consistent SSID purpose, authentication method, VLAN or named-VLAN policy, firewall policy, and ownership across the roaming domain.
• Use AP tags when a subset of APs needs a specific VLAN or RF behavior. Record the tag-to-policy relationship as part of the template contract.
• Keep client VLANs, AP management VLANs, and infrastructure management controls distinct unless the design explicitly requires otherwise.

RF profiles and AI-RRM

Use RF profiles to express the intended channel width, transmit-power range, minimum bitrate, and receiver sensitivity for an area. AI-RRM can adjust channel and power settings based on the observed environment, but it operates at the Meraki network scope. APs that are RF neighbors should therefore be in the same network unless a tested boundary is intentional.

• Use 20 MHz channels as the default starting point for most enterprise 5 GHz deployments; use wider channels only where the client density, channel availability, and capacity model justify them.
• Use a site survey or measured telemetry to set minimum bitrates and power boundaries. Raising the minimum bitrate or receiver sensitivity can improve reuse and roaming, but can also create coverage holes.
• Enable AI-RRM within documented guardrails and validate a pilot area after RF-profile changes. Avoid simultaneous, unconstrained changes across a large campus.
• Disable wireless meshing when it is not required so APs do not advertise mesh service that consumes airtime.
• For 6 GHz, validate regulatory domain, client capability, security requirements, and channel-width policy before enabling the band. WPA3 requirements apply to 6 GHz operation.

Hub-and-spoke design

Use a small set of stable hub locations for shared services, data centers, or corporate resources. Spokes build tunnels to their configured hubs and do not automatically form spoke-to-spoke tunnels. A hub-and-spoke design reduces the number of relationships that each branch must maintain and makes the intended traffic path easier to operate.

Overlay scale and route behavior

• Count hubs, spokes, uplinks, advertised subnets, and expected traffic paths before deployment. Dual WAN and multiple hubs increase tunnel and route relationships.
• Keep Auto VPN hub roles intentional. Configuring many devices as hubs can create more hub-to-hub and route relationships than a large deployment needs.
• Use the current Auto VPN static-routing scaling features only with Cisco Support and Solutions Engineering involvement when the design requires suppressing hub-to-hub tunnels, spoke-to-spoke routes, or route tracking behavior.
• Do not place the hub role in a template unless the current product guidance explicitly supports that model for the selected network type. Verify the resulting VPN topology after binding or cloning.

Network firmware vs. device firmware 

There is often confusion between the configured network firmware and the firmware installed on a device. While devices are designed to inherit the firmware configured on the network, this may not always be the case. There are two reasons why this could be the case. 

Identifying configured firmware version 

Existing firmware version for a network can be found at Organization > Monitor > Firmware Upgrades. The version on a specific device can be found on the network device status page. 

Upgrade sequence and availability

Mechanisms have been put in place to reduce downtime for highly available networks. Devices continue to operate during download and install; downtime only occurs during reboot/reload. Expected real downtime for all devices is 5 minutes during the reboot after firmware installation is complete.

Firmware image size 

API architecture 

The Meraki API follows a resource-based hierarchy: Organizations contain Networks, which contain Devices. Services are grouped by function: CONFIGURE (manage cloud configurations), MONITOR (return status and history), and LIVE TOOL (directly interact with devices). The base URI for each region is: 

API key management 

API keys are associated with the dashboard administrator account that generates them and inherit the same permissions. Understanding key lifecycle management is critical for enterprise security: 

• Create a dedicated local administrator for automation; do not use a personal administrator account for unattended jobs.

• Grant only the organization or network scope required by the job. Remember that an API key inherits the creator account permissions.

• Store keys in a secrets manager, rotate them on a defined schedule, and revoke keys when the owner, integration, or authorization boundary changes.

• Separate read-only inventory and monitoring jobs from write-capable deployment jobs when the operating model allows it.

Rate limiting 

The Meraki API enforces rate limits to protect the platform at 10 API calls per second per organizations, with the ability to burst to 30 API calls per second. When rate limits are exceeded, the API returns HTTP 429 responses with a Retry-After header. The official Meraki Python SDK includes automatic retry logic with exponential backoff for 429 errors. For custom integrations, implement retry logic with appropriate delays and request batching with Action Batches. 

Push API

Use Push API when you need event-driven updates for supported topics and repeated Dashboard API polling would consume API capacity or delay operational response. An organization subscribes to a topic, and Meraki sends updates to an HTTPS webhook endpoint. Push API notifications do not count against the organization’s API rate limit.

Common automation use cases 

• Provisioning: Create organizations, networks, and claim devices in bulk. Pre-stage configurations and bind to templates automatically. 

• Cross-organization management: Push firmware schedules, administrator changes, and firewall rules across multiple organizations. 

• Network migration: Move devices and configurations between organizations. Since devices lose their configuration when removed from a network, API scripting is the only reliable way to preserve settings during migration. 

• Compliance auditing: Query device tags, firmware versions, and configuration state across the fleet. Identify drift from golden configurations. 

• Custom reporting: Extract performance metrics, client statistics, and event data for dashboards beyond what the native dashboard provides. 

• Event-driven automation: Combine webhooks with API calls to automatically isolate compromised devices, adjust bandwidth shaping, or generate ITSM tickets. 

Infrastructure as Code (IaC) 

For organizations already using IaC practices, the Meraki API integrates with Terraform and Ansible to bring network configuration under the same version control and CI/CD workflows used for application infrastructure. Treat template changes like code: version them, test in staging, and roll out through a deployment pipeline. 

The official Meraki Python SDK (available via pip install meraki) provides built-in pagination control, automatic retry on rate limits, call simulation for previewing changes, and structured logging. It is the recommended starting point for Python-based automation. 

Cisco Workflows 

Cisco Workflows is a cloud-hosted automation engine available natively within the Meraki dashboard, accessible at no additional cost under the Automation menum, or in Cisco Cloud Control. It provides a low-code/no-code environment for building, executing, and managing automations across Cisco and third-party systems. For large-scale enterprise deployments, Workflows fills the gap between simple API scripting and full-scale orchestration platforms, enabling network teams to automate Day 0 through Day 2 operations using a simple, visual, drag-and-drop editor without writing or maintaining custom code. Workflows also provides a catalog of pre-built automations in the Workflows Exchange that can be used as is or easily customized to your use case. Refer to the Cisco Workflows documentation for detailed steps on getting started.

Common workflow patterns in large-scale Meraki deployments include: 

• Cross-organization firmware scheduling: A workflow that iterates across all organizations an API key has access to, schedules firmware upgrades by network tag, and pauses for administrator approval before executing. 

• Switch port configuration cloning: Copying port configurations from a source switch to a target switch across sites, handling edge cases like trunk ports with “allow all” VLAN configurations. 

• Multi-domain provisioning: Combining Meraki network creation with ISE policy deployment and Catalyst Center onboarding in a single automated workflow, reducing new-site provisioning from hours to minutes. 

• Compliance and drift detection: Scheduled workflows that query device configurations, compare against golden standards, and generate reports or ITSM tickets for deviations. 

Cisco AI Assistant for Networking

Cisco AI Assistant for Networking is a conversational capability integrated into the Cisco Meraki Dashboard. It allows administrators to ask questions in natural language and receive context-aware information derived from supported Dashboard data, Cisco networking knowledge, and published Meraki documentation. This reduces the need to navigate among multiple Dashboard pages or manually correlate information during routine monitoring and troubleshooting.

The assistant is intended to accelerate common Day 0 through Day 2 activities. Depending on the capabilities available in a given cloud and organization, administrators can use it to summarize network health, investigate client and device behavior, obtain configuration guidance, interpret screenshots or diagrams, review support-case summaries, and initiate supported automated workflows. Responses may adapt to the question by presenting explanatory text, structured results, or purpose-built user-interface elements.

Cisco Cloud Control

Cisco Cloud Control is a cloud-based operational platform designed to unify supported Cisco products and domains within a common experience. It provides a shared operational layer for networking, security, compute, observability, and collaboration platforms, with capabilities such as unified access, inventory, topology, prioritized actions, AI-assisted investigation, and extensibility to supported third-party systems.

For a Meraki deployment, Cisco Cloud Control complements rather than replaces the Meraki Dashboard. The Meraki Dashboard remains the authoritative management platform for Meraki organizations, networks, devices, configuration, licensing, and product-specific monitoring. Cisco Cloud Control consumes permitted product context and provides a broader cross-domain view, allowing operators to investigate dependencies and conditions that may span Meraki and other supported platforms.

Webhook controls

• Use an HTTPS endpoint with a certificate trusted by the public certificate chain. Confirm that the receiver permits traffic from the Meraki Cloud source ranges required by the service.
• Validate the webhook payload, authenticate the sender where supported, make processing idempotent, and retain the event identifier or timestamp needed to deduplicate retries.
• Begin with device offline, WAN failover, security, and other events that have a defined owner and response. Expand only after alert volume and operational value are measured.

SNMP and syslog boundaries

Meraki supports cloud-based and local-device SNMP polling with different visibility and network-path characteristics. Confirm whether the NMS should poll the cloud or the device, and test NAT, ACLs, UDP reachability, credentials, and polling intervals. SNMP traps are cloud-originated; a receiver behind NAT may require an explicit forwarding design.

Syslog is configured per network under Network-wide > Configure > General. MX can report event log, IDS alerts, URLs, and flows; MR can report event log, URLs, and flows; MS currently reports event log messages. Retain logs in a system with an access, retention, and time-synchronization policy.

Troubleshooting sequence

1. Confirm the scope: organization, network, device, client, uplink, VLAN, or policy.
2. Check current device reachability and cloud status before changing configuration.
3. Compare the effective device state with the intended template, tag, firmware, and local override state.
4. Use the event log, packet capture where authorized, client timeline, and uplink statistics to isolate the first observable failure.
5. Test the smallest reversible change in a pilot or maintenance window, then record the result in the change record.

Change management

Use the organization change log as the Dashboard audit trail, but connect it to the broader change-management process rather than treating it as approval evidence. Track and notify on configuration changes through the appropriate combination of Dashboard API queries, webhooks or push notifications, and email alerts. Use the API for scheduled reconciliation and reporting, push notifications for near-real-time operational response, and email for human escalation. Confirm event coverage, delivery behavior, and ownership for each notification method.

For high-blast-radius changes, record the request, owner, source of truth, test evidence, affected scope, maintenance window, success criteria, and recovery procedure before execution.

A useful staged rollout is a small pilot group, an observation period that matches the failure mode, and controlled expansion. Select the pilot size and observation interval based on the risk and traffic pattern of the change rather than applying a universal rule.

Configuration drift

• Scan for local overrides, inconsistent tags, unsupported firmware, missing VLANs, and deviations from the template contract.
• Use infrastructure as code, such as Terraform or another approved declarative tool, when configuration requires repeatable desired-state management. Define which resources the tool owns and reconcile changes through reviewed plans rather than allowing competing sources of truth.
• Treat a manual change as either an approved exception with an owner and expiry date or a defect to be reconciled.
• Keep a configuration backup or exported representation of critical intent, including addressing, VLANs, routing, firewall policy, SSIDs, and administrator scope.
• Use API polling, webhook events, and scheduled comparisons to identify drift; do not assume that a single notification method captures every configuration change.
• Review drift by site archetype and owner so the result becomes an actionable queue rather than a fleet-wide exception report.

Capacity and continuity

Track organization and network device counts, API consumption, network size, VPN topology, log volume, and wireless roaming-domain size. Maintain offline documentation for critical site recovery, including the management VLAN, WAN handoff, addressing, trunk requirements, upstream dependencies, and support contacts.

During a cloud-management outage, devices can continue forwarding with their cached configuration, but operators cannot assume that telemetry, configuration changes, firmware, or inventory operations will be available. Define which local services must continue, how an emergency change is authorized, and how the state is reconciled after access returns.