Building a Scalable Meraki Solution

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 you 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.
  • 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 20,000 Meraki devices in their 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 LANs 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, including 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 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.

SD-WAN

Each organization represents a separate SD-WAN instance. Meraki SD-WAN is implemented through 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 within 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 compliance with the GDPR 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 reasons (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 primary 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.