Distributed Data Plane Approach

In a Large Campus deployment, Meraki Wireless is recommended to be deployed with at most 800 APs and 10K clients per Meraki Network today with seamless and fast roaming. Meraki Wireless deployments leverage a distributed data plane approach, meaning that all the MR access points locally switch all the wireless traffic to the rest of the network. This is like a FlexConnect deployment using a Cisco AireOS or Catalyst 9800 WLCs.

One of the main benefits of the distributed data plane approach is that it addresses the throughput demands of newer Wi-Fi standards, like Wi-Fi 6E and beyond, since each AP will switch all its wireless traffic locally to the rest of the network. Unlike centrally switched WLC-based deployments where throughput is limited by the WLC, the total throughput of a distributed wireless network scales based on the number of access points and is only limited by the underlying switching architecture.

Additionally, since Meraki leverages the distributed data plane and a cloud-based device manager, it reduces the amount of equipment that needs to be deployed since, for most cases, a WLC is not required as the Meraki Dashboard manages and monitors all devices in the network. Only MR Access Points are needed to deploy.

However, using a distributed data plane approach requires more planning on the roaming domains and switching architecture.

Switching Architecture

When designing the underlying switching architecture, the ports on the access switches that are connected to the APs follow these recommendations:

• The ports should be configured as trunk ports to allow the APs to pass multiple VLANs when they switch the wireless traffic to the wired network.
  • Ensure the VLANs for management traffic for the APs and each broadcasted SSID are allowed on the port.
  • For zero-touch provisioning of the MR, set the native VLAN on the trunk port to be the management VLAN for the APs.
• Configure the ports with Spanning Tree Portfast Trunk, BPDU guard, and Root guard.

For more information, please see the article on VLAN Tagging on MR Access Points: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging_on_MR_Access_Points

If wired clients are connected to the same switch, the VLANs associated with the wired clients should be confined to that specific access switch (see the example below). VLANs associated with the wireless clients should span across all the access switches that are within the roaming domain. This will be discussed in the next section.

Moving up to the distribution layer switches, it is recommended to configure the distribution switches in either:

• StackWise Virtual / Virtual Stacking
  • Provides redundancy at the distribution layer with no deliberate layer 2 (L2) loops.
  • Uplinks from the access switches to the distribution switch must be configured as trunk ports and in EtherChannel.
  • Prune the allowed VLANs on the trunk ports to only the required VLAN.
• HSRP / VRRP
  • Provides first-hop redundancy.
  • STP Root and HSRP primary should be configured on the same switch.
  • Uplinks will be configured as trunks and EtherChannel.
  • BPDU and Root Guard on downlinks and Loop Guard on uplinks
  • Only the required VLANs should be allowed on trunks to the distribution layer.

The VLANs the wireless clients are placed in when connecting to the WLANs must be allowed on the trunks between the distribution and all the access switches that are part of the roaming domain.

Dual PoE for MR57 (PoE Redundancy and LACP)

MR57 has two Ethernet ports and can support 802.3af/802.3at/802.3bt/UPoE. 

There are three PoE operation modes:

• Single PoE: Only one Ethernet port receives PoE.
• Dual PoE (power sharing mode): Both Ethernet ports receive PoE. The power is split on both ports, not necessarily even.
• Dual PoE (dual-uplink mode): Both Ethernet ports receive PoE. If PoE on one of the Ethernet ports fails, MR57 will seamlessly switch to the remaining Ethernet port without adversely affecting wireless clients' connectivity.

In power-sharing mode, the power draw is not split equally among the two PoEs. MR57 tends to draw more power from the PoE with higher voltage. For example, if MR57 is connected to two 802.3af PSE ports and draws 23W in total, MR57 could draw more than 802.3af power from one PoE port (18W) while little from the other (5W). Some switch ports might shut down the port if the PD draws more power than the switch support, and MR57 will reboot. To solve this problem, MR57 needs to set the maximum power draw from the PSE depending on the classified PD type or LLDP/CDP negotiation results.

In the High-Availability mode, MR57 will not reboot or drop any wireless clients if one of the ports loses power.

For both cases, the switch will allocate the maximum power capable to both switch ports connected to the MR57. When planning the power budget, this behavior needs to be considered as the power allocated per AP will now be doubled.

For more information, please see here: https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR57_Dual_Uplink_High_Availability

Roaming Domains

A roaming domain is an RF continuity domain with the same SSID where client devices can stay connected no matter where they move within the domain. These can be multiple physical or virtual domains where users would logically move and require fast and seamless roaming to maintain connectivity for their applications.  

What does fast and seamless roaming mean?

• Seamless: You have a seamless roam when the client keeps its IP address and policy as it roams across different APs. A seamless roam requires keeping stateful client information of both the policy and IP address, no matter which AP the client connects to within a roaming domain. Meraki Dashboard ensures this information is kept consistent among all APs within the network.
• Fast: You have a fast roam when a client does not have to re-authenticate every time It roams to a new AP.  A fast and secure roam requires keeping the Pairwise Master Key (PMK), derived during the initial authentication, consistent and shared with the roaming domain. This guarantees small delays in roaming, usually less than 50ms. To achieve this, key caching protocols, like 802.11r or OKC, need to be enabled and supported by clients. To further optimize this, networks can take advantage of 802.11k/v.

Roaming domains include groups of floors, a single building, multiple buildings, etc. Whichever physical or virtual groupings are chosen for the roaming domain will affect how the APs are added to Meraki Dashboard. Within Meraki Dashboard, there are two main management design constructs:

• Organization: A collection of networks that are part of a single organizational entity
  • Recommended number of nodes: 25,000
• Network: Set of Meraki devices, their configurations, statistics, and info. This is usually mapped to a geographical location (ex. Sites, groups of buildings, buildings, floors, etc.)
  • Recommended number of nodes: 800

A Meraki Network is the fast-roaming domain, as the client PMK information is shared between MRs that are part of the same network. Also, the APs must be in the same management VLAN and be able to communicate with each other using source port 23541 and destination port 35213. This will allow the APs to share the PMK for the clients amongst each other. Thus, client devices roam between APs in the same Meraki Network, they will do a fast roam between the APs. However, when roaming between APs in different Meraki Networks, the IP address, policy, and PMK for each client is not shared, resulting in a hard roam where the client devices must fully reauthenticate.

Because of this, it is essential to design the roaming domains to divide the campus's physical locations with clear RF boundaries, ensuring that clients will roam to APs within the same roaming domains. Examples of finding these divisions can be:

• Geographical Areas: Look for sections of a campus that can be logically carved out. For example, the North, South, East, and West parts of a campus are named as such for a reason.
• Outdoor Wireless: Group outdoor wireless areas within the buildings they’re attached to.
• Stadiums/Sports Venues: These areas have large amounts of clients, so it would be best to make them their own individual roaming domain and a dedicated Network for them.

It is recommended to segment the campus by building as the smallest roaming domain. This is due to RF leakage between floors, leading to client devices possibly connecting to APs on different floors. Otherwise, clients might have hard roams within the same building.

Additionally, within a Meraki Network, it is essential to understand and decide whether there will be Layer 2 (L2) or Layer 3 (L3) roaming for clients when sizing the roaming domain as this will directly be impacted by the underlying switching architecture.

• Layer 2 Roaming: This is when a client roams to another AP where the WLAN is associated with the same VLAN, maintaining its session. This is due to the SSID being the same and on the same VLAN, leading to a seamless roam (same IP address) as well as a fast roam. If clients roam to an AP where the same WLAN is associated with a different VLAN, the session breaks, and the client must eventually re-DHCP, which may take a few seconds.
• Layer 3 Roaming: If clients roam to an AP where the same WLAN is associated with a different VLAN, but there is a mechanism in place (tunneling, re-anchoring to original AP) that allows the client to keep its IP address and hence the roaming will be seamless.

	L2 Roaming  (same VLAN)	L2 Roaming (different VLAN)	Distributed L3 Roaming (different VLAN) **
Same SSID	Client re-auth Seamless (same IP)	Client re-auth Session breaks	Client re-auth Seamless (same IP)
802.11r (or OKC)	Fast roaming Seamless (same IP)	Fast roaming Session breaks	Fast roaming Seamless (same IP)

Distributed L3 Roaming (DL3R) is Meraki’s solution to provide seamless L3 roaming. As of today, this solution doesn’t support fast roaming at scale; hence, it is not recommended for a large enterprise campus.  For this reason, it’s recommended to go with an L2 roaming solution, and it becomes essential to design the network in such a way that when seamless and fast roaming is required, the same VLAN is associated with all the MRs in the Meraki Network. If large-scale Layer 3 roaming is required, please reach out to the Cisco Wireless Business Unit.

How bad is it if there is a VLAN change and the session breaks because the client's IP address is no longer valid? It depends on the client operating system (OS):

• Even with a full re-auth on roaming (no fast roaming enabled or crossing a Meraki Network boundary), some client OSes may consider the same SSID equal to the same network and subnet, and hence, they might not check if DHCP is still valid.
• Windows OS does a DHCP inform and GW detection upon roaming, but no OS will go through the whole DHCP discovery process.
• Other client OSes will not do anything, and DHCP will time out (30-second session break)
• If roaming fails and the client receives a de-auth, then the client will do a full DHCP discovery after a new reauthentication (still 4-5 seconds)

In addition to client behavior, it is important to consider the impact on the applications and services on the network if the session breaks. Will the application recover seamlessly? Some applications like VPN will not work and need to re-establish the connection. Additionally, services like DHCP and AAA will be under extreme pressure in the case of a mass roam where client sessions must be re-established. To get around these issues, a seamless and fast roam is essential, and the same VLAN for the clients is required, which will require an L2 Roam.

However, having an L2 roam with the same VLAN for the WLAN requires the VLAN to be spanned across all the access switches within the roaming domain, possibly spanning multiple wiring closets or even multiple buildings. Depending on the number of devices in the roaming domain, there may be a requirement for a large subnet for the VLAN, which leads to a large broadcast domain.

The size of this VLAN will be affected by the types of Layer 2 and Layer 3 switches deployed at the site. Their MAC address and ARP table scale, the impact of spanning tree on the CPU, the client scale, the DHCP scope design, and many more will directly impact how large a VLAN can be deployed. The best practices of access network design should be followed.

It's recommended to keep separate VLANs/subnets for each roaming domain in addition to RF boundaries. This will limit the size of the broadcast domain to that of the roaming domain, limiting the impact of traffic like broadcast, unknown unicast, and multicast (BUM). Also, this will reduce fault and security issues (TCAM/ARP attacks, broadcast storms, etc.). It has the added benefit of simplifying management since the VLAN/subnet can easily locate clients.

RADIUS

RADIUS Server Scale

Meraki Dashboard has a max of three AAA servers per SSID that can be configured. These are configured in order of priority that they will be used.

1. The AAA server configured first will always be used first.
2. If Server 1 fails, then Server 2 will be used.
3. If Server 2 fails, the Server 3 will be used.

The MRs can be configured with the fallback option enabled. Once the higher-priority server recovers, the AP will fall back to using that preferred (higher-priority) server.  

Typically, having three AAA servers per SSID is not a constraint. Still, for large, high-density deployments, it is recommended to consider placing a load balancer in front of the AAA servers to scale to a larger number. If using a load balancer, configure a sourced-based sticky load balance for each client session to always talk to the same AAA server, given that it’s alive.

For more information, please see here: https://documentation.meraki.com/MR/Access_Control/MR_Meraki_RADIUS_2.0

Adaptive Policy

Cisco Group Based Policy and, specifically, micro-segmentation with SGT is supported on Meraki. Note: Only inline tagging is supported (no SXP). This means that to apply an end-to-end policy, all the switches in the path need to support SGT and inline tagging. Only MS390 supports Adaptive Policy, so using other Cisco Catalyst switches is recommended.

For more information, please see here: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Adaptive_Policy/Adaptive_Policy_Configuration_Guide

DHCP

When configuring the DHCP for the campus, size the DHCP scope first by considering all the possible devices that could join the area/building. These devices can range from stationary devices, such as network devices, printers, TVs, etc., to roaming devices, like phones and laptops. If it connects to the network, it must be taken into account. The last thing we want to happen is to run out of DHCP addresses. Larger scopes are needed for high-density areas, think stadiums and public events (/16 or /18). The recommendation for the pool size should be around three times the number of expected clients.

The DHCP Lease time is critical to the DHCP design as it could prevent DHCP scope starvation and security issues. To choose the lease time for a DHCP scope, align this to the average dwell time in the environment it will be deployed in.

Some examples are:

• Universities: 8 hours
• Retailers: 1 hour
• Offices: 12 hours

For higher security, the lease time can be set very low (ex. 30 min), but this is the cost of increased load on the DHCP server and APs. Clients will check their DHCP at the half-life, so decreasing the lease time will increase the frequency of these checks. The DHCP lease should also be lowered for RCM environments to prevent starvation, as the same device could be assigned different IP addresses whenever its MAC address changes.

If Static IP assignment is required, consider using DHCP reservation on the DHCP server. Doing this will keep the added security from enabling DHCP Mandatory while giving the flexibility to use a Static IP address.

With these in mind, the DHCP scope will most likely be limited by the subnet size allowed for each size. For example, each building may have its own subnet that can be max /24. Some reasons for this are:

• Subnet design and summarization at the distribution level
• The use of Public IPs whose subnets can’t easily be increased or changed.

If the subnet design limits the DHCP scope, consider configuring VLAN pooling. This allows multiple VLANs to be assigned to a single SSID.

For more information, please see here: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/VLAN_Profiles

DNS

Using a bridge mode SSID is recommended so wireless clients can receive the DNS server information from the organization's DHCP server.

However, if deploying the SSID in NAT mode, please refer to config guide: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Configuring_Custom_DNS_for_an_SSID_in_NAT_Mode

Firewall

For detailed instructions to configure, please refer to the configuration guide: https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/MR_Firewall_Rules

Multicast to Unicast

MR maintains the list of clients that joined a multicast stream. This is learned through IGMP snooping. MR only sends unicast (converted) packets to those clients that requested the multicast stream.

For more information, please see here: https://documentation.meraki.com/MR/Other_Topics/Multicast-Unicast_Conversion

Multicast and AAA VLAN Override

When a single SSID is used and mapped to multiple client VLANs via AAA policies, IP multicast separation may be required across the client VLANs.

In the example below, clients belong to the same SSID and IP multicast separation is not configured. This results in the following behavior.

1. Client 1 requests IP multicast
2. IGMP query goes on VLAN 100
3. Multicast traffic is received in VLAN 100
4. In the air, since #1 SSID <> #1 GTK, AP sends it as broadcast and traffic is received by client 2 (on VLAN 103) as well.
5. There is no multicast or broadcast segmentation in air. This applies to IPv4 and IPv6.

In order to configure IP multicast separation, ensure the multicast to unicast feature is enabled. This configures the MRs to “de-multicast” traffic over the air to preserve the VLAN segmentation.

mDNS

mDNS is supported and allows Bonjour services to work across multiple VLANs. You can also choose specific services to enable Bonjour forwarding for a limited subset of services (e.g., only for AirPlay). Please note that location-specific filters are not supported.

For more information, please see here: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Bonjour_Forwarding

Bridge Mode SSIDs

Configuring the SSID in bridge mode is recommended for large-scale centralized or distributed deployments. The APs will work transparently, performing neither DHCP nor NAT. This provides L2 connectivity to the LAN and allows the organization’s DHCP server and NAT router to handle all the client traffic. When put in bridge mode, the client traffic must be tagged with the correct VLAN so the appropriate actions can be applied to the traffic.

Please be aware that bridge mode SSIDs only allow communication on the same VLAN, so Distributed L3 Roaming or L3 with a concentrator will be necessary to roam between subnets. However, there will be additional overhead involved with these configurations, so they are not ideal for a completely seamless roaming experience.

For more information on Bridge mode SSIDs, please see here: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Modes_for_Client_IP_Assignment

6 GHz WPA3 design

With the release of Wi-Fi 6E and the 6 GHz band, stricter WLAN security measures are now required. For an SSID to be broadcast in 6 GHz, it is mandated to configure the following:

• WPA3 for the layer 2 security. This can be either:
  • OWE
  • SAE
  • 802.1X SHA256
• Protected Management Frame (PMF) enabled.
• No non-WPA3 L2 security method is allowed (i.e., no mixed mode is possible)

Because of the above requirements, most current WLAN deployments may not support broadcasting in 6GHz. To solve this, there are three recommended migration paths:

1. “All-In” Option: Reconfigure the existing WLANs to use WPA3 (one SSID for all three radios 2.4/5/6 GHz)
2. “Multiple SSIDs” Option: Redesign the WLANs to have specific WLANs/SSIDs with specific security settings
3. “One SSID” Option: Coming in the MR31 release, a single SSID can be configured with transition mode (WPA2 + WPA3) on 2.4GHz/5GHz and WPA3 only on 6GHz. More information to come when the feature is released.

VLAN planning

When designing the VLANs and subnets for the clients, please follow the best practices outlined in the DHCP section above.

Some general recommendations for client VLANs are:

• VLAN broadcast domain rules apply
  • /24-/20 subnet sizes
  • Enable wireless multicast-to-unicast
• Consider separating VLANs
  • Example: Create a Service VLAN for printing resources for visitors
  • Use tag based VLAN and/or SSID assignment
• For the MR30 release or later, configure Named VLAN / VLAN pooling for larger client VLAN sizes.

AP Tags

AP Tags are a great way to segment or partition groups of MRs within the same Meraki Network based on different use cases and needs. Some examples of this can be:

• Tag-based RF Profile Assignments
  • APs in a classroom vs APs in an auditorium
  • Ceiling vs wall mount APs
• More easily run search, report, and analytic filters on specific groups of APs
• SSID Availability: Broadcast SSIDs based on APs for a certain length of time
  • Ex. Guest SSID only broadcasted by lobby APs from 8 am to 5 pm on weekdays.
• VLAN Tagging: Different VLANs are applied for the same AP based on the AP tag

For more information on creating AP tags, please see here: https://documentation.meraki.com/MR/Monitoring_and_Reporting/Using_Tags_to_Manage_MR_Access_Points

For more information on using tags for SSID availability, please see here: https://documentation.meraki.com/MR/Other_Topics/Using_Tags_to_Broadcast_SSIDs_from_Specific_APs  

Quality of Service Guidelines

QoS can play an important role in your network as it helps prioritize and reliably deliver certain types of data using the Differentiated services model. "DiffServ" implements the prioritized model by marking packets according to the type of service they desire. In response to these markings, access points, routers, and switches use various queueing strategies to tailor performance to expectations.

Some general guidelines when configuring the QoS for your wireless networks are:

• SSID
  • Set the SSID to prioritize a type of traffic (e.g. VoIP and video conferencing)
• Switching Infrastructure
  • Define and match the DSCP values that are used by the SSID and the rest of the network.
• WAN Infrastructure
  • Keep the QoS policies between the different sites consistent
  • Apply the policies for bidirectional traffic.

When shaping the traffic on the SSID for clients and applications, the types of traffic and their requirements should be considered. The traffic shaping should not be done as a top-down enforcement for the entire SSID. Instead, traffic should be shaped per client followed by per application.

In the case of guest networks, it may be necessary to apply bandwidth throttling policies. For these guest clients, you must understand their workload and the average bitrate needed before applying any shaping rules. After determining the required bandwidth limit, apply this to the per-client bandwidth rules. Enable SpeedBurst as well to allow for a graceful traffic shape, so users can go past their allotted bandwidth temporarily to access any services or download small files without a degraded experience.

For applications, mission-critical applications can be derestricted and prioritized, while recreational applications or bandwidth-hogging applications can be restricted. These applications can be chosen based on the deployment use case. For example, video conferencing and collaboration applications can be prioritized along with the industry-specific applications while simultaneously restricting the performance of applications like peer-to-peer and cloud backup / OS updates.

For more information, please see the configuration guide on traffic shaping here: https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Traffic_and_Bandwidth_Shaping

Access Point Radio Configuration

Wireless Mesh Networking

If wireless mesh deployments are not needed, it is recommended to set the Meshing settings to Meshing disabled. This will stop the MR from broadcasting the Mesh SSID, which will save airtime.

For more information, please see here: https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Wireless_Mesh_Networking

AI-Powered Auto RF

Infrastructure Management

Features that Need Support to Enable

Unless otherwise stated, all features can be configured from Meraki Dashboard. For some features, Meraki Support will need to enable your organization to be able to use these features. In these cases, this will be clearly marked on the feature’s configuration guide like the note below.