Cisco Meraki Best Practice Design

Routed (NAT) Mode

Routed mode on a Cisco Meraki MX is best used when the security appliance will be connecting directly to your internet demarcation point. When this is the case, the MX will have a public IP address that is issued by the internet service provider. The MX will also be the device handling the routing for clients to the internet, and any other networks configured for the device to communicate to.  This mode is optimal for networking environments that require a security appliance with Layer 3 networking capabilities.

Passthrough/VPN Concentrator Mode

Passthrough mode on a Cisco Meraki MX configures the appliance as a Layer 2 bridge for the network.  The MX in this mode will not perform any routing or any network translations for clients on the network.  Passthrough/Concentrator Mode is best used when there is an existing Layer 3 device upstream handling network routing functions.  The MX in this instance would still act as a security appliance, but with less functionality for Layer 3 networking.

The recommended use case for the MX security appliance in passthrough mode is when it is acting as a VPN Concentrator for the Cisco Meraki Auto VPN feature.  Passthrough/VPN Concentrator mode ensures easy integration into an existing network that may already have layer 3 functionality and edge security in place.  With this mode, a Cisco Meraki MX security appliance can be integrated into the existing topology and allow for seamless site to site communication with minimal configuration needed.

High Availability and Redundant WAN Connections

The recommended deployment to ensure the most possible uptime is an environment that combines two high availability paired MX appliances with multiple Internet Service Provider connections. In this architecture, there is full redundancy to minimize the possible downtime in the event of a failure in either an appliance or a service provider. 

High Availability (HA) Pair

When deploying two MX security appliances in high availability (HA), it is recommended to have the management traffic for HA traverse via a downstream connection to a layer 2 switch, and to not have a dedicated HA cable connected between the two appliances. The reason for this is because there is an increased potential for a spanning-tree loop if the MX appliances are also connected to the same layer 2 switch. The best topology is to have the MX appliances connected to the same downstream Layer 2 switch.

Addressing and VLANs

The best practice for planning and configuring a network is to have multiple VLANs for different traffic uses cases. This is especially recommended for separation of networks that will be hosting employee data and networks providing guest access. This is a critical consideration to ensure the maximum possible security for your networking environment. Using multiple VLANs for different use cases will also decrease the amount of broadcast traffic within the same subnet. When designing and configuring multiple VLANs, it is generally recommended to create the subnet to be sized for the necessary amount of devices intended to be in that particular network. Generally, networks with /24 subnet masks are large enough for common deployments, while also providing room for expansion and simple subnetting scalability if more VLANs are to be added. However, it is always best to consider the needs of your deployment when planning your subnets, as some deployments may require larger addressing spaces.

Routing and Layer 3 Connectivity

In certain deployments, the MX security appliance may not be the only device performing layer 3 functions for the entirety of the data network. Examples of this can be a deployment where the MX acts as the internet edge gateway while layer 3 routing is performed on downstream devices, or where another layer 3 capable device is added into the existing routing topology. If this is the case, then the MX security appliance must have static routes configured to allow for effective communication to the other layer 3 destinations in the network. The other layer 3 devices must also have static routes in place to the MX. 

In the example below, an MX is set up as an Internet edge firewall, with the rest of the layer 3 routing taking place on a downstream switch stack. With this configuration, it is best to have a single subnet configured between the MX and the other layer 3 device, to minimize the amount of traffic and routing that will be taking place as well as to keep routing consistency. This single subnet will act as a transit VLAN for all routing that is to take place between the two layer 3 endpoints in the topology. 

Layer 3 Firewall Rules

The MX security appliance allows for custom outbound firewall rules to be configured to ensure precise and granular control over which networks are able to communicate with one another.  The MX security appliance is a stateful firewall, meaning that all inbound connections are blocked unless they have either originated from within the MX or a forwarding rule is configured.  

By default, all VLANs configured on the MX security appliance will be able to communicate with one another.  If there are VLANs you wish to not be able to pass traffic between, firewall rules will need to be configured.  It is best practice to restrict the amount of traffic that can travel between subnets that are not closely related.  For example, it is recommended to create firewall rules to block all traffic from a VLAN that may be used for guest access from being able to contact other VLANs used for business operations.  

Additionally, if there are internal users that need internet access, but should be blocked from accessing a certain site or IP address, the firewall rules can be configured with IPs or URLs as the destinations. The use case for this is if you know of a website the users in that VLAN should not access.

Layer 7 Firewall Rules

Best practice design for Layer 7 rules is to ensure that the category you have selected to block does not fall under the traffic flow for applications you may use.  For example, if you choose to block the category for "File Sharing," and you block all options, you may cause a disruption in service for an application such as Microsoft OneDrive.  It is best to try and configure Layer 7 rules as granular as possible, to avoid such scenarios.

Using Layer 7 firewall rules for blocking traffic based on countries also has its caveats as well.  While it may seem more secure to block all countries other than the one the MX is located in, this can cause issues with traffic flows to certain resources that may actually be necessary for daily operations.  Certain webpages and web applications can be hosted in a country not being blocked, but they may pull supplementary data or resources from a server located in a country that is being blocked by the MX appliance.  As a result, certain aspects may not function as intended or may fail to function altogether.  It is essential to only block countries with a Layer 7 rule if you know traffic from this country is malicious in nature.  

Port Forwarding and NAT Rules

Due to the nature of the Cisco Meraki MX, all inbound traffic that did not originate from within the networks configured on the appliance will be dropped by default. This is because the MX security appliance is a stateful firewall, so the MX must be aware of or expecting incoming traffic.  For connections that originate from outside of the MX and need to be allowed in, either a port forwarding rule or a NAT rule can be configured to permit this traffic.  

Advanced Malware Protection (AMP)

Advanced Malware Protection (AMP) is an adaptive and powerful tool that is incorporated on the Cisco Meraki MX security appliance with the Advanced Security license.  AMP scans and inspects HTTP downloads that are moving through the MX security appliance.  The MX then takes action based on the threat intelligence it receives from the AMP cloud.  If a download matches a known signature from the AMP cloud, then the security appliance will block the download.  With an MX security appliance, it is highly recommended to have AMP enabled and functioning so your networking environment is secure and safe from attacks. 

Intrusion Detection and Prevention (IDS/IPS)

With the Advanced Security license, Intrusion Detection and Prevention (IDS/IPS) enables the MX security appliance to inspect all incoming and outgoing traffic that is being routed internally and externally in the networking environment. IDS/IPS searches for various signature-based attacks as traffic flows through the security appliance. This is achieved with the various rules and signatures that are in the SNORT® intrusion detection engine. This enables the MX to detect malicious traffic and not only provides alerts that a known signature was detected, but also take action against that threat and prevent it from doing harm on the network. To ensure a secure and stable networking environment, it is recommended to have Intrusion Detection and Prevention services enabled and operating on the MX.  

IP Source Address Spoofing Protection

IP Source Address Spoofing Protection is a security mechanism on the Cisco Meraki MX that enables protection from malicious users on the network from impersonating other hosts and attempting to bypass security restrictions.  The MX uses several methods of traffic verification to ensure client data is authentic and not spoofed by a malicious attacker.  It is recommended to have this feature set to the mode "Block" so malicious IP spoofing events are mitigated on the network by the MX security appliance as soon as they are identified. There is the option to have the mode set to "Log" but this will not provide protection against these types of attacks, but rather just alert that malicious traffic of this nature has been detected. 

Meraki Auto VPN

The MX security appliance allows for simple and seamless integration and configuration of VPN tunnels among sites.  This is achieved with Meraki's proprietary Auto VPN functionality that allows for simple and fast configuration of site to site VPN tunnels.  Additionally, Auto VPN enables maximum uptime of the site-to-site tunnels with congruent VPN tunnels on all available WAN interfaces. VPN tunnels are built actively on all WAN interfaces on the MX that can reach the Meraki cloud.  This allows for dynamic failover and built-in redundancy with no extra configuration needed.  It is recommended to use Meraki Auto VPN between MX security appliances for essential inter-site communication. Note that Auto VPN can only be used for Meraki to Meraki communications, for Meraki devices in the same Meraki dashboard organization. Separate Meraki dashboard organizations generally represent separate SD-WAN environments.

Uplink Configuration

Under the SD-WAN settings, the uplink connections for the MX security appliance can be configured to best fit the needs of your networking environment.  The uplink bandwidth limit can be configured and changed to best fit the requirements of the connection with your internet service provider.  It is best practice to set the throughput bandwidth to the highest possible amount based on your bandwidth set by your provider as to avoid potentially saturating the connection.  

For uplink monitoring, it is recommended to configure multiple uplink statistic test IPs on the Meraki dashboard.  This is exceptionally useful for troubleshooting purposes, as it allows the dashboard to collect and monitor data on certain connections specified.  A few examples of connections to monitor would be a general connection to the internet (Google's 8.8.8.8 is configured by default), the connection to your service provider gateway, and the connection to any remote sites that may be participating in site to site VPN tunneling. 

Another feature of the functionality that the MX includes is automatic security list updates for features such as AMP, IDS/IPS, and content URL filtering.  These lists can be configured to check for changes in security rules on an hourly, daily, or weekly basis.  The best practice to ensure your environment stays secure is to have this interval set to check the security lists hourly.  The frequency of updates can be changed per each WAN uplink, including the cellular uplink as well.  

Uplink Selection

Included with the SD-WAN options is the ability to have the MX route traffic to different uplinks depending on certain scenarios. Uplink selection enables the ability of policy-based routing on the MX, which uses flow preferences for specific traffic as it heads out the WAN connection. With this tool, it is recommended to have the uplink connections be set to load balance the traffic if applicable. This is best used if there are redundant internet connections that have similar bandwidth capabilities.  

With flow preferences based on the source traffic, it is easy to shape traffic to best fit the nature of the network traffic as it transverses to the WAN connection. An example of what a flow preference may be used for is guest traffic.  To allow for a consistent and stable connection the more cost-effective secondary WAN connection can be configured to handle guest related traffic. 

SD-WAN Policies

SD-WAN policies can be configured to control and modify the flows for specific VPN traffic. With multiple WAN uplinks, the MX will proactively build multiple tunnels with each available WAN interface.  In the case where there are redundant WAN connections on the security appliance, traffic flows based on the type of traffic traversing the VPN connections can also be configured to allow for best performance. Custom policies set to desired preferences can be set to ensure traffic flows take the appropriate path based on your environment.  If a WAN connection that normally handles traffic such as file transfers begins to have performance issues, the Cisco Meraki MX can dynamically change the VPN connection to an alternative WAN uplink. This is done with custom policies or predetermined policies on the dashboard. It is encouraged to configure said policies in your deployment to best fit the needs based on the nature of the traffic and the capabilities of the WAN connections available on the MX. 

Global Bandwidth Limits

In larger deployments, bandwidth limits for end-user devices can to be put in place to ensure the uplinks do not become saturated. This largely depends on the type of traffic that is seen from users, how many users are on the network, as well as the throughput capabilities of the MX security appliance and the uplinks. With more substantial deployments where there are a large number of clients, it is recommended to set a bandwidth limit on all traffic. The amount of bandwidth required per client can vary depending on the type of traffic seen in the networking environment.  

Speedburst is an option to allow clients a short window of time to exceed the bandwidth limit configured to allow, for example, a large file to transfer faster. This is a useful feature if there are users that will be handling and uploading large files frequently on the network. Speedburst is a recommended feature to enable, with the caveat that it should only be used if there are not a large number of clients that will need high amounts of bandwidth at the same time. If there are a select few users or devices that require moments of higher bandwidth then Speedburst is recommended.

Traffic Shaping Rules

Different types of traffic require different priorities on the network.  The MX is able to prioritize and shape traffic on the local network based on the traffic type.  The Meraki dashboard offers default traffic shaping rules that best fit the needs for most deployments.  These default rules ensure best performance for local voice traffic, software updates for end client devices, and collaboration applications.  It is recommended to enable these default traffic shaping rules on the MX as it allows for simple and fast configuration for the best performance of network traffic.

Auto VPN at the Branch

Before configuring and building Auto VPN tunnels, there are several configuration steps that should be reviewed.

WAN Interface Configuration

While automatic uplink configuration via DHCP is sufficient in many cases, some deployments may require manual uplink configuration of the MX security appliance at the branch. The procedure for assigning static IP addresses to WAN interfaces can be found in our MX IP assignment documentation.

Some MX models have only one dedicated Internet port and require a LAN port be configured to act as a secondary Internet port via the device local status page if two uplink connections are required. MX models that require reconfiguring a LAN port as a secondary Internet port currently include the MX64 line, MX67 line, and MX100 devices. This can also be verified per-model in our installation guides online. This configuration change can be performed on the device local status page on the Configure tab.

Subnet Configuration

Auto VPN allows for the addition and removal of subnets from the Auto VPN topology with a few clicks. The appropriate subnets should be configured before proceeding with the site-to-site VPN configuration.

Hub Priorities

Hub priority is based on the position of individual hubs in the list from top to bottom. The first hub has the highest priority, the second hub the second highest priority, and so on. Traffic destined for subnets advertised from multiple hubs will be sent to the highest priority hub that a) is advertising the subnet and b) currently has a working VPN connection with the spoke. Traffic to subnets advertised by only one hub is sent directly to that hub.

Configuring Allowed Networks

To allow a particular subnet to communicate across the VPN, locate the local networks section in the Site-to-site VPN page. The list of subnets is populated from the configured local subnets and static routes in the Addressing & VLANs page, as well as the Client VPN subnet if one is configured.

To allow a subnet to use the VPN, set the Use VPN drop-down to yes for that subnet.

Auto VPN at the Data Center

Deploying a One-Armed Concentrator

A one-armed concentrator is the recommended datacenter design choice for an SD-WAN deployment. The following diagram shows an example of a datacenter topology with a one-armed concentrator:

NAT Traversal

Whether to use Manual or Automatic NAT traversal is an important consideration for the VPN concentrator.

Use manual NAT traversal when:

• There is an unfriendly NAT upstream

• Stringent firewall rules are in place to control what traffic is allowed to ingress or egress the datacenter

• It is important to know which port remote sites will use to communicate with the VPN concentrator

If manual NAT traversal is selected, it is highly recommended that the VPN concentrator be assigned a static IP address. Manual NAT traversal is intended for configurations when all traffic for a specified port can be forward to the VPN concentrator.

Use automatic NAT traversal when:

• None of the conditions listed above that would require manual NAT traversal exist

If automatic NAT traversal is selected, the MX will automatically select a high numbered UDP port to source Auto VPN traffic from. The VPN concentrator will reach out to the remote sites using this port, creating a stateful flow mapping in the upstream firewall that will also allow traffic initiated from the remote side through to the VPN concentrator without the need for a separate inbound firewall rule.

Topology

The following is an example of a topology that leverages an HA configuration for VPN concentrators:

Behavior

When configured for high availability (HA), one MX is active, serving as the primary, and the other MX operates in a passive, standby capacity. The VRRP protocol is leveraged to achieve failover. Check out our MX Warm Spare documentation for more information.

MX IP Assignment

In the datacenter, an MX Security Appliance can operate using a static IP address or an address from DHCP. MX appliances will attempt to pull DHCP addresses by default. It is highly recommended to assign static IP addresses to VPN concentrators.

Uplink IPs

Use Uplink IPs is selected by default for new network setups. In order to properly communicate in HA, VPN concentrator MXs must be set to use the virtual IP (vIP).

Virtual IP (vIP)

Virtual IP is an addressing option that uses an additional (third) IP address that is shared by the HA MXs. In this configuration, the MXs will send their cloud controller communications via their uplink IPs, but other traffic will be sent and received by the shared virtual IP address.

Failover Times

There are several important failover timeframes to be aware of:

Configuring OSPF Route Advertisement

MX Security Appliances support advertising routes to connected VPN subnets via OSPF. 

An MX with OSPF route advertisement enabled will only advertise routes via OSPF; it will not learn OSPF routes.

When spoke sites are connected to a hub MX, the routes to spoke sites are advertised using an LS Update message. These routes are advertised as type 2 external routes.

BGP and Auto VPN

BGP VPNs are utilized for Data Center Failover and load sharing. This is accomplished by placing VPN Concentrators at each Data Center. Each VPN Concentrator will utilize BGP with DC edge devices. BGP is utilized for its scalability and tuning capabilities.

More information about implementing BGP and its use cases can be found in our BGP documentation.

Dashboard & Cloud

The MX Security Appliance is a cloud managed networking device. As such, it is important to ensure that the necessary firewall policies are in place to allow for monitoring and configuration via the Meraki dashboard. The relevant destination ports and IP addresses can be found under the Help > Firewall Info page in the dashboard.

VPN Registry

Meraki's Auto VPN technology leverages a cloud-based registry service to orchestrate VPN connectivity. In order for successful Auto VPN connections to establish, the upstream firewall must allow the VPN concentrator to communicate with the VPN registry service. The relevant destination ports and IP addresses may vary by region, and can be found under the Help > Firewall Info page in the dashboard.

Uplink Health Monitoring

The MX also performs periodic uplink health checks by reaching out to well-known Internet destinations using common protocols. The full behavior is outlined here. In order to allow for proper uplink monitoring, the following communications must also be allowed:

• DNS test to canireachthe.net

• Internet test to icmp.canireachthe.net

Hardware Redundancy in VPN Concentrator Mode

MX VPN Concentrator warm spare is used to provide high availability for a Meraki Auto VPN head-end appliance. Each concentrator has its own IP address to exchange management traffic with the Meraki Cloud. However, the concentrators also share a virtual IP address that is used for non-management communication.

MX VPN Concentrator - Warm Spare Setup

Before deploying MXs as one-arm VPN concentrators, place them into Passthrough or VPN Concentrator mode on the Addressing and VLANs page. In one-armed VPN concentrator mode, the units in the pair are connected to the network "only" via their respective ‘Internet’ ports. Make sure they are NOT connected directly via their LAN ports. Each MX must be within the same IP subnet and able to communicate with each other, as well as with the Meraki dashboard. Only VPN traffic is routed to the MX, and both ingress and egress packets are sent through the same interface.

MX VPN Concentrator - Virtual IP Assignment

The virtual IP address (vIP) is shared by both the primary and warm spare VPN concentrator. VPN traffic is sent to the vIP rather than the physical IP addresses of the individual concentrators. The virtual IP is configured by navigating to Security appliance > Appliance status when a warm spare is configured. It must be in the same subnet as the IP addresses of both appliances, and it must be unique. It cannot be the same as either the primary or warm spare's IP address.

The two concentrators share health information over the network via the VRRP protocol. Failure detection does not depend on connectivity to the Internet/Meraki dashboard.

MX VPN Concentrator - Failure Detection

In the event that the primary unit fails, the warm spare will assume the primary role until the original primary is back online. When the primary VPN concentrator is back online and the spare begins receiving VRRP heartbeats again, the warm spare concentrator will relinquish the active role back to the primary concentrator. The total time for failure detection, failover to the warm spare concentrator, and ability to start processing VPN packets is typically less than 30 seconds.

MX Warm Spare Alerting

There are a number of options available in the Meraki dashboard for email alerts to be sent when certain network or device events occur, such as when a warm spare transition occurs. This is a recommended configuration option and allows a network administrator to be informed in the event of a failover.

The event, “A warm spare failover occurs,” sends an email if the primary MX of a High Availability pair fails over to the spare, or vice-versa.

This alert and others, can be referenced in our article on Configuring Network Alerts in Dashboard.

If you are having difficulties getting warm spare to function as expected, please refer to our MX Warm Spare - High Availability Pair document.

HW Redundancy in NAT mode

MX NAT Mode – Warm Spare

MX NAT Mode Warm Spare is used to provide redundancy for internet connectivity and appliance services when an MX Security Appliance is being used as a NAT gateway.

MX NAT Mode - Warm Spare Setup

In NAT mode, the units in the HA pair are connected to the ISP or ISPs via their respective Internet ports, and the internal networks are connected via the LAN ports.

WAN configuration: Each appliance must have its own IP address to exchange management traffic with the Meraki cloud. If the primary appliance is using a secondary uplink, the secondary uplink should also be in place on the warm spare. A shared virtual IP, while not required, will significantly reduce the impact of a failover on clients whose traffic is passing through the appliance. Virtual IPs can be configured for both uplinks.

LAN configuration: LAN IP addresses are configured based on the Appliance IPs in any configured VLANs. No virtual IPs are required on the LAN.

Additional warm spare configuration details can be found in our article, MX Warm Spare - High Availability Pair.

MX NAT Mode - Virtual IP Assignment

Virtual IP addresses (vPs) are shared by both the primary and warm spare appliance. Inbound and outbound traffic uses this address to maintain the same IP address during a failover to reduce disruption. The virtual IPs are configured on the Security Appliance > Monitor > Appliance status page. If two uplinks are configured, a vIP can be configured for each uplink. Each vIP must be in the same subnet as the IP addresses of the appliance uplink it is configured for, and it must be unique. It cannot be the same as either the primary or warm spare's IP address.

MX NAT Mode - Failure Detection

There are two failure detection methods for NAT mode warm spare. Failure detection does not depend on connectivity to the Internet / Meraki dashboard.

WAN Failover: WAN monitoring is performed using the same internet connectivity tests that are used for uplink failover. If the primary appliance does not have a valid Internet connection based on these tests, it will stop sending VRRP heartbeats which will result in a failover. When uplink connectivity on the original primary appliance is restored and the warm spare begins receiving VRRP heartbeats again, it will relinquish the active role back to the primary appliance.

LAN Failover: The two appliances share health information over the network via the VRRP protocol. These VRRP heartbeats occur at layer 2 and are performed on all configured VLANs. If no advertisements reach the spare on any VLAN, it will trigger a failover. When the warm spare begins receiving VRRP heartbeats again, it will relinquish the active role back to the primary appliance.

MX NAT Mode – DHCP Synchronisation

The MXs in a NAT mode high availability pair exchange DHCP state information over the LAN. This prevents a DHCP IP address from being handed out to a client after a failover if it has already been assigned to another client prior to the failover.

DC-DC Failover - Hub/Data Center Redundancy (Disaster Recovery)

Meraki's MX Datacenter Redundancy (DC-DC Failover) allows for network traffic sent across Auto VPN to failover between multiple geographically distributed datacenters.

DC Failover Architecture

A DC-DC failover architecture is as follows:

• One-armed VPN concentrators or NAT mode concentrators in each DC

• A subnet(s) or static route(s) advertised by two or more concentrators

• Hub & Spoke or VPN Mesh topology

• Split or full tunnel configuration

Operation and Failover

Deploying one or more MXs to act as VPN concentrators in additional data centers provides greater redundancy for critical network services. In a dual- or multi-datacenter configuration, identical subnets are advertised from each datacenter with a VPN concentrator mode MX.

In a DC-DC failover design, a remote site will form VPN tunnels to all configured VPN hubs for the network. For subnets that are unique to a particular hub, traffic will be routed directly to that hub. For subnets that are advertised from multiple hubs, spoke sites will send traffic to the highest priority hub that is reachable.

When an MX Security Appliance is configured to connect to multiple VPN concentrators advertising the same subnets, the routes to those subnets become tracked. Hello messages are periodically sent across the tunnels from the remote site to the VPN hubs to monitor connectivity. If the tunnel to the highest priority hub goes down, the route is removed from the route table and traffic is routed to the next highest priority hub that is reachable. This route failover operation only applies when identical routes are advertised from multiple Auto VPN hubs.

Concentrator Priority

When multiple VPN hubs are configured for an organization, the concentrator priority can be configured for the organization. This concentrator priority setting determines the order in which VPN mesh peers will prefer to connect to subnets advertised by multiple VPN concentrators.

This setting does not apply to remote sites configured as VPN spokes.

Other Datacenter Considerations

When implementing an DC-DC architecture, a warm spare concentrator configuration (see warm spare section above) and OSPF route advertisement should always be taken into consideration for MXs acting as VPN concentrators in a datacenter. Additionally, route flow logic should be considered for all applications in the deployment environment to ensure availability requirements are met. To assist with better understanding DC-initiated flows, please refer below.

VPN Topologies

There are several options available for the structure of the VPN deployment.

Standard Hub & Spoke

How it works:

Utilizing the standard Meraki Auto VPN registry to ascertain how the VPN tunnels configured need to form (i.e. via public address space or via private interface address space) as described in Configuring Site-to-site VPN over MPLS.

When should it be used?

Whenever possible. It is strongly recommended that this model is the 1st, 2nd and 3rd option when designing a network. Only if the deployment has an exceptionally strong requirement should one of the following hub and spoke derivatives be considered.

VPN Mesh

It is also possible to use a VPN mesh configuration in an SD-WAN deployment.

In a mesh configuration, an MX appliance at the branch or remote office is configured to connect directly to any other MXs in the organization that are also in mesh mode, as well as any spoke MXs that are configured to use it as a hub.

• Full Mesh - Total Tunnel Count = (N x (N-1)2)xL- Where N is the number of MXs and L is the number of uplinks each MX has.

For example, if all MXs have 2 uplinks and there are 50 MXs, then the total number of VPN tunnels would be 2450 and every MX would have to be able to support 196 tunnels from  the number of VPN peers for a single MX (49) multiplied by the number of VPN tunnels between each peer (4), in this case, we would need 50 MX100s as a minimum.

China Auto VPN Architecture

In the above diagram, we are utilizing Meraki Auto VPN to connect the enterprise sites inside China. The above diagram also demonstrates the Chinese government-approved dedicated circuits connecting the Chinese parts of the enterprise to the rest of the global enterprise. Dynamic routing such as BGP or OSPF can be utilized to exchange routing information between the domains.

Creating a Template Network

As outlined above, a template network should be created for each type of site to be deployed.

To create a template network:

1. In the dashboard, navigate to Organization > Monitor > Configuration templates

2. Choose Create a new template

3. Select a descriptive name for your template. If this is a completely new template, select Create new

   • If this template should be based on an existing network, select Copy settings from and select an existing Security appliance network from the drop-down menu.

4. Choose Add:

5. If you would like to bind existing networks to this new template, select those networks as Target networks and choose Bind. Otherwise, choose Close.

Template VLAN Configuration

1. In the dashboard, navigate to Security & SD-WAN > Configure > Addressing & VLANs

2. Under Routing section, LAN setting sub-section click VLANs 

3.  Choose Add VLAN under Subnets sub-section

4. Select a descriptive name for your VLAN

5. Choose whether the subnetting should be Same or Unique for every network bound to this template.

   • If Same is chosen, all the networks bound to the template will share the exact same subnet. This is not eligible for site-to-site VPNs.

   • If Unique is chosen, each network bound to the template will get a unique subnet based on the configured options. The MX does allow local VLAN overrides on templates, however, the chosen subnet needs to be from the same subnet pool assigned to the VLAN on the template and you can't override the VLAN ID. 

     • Subnets are assigned randomly to each network bound to the template.

For more information about template IP range VLAN allocation, reference our article on Managing Networks with Configuration Templates.

Template Static Routes

In template-based MX deployments, static routes can be configured on the parent template and passed to child networks like other configuration parameters.  The procedure for configuring a template-based static route is almost identical to the procedure for a regular network, with the exception of how next-hop IP addresses are defined as the next-hop value may be network specific.

1. In the dashboard, navigate to Security & SD-WAN > Addressing & VLANs > Routing > Static Routes

2. Choose Add Static Route

• Name  

  • Text description for the static route(not parsed)

    • Ex: prodWirelessNet

• Subnet 

  • Subnet reachable via static route specified in CIDR notation

    • Ex: 10.0.10.0/24  

• Next Hop IP

  • Next-hop IP is the IP address of the device that connects the MX Security Appliance to this route.  There are two methods for specifying next-hop values on template-based networks. 

    • Option A: IP Assignment

      • Manually define next-hop value

      • Required Info: 

        • Next-hop IP address

    • Option B: IP offset

      • Calculate next-hop IP based on network address for specified VLAN 

        • NOTE: Next Hop IP will be calculated as Network Address + Offset and not MX IP + Offset

      • IP offset parameters: 

        • Select the desired VLAN from the dropdown

        • Offset value (a positive integer) 

      • Example:

        • VLAN configured: 10.0.254.0/30

        • VLAN MX IP: 10.0.254.1

        • Offset: 2 

        • Calculated route next-hop IP: 10.0.254.2

• Active 

  • The active modifier controls conditions that must be met for the MX to deem the route usable and add the route to the local routing table. 

    • Always: 

      • The route will always be active in MXs' routing table 

    • While next-hop responds to ping: 

      • The route is available as long as the configured next hop is responding to pings

    • While host responds to ping:

      • The route is available as long as the configured host is responding to pings

Template Firewall Rules

When configuring layer 3 firewall rules, CIDR notation, as well as the VLAN name, can be used. The VLAN name is used when the entire subnet needs to be specified whereas CIDR notation is used when more flexibility is needed to specify the subnets.

1. Go to Security & SD-WAN > Configure > Firewall > Layer 3, click Add a rule

2. Choose the policy, specify if the rule matched should be allowed or denied

3. Select the protocol to match in outbound traffic

4. Specify the IP address or range using CIDR notation to match the outbound traffic. Note that also the name of the VLAN can be chosen as well

5. Choose the Src/dst port to match in outbound traffic

Template SD-WAN Policies

1. SD-WAN policies can be configured to control and modify the flows for specific VPN traffic. You can have a specific type of traffic go over one Uplink over the other. 
    

2. Go to Security & SD-WAN > Configure > SD-WAN & traffic shaping > SD-WAN policies > VPN traffic, and choose Add a preference

3. You'll be prompted with the Uplink selection policy dialog box. From this box, you can define the type of traffic that should adhere to the policy on the Traffic filters section. You can either add Custom expressions to select traffic based on Protocol/Source/Destination criteria, or you can select traffic based on pre-defined applications. 

   • To add a custom expression to select traffic. 

     • Choose Add +

     • The Custom expressions option should already be selected.

     • Choose the Protocol. You can choose either TCP, UDP, ICMP or Any

     • Choose Source to define the source address criteria. You can select one of the following: 

       • You can choose Any

       • You can type in the source in CIDR format( eg: 10.0.0.0/8), and then choose Add

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then choose Add VLAN

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then click Host, type in the last octet of the host address, then choose on Add host

     • Choose the Src port. The Source port could be 'Any', a port number (eg: 2000), or a port range (eg: 2000-3000) within 1-65535.

     • Click Destination to define the source address criteria. You can select one of the following: 

       • You can choose Any

       • You can type in the source in CIDR format( eg: 10.0.0.0/8), and then choose Add

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then choose Add VLAN

       • You can choose a VLAN from the drop-down menu with the list of VLANs and then choose Host, type in the last octet of the host address, then choose Add host

     • Choose the Dst port. The Destination port could be 'Any', a port number (eg: 2000), or a port range (eg: 2000-3000) within 1-65535.

   •  To add a pre-defined application to select traffic.

     • Select the application type from the menu and then the interesting application in question from the sub-menu (e.g., VoIP & video conferencing > Webex)

     • Add all the applications which you want them to adhere to the policy and then choose Add+ to exit the applications menu

4. Under the Policy section, you can select one of the following as the Preferred uplink

   • WAN1 or WAN2. If you choose WAN1 or WAN2, you'll have the opportunity to configure failover criteria under Fail over if drop-down menu. You can select either Poor performance and then choose one of the performance classes from the Performance class drop-down menu or you can choose Uplink down.  By default, VoIP is the only pre-defined performance class. Any additional performance classes have to be defined under Security & SD-WAN > Configure > SD-WAN & traffic shaping > SD-WAN policies > Custom performance classes.

   • Best for VoIP. The uplink that is best for VoIP traffic will be chosen.

   • Load balance. The MX will balance traffic across the uplinks that meet the performance class selected from On uplinks that meet performance class drop-down menu.

   • Global preference. The uplink will be chosen based on the configuration under Security & SD-WAN > Configure > SD-WAN & traffic shaping > Uplink selection > Global preferences. 

5. Once you are done with configuring the criteria to apply the policy and the policy, choose Save

Local Overrides

Once an MX Security Appliance network has been bound to a template, some options can still be configured normally through the dashboard. Any local configuration changes made directly on the MX network will override the template configuration.

In the example below, the bound MX was directly configured to have a custom Default VLAN. This change can be made in the template network, under Security & SD-WAN > Configure > Addressing & VLANs:

If a network is removed from a template, local overrides will automatically be lost as well as any template related configuration. The MX will automatically get the configuration from the network it is on.

DHCP Exceptions

The Meraki MX appliance provides a fully-featured DHCP service that can be enabled and configured on each VLAN individually. When bound to a template, local overrides can be made to the DHCP configurations under Security & SD-WAN > Configure > DHCP.

Forwarding Rules Overrides

To override forwarding rules, navigate under Security & SD-WAN > Configure > Firewall > Forwarding rules overrides.

Active-Active AutoVPN

To override the uplink selection rules for Active-Active AutoVPN, navigate to Security & SD-WAN > Configure > SD-WAN & traffic shaping  > Active-Active AutoVPN.

Templates with MXs of Different Port Counts

You can toggle the LAN2 port between LAN and Internet, through Uplink configuration under the Local status tab on the Local Status Page.

Switch Stacking

The following steps explain how to prepare a group of switches for physical stacking, how to stack them together, and how to configure the stack in the dashboard:

1. Add the switches into a dashboard network. This can be a new dashboard network for these switches, or an existing network with other switches. Do not configure the stack in the dashboard yet.

2. Connect each switch with individual uplinks to bring them both online and ensure they can check in with the dashboard.

3. Download the latest firmware build using the Firmware Upgrade Manager under Organization > Monitor > Firmware Upgrades. This helps ensure each switch is running the same firmware build.

4. With all switches powered off and links disconnected, connect the switches together via stacking cables in a ring topology (as shown in the following image). To create a full ring, start by connecting switch 1/stack port 1 to switch 2/stack port 2, then switch 2/stack port 1 to switch 3/stack port 2 and so forth, with the bottom switch connecting to the top switch to complete the ring.

5. Connect one uplink for the entire switch stack.

6. Power on all the switches, then wait several minutes for them to download the latest firmware and updates from the dashboard. The switches may reboot during this process.

   • The power LEDs on the front of each switch will blink during this process.

   • Once the switches are done downloading and installing firmware, their power LEDs will stay solid white or green.

7. Navigate to Switch > Monitor > Switch stacks.

8. Configure the switch stack in the dashboard. If the dashboard has already detected the correct stack under Detected potential stacks, click Provision this stack to automatically configure the stack.

9. Otherwise, to configure the stack manually:

• Navigate to Switch > Monitor > Switch stacks.

• Click add one / Add a stack:

• Select the checkboxes of the switches you would like to stack, name the stack, and then click Create.

The configuration is complete and the stack should be up and running.

• Use 2 ports on each of “top” and “bottom” switches of the stack for uplink connectivity and redundancy.
• Configure cross-stack link aggregation for uplink connectivity  

Warm Spare for Layer 3 Switches

MS Series switches configured for layer 3 routing can also be configured with a “warm spare” for gateway redundancy. This allows two identical switches to be configured as redundant gateways for a given subnet, thus increasing network reliability for users.

Note that, while warm spare is a method to ensure reliability and high availability, generally, we recommend using switch stacking for layer 3 switches, rather than warm spare, for better redundancy and faster failover.

Warm Spare is built on VRRP to provide clients with a consistent gateway. The switch pair will share a virtual MAC address and IP address for each layer 3 interface. The MAC address will always begin with 00-00-5E-00-01, and the IP address will always be the configured interface IP address on the primary. Clients will always use this virtual IP and MAC address to communicate with their gateway.

• For redundancy, ensure an alternate path exists for the exchange of VRRP messages between the Primary and Spare. A direct connection between the Primary and Spare is recommended

The Aggregation Layer

The best networks have redundancy, so our recommended environment will leverage the stackable switches capable of running layer 3 features like the MS425 at the aggregation layer. This will allow the network to get 40 Gigabit connections to interconnect the two aggregation layer switches for physical redundancy as well as the resiliency of protocol failover in this setup. This way, the gateway remains up.

To begin, the MS425s should be online and connected to their gateway upstream. This will allow them to download any available firmware updates, in addition to grabbing any configuration changes made (before or after deployment). If the switches are online, the status LED should be solid white. If the LED is not turning white several minutes after being connected, the MS425 Series Installation Guide can be used to help troubleshoot. In the dashboard, the units should show a green status, meaning the the device is connected, has received the latest configuration, and is ready to go.
 

One the switches are online, the next step is to configure the dedicated QSFP+ stacking ports on the back of the switch to act as stacking ports. This can be configured across many switches in the dashboard via Switch > Switch Ports or for each individual switch, by clicking on the ports.

In the switch port configuration window, select stacking and save the configuration. This will push the change to the switches and the ports will be enabled for stacking. The next step is to configure the stack members in dashboard. This can be done on the Switch > Switch Stacks page in the dashboard. Switch stack members can either be selected from the Detected potential stacks section, or by selecting add one near the top of the page. Once the switches have been added to a stack in the dashboard, it will take about a minute for them to receive their configuration. Once the switches have received their stacking configuration from the dashboard, they will appear on the detected stacks list.

Name the stack and save changes to get the switches ready for adding interfaces and routes. The next step is to configure VLANs on a switch or stack basis under Switch > Routing and DHCP. From there, interfaces and static routes can be configured to keep traffic restricted. Click Add a static route or Add an interface and fill out the appropriate information, making sure to select the switch stack that was defined earlier.

After this configuration has been completed, OSPF can also optionally be enabled. The need for this depends on the size of the campus, with larger environments generally being more likely to require a dynamic routing protocol among sites/locations. OSPF is enabled via Switch > OSPF, and enabling it will provide failover capabilities for redundant internet paths as well as connections between buildings. If choosing to use OSPF, enable it, advertise the appropriate interfaces and set the Hello and Dead timers to the desired values. It is generally bast practice to start with low timer values of 1 (Hello) and 3 (Dead), but your network may require higher values if there is a great deal of delay or distance between your devices.

This configuration will provide a foundation for the campus architecture at the aggregation layer. The next part to configure for the campus architecture is the Access Layer.

The Access Layer

Once the aggregation layer has been configured, a campus network architecture will require a way to connect end-users and clients to the network. It is generally recommended best practice to introduce physical stacking into the access or edge of the network. Physical stacking will provide a high-performance and redundant access layer to minimize any type of failure that might occur, while giving the network ample bandwidth for an enterprise deployment. The MS350 is an ideal example of an access layer switch that has been engineered for this purpose with fully redundant power supplies and fans, plus the ability to stack up to eight switches, providing up to 384 ports in a single stack. Stacked access layer switches like the MS350 should provide ample connectivity for a network closet to accommo­date a floor or a wing of a floor, and coupled with 160 Gbps stack bandwidth, multiple uplinks can be used with cross-stack link aggregation to achieve more throughput to aggregation or core layers. High bandwidth uplinks through access-layer port stacking will allow integration with the stacked aggregation layer MS425s that were setup earlier to provide redun­dancy from access to core, minimizing any sort of failures that might occur.

Before configuring a switch stack, every switch should be added to the same dashboard network and individually brought online with separate, individual uplinks. This ensures that the switches are up-to-date with the latest (and same) firmware versions, and helps ensure the entire stack will come online. 
To begin setting up stacking, the first step is to connect the stack links. Make sure the switches are powered down for this. As best practice, stacking should be set up in a full ring topology by connecting stack port "one" of one switch to stack port "two" of the next switch, continuing this pattern the whole way through the stack, and finishing with the bottom switch connecting to the top switch to complete the ring.

Once the stack has been cabled correctly, the stack should be brought online with a single uplink for the entire stack. This will allow the switches to connect to the Meraki cloud and configure everything or sync with the configuration that was set up ahead of time. Once the switches comes online from their single uplink, the Meraki cloud will automatically detect the stack if it’s not already configured and will ask to provision or name the stack:

Once the stack has been named and configured, clients can be connected and link aggregation can be configured for an uplink back to the aggregation layer or core. Enterprise Meraki switches are able to use Link Aggre­gation Control Protocol (LACP) to bundle up to eight links. It is best practice to make sure to accommodate for additional bandwidth by using at least two links for the uplink in any stack.

When selecting ports for an aggregated stack uplink, it is best to space the links out so there are minimal hops across the stack for traffic to get to an uplink. In a stack with four switches, this would mean that switch 1 and switch 3 have uplinks. In a stack with eight switches and two uplink cables, this would mean that switch 1 and switch 4 have uplinks. This "maximum spacing" method will provide optimal coverage, during normal operation and in failures. This should help avoid having traffic unnecessarily traverse the whole stack to get to an uplink. Link aggregation is simple to configure using the dashboard, as all ports for all switches can be viewed from a single page. Simply select the ports to be in the link aggregate and click the Aggregate button in dashboard.

For even higher-capacity needs, the Meraki MS355 switch family has a multigigabit ethernet model that pairs with the Meraki multigigabit MR access points to provide single-cable speeds greater than a gigabit. This allows a campus to have the stacking redundancy as well as greater throughput for end clients should it be needed. 

Enabling Traffic Analytics

This is an opt-in feature and can be enabled under the Configure > Network-wide settings page by selecting the Enable Hostname Visibility function.

Using Traffic Analytics

The enhanced Traffic analytics page will be visible under the Monitor menu whenever hostname visibility is enabled. This page will provide a total unique client count across an entire network over time. The view can be customized for different time periods (last 2 hours, week, day, and month), and on a per-SSID basis.

This page will show the following information on a per-network or per-SSID basis:

• Application

• Specific destination for broad application categories such as ‘Miscellaneous secure web’

• Protocol information

• Port information

• Usage breakdowns by %, data sent and received, number of flows

• Total active time on application across all clients

• Number of clients

Signature or Application-Level Analytics

By clicking on an application signature (e.g. ‘Dropbox’ or ‘Non-web TCP’), it’s possible to see a complete breakdown of hostnames and IP addresses comprising this application category. Use this information to understand the communication patterns of certain types of traffic.

This page will show you the following information on a per-application basis:

• Application name, category, ports, description

• Usage over time

• List of users

• Destination list - hostnames and IP addresses contributing to this application

• Total number of clients per destination

• Time spent per client

User Level Analytics

By clicking on a specific user, it’s possible to see a complete breakdown of hostnames and IP addresses this user has visited, including the time spent on each destination. Use this information to understand individual user behavior and apply policies on a per-user basis.

Summary reports can be mailed directly to the network administrator, relieving them of at least one task when their plate is full. These reports provide updates on the network and can be shared directly to key stakeholders with little to no effort.

Layer 3 Routing & DHCP

Layer 3 settings for networks bound to a template act as exceptions to the template. The Routing & DHCP, OSPF routing, and DHCP servers & ARP pages will be configurable on each network bound to a template and behave the same as if the network was not bound to a template. The one difference is that setting email alerts for newly detected DHCP servers on the DHCP servers & ARP page is available from the parent template's Network-wide > Alerts page and therefore applies to all networks bound to the template. 

Template Networks

A "site" in network deployment terms is usually the same as a "network" in Dashboard terms; each site gets their own Dashboard network. As such, when planning multiple sites to be configured the same way, they will share a template network.

A template network is a network configuration that is shared by multiple sites/networks. Individual site networks can be bound to a template network, so changes to the template will trickle down to all bound sites. A new network can also be created based on a template, making it easy to spin up new sites of the same type.

When planning a template deployment, you should have one template network for each type of site.

Switch Profiles

If multiple switches on a site share the same port configuration, they can easily be deployed and updated using switch profiles. Within a template network, a switch profile defines the per-port configuration for a group of switches. For example, if all sites contain multiple MS220-24 switches that are all configured identically, an administrator can set up a switch profile for their MS220-24 switches. This way, whenever a new MS220-24 is installed at a site, it will automatically assume its switch profile and configure its ports accordingly.

When planning a template deployment, if multiple switches share the same configuration, consider using a switch profile for each type of switch.

Guidelines and Limitations

1. STP bridge priority cannot be changed on switch stacks using templates. In a network template, switch profiles can be assigned STP bridge priority values from Switch > Switch settings > STP configuration. A value assigned to a switch profile, however, will only propagate to the standalone switches bound to that profile; switch stacks will retain the default STP priority of 32768. 

If an MS switch stack must be the root bridge of an STP domain which has at least one other MS switch stack, it should be placed in a Dashboard network that is not bound to a network template for the STP priority value configured on it to take effect.

The following diagram shows the relationship between network templates and switch profiles:

Creating a Template Network

As outlined above, a template network should be created for each type of site to be deployed.

To create a template network:

1. In Dashboard, navigate to Organization > Monitor > Configuration templates.
2. Click Create a new template.
3. Select a descriptive name for your template. If this is a completely new template, select Create new and Switch template.
   • If this template should be based on an existing network, select Copy settings from and an existing switch network.
4. Click Add:
   
5. If you would like to bind existing networks to this new template, select those networks as Target networks and click Bind. Otherwise, click Close.

Once a network has been bound to this template, the template network should appear in the network drop-down:

Configuring a Template Network

Once a template has been created, it can be configured with some global switch settings. These settings will also apply to all networks bound to this template.

To configure a template network, select the template from the network drop-down and configure settings normally under the Switch > Configure menu options. This can include setting a global management VLAN, IPv4 ACLs, port schedules, etc. Switch profiles can also be configured here, as detailed below.

Creating and Using Switch Profiles

Switch profiles can be used to bulk configure switches of the same model.

To create a switch profile:

1. Select the appropriate network template from the network drop-down.
2. Navigate to Switch > Configure > Profiles.
3. If no profiles have been created, a Create Profile window will appear. Otherwise, click Create profile.
4. Select a descriptive name and the switch model to be configured.
5. Click Save:
   
6. Click on the newly created profile.
7. To configure the profile, select View ports on this profile.
8. The following port configuration page can be used identically to the normal switch port configuration page:
   
9. Navigate back to the switch profile under Switch > Configure > Profiles > Profile name.
10. Click Bind switches.
11. Select one or more switches, then click Bind to profile:
    

All bound switches will now use the port configuration set in the switch profile. Any changes made in the profile will now affect all bound switches.

Capacity Planning

Once the above mentioned details are available, capacity planning can then be broken down into the following phases:

• Estimate Aggregate Application Throughput

• Estimate Device Throughput

• Estimate Number of APs

Calculating the number of access points necessary to meet a site's bandwidth needs is the recommended way to start a design for any high density wireless network.

Mounting Access Points

The two main strategies for mounting Cisco Meraki access points are ceiling mounted and wall mounted. Each mounting solution has advantages.

Ceiling mounted MR, Cisco San Francisco

Ceiling mounted access points are placed on a ceiling tile, T-bar, roof, or conduit extending down from the roof. This brings advantages such as a clear line-of-sight to the user devices below and flexibility in where to place the access point. Access points can be easily placed with even spacing in a grid and at the intersection of hallways. The disadvantage is the ceiling height and the height of the access point could negatively impact the coverage and capacity.

• If access points have to be installed below 8 feet (~3 meters), indoor access points with integrated omni antennas or external dipole/can omni antennas are recommended.

• If access points have to be installed between 8 - 25 feet (3 - 8 meters), indoor access points with external downtilt omni antennas are recommended.

Wall mounted MRs, Cisco San Francisco

When ceiling heights are too high (25+ feet) or not feasible to mount access points (hard ceiling), a wall mounted design is recommended. The access points are mounted on drywall, concrete or even metal on the exterior and interior walls of the environment.  Access points are typically deployed 10-15 feet (3-5 meters) above the floor facing away from the wall. Remember to install with the LED facing down to remain visible while standing on the floor. Designing a network with wall mounted omnidirectional APs should be done carefully and should be done only if using directional antennas is not an option. 

Pole mounted MR66 with Sector antennas, Cisco San Francisco

Directional Antennas

If there is no mounting solution to install the access point below 26 feet (8 meters), or where ceilings are replaced by the stars and the sky (outdoors), or if directional coverage is needed it is recommend to use directional antennas. When selecting a directional antenna, you should compare the horizontal/vertical beam-width and gain of the antenna.

When using directional antennas on a ceiling mounted access point, direct the antenna pointing straight down. When using directional antennas on a wall mounted access point, tilt the antenna at an angle to the ground. Further tilting a wall mounted antenna to pointing straight down will limit its range.

Cisco Meraki offers 6 types of indoor-rated external antennas (available for MR42E and MR53E):

Cisco Meraki offers 4 types of outdoor external antennas and supports 5 types of outdoor antennas. Cisco Meraki has certified the antennas for use with the Meraki MR84, MR74, MR72, MR66, and MR62 access points. AIR-ANT2514-P4M can only be used with MR84: 

Access Point Placement

Once the number of access points has been established, the physical placement of the AP’s can then take place. A site survey should be performed not only to ensure adequate signal coverage in all areas but to additionally assure proper spacing of APs onto the floorplan with minimal co-channel interference and proper cell overlap. It’s very important to consider the RF environment and construction materials used for AP placement.

Review the designs below from the Cisco Meraki San Francisco office. The 4th Floor was constructed to support Cisco's sales team, customer briefings, and a cafe. In contrast, the 3rd floor was constructed to support Cisco's 24x7 technical support, our small IT department, and Cisco's Collaboration group with applications such as Telepresence and Cisco Spark HD video chat. The density of the 3rd floor is double that of the 4th floor.

High density with 30 access points, Cisco San Francisco, 4th Floor

Ultra High density with 60 access points, Cisco San Francisco, 3rd Floor

Number of SSIDs 

The maximum recommended number of SSIDs is 3, and in a high-density environment, this recommendation becomes a requirement. If needed, the number of SSIDs can be increased to 5 but should be done only when necessary.  Using more than 5 SSIDs creates substantial airtime overhead from management frames: consuming 20% or more of the bandwidth available and limiting the maximum throughput to less than 80% of the planned capacity. Create a separate SSID for each type of authentication required (Splash, PSK, EAP) and consolidate any SSIDs that use the same type authentication.

Enable Bridge Mode

Bridge mode is recommended to improve roaming for voice over IP clients with seamless Layer 2 roaming. In bridge mode, the Meraki APs act as bridges, allowing wireless clients to obtain their IP addresses from an upstream DHCP server. Bridge mode works well in most circumstances, provides seamless roaming with the fastest transitions. When using Bridge mode, all APs in the intended area (usually a floor or set of APs in an RF Profile) should support the same VLAN to allow devices to roam seamlessly between access points.

For seamless roaming in bridge mode, the wired network should be designed to provide a single wireless VLAN across a floor plan. If the network requires a user to roam between different subnets, using L3 roaming is recommended. Bridge mode will require a DHCP request when roaming between two subnets or VLANs. During this time, real-time video and voice calls will noticeably drop or pause, providing a degraded user experience.

Layer 3 Roaming

Large wireless networks that need roaming across multiple VLANs may require layer 3 roaming to enable application and session persistence while a mobile client roams. With layer 3 roaming enabled, a client device will have a consistent IP address and subnet scope as it roams across multiple APs on different VLANs/subnets.

Cisco Meraki's Layer 3 roaming is a distributed, scalable way for Access Points to establish connections with each other without the need for a controller or concentrator. The first access point that a device connects to will become the anchor Access Point. The anchor access point informs all of the other Cisco Meraki access points within the network that it is the anchor for a particular client. Every subsequent roam to another access point will place the device/user on the VLAN that defined by the anchor AP. This is ideal for high-density environments that require Layer 3 roaming, and there is no throughput limitation on the network.

The MR continues to support Layer 3 roaming to a concentrator requires an MX security appliance or VM concentrator to act as the mobility concentrator. Clients are tunneled to a specified VLAN at the concentrator, and all data traffic on that VLAN is now routed from the MR to the MX. The concentrator creates a choke-point, and in a high-density environment, the number of clients may be limited by the throughput of the MX concentrator.

Band Selection

If the client devices require 2.4 GHz, enable 'Dual-band with band steering' to enable client devices to use both 2.4 GHz channels and 5 GHz. Devices will be steered to use the 5 GHz band. For more details refer to the Band Steering Overview article. With a dual-band network, client devices will be steered by the network. If 2.4 GHz support is not needed, it is recommended to use “5 GHz band only”. Testing should be performed in all areas of the environment to ensure there are no coverage holes.

Using RF Profiles, minimum bit rate can be set on a per band or a per SSID basis. For high-density networks, it is recommended to use minimum bit rates per band. If legacy 802.11b devices need to be supported on the wireless network, 11 Mbps is recommended as the minimum bitrate on 2.4 GHz. Adjusting the bitrates can reduce the overhead on the wireless network and improve roaming performance. Increasing this value requires proper coverage and RF planning. An administrator can improve the performance of clients on the 2.4 GHz and 5 GHz band by disabling lower bitrates. Management frames will be sent out at the lowest selected rate. Clients must use either the lowest selected rate or a faster one. Selecting a Minimum bitrate of 12Mbps or greater will prevent 802.11b clients from joining and will increase the efficiency of the RF environment by sending broadcast frames at a higher bitrate.

RX-SOP

Using RX-SOP, the receive sensitivity of the AP can be controlled. The higher the RX-SOP level, the less sensitive the radio is and the smaller the receiver cell size will be. The reduction in cell size ensures that the clients are connected to the nearest access point using the highest possible data rates. In a high density environment, the smaller the cell size, the better. This should be used with caution however as you can create coverage area issues if this is set too high. It is best to test/validate a site with varying types of clients prior to implementing RX-SOP in production.

 

 

 

The table below gives the recommended values for RX-SOP in high density deployments:

802.11 Band	High Threshold	Medium Threshold	Low Threshold
5 GHz	-76 dBm	-78 dBm	-80 dBm
2.4 GHz	-79 dBm	-82 dBm	-85 dBm

Note: RX-SOP is supported on 802.11 ac Wave 2 and 802.11 ax APs i.e. MR30H/33/42/52/53/74/84/42E/53E/45/55

Set Bandwidth Limits 

Consider placing a per-client bandwidth limit on all network traffic. Prioritizing applications such as voice and video will have a greater impact if all other applications are limited. For more details refer to the article Configuring Bandwidth Limitations and Enabling Speed Burst on Wireless Networks. 5 Mbps is a good recommendation for per-client bandwidth limit in high-density environment. You can override this limit for specific devices and applications.

1. Go to Wireless > Configure > Firewall & traffic shaping and choose the SSID from the SSID drop-down menu at the top of the screen.
2. Set a 'Per-client bandwidth limit' to 5 Mbps with 'Speed Burst'. This will apply to all non-voice application traffic. This step in the guide is optional. 
3. Set a 'Per-SSID bandwidth limit' to unlimited.

Define Traffic Shaping Rules

Use traffic shaping to offer application traffic the necessary bandwidth. It is important to ensure that the application has enough bandwidth as estimated in the capacity planning section. Traffic shaping rules can be implemented to allow real-time voice and video traffic to use additional bandwidth, and the rules can be used to block or throttle applications such as P2P, social networks. 

1. Go to Wireless > Configure > Firewall & traffic shaping and choose the SSID from the SSID drop-down menu at the top of the screen.
2. Click the drop down menu next to Shape traffic and choose Shape traffic on this SSID, then click Create a new rule.
3. Click Add + and select 'All voice & video conferencing' 
4. Set Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' and click Save changes.

Convert Multicast to Unicast

Cisco Meraki APs automatically perform a multicast-to-unicast packet conversion using the IGMP protocol. The unicast frames are then sent at the client negotiated data rates rather than the minimum mandatory data rates, ensuring high-quality video transmission to large numbers of clients. This can be especially valuables in instances such as classrooms, where multiple students may be watching a high-definition video as part a classroom learning experience. 

Limit Broadcasts 

Broadcast Domain Mapping

Each Meraki Access point sends layer 2 broadcast probes over the Ethernet uplink to discover broadcast domain boundaries on each VLAN that a client could be associated with when connected. This is done for multiple reasons. One reason is because there can be instances where AP1 is connected to an access port (no VLAN tag) and AP2 is connected to a trunk port where the same VLAN is used, but the VLAN ID is present and tagged on the uplink. These broadcast frames are of type 0x0a89 sent every 150 seconds.

There could also be situations where the same VLAN ID is used in different buildings (representing different broadcast domains), so it’s important to ensure exactly which APs and VLAN IDs can be found on which broadcast domains. Apart from tunnel load balancing and resiliency, the broadcast domain mapping and discovery process also allows for anchor APs and hosting APs to have a real-time view into which VLANs are shared between the two APs. This allows for efficient decision making when it comes to layer 2 vs layer 3 roaming for a client, as described in the “VLAN Testing and Dynamic Configuration” section below.  This is important so that anchor APs for clients can be dynamically switched for load balancing reasons, or in failover situations where the original anchor AP is no longer available. 
Meraki APs will send out probes to discover the following broadcast domains:

• The AP’s native VLAN
• Any VLAN that is configured for the SSID on the AP
• Any VLAN that is dynamically learned via a client policy 
• Any VLAN that an AP has recently received a broadcast probe on from another Meraki AP in Dashboard network

The power of the broadcast domain mapping is that this will discover broadcast domains agnostic of VLAN IDs configured on an AP. As a result of this methodology, each AP on a broadcast domain will eventually gather exactly the AP/VLAN ID pairs that currently constitute the domain. Whenever a client connects to another SSID the Anchor AP for that client is updated.

Broadcast Domain Discovery

The following steps establish the AP/VLAN ID (VID) pair that correspond to a broadcast domain:

1. APs periodically broadcast a BCD announcement packet that contains the AP’s VLAN ID for that broadcast domain, giving a {sender AP,VID} pair on each broadcast domain the AP interacts with.
2. Create equivalence classes based on AP/VID pairs recently observed in BCD announcement packets on the same broadcast domain.

Additional notes:

• Each AP on a broadcast domain will eventually gather exactly the AP/VID pairs that currently constitute the domain.
• In principle, any AP/VID pair can be used to refer to a broadcast domain. Given AP1/VID1, as long as you know the full list of pairs for that broadcast domain, you can tell whether some other AP2/VID2 refers to the same domain or not.

An AP could theoretically broadcast BCD announcement packets to all 4095 potentially attached VLANs, however it will limit itself to the VLANs outlined above.

Roaming with Broadcast Domains

The Meraki MRs leverage a distributed client database to allow for efficient storage of clients seen in the network and to easily scale for large networks where thousands of clients may be connecting. The client distributed database is accessed by APs in real-time to determine if a connecting client has been seen previously elsewhere in the network. This requires that the APs in the Meraki network have layer 3 IP connectivity with one another, communicating over UDP port 9358. Leveraging the Meraki Dashboard, the APs are able to dynamically learn about the other APs in the network (including those located on different management VLANs) to know whom they should communicate with to look up clients in the distributed client database. 
 

The following process describes how client roaming operates with distributed layer 3 roaming

1. Anchor APs have a full set of AP/VLAN ID pairs for each attached broadcast domain as described above.

2. On client association, the hosting AP retrieves the client data from the distributed store.

   • If the hosting AP does not find an entry in the store:

     • The hosting AP then becomes the anchor AP for the client. It stores the client in the distributed database, adding a candidate anchor AP set. The candidate anchor set consists of the AP’s own AP/VLAN ID pair plus two randomly chosen pairs from the same anchor broadcast domain.

   • If the hosting AP does find an entry in the store:

     • It checks to see if the client’s VLAN is available locally, from the previous broadcast domain discovery process outlined above. If the associated VLAN ID is available, the hosting AP will become the anchor AP and the VLAN for that client will dynamically be provisioned for the client. See the section “VLAN Testing and Dynamic Configuration” below.

     • Otherwise, the hosting AP sets up an anchor AP for the client (picking a random pair from the candidate anchor set).

3. As long as the hosting AP continues to host the client, it periodically receives updates to the candidate anchor set from the anchor AP. The anchor AP replaces any AP/VLAN ID pair in the candidate anchor set that disappears with another randomly chosen AP/VLAN ID pair for that broadcast domain. The hosting AP updates the distributed store’s client entry with changes to the candidate

VLAN Testing and Dynamic Configuration

The anchor access point runs a test to the target access point to determine if there is a shared layer 2 broadcast domain for every client serving VLAN. If there is a VLAN match on both access points, the target access point will configure the device for the VLAN without establishing a tunnel to the anchor. This test will dynamically configure the VLAN for the roaming device despite the VLAN that is configured for the target access point and the clients served by it. If the VLAN is not found on the target AP either because it is pruned on the upstream switchport or the Access Point is in a completely separated layer 3 network, the Tunneling method described below will be used.

Tunneling

If necessary, the target access point will establish a tunnel to the anchor access point. Tunnels are established using Meraki-proprietary access point to access point communication. To load balance multiple tunnels amongst multiple APs, the tunneling selector will choose a random AP that has access to the original broadcast domain the client is roaming from. If the target AP detects a connectivity failure to the currently selected anchor AP, as a failover mechanism the target AP will choose a new anchor AP. Hosting AP will ping Anchor AP every second to ensure that the Anchor AP has not failed. This ping is integrated as a part of the L3 communication on UDP port 9358.
 
All APs must be able to communicate with each other via IP.  This is required both for client data tunneling and for the distributed database. If a target access point is unable to communicate with the anchor access point the layer 3 roam will time out and the end device will be required to DHCP on the new VLAN. Data packets are not encrypted between two Anchor APs on the wired side but control and management frames are encrypted.

Voice Quality Before this Guide

With the default settings on the MR, we see the baseline for quality. Voice calls with Lync on this network would be acceptable to some users, but not acceptable to others. The results of the Lync testing show that the Network Mean Opinion Score (MOS) drops below 3.5. Values values dropping below 3.5 are termed unacceptable by many users. The packet loss jumps to 8 percent during a period of network congestion simulated by running a speed test. Jitter fluctuates from 12 milliseconds to over 36 milliseconds. Cisco recommends a target of 10 ms of jitter and no more than 50 ms of jitter. Jitter is handled using buffering in voice/video applications, adding a small delay. The human ear normally accepts up to about 140 milliseconds of delay without noticing it.

Voice Quality After this Guide

After making the changes exactly as described in this guide, we see a significant improvement in voice quality. The MOS score approaches 3.9, the packet loss is near zero, and the jitter is consistently below 6 milliseconds and always below 12 milliseconds. As the call starts, traffic shaping kicks in automatically with prioritization and QoS tagging. A speed test was performed with no impact to the voice traffic - packet loss increased to 0.5% during the congestion.

Summary of 802.11 Standards

All Meraki MR series access points support the most recent 802.11 standards implemented to assist devices to roam between access points and ensure voice calls maintain a quality user experience. 

• 802.11r: Fast BSS transition to permit fast and secure hand-offs from one access point to the other in a seamless manner
• 802.11i: Enabling client devices authenticated via 802.1x to authenticate with decreased latency whilst roaming
• 802.11k: assisted roaming allows clients to request neighbor reports for intelligent roaming across access points.
• 802.11e: Wireless Multimedia Extensions (WMM) traffic prioritization ensures wireless VoIP phones receive higher priority.
• WMM Power Save: maximizes power conservation and battery life on devices without sacrificing Quality of Service.
• 802.11u: Hotspot 2.0 also known as Passpoint is a service provider feature that assists with carrier offload.

Add a Dedicated Voice SSID 

Voice optimization typically requires a different configuration including access control and traffic shaping to address device specific recommendations. You should create a separate Voice SSID for devices dedicated to voice applications. While this is not a requirement, we recommend to create a separate network to follow this guide. In networks with VoIP handsets from two different manufacturers, it is common to create two voice SSIDs. 

Authentication Type

Voice over WiFi devices are often mobile and moving between access points while passing voice traffic. The quality of the voice call is impacted by roaming between access points. Roaming is impacted by the authentication type. The authentication type depends on the device and it's supported auth types. It's best to choose the auth type that is the fastest and supported by the device. If your devices do not support fast roaming, Pre-shared key with WPA2 is recommended. ​WPA2-Enterprise without fast roaming can introduce delay during roaming due to its requirement for full re-authentication. When fast roaming is utilized with WPA2-Enterprise, roaming times can be reduced from 400-500 ms to less than 100 ms, and the transition time from one access point to another will not be audible to the user. The following list of auth types is in order of fastest to slowest.

1. Open (no encryption)
2. Pre-shared key with WPA2 and Fast roaming
3. WPA2-Enterprise with Fast roaming
4. ​Pre-shared key with WPA2 
5. ​WPA2-Enterprise 

WPA2 only for Encryption Mode

Voice devices can benefit from having a single type of encryption used. ​By default, SSIDs on Cisco Meraki access points that are configured as WPA2 will utilize a combination of both WPA1 TKIP and WPA2 AES encryption. WPA2 (AES) is recommended and required in order to utilize caching or fast roaming. The WPA encryption setting is SSID specific, and can be found on the Wireless > Configure > Access control page.

• If all Voice devices support WPA2, the 'WPA2 only' option is recommended for Voice over IP devices. 
• If the device does not support AES, it is also possible to force TKIP only. Please contact Cisco Meraki support to configure this option.

For step-by-step instructions on changing the WPA encryption mode, see our document on Setting a WPA Encryption Mode.

802.11r fast roaming

Enabling 802.11r is recommended to improve voice quality while roaming. The 802.11r standard was designed to improve VoIP and voice applications on mobile devices connected to Wi-Fi, in addition to or instead of cellular networks. When mobile devices roam from one area to another, they disassociate from one access point and reassociate to the next access point. Enabling 802.11r benefits VoIP devices by reducing the roaming time spent changing between access points. Some client devices are not compatible with Fast BSS Transition (802.11r). You may wish to check your devices for compatibility.

Layer 2 and Layer 3 Roaming 

Bridge mode is recommended to improve roaming for voice over IP clients with seamless Layer 2 roaming. In bridge mode, the Meraki APs act as bridges, allowing wireless clients to obtain their IP addresses from an upstream DHCP server. Bridge mode works well in most circumstances, particularly for seamless roaming, and is the simplest option to put wireless clients on the LAN. To configure the client IP assignment modes please refer to our document on SSID Modes for Client IP Assignment.

When using Bridge mode, all APs on the same floor or area should support the same VLAN to allow devices to roam seamlessly between access points. Using Bridge mode will require a DHCP request when performing a Layer 3 roam between two subnets. For example, when a user on a VoIP call roams between APs on different VLANs without layer 3 roaming, the user's session will be interrupted as the external server must re-establish communication with the client's new IP address. During this time, a VoIP call will noticeably drop for several seconds, providing a degraded user experience. 

Large wireless networks with multiple VLANS per floor may require IP session roaming at layer 3 to enable application and session persistence while a mobile client roams across multiple VLANs. With layer 3 roaming enabled, a client device will have a consistent IP address and subnet scope as it roams across multiple APs on different VLANs/subnets. If Layer 3 roaming is required on your network, please refer to our article on Layer 3 Roaming. 

Segregate Traffic on a Voice VLAN 

Voice traffic tends to come in large amounts of two-way UDP communication. Since there is no overhead on UDP traffic ensuring delivery, voice traffic is extremely susceptible to bandwidth limitations, clogged links, or even just non-voice traffic on the same line. Separating out your voice traffic allows it to function independently of other network traffic, and allows for more granular control over different types of traffic.

If a voice VLAN is specified on a Meraki MS switch, the port will accept tagged traffic on the voice VLAN. In addition, the port will send out LLDP and CDP advertisements recommending devices use that VLAN for voice traffic.  The VLAN tagged on the wireless access point should match the Voice VLAN on your wired network.  For more information, please visit the article on Configuring MS Access Switch for Standard VoIP deployment.

Band Selection

The 2.4 GHz band has only 3 channels that do not overlap, while the 5 GHz band has up to 19 individual channels in the US. A wireless network will provide the best quality of service for wireless voice when designed correctly to support 5 Ghz coverage for voice. This can be configured under Access Control > Wireless options > Band selection > '5 GHz band only'. After configuration, testing should be performed in all areas of your environment. If you do not have proper 5 GHz coverage after a post-install site survey, you can manually increase the power on the 5 GHz radio  in Radio Settings > Channel Planning. 

If you do not have a dedicated Voice SSID, enable 'Dual-band with band steering' to enable your voice devices to use both 2.4 GHz channels and 5 GHz. Devices will be steered to use the 5 GHz band. For more details refer to the Band Steering Overview article. With a dual-band network, client devices will be steered by the network. However,  to improve voice quality, please follow our guide on configuring wireless band preference on client devices.

If you have devices that only support a 2.4 GHz network such as 802.11bgn devices, please contact Meraki Support to enable a 2.4 GHz only network.

Minimum Bitrate

For Voice networks, 12 Mbps is recommended as the minimum bitrate. Increasing this value requires proper coverage in the RF planning. An administrator can improve the performance of clients on the 2.4 GHz and 5Ghz band by disabling lower bitrates. Adjusting the bitrates can reduce the overhead on the wireless network and also in some cases improve roaming performance. 

Bandwidth Limits

Consider placing a per-client bandwidth limit on the rest of your network traffic. Prioritizing voice will have a greater impact if all other applications are limited. For more details refer to the article Configuring Bandwidth Limitations and Enabling Speed Burst on Wireless Networks.

1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
2. Set a 'Per-client bandwidth limit' to 5 Mbps with 'Speed Burst'. This will apply to all non-voice application traffic. This step in the guide is optional. 
3. Set a 'Per-SSID bandwidth limit' to unlimited.

Traffic Shaping Rules

Use traffic shaping to offer voice traffic the necessary bandwidth. It is important to ensure that your voice traffic has enough bandwidth to operate. As such, traffic shaping rules can be implemented to allow voice traffic to use additional bandwidth, or limit other types of traffic to help prioritize voice traffic.

1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
2. Click the drop down menu next to Shape traffic and choose Shape traffic on this SSID, then click Create a new rule.
3. Click Add + and select 'All VoIP & video conferencing' 
4. Set Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' and click Save changes.​

​

PCP, DSCP, and WMM mapping

Many devices support Quality of Service (QoS) tags to maintain traffic priority across the network. Meraki MR access points support WMM to improve the performance of real-time data such as voice and video.  WMM improves the reliability of applications in progress by preventing oversubscription of bandwidth. WMM accomplished this by enhancing the prioritization of traffic using the access categories: voice, video, best effort, and background data. WMM has mapped values which can be found in this article. To configure correct mapping for PCP and DSCP values, the following steps should be followed:

1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
2. Under the traffic shaping rules, make sure Shape Traffic for this SSID is selected and that  there's a rule for All voice & video conferencing.
3. Set PCP to '6' or the setting recommended by your device/application vendor (Note that PCP values can only be changed if the SSID has VLAN tagging enabled. This ensures there's a field to which the CoS value can be written).
4. Set DSCP to 46 (EF - Expedited Forwarding, Voice) or the setting recommended by your device/application vendor.

If no DSCP values are configured, the default DSCP to WMM mapping will be used. The access point does the mapping between the LAN's Layer 2 priority and the radio's WMM class. Below is table showing the mapping between common traffic types and their respective markings:

* n as used in place for the drop indication of assured forwarding matches values 1-3.  

For QoS prioritization to work end to end, ensure that upstream networking equipment supports QoS prioritization as well. The PCP and DSCP tags applied on the wireless access point should match the wired network configuration to ensure end-to-end QoS. For more information, please visit the article on Configuring MS Access Switch for Standard VoIP deployment article.

Custom Traffic Shaping 

If your voice traffic does not match the built-in application signatures or is not listed, you can create your own signature for traffic shaping.

1. Add the IP and ports used by your servers hosting Microsoft Lync / Skype for Business, Jabber, Spark, or other voice application.
   1. In the Definition field click Add + and Custom expressions 
   2. In the text field, enter the IP address of each of your voice servers for example 172.16.1.123 or a range of server IPs 172.16.1.0/24
   3. Also, add your servers as source addresses by using the CIDR notation localnet:172.16.1.123/32 for an individual server, or localnet:172.16.1.0/24 for a range of IPs.
   4. Click the Add + button again when finished.
2. If you have a dedicated voice SSID and dedicated voice VLAN add the local subnet of the client devices.
   1. In the Definition field click Add + and Custom expressions 
   2. In the text field, enter localnet:192.168.0.1/16 indicating the source subnet of your client devices in CIDRnotation.
   3. Click the Add + button again when finished.
3. Set Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' and click Save changes.​

Microsoft Lync / Skype for Business

This section will provide guidance on how to implement QoS for Microsoft Lync and Skype for Business. Microsoft Lync is a widely deployed enterprise collaboration application which connects users across many types of devices. This poses additional challenges because a separate SSID dedicated to the Lync application may not be practical. When you install Microsoft Lync Server / Skype for Business, Quality of Service (QoS) will not be enabled for any devices used in your organization that use an operating system other than Windows. For more guidance on deploying Lync over Wi-Fi, please read Microsoft's deployment guide, Delivering Lync 2013 Real-Time Communications over Wi-Fi.

Meraki's deep packet inspection can intelligently identify Lync calls made on your wireless network and apply traffic shaping policies to prioritize the Lync traffic - using the SIP Voice protocol. In addition to the Meraki built-in signatures for Skype and SIP, you should also identify each Lync server by IP and any custom ports used by your Lync clients or servers. Follow these steps to configure your traffic shaping rules for Lync / Skype.

1. Go to Wireless > Configure > Firewall & traffic shaping and choose your SSID from the SSID drop down menu at the top of the screen.
2. Click the drop down menu next to Shape traffic and choose Shape traffic on this SSID, then click Create a new rule.
3. Consider setting a 'Per-client bandwidth limit' to 5 Mbps with 'Speed Burst'. This will apply to all non-voice application traffic
4. Set Per-client bandwidth limit to unlimited
5. Create a traffic shaping rule for All voice & video conferencing > 'Skype' and 'SIP (Voice)'
6. Set the Per-client bandwidth limit to 'Ignore SSID per-client limit (unlimited)' from the drop down.
7. Set PCP to '6'. The 802.1p parameter is no longer supported in Lync Server 2013. The parameter is still valid for backward compatibility with Microsoft Lync Server 2010; however, it has no effect on devices used with Lync Server 2013.
8. Set DSCP to '46 (EF - Expedited Forwarding, Voice)' 
9. Add 'Custom expressions' for the IP and ports used by your servers hosting Microsoft Lync / Skype for Business
   1. For Cloud-hosted Lync / Skype, add the domain names from the table below
   2. Add the Port numbers from the table below or your own list of assigned port numbers
   3. Add the IP address of each of your on-premise Lync servers
10. You can test that DSCP markings are applied using the Meraki packet capture tool. 

Cisco 7925G Phones

Cisco 7925G, 7925G-EX, and 7926G VoIP phones require specific settings to inter-operate with Meraki MR access points configured with WPA2-PSK association requirements. For more in-depth information on integrating Cisco 792xG with MR Access Points, see the Cisco Unified Wireless IP Phone 792xG + Cisco Meraki Wireless LAN Deployment Guide. 

1. Cisco recommends to set band selection to 5 GHz only.
2. Do not utilize the Dual band operation with Band Steering option. If the 2.4 GHz band needs to be used due to increased distance, select Dual band operation (2.4 GHz and 5 GHz) should be selected. 
3. Set the Minimum bitrate to 11 Mbps or higher. 
4. By default, Cisco Meraki access points currently tag voice frames marked with DSCP EF (46) as WMM UP 6 and call control frames marked with DSCP CS3 (24) as WMM UP 4.

Cisco Meraki access points will trust DSCP tags by default. Administrators should ensure that upstream QoS is in place and that the QoS markings outlined below are in place for the 7925 phones. To rewrite QoS tags for certain traffic types or source/destination, then create a traffic shaping rule as outlined in Custom Traffic Shaping above.

Below is the QoS and port information for voice and call control traffic used by the Cisco Unified Wireless IP Phone 7925G, 7925G-EX, and 7926G. For a full list of ports and protocols used by Cisco phones refer to the Cisco Unified Communications Manager TCP and UDP Port Usage Guide.

Apple iPhones

Apple and Cisco have created partnership to better support iOS business users by optimizing Cisco and Meraki networks for iOS devices and apps. For more information on this partnership, please see Apple's website. Meraki's group policies can be easily configured to optimize Apple devices on a Meraki network. First create a group policy you would like to apply to Apple devices.

1. Browse to Network-wide > Configure > Group Policies, scroll down and click Add Group. 
2. Under traffic shaping, create a new rule, and add All VoIP & video conferencing
   1. Set the Per-client bandwidth limit to Ignore network per-client limit
   2. Set PCP to 6 (highest priority) and DSCP to 46 (EF - Expedited Forwarding, Voice). 
3. Create a second rule, and add All Video & music
   1. Set the Per-client bandwidth limit to Ignore network per-client limit
   2. Set PCP to 5 and DSCP to 34 (AF41- Multimedia Conferencing, Low Drop).

To apply your new Apple device group policy, browse to Wireless > Access Control and enable Assign group policies by device type. Click Add group policy for a device type for each Apple device type (iPhone, iPad, iPod, and Mac OS X) and assign the Apple device group policy you created. Click save and your optimization is complete.

Vocera Badges

Vocera badges communicate to a Vocera server, and the server contains a mapping of AP MAC addresses to building areas. The server then sends an alert to security personnel for following up to that advertised location. Location accuracy requires a higher density of access points. In a high density deployment, you may need to reduce the transmit power of each AP manually to as low as 5 dB on all supported radios. Vocera provides additional documentation on deploying WLAN best practices to support Vocera badges. For more information download their document on Vocera WLAN Requirements and Best Practice

WiFi Calling

Mobile network operators (MNOs) now allow their customers to place phone calls over Wi-Fi to save roaming costs and leverage WiFi coverage in buildings with poor cellular coverage. WiFi calling is expected to be supported by majority of mobile devices and MSPs by the end of 2015. Apple maintains a list of carriers that have wifi calling ready and devices that support it. 

An Enterprise WiFi infrastructure handles more than just carrier voice traffic, and this limited spectrum is shared by other applications and services like Video streaming & Web Conferencing. The requirements for voice in terms of latency and jitter warrants a network with proper end-to-end QoS design & Voice optimizations that would optimize delivery of WiFi calling packets in the presence of other applications.

Hotspot 2.0

Hotspot 2.0 also known as Passpoint is a service provider feature that assists with carrier offloading. Part of the 802.11u amendment to the 802.11 standard additional information is included in Hotspot 2.0 configured SSIDs that Hotspot 2.0 client devices can analyze use to determine if it is able to join the network automatically. 

Managed Service Providers (MSPs) can now take enable of Hotspot 2.0 options on the Cisco Meraki MR access points. Meraki allows MSPs to customize the Hotspot 2.0 SSID advertisements to allow their subscribers to easy roam between networks.  Hotspot 2.0 options are only available to qualified Managed Service Providers. Please contact Cisco Meraki Support to check eligibility.

Optics

Hardware

Software

MV Features

Video Transmission

Security and Architectures

Cyber attacks have become more and more prevalent, with attackers leveraging any insecure means of entry into the network. Recent attacks have used poorly secured security cameras and NVRs as the path into the network. As such, these devices should have the same level of security as traditional network devices.

By simplifying the architecture and making many best practice security features enabled by default, Meraki’s MV security cameras offer extensive security out of the box.

Let’s compare traditional camera systems to the Meraki MV Camera solution.

Passwords and Administrators

Secured Access and Encryption

Alerts and Logging

Pre-site Survey Requirements

The list below is a starting point to identifying deployment needs, and will help ensure a better site survey outcome:

• Acquire to-scale floor plans of the building(s)

  • A purpose of the site survey is to determine the mounting locations of cameras to be installed. Having floor plans helps the site administrator and the installer both fully understand the intent of the design and requirements. If outdoor camera coverage is also required, try to obtain external building plans as well.

• Locate all network equipment closets

  • During the site survey it is necessary to understand existing network equipment, as the cameras will most likely be powered by and connected to the network. Identifying these locations beforehand is necessary.

• Ask the simple questions:

  • Why is an IP video surveillance system needed?

  • What purpose does the system serve?

  • What are the requirements the system MUST have and why MUST the deployment have them?

  • When does the project need to be done?

  • Where is camera coverage required?

  • Who and/or what needs to be protected?

  • Are there any restrictions around mounting cameras to walls and/or ceilings?  

  • Are there any restrictions around running CAT5e/6/7 cabling throughout the building/facility?

• Get keys and access to ALL parts of the building/facility

  • This may be difficult as some companies/entities have high levels of security. Be sure to coordinate with management/security/facilities, and explain the purpose of and requirements for survey.

• Schedule and treat the site survey like a project

  • Coordination and communication is key to making the site survey a success.  Identifying things in the pre-site survey meeting can save a lot of time during the site survey.

• Understand and know the County/State/Local regulations around cameras/surveillance for each facility to be surveyed

Conducting a Site Survey

The site survey determines where to place the cameras. It may also uncover additional suggestions or recommendations that were not initially considered.

Site Survey Checklist

• Have a system to take extensive notes and make recommendations

• Have several copies of the floor plans handy for marking where cameras should be installed

• Take lots of pictures! Pictures can help convey design a lot more easily and are extremely helpful for documentation.

• Consider the following to determine placement for each camera:

  • Take into consideration camera position and areas of high contrast - bright natural light and shaded darker areas.

  • It is HIGHLY recommended to have at least two (2) vantage points on each ingress and egress point. Having multiple cameras covering the same area is a GOOD thing, as it creates redundancy for backup.  

  • Consider the following areas as examples:

    • Entrances, exits, loading, and/or delivery entrances to the building(s)

    • Any gateway(s) or parking areas/lots where employees/guests park vehicles

    • Cashier, ATM, and other locations handling monetary transactions

    • Highly used areas such as lunch rooms, reception areas, break rooms, waiting areas, hallways, etc.

    • Perimeter coverage of building, including walkways, fences, patio, and outdoor accessible areas used by employees, guests, and others

    • High value items and areas where security and visibility are a necessity

  • The closer a camera is positioned with a narrow field of view, the easier things are to detect and recognize. General purpose coverage provides overall views.

  • Will camera placement require a man lift for installation?

    • How difficult and high is the mount? This may affect future maintenance.

  • What mounting equipment is required for each camera and how will they be mounted?

    • Height of installation

    • Distance to targets

    • Lighting

    • Angle of placement

    • Mounting style and mounts (ceiling vs. wall)

  • Determine if new cable runs are required and the distance of the cable run to the nearest networking closet

  • If vandalism of cameras is a concern, position the IP66 rated vandal resistant cameras offered in the Meraki portfolio

• When it comes to audio recording be aware of local laws

• Determine if existing networking equipment is adequate for new security cameras

  • Are there enough ports on the switch(es)?

  • Are additional network switches required?

  • Are these ports PoE and does the equipment have adequate PoE budget to compensate for security cameras?

  • Is the UPS adequate enough to handle the additional power draw and meet company policy standards for run time when down?

  • Are power injectors required?

  • Create network diagrams and document internet connections

  • What is the WAN design and LAN uplink connections and are they adequate to support the necessary streaming?

• Are there dedicated computers for video surveillance?

  • What are the specifications of these computers and do they meet the minimum requirements to run a dedicated video wall?

  • Which employees have access now and who will require access to the new security camera system?

• Other notable considerations:

  • Use tools such as IPVM.com as resources for determining proper placement for cameras and illustrating the outcome of an installation could look like

  • Consider using a live camera on a stick connected to Meraki MX65 (or similar device with PoE ports and access to internet via USB Cell provider) and UPS on a rolling cart (similar to an Active Wireless site survey)  [This is very time consuming but provides examples of what camera footage will look like after installation. Would require at least a MV21, MV12N, and/or MV12W (different optics in each of these models)]

Post-Site Survey Report and Deliverables

The site survey process starts with information gathering, then the actual on-site survey, and is concludes with documentation of the results and findings. The site survey report should be presented in a format that clearly shows the recommendations and design for the security system.  This ensures all parties fully understand the requirements and deliverables for implementation. Below are recommendations of what should be included in the final report from a site survey:

• A full write-up on findings, obstacles, and recommendations

  • Include pictures

  • Explain in detail needs from network

    • Additional switches

    • Additional network cable drops

• A floor plan indicating locations of all networking closets and recommendations on camera locations

• LAN/WAN diagrams and information about Internet connection

  • Show ports and cable types connecting all network devices

  • Document VLANs, ACLs, Routing

• Complete equipment/materials list necessary to complete design

  • Total number and model of cameras

  • Mounting hardware required (if necessary)

  • Total new networking drops (if necessary)

  • Total number of power injectors (if necessary)

  • Total new networking switches (if necessary)

• Configuration details of existing network equipment

  • Is QoS adequate?

  • Will a new VLAN schema need to be built out?

  • Do firewall ports need to be opened to the Meraki cloud?

  • Is the existing security system computer adequate to handle video streams?

Build a Physical Security System Requirements Plan

A physical security system requirements plan (PSSRP) is developed by an organization or company to outline requirements for a security system. Borrowing ideas from plans of other entities is okay, as long as they meet the security requirements for the organization installing the system. The goal of a PSSRP is to ensure consistency across multiple buildings, which helps with network security and accessibility.

Define a Network Layout in the Meraki Dashboard

A network in the Meraki dashboard is a logical separation of devices managed in a single container. A network can be defined in a number of ways, but many Meraki customers divide networks up geographically so that each building/location can be managed independently of other locations. There are many ways to divide up networks, and some customers may choose to create only one. When planning the network design within the Meraki dashboard, it is helpful to think about users may need access to the system and which parts they will need to access. Within the dashboard, a user can be given rights at an organization or network level; separating each location into its own network makes it easy to grant an individual access to just the location they are responsible for. In addition to organization and network-wide administrators, the dashboard also allows a number of camera-only admin capabilities, as shown below.

Create a Naming and Tagging Schema for Cameras Being Installed

By default, the Meraki MV apply the MAC address given to the device as the name for each camera. This helps identify each camera initially, but it is not easy to remember which camera is represented by which 12 characters. Naming and tagging become even more important the larger the deployment. Make it a point to apply a name to each camera that makes sense, is logical, and is easily understood when looking at a list of cameras. Tags are applied to cameras to help group them with other like cameras. Multiple tags can be applied to a single camera. Tags are useful to sort or find a group of cameras and apply features or administrative rights to a group of cameras.

Design a VLAN Schema, Determine QoS Policies, and Apply Network Security

Creating layer 3 VLAN boundaries has been common in network security for years, as network administrators use VLAN separation to help protect devices and data. Creating a separate VLAN for security cameras only is highly recommended. Make sure this port is configured as an access port (trunk is not needed). This gives the ability to create access control lists on the layer 3 SVI to specify what can access to those devices specifically. It also enables the use of QoS on a VLAN basis throughout the campus/building network. The QoS marking recommendation is DSCP of 40 (CS5 - Broadcast Video). Be sure to have a QoS network policy in place, as this is needed throughout the network. Analyze all aspects of the routed traffic, including switches and routers.  The Meraki MV automatically tags for QoS and the upstream network devices only need to trust the tag.

Determine Administrative Access to the System

As mentioned previously, administrative access is important in considering and designing an organization or network schema. Organizational-level administrators have access to the entire dashboard, all networks, and organization-wide pages, including licensing, inventory, creating/deleting networks, etc. Network-level administrators have the ability to access and manage everything within a network in an organization. This means they can see and modify general settings. Organization and network-level admins can be given read or write access. Camera-only admins have only access to cameras. Access can be granted to all cameras, individual cameras by name, or groups of cameras by tags. Permissions can be set to allow the user to view/export all footage, view all footage, or view only live footage.

Determine Quality and Retention for Each Camera

It is important to create a policy for video quality and retention for each camera. Policies may differ based on camera location, purpose, and what is being recorded. It is possible that all cameras may have the same policy, but there may be different needs for different groups of cameras.

In most cases, having at least some amount of recorded video is recommended. However, some locations and/or countries have very specific privacy laws; if this is the case, it is important to configure cameras to adhere to these laws. By default, Meraki cameras are set to always record footage, and delete only when space runs out (files follow a first-in-first-out, or FIFO, methodology). When needed, cameras can be set to record based on a schedule, and delete footage after a certain period of time. Example configurations for footage deletion and recording schedules can be seen below:

Motion-based retention can be enabled when feasible to extend the storage capacity for each camera. When enabled, the camera will always retain the most recent 72 hours of continuous footage recorded. After three days, video clips which do not contain any motion are automatically deleted, allowing the camera to store only footage of interest and increase retention. Motion-based retention is disabled by default.

Video resolution isn’t a big mystery: the larger number in 1080p vs 720p means that there are more lines in the frame of video being displayed. Higher resolution means higher bandwidth and storage requirements. The same holds true in frame rates or fps.  Estimated retention is automatically calculated for each camera based on its current settings. These settings include 24x7, scheduled, or motion-based retention, along with video resolution and quality. Higher video resolution and quality is recommended, but isn’t always necessary in all deployments.

Some Meraki MV cameras, like the MV12, can record audio. Audio recording is disabled by default. Determine if recording audio is a requirement and if so, if it is legal.  Privacy laws vary from country to country, and not adhering to laws can result in serious repercussions.

Night Mode Configuration

When ambient light falls below certain thresholds, the cameras can switch to night mode, allowing them to be more sensitive to infrared illumination. By default night mode is set to “auto” and the built-in infrared illuminators of the Meraki MV cameras are set to “on during night mode.”  For first generation cameras, “Transition thresholds” can be adjusted to fine tune night (and day) mode. By default, the transition thresholds are configured at 0.5 lux for night and 3.0 lux for day. Keeping default settings is recommended.

Second generation cameras will automatically transition in and out of night mode based on optimal transition thresholds. 2nd gen cameras will prefer night mode in low light environments as it provides a much higher video quality in regards to physical security. Night mode allows for easier detection and classification of objects in the scene when video is reviewed for security purposes.

Motion Alerts

Motion alerts send notifications via email when motion is detected either within the frame or a selected region of a camera. These can be extremely useful in monitoring areas where tracking motion is important. Motion alerts can be configured to be sent always, or only during a certain schedule. Scheduling motion alerts is useful when monitoring an area after hours. Motion alerts are disabled by default.

Create an Inventory List for All Cameras

This is multifaceted as it will help with pre-installation setup and deployment as well as help with post-installation documentation. Having something as simple as an excel spreadsheet listing a camera by model number, serial number, name, MAC address, location description, and other details in the PSSRP is a big plus when coordinating efforts with multiple hands.  This can easily be done with the CSV export tool within the Meraki Dashboard from a network or organization inventory.

Define Necessary Video Walls for Monitoring Feeds

Video walls can be configured to allow for simultaneous viewing of multiple camera feeds. It may not be possible to determine all video wall needs prior to implementation, as customers may not know what they want or need. However, it is useful to have some basic video wall needs defined, as it is helpful in conveying how the system can operate/what it can do.

Determine which Users Need Alerts

A big advantage of the Meraki MV system is that the camera device (node) functions in relationship to other equipment in the dashboard. This enables alerting/notification of administrators in the event that the system goes offline. In many other systems, the security cameras, video management system, and storage solutions operate independently in silos. If one part of the system fails, there may not be a process to alert or notify administrators of the failure. This results in many administrators not knowing that a camera or storage system is offline until there is a need to pull footage. As part of the deployment, determine which users should be notified of issues, and configure alerts to be sent in the event of operational disruptions.

Dedicated Security or Monitoring Station(s)

Monitoring stations are common in instances that security guards need to watch multiple areas of a facility or campus. The Meraki dashboard can be configured with video walls to view up to 16 simultaneous camera streams at once per browser. System requirements for machines running video walls are available in our Hardware Guidelines for MV Streaming Workstations document.

Pre-Install Preparation for MV Cameras

Installing and Configuring MV Cameras

Note:  Leave the plastic film cover on all lenses until installation is complete. Take photos of installed cameras for reference.  Add a name and physical address to each camera.

Run Dark Mode

Run dark disables the LED lights on all MVs. This feature is useful in situations where the lights may be annoying, distracting, or overly conspicuous. For example, the LEDs can be disabled to prevent outdoor MVs from drawing attention at night. To enable dark mode, add the tag “run_dark” to the camera. More details can be found in our Dark Mode documentation.

Troubleshooting IR Reflections

All Meraki MVs, with the exception of the MV32, are equipped with infrared (IR) illuminators. These can be turned on in night mode and used to provide an illuminated view.  If the picture appears too blurry, please follow this Video Quality Troubleshooting guide.

Manage and Monitor Endpoint Devices

Cisco Meraki Systems Manager provides visibility into managed endpoint devices to help you better understand and react to changes. State changes include events such as a non-sanctioned application being installed, corporate applications being removed, and a device leaving a predetermined area. The dynamic tagging functionality in Systems Manager continually assesses the state of endpoints and automatically takes corrective action. Systems Manager profiles that are deployed on devices restrict or enable device capabilities based on your organization’s best practices.

Key capabilities include:

• Enforcing endpoint-specific restrictions (screenshots, camera usage, password length, screen lock activation, etc.)
• Applying network-based configuration (VPN, per-app VPN, wireless, etc.)
• Applying security certificates
• Monitoring and alerting when a device’s status changes (the device leaves a physical area, installs specific software, disconnects from a network, etc.)

Manage and Distribute Applications

Systems Manager application management enables the deployment of macOS, Windows, Android, and iOS applications. Organizing multi-device application management in a single interface allows you to monitor and set policies on applications holistically.

Key capabilities include:

• Delivering the right applications to the right devices based on tagging mechanisms

• Loading and distributing macOS and Windows applications from the cloud

• Provisioning and managing licensing for iOS and macOS through Apple’s Volume Purchase Program

• Provisioning Google Play Store applications through Android Enterprise

Apply and Investigate Device Security Status

Systems Manager applies and actively enforces the security status of macOS, Windows, iOS, and Android devices to maintain device security integrity. By setting and responding to security requirements, you can better understand and control device access and capabilities.

Key capabilities include:

• Requiring that certain applications be loaded and running across all devices
• Requiring minimum operating system levels on all devices
• Requiring devices check in online with a specified frequency
• Requiring devices to be locked with passwords
• Requiring that devices not be jailbroken (iOS) or rooted (Android)
• Requiring that firewalls be enabled (desktop devices)

Requirements

Customers must set up a Cisco Meraki account and obtain licensing for Meraki Systems Manager. Systems Manager licensing is offered as a 1-, 3-, or 5-year subscription.

Logical Topology

The logical topology consists of endpoint devices enrolling and communicating with the Cisco Meraki cloud, and at times with MDM services from the operating system provider, such as Google or Apple notification services. If communication between the endpoints and that cloud traverses a firewall, you will need to open ports as described here. Additional info on Systems Manager specific firewall settings can be found here.

Best Practices

Deployment settings should vary depending on the level of control your organization has over devices, for example BYOD vs company-owned devices. Consider the following settings, especially for company-owned or single-purpose devices.

• Apply device security settings:
  • Allow all mandatory apps
  • Deny all non-sanctioned apps—for example, ensure that apps like Tor browsers aren’t installed on devices
  • Mandate passcodes on devices combined with minimum screen-locking periods
  • Mandate that firewalls are running on devices
  • Mandate that devices are not jailbroken or rooted
  • Mandate a minimum secure operating system for each device type
• Monitor and remediate devices
  • Alert when devices install non-sanctioned software
  • Alert when mission-critical devices leave the network or go offline
  • Alert when devices violate mandated security settings
  • Restrict non-corporate cloud apps
  • Remove device profiles when devices leave their proper geographical area or violate device security rules
  • Remove device applications when devices leave their proper geographical area or violate predefined device security rule

Enrollment

Before devices can be managed within Systems Manager, they have to be enrolled in your Enterprise Mobility Management (EMM) network. Different types of enrollment can be used to meet the needs of different device types or deployment models. For example, while the simplicity of fully automated enrollment is ideal, this method does not suit Bring-Your-Own-Device (BYOD) deployments. It also isn’t compatible with all devices. Some of the available enrollment methods are described below.

Systems Manager Enrollment Authentication

To provide an extra layer of security, you can require authentication upon enrollment through services such as Active Directory, Azure, Google, or Meraki authentication. Authentication is compatible with all types of enrollment, and it has additional benefits beyond security. First, enrollment authentication ties an owner to a device automatically. Second, enrollment authentication can tie in a user’s groups (either LDAP or those managed by Cisco Meraki solutions) to all of their devices as dynamic tags, for automatic grouping.

For a comprehensive guide to enrollment authentication, refer to the SM Enrollment Authentication article.

Tags

Tags are used to group devices and to inform you of a device’s current state within Systems Manager. These tags, once generated, can be used to define the apps, profiles, and settings that are provisioned by Systems Manager. For a comprehensive guide to tags, refer to Using Tags in Systems Manager.

There are three main types of tags:

• Static tags (category: Device Tag) are generally applied manually to individual devices by the administrator.
• Dynamic tags (category: Policy Tag) are automatically applied to devices based on their state and can change depending upon certain factors:
  • Time-based tags use time-of-day information to implement device configurations, enforce policy restrictions, and enable application access.
  • Geofence tags use location-based information to implement device configurations, enforce policy restrictions, and enable application access.
  • Security policy tags use a device’s posture to implement device configurations, enforce policy restrictions, and enable application access.
• Owner tags (category: User Tag) use identity information to implement device configurations, enforce policy restrictions, and enable application access. Owner tags can be created or automatically imported from certain directory systems.

Scoping apps and profiles with tags is accomplished by using logical operators (AND and OR), which allows for a high degree of granularity when setting a device scope.

Profiles

After a device is enrolled, additional configuration profiles can be installed via Systems Manager. These profiles contain settings that are installed onto your managed devices, such as Wi-Fi access, VPN access, device restrictions, app home-screen layouts, email ActiveSync settings, and much more. Profiles allow you to easily customize and secure your enrolled devices. For more information, review Configuration Profiles.

In the Cisco Meraki dashboard, the Systems Manager > MDM > Settings page allows you to create or delete configuration profiles. These profiles are not to be confused with management profiles, which are installed when a device is first enrolled into Systems Manager.

Profiles are scoped to devices based on tags. This allows you to specify the devices, users, and specific conditions required for a device to receive a profile.

In an enterprise environment, it is often necessary to preconfigure or limit the availability of some features. These can be restrictions like disabling the camera or configuring settings like email or Wi-Fi. Restrictions and settings can be collected together into a profile, and devices can have multiple profiles applied to them.

Applications

Cisco Meraki Systems Manager can deliver both mobile and desktop applications through the dashboard. This includes apps found in public app stores (iOS, macOS, Android) and custom apps (iOS, macOS, Android, Windows) that can be hosted externally or on the Cisco Meraki cloud.

Security

Endpoint device security takes on multiple roles in a multi-cloud environment. By leveraging security profiles, you can verify end users are using devices only in the manner you intend them to. By using a combination of notifications and remote wipe tools through Cisco Meraki Systems Manager, you can mitigate potential security breaches in the event a device is lost or stolen.

Mobile Live Tools

The live tools that are available depend on the device’s vendor and the level of access given to any Mobile Device Management (MDM) solution.

• Mobile security: Mobile security gives remote control over devices, including:
  • Locking devices
  • Clearing passcodes
  • Selectively wiping devices (removing MDM-delivered applications and profiles)
  • Erasing devices (resetting devices to factory defaults)
  • Lock bypass that allows you to disable the activation lock on an iOS device when you do not have access to the Apple ID account used to lock it.
• AirPlay (iOS only): The AirPlay tool can be used to initiate streaming to known AirPlay-supported devices using MAC or device name.
• Power Control (iOS only): Power Control allows remote rebooting or shutdown of a device.
• Send Notification: The Send Notification feature sends a pop-up notification to the device to alert an end user.
• GPS Location (iOS only): GPS Location enables a request of the current location of an iOS device and delivers it back to the interface.
• Single App Mode (iOS only): Single App Mode locks an iOS device into a specific mode in which only the app you select will be available for use on the device. This is also referred to as Kiosk mode.
• Beacon (Android only): The Beacon feature enables an alarm to sound on an Android device to locate it.
• OS Upgrade (iOS only): OS Upgrade supports remote upgrading of an iOS device.
• Lost Mode (iOS only): When enabled, Lost Mode can push specific messages and contact information to the device on the lock screen.

Desktop Live Tools

The live tools that are available depend on the device’s vendor and the level of access given to the MDM solution.

• Mobile Security (macOS only): Mobile security gives you remote control over devices, including:
  • Locking devices
  • Changing passwords
  • Selectively wiping devices (removing MDM-delivered applications and profiles)
  • Erasing devices (resetting devices to factory defaults)
• Process List: The Process List tool provides an active list of all running process on the device at the time of execution.
• Command Line: The Command Line tool allows administrators to run shell commands on Windows and Mac devices.
• Network Stats: Network Stats gives remote visibility into current network-specific information such as TCP connections, TCP statistics, and the device’s routing table.
• Screenshot: The Screenshot feature enables access to a real-time screenshot of the desktop device.
• Remote Desktop: The Remote Desktop feature enables full remote access to the MDM-managed desktop device.
• Power Control: Power Control allows remote rebooting or shutting down of a device.
• Send Notification: The Send Notification tool sends a pop-up notification to the device to alert the user.
• OS Update (macOS only): OS Upgrade supports remote updating of a macOS device.