Meraki Cloud Sizing and Scaling Considerations and Best Practices

Network & Device Management

For flexible environments with many admins and possibly hundreds of networks and devices, even a relatively simple script can drastically simplify the process of managing configurations across multiple networks and organizations down to a single command. For example, a script to update the SSID name can pull a list of networks and orgs accessible to the API user, and then execute the same SSID command on all orgs and networks, or allow the user to specify which ones to execute the command on.

 

On the Meraki Developer Hub, a demo project for a python script which manages administrators across organizations details how to install and use the script, as well as providing source code for the script, which can be used as a guide for writing your own scripts.

 

Another project describes a python script that manages MX firewall rules at scale, also providing source code and methods for installation for use with your own organizations.

Network Automation

For flexible scaled environments requiring regular audits, deploying networks or configuration changes in bulk, or performing other regular repetitive tasks, network and device management can also be automated using the API. It can be used for anything as simple as changing a single record on a scheduled basis, up to complex scripts that are triggered by other automatic processes and which output data to other processes or programs. 

 

A lab on the Meraki Developer Hub walks through the steps to set up Python to automate tasks with the Dashboard API and provides a good starting point for writing your own tools for automation.

 

For a more advanced example, involving integration with other services, a demo project walks through using ServiceNow to provision Meraki networks, tying in inventory management and touching on the concept of building your own application for more advanced control.

Action Batches

Action Batches are a feature of the dashboard API that let you store multiple actions for an organization in a single API command. This allows for complex chains of related commands to be executed at once, or in order, to simplify the number and variety of calls that need to be made from a script, integration, or solution. This can also be used to help work around issues that may be encountered with the 10 API calls-per-second limitation imposed by the dashboard API endpoints.

 

For example, adding a switch to a network, configuring all 48 ports, and setting the switch’s management interface in a single POST can be part of one single action batch. Each action batch counts as one call in regard to the 10 calls-per-second limit. For more information on action batches, please reference Cisco's DevNet article on action batches. 

Proactive Alerting with Webhooks

Alerts are vital for any network performance monitoring, and any network or organization scaling up needs an equally flexible and scalable way of receiving and responding to these alerts. The dashboard provides all networks with configurable alerts for certain significant network events; Webhooks provide the means to take these alerts and leverage them into actionable items and advanced monitoring data. Webhooks will send alerts to one or more configured HTTPS URLs, in the form of JSON objects; this allows them to be used by any service that can interpret JSON, leading to a wide range of possible integrations.

 

Integrations do not need to be complicated in order to be useful - for example, this demo project describes logging dashboard alerts to a Google Sheet that can be used to instantly track data and create reports in an accessible manner.

 

Another easy way to leverage webhooks is for a message to be sent in a collaboration app, such as Cisco WebEx Teams or Slack, when a particular incident occurs. In this example, automation service Zapier relays network alerts to WebEx Teams to notify critical teams of a new incident. Automation services in general can be used to take a variety of actions when a webhook is received, extending the functionality of network alerts.

Organization Administrators

Organizations with admins in the hundreds will be leveraging SAML authentication, possibly with multiple Identity Providers (IdP)s. Multiple SAML roles will be created in the org, to specify who is able to access specific sets of networks and what levels of privileges are available for each role. Manual admins will still be used on the org, but to a more limited degree. The main reason for this is that SAML admins cannot use the Dashboard API, so any API users will need to be standard admins for any orgs being used with the API.

 

These organizations and accounts will also use the Dashboard API to manage both standard administrators and SAML roles. The Admins endpoint can be used to add, change, or delete a standard admin on one or multiple orgs at once, and the SAML Roles endpoint can be used to get a list of one or more roles on an org, as well as add, change, or delete SAML roles.

 

For more information on configuring SAML SSO login, refer to the article Configuring SAML Single Sign-on for Dashboard.

Inventory & Per-Network Device Limits

In order to maintain optimal performance while interacting with the Dashboard UI, the total number of Meraki devices in networks across a single organization should stay within these limits. If your organization is approaching these limits as part of standard business operation, there are a few steps that can be taken to ensure these devices can still be managed optimally:

• Talk with your Meraki account team to discuss an Organization Split, in which part of the networks, devices, and licenses of an organization are split off into a separate dashboard org. This can also help for establishing a scheme for org splits which can act as a guideline to speed up the process of splitting orgs in the future.

• If a network is approaching or past the recommended per-device network limit, consider cloning the network within the organization and moving devices from one network to the other. This will maintain the network-level configurations while avoiding performance issues at higher numbers of devices in a network.

• Use the Dashboard API for management of the network, particularly in cases where multiple device-level configuration changes need to be made at once. This can also drastically simplify the process of maintaining configuration sync between two networks or two organizations.

• If you reach or expect to reach >700 organizations managed, talk to your Meraki account team about ways that this increase in scale can be addressed.

SNMP & Syslog

Organizations of both standard size and at scale leverage traditional monitoring protocols like Syslog and SNMP for both system and network logging purposes, and for reporting statistics on a device, network, and organization level. If your organization at scale will be implementing these technologies, a few considerations should be made:

• For SNMP, while Meraki devices can be polled directly to access information, the most useful information will be gathered by polling the dashboard using the proprietary Meraki MIB. This allows more detailed information to be gathered on device usage and network utilization; for more information on setting up SNMP, read our SNMP Overview and Configuration guide.

• Syslog can also be used to store events from the dashboard Event Log for analysis. This bypasses the limitations of the Event Log for storing events in dashboard, by allowing logs to be stored for a longer period of time, past the point where they would no longer show in the Dashboard event log. For more details, read our Syslog Server Overview and Configuration guide.

Auto VPN Deployments Across Multiple Organizations

As a scaled organization, it may be necessary to have multiple organizations that all need to leverage secure inter-site communications. Meraki provides a very low-touch solution for establishing VPN tunnels between different MXs for this purpose, called Auto VPN; however, MXs enabled for Auto VPN will only be able to build VPN tunnels with other MXs in the same dashboard organization. Therefore, if VPNs between multiple dashboard organizations are necessary, a few extra configuration steps and design considerations will need to be made to allow for this.

• Each individual organization should optimally have a hub-and-spoke topology, with one or more hub MXs establishing a larger amount of tunnels to their spokes. This lightens the tunnel and traffic load on smaller MXs, and allows them to stay within their rated limits for numbers of established tunnels, while making VPN access easier to organize.

• Hub MXs in Auto VPN can participate in routing protocols like OSPF and iBGP, which can be used to dynamically exchange routes between hubs in different organizations. iBGP is able to function on both NAT mode and Passthrough mode MXs, allowing for flexibility within an MX’s routing and VPN configuration.

• Secure tunnels can be established between hub MXs in different orgs by creating a “non-Meraki” IPSec VPN configuration in each org. These can be configured like any other non-Meraki IPSec VPN, where the tunnel will establish as long as Phase 1 and Phase 2 settings match between each MX.

Regulatory Domains

One consideration that needs to be made for any organization operating Meraki access points in multiple countries is the use and management of regulatory domains in each MR network. Regulatory Domains, which dictate the legal restrictions for wireless signal transmission, are different in each nation, and will need to be set explicitly per MR network. Because they are set on a per-network basis, APs in multiple different regulatory domains cannot be in the same dashboard network. Here is how this can be handled by a scaled organization.

• Organize access points into separate networks by regulatory domain to avoid issues with conflicts.

• For newly purchased access points, the regulatory domain is set by a combination of the ship-to location, and the IP geolocation of the public IP the AP reports when it first connects to the cloud. Keep this in mind when determining where to ship new access points on purchase, particularly if the APs go through pre-deployment testing in a different location.

• Even with preparation, your organization may still encounter instances in which an AP needs to be moved to a different network, or across regulatory domains, or otherwise encounter some form of regulatory domain conflict. The article on MR regulatory domains goes into further detail about how to determine the regulatory domain, and how to resolve regulatory domain changes, mismatches and conflicts.

MV Network Streaming and Usage Considerations

Streaming Video (regular usage)

• Each camera is constantly using ~50kbps of upstream BW for configuration data, metadata (motion, other detections)  
• On top of this, each camera will require a certain bitrate (between 0.5Mbps to 8Mbps) when video is being viewed from that camera
• When cloud streaming, this will be upstream BW requirements
• When cloud streaming, there is effectively no viewing limit
• When locally streaming, this will not be upstream BW requirements

MV Video Wall

• When creating a video wall, these bitrates add up to the total BW that will be required when viewing the video (we show this estimate on the UI)
• When the tile size is too low, we turn on adaptive bitrate streaming
• Dedicated hardware workstations for viewing video also have hardware requirements

Here's a diagram that can show you the different points of failure when streaming video:

 

Video Export (regular usage)

• We recommend at least 1Mbps upstream bandwidth per export, since cameras send video to the cloud before they are downloaded as exports

When MV Cloud Archive is Enabled (optional add-on license)

• At least 1Mbps upstream required per camera when using Cloud Archive

When External RTSP is Enabled

• External RTSP allows you to access video directly from the camera when on the camera’s local network. The stream will respect the bitrate configured on the dashboard. Note this when enabling external RTSP streams and ensure that your local network can handle the traffic

Video Streaming Limitations

Due to the fact that all Meraki MV cameras will record their footage to solid-state local storage on the camera itself, MV cameras are for the most part very low-bandwidth network devices. The primary exception is when streaming video from the dashboard; this will cause bandwidth usage to increase as video is sent from the camera’s local storage to the streaming client. When viewing a Video Wall, each camera will be streaming their own footage, which can put a burden on the bandwidth of a network depending on the bandwidth capacity and the number of cameras streaming to the video wall. Here are a few considerations to make:

• If a browser viewing MV video is on the same local network as the cameras being viewed, the cameras will stream directly to the client machine without using any WAN bandwidth. Keep this in mind if you are looking to deploy a security machine for viewing footage, especially for a large local deployment of cameras. For more information on this functionality, read the documentation article on direct streaming vs cloud proxy for cameras.

• If Cloud Archive is used, camera footage will use network bandwidth whenever the camera is recording for uploading video to the archive. Keep this in mind, particularly with large camera deployments, and plan your WAN bandwidth capacity accordingly. For more information, read the documentation article on the cloud archive feature.

Camera APIs

All second generation (MVx2) cameras are capable of processing powerful analytics on the camera itself and transmitting this metadata to the Meraki cloud. This architecture dramatically reduces the cost and complexity of gathering detailed analytics in any environment. Meraki cameras also include a suite of APIs for accessing these analytics and zeroing in on significant motion events. These tools allow organizations at scale to use their MV cameras as sensors and analysis engines for motion data with any of their organization cameras.