Home > Architectures and Best Practices > Cisco Meraki Best Practice Design > Building a Scalable Meraki Solution

Building a Scalable Meraki Solution

When designing a network solution with Meraki, there are certain considerations to keep in mind to ensure that your implementation remains scalable to hundreds, thousands, or even hundreds of thousands of endpoints.

Design Considerations

Meraki Solution Sizing

When planning for deploying a Meraki solution, whether it be a small part of a larger network solution or a full-stack total solution, it is essential to take some time to consider the organizational structure you will use. Generally, your structure will be determined based on the size of your deployment.

 

You will need to make a few considerations based on the way the Meraki cloud solution is structured. You will begin by creating a Meraki account, which is a user’s identity for managing the Meraki dashboard management interface. Accounts have access to "organizations," which are logical container for Meraki "networks." And Meraki networks are logical containers for a set of centrally managed Meraki devices and services.
 

Account_structure.png

 

By understanding this structure, you can begin to determine how many you will need of each.

Number of User Accounts

Account Scope General Recommendation

  • 2 or more user accounts per owner
  • 1 user account per network admin

 

Your Meraki account is your first step in building a Meraki solution, and it will also be your only method of gaining access to your devices, and distributing access to other users. As such, we strongly recommend having at least one secondary account for owners, in case your are locked out of or lose access to your primary account. Lost or forgotten passwords are common, but lost email access can lead to total lockout from your organizations, so it is essential to consider a backup plan at the beginning of the planning process.

 

Additional network administrators or viewers will only require one account. Alternatively, distributed SAML access for network admins is often a great solution for ensuring internal scalability and secure access control.

Number of Organizations per Account

Organization Scope General Recommendation

  • One organization per customer

OR

  • One organization per service

 

If you are the customer who will be using and managing Meraki equipment, it is likely that you will only need a single organization. Each organization is simply a container for your networks, and a single-organization model is generally the most simple solution if it's realistic for your deployment.

 

Multiple organizations are recommended in a few different situations.

  • Global multi-region deployments with needs for data sovereignty or operational response times
    • If your business exists in more than one of: The Americas, Europe, Asia/Pacific, China - then you likely want to 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. Additionally, if you have global IT staff, they may have difficulty with management if they routinely need to access an organization hosted outside their region.
    Companies with multiple business types with multiple different operational structures
    • Companies that have split business units generally find that they want multiple organizations for simpler management, based on which company sub-group or sub-company is using the service. This is commonly split based on groups like "mergers and acquisitions" vs "corporate" or "retail locations" vs "service locations," etc.
  • Very large companies with multiple distinct use cases
    • Very large companies, with tens or hundreds of thousands of employees, will often separate their organizations based on types of workers. Organizations may be split into groups such as "remote teleworkers," "branch offices," "campus offices," etc.
  • Service Provider businesses with separate service offerings
    • Service providers, companies that sell or lease Meraki service solutions to their end users, will generally find that they require multiple organizations. Generally, the number of organizations for service providers will be determined based on one of the following structure models.
      • One organization per service: Separate organizations for each service offering. Different organizations often represent different tiers of service.
      • One organization per customer: Common in cases when the end customer owns their own equipment or requires full management of their own network.
      • One organization per SD-WAN: The scope of an organization defines the connectivity domain for Meraki SD-WAN (Auto VPN).
    • More information on service provider dashboard structures can be found in our Service Provider Recommended Dashboard Structures article.

 

Additionally, it is important to consider Meraki server and data center limits. Meraki server architecture is a multi-tenant solution that hosts multiple customers on the same hardware with secure permissions-based segmentation among them. The maximum scale supported in a single organization is 25,000 physical Meraki devices. If a single business intends to have more than 25,000 devices in their Meraki solution, they are strongly encouraged to work with their account team to design a deployment strategy across multiple organizations.

Number of Networks per Organization

Network Scope General Recommendation

  • One network per physical location or branch

 

Generally, networks will represent physical locations or actual LAN networks at different sites. A deployment with only 5 sites will usually only have 5 networks. Dashboard networks only support 1 MX security appliance per network (or 2 with 1 as a spare), so if MX devices are being used as LAN/WAN boundaries, each network will represent a unique LAN. Device configurations are scoped on a per-network basis, so generally, networks can also be thought of as representing unique configurations. For example, all access points on a network will share a common set of SSIDs. All layer 3 switches on a network will share a routing information.

 

Additionally, for smaller deployments, it is sometimes common to separate networks based on type of device. So, there may be a "wireless devices" network, an "endpoint management" network, a "cameras" network, etc.

It is worth noting that, at more than 2000-5000 networks, the list of networks might start to be troublesome to navigate, as they appear in a single scrolling list in the sidebar. At this scale, splitting into multiple organizations based on the models suggested above may be more manageable.

 

For service providers, the standard service model is "one organization per service, one network per customer," so the network scope general recommendation does not apply to that model.

Number of Devices per Network

The number of Meraki devices (MX, MS, MR, MV, etc., not user devices) per network is a much more variable number that does not have a general recommendation. It will vary from case to case.

Note that there is a limit of 1000 devices per network. Networks exceeding this number should be split. However, it is generally uncommon for networks to approach this number unless they have a very large number of cameras or wireless access points. If this is the case, it is recommended to split the networks based on physical areas or use cases.

Multi-Organization Considerations
SD-WAN

Each organization represents a separate SD-WAN instance. Meraki SD-WAN is implemented though use of Meraki Auto VPN technology. Auto VPN is an extremely low-touch solution for creating SD-WAN networks, by automatically networking all sites in a single organization. Because of this, multi-organization deployments are also multi-SD-WAN-domain deployments. Usually this is preferred for customers with needs for multiple organizations, but it should be noted in design.

Geographic Locations

For compliance reasons many countries require information gathered by companies to be kept in specific geographical regions.  You should consider creating separate organizations in order to stay compliant. Additionally, whenever one is leveraging a cloud based solution, making sure the administrators of that system are close to the management hub makes the execution of cloud management more seamless. For example, deployments in the EU are subject to GDPR compliance and deployments in China are subject to country-wide security restrictions. Organizations may need to be scoped by region based on these considerations.

Templates

In order to maintain consistency between networks, many customers use network templates. Templates allow administrators to quickly make many copies of a certain network configuration across an organization. However, templates are not maintained across different organizations, and there are not currently any options for copying networks among organizations. It is recommended to change all relevant templates across your organizations at the same time if they are intended to act the same.

Firmware

Similar to templates, firmware consistency is maintained across a single organization but not across multiple organizations. When rolling out new firmware, it is recommended to maintain the same firmware across all organizations once you have gone through validation testing.

Ordering Recommendations

It is recommended to order and ship devices within the same country. Doing so will automatically assign the correct regulatory domain for devices in the order, when relevant. This primarily applies to devices with wireless capabilities.

It is also recommended to separate your orders based on organization for inventory and claiming reason (listed below). Orders for hardware that will be used in multiple organizations should ideally be split, unless doing so would cause more difficulty than it would solve.

On the other side of the same coin, multiple orders for a single organization (made at the same time) should ideally be joined. One order per organization usually results in the simplest deployments for customers. 

Inventory and Claiming

When claiming new Meraki devices, it is recommended to claim by order number within the organization you intend to use the devices (as opposed to claiming individual serial numbers). Claiming by order number will pull in all hardware and licenses associated with the order and tie them to the organization before devices ever physically arrive on-site. Once claimed, devices can be moved from one organization to another if needed. Meraki recommends always claiming by order number when possible, rather than claiming by MAC or serial number.

API Key

API keys are tied to the access of the user who created them.  Programmatic access should only be granted to those entities who you trust to work within the organizations they are assigned to. Because API keys are tied to accounts, and not organizations, it is possible to have a single multi-organization master API key for simpler configuration and management. This can be achieved by giving an account organization-level permissions for all organizations. However, access to this account should be granted carefully.

Deployment Considerations

Cloning Networks

An excellent way to save time in deployments with many networks is to clone networks. The larger a deployment is, the more helpful it is to have one or more "golden configuration networks" which are never used for devices, but represent an ideal configuration that new networks should have. Whenever a new network is created, there is an option to clone it from an existing network, and it's usually best to clone from networks specifically configured for this purpose. When planning a deployment, these "golden configuration networks" should ideally be created first, and subsequent networks can be copied from them.

Template-Based Networks

Cloning networks provides a static method for creating many networks with identical configurations. Alternatively, templates provide a more dynamic solution. Configuration templates can allow many Meraki dashboard networks to be deployed following a single base configuration network, and they will dynamically updates as changes are made to the base configuration network. This makes it much easier to roll-out new sites/users and maintain consistency across each site's configuration. Networks that are bound to a template will utilize its configuration as a base. Any changes made to the template will then be pushed out to all bound networks.

 

Template-based network are most useful in cases where a large number of sites exist that share a common network design. Examples of this are common in retail deployments with many stores, or in cases with large numbers of home users with teleworker VPN devices connecting to a corporate network over VPN.

 

Templates should always be a primary consideration during deployments, because they will save large amounts of time and avoid many potential errors.

 

It should be noted that service providers or deployments that rely heavily on network management via API are encouraged to consider cloning networks instead of using templates, as the API options available for cloning currently provide more granular control than the API options available for templates.

Tagging

Tagging is a way to group or identify devices, networks or ports for specific use cases. These tags can be used to search, filter, identify or assign access to particular functions. The following items can have network tags applied to them:

  • Networks
  • Meraki Devices
  • Switch Ports
  • Systems Manager Devices

 

Tagging networks allows specific admins to have network level configuration access without organizational wide access. Access can be scoped based on network tags, which allows for much more granular access control. This is most commonly used for assigning permissions to local IT admins that are not "super users."  Additionally, network tagging allows "visibility-only" roles for users to see the most relevant application data. This is most commonly used for managers interested in the traffic usage of their network, but may not want to make configurations.

 

Meraki device tags are used to easily search for certain types of devices on your networks, based on user-defined attributes. Common device tags may include locations like "1stFloor," "Dorms," "Classroom," etc., or  attributes of the device like "LeftRack" or "MiddleRack" for MXs and MSs or "CeilingMount," "WallMount," for MRs or MVs. Additionally, APs can be tagged for specific VLANs. There is an option to tag traffic on specific APs with a particular VLAN based on device tags. 

 

Systems Manager device tags are used to logically group end-user devices together and associate them with applications and profiles. Users may be given a tag for a certain application that should only be installed on their devices, or a certain security level that should only apply to them.

 

Switch port tags allow administrators to set granular port management privileges. Organization administrators could use port tags to give read-only admins configurations access and packet capture capability on specific ports.

Administrators

There are two basic types of Dashboard administrators: Organization administrators and Network administrators.

  • Organization administrators have complete access to their organization and all its networks. This type of account is equivalent to a root or domain admin, so it is important to carefully maintain who has this level of control.

    • Organization - Read-only: The user is able to access/view most aspects of network and organization-wide settings, but is unable to make any changes.

    • Organization - Full: The user has full administrative access to all networks and organization-wide settings. This is the highest level of access available.

  • Network administrators have access to individual networks and their devices. These users can have complete or limited control over their network configuration, but do not have access to organization-level information (licensing, device inventory, etc).

    • Network - Guest ambassador: The user is only able to see the list of Meraki authentication users, add users, update existing users, and authorize/de-authorize users on an SSID or Client VPN. Ambassadors can also remove wireless users, if they are an ambassador on all networks.

    • Network - Monitor-only: The user is only able to view a subset of the Monitor section in the dashboard and no changes can be made.

    • Network - Read-only: The user is able to access most aspects of a network, including the Configure section of the dashboard, but no changes can be made.

    • Network - Full: The user has access to view all aspects of a network and make any changes to it.

SAML

SAML (Security Assertion Markup Language) can be used with the Cisco Meraki Dashboard to provide external authentication of users and a means of SSO (Single Sign-On). SAML users can be organization administrators or network administrators. Assignment of permission to these roles is identical to that of normal users. SAML access is highly recommended in deployments already set up with an IdP.

SNMP vs API for Device Status Reporting

Many deployments will find that they benefit from some type of device reporting, or may have some kind of mechanism in place for monitoring device status. Options for monitoring devices include standard dashboard monitoring, SNMP reporting and API device status reporting. SNMP is an available option for users who are used to using an SNMP solution, but for large deployments (20,000+ devices), we highly recommend relying on device status reporting via the API for scalability. Smaller to medium-sized deployments may also find that an API solution for device reporting better suits their needs, so the option should be considered.

You can read more about our available API endpoints for device status reporting in our API docs.

Syslog Reporting

The Meraki dashboard has built-in event log reporting for all of its devices, but the event log is limited to a history of about 3 months. Any deployments that require longer historical records should deploy a syslog server solution in their deployment, and should enable syslog reporting on their networks. The MX Security Appliance supports sending four categories of messages/roles: Event Log, IDS Alerts, URLs, and Flows.  MR access points can send the same roles with the exception of IDS alerts. MS switches currently only support Event Log messages.

You can read more about setting up syslog with a Meraki deployment in our syslog Server Overview and Configuration article.

Zero-Touch Deployments

Cisco Meraki links their ordering and cloud dashboard systems together to give customers an optimal experience for onboarding their devices. Because all Meraki devices are pre-built for reaching out to cloud management, there is no pre-staging for device or management infrastructure needed to onboard your Meraki solutions. Configurations for all your networks can be made ahead of time, before ever installing a device or bringing it online, because configurations are tied to networks, and are inherited by each network's devices. Additionally, due to the real-time remote troubleshooting tools built into the dashboard, an IT Admin can remotely view the installation status while remote installers physically plug in ports and access points, allowing for a truly zero-touch deployment.

Each device, upon connecting to the internet, automatically downloads its configuration via the Meraki cloud, applying your network and security policies automatically so you don’t have to provision on-site. Wireless APs optimize their RF configuration based on the environment, and switches integrate seamlessly into existing RSTP domains. We recommend configuring your network ahead of time, before deploying, to ease installation time and avoid deployment errors.

Internet Access

Because each Meraki device gets all of its configuration information from the Meraki Cloud platform, the devices must have the ability to call out to the internet and access the Meraki platform for onboarding. This means that DHCP and DNS rules should be configured on your management VLAN and proper firewall rules should be opened outbound to make sure all Meraki devices are able to connect once they're turned on. A list of all ports and IPs needed for firewall rules can be found in your Meraki dashboard under Help > Firewall info, as the ports and addresses may vary based on region.

Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 7114

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community