Starting with this section, the rest of the chapter focuses even more on large campus design. As noted previously, many of the aspects that are required for designing and deploying a large campus network can be scaled down and applied as needed to smaller deployments based on your deployments needs. By discussing these at scale, we can address the most complex implementations of these concepts, which you can then take and apply as needed based on your unique deployment.

Why Distributed Networks?

One key aspect to keep in mind when designing and deploying Meraki wireless is that Meraki uses a distributed data plane approach instead of a centralized, controller-based approach. Although the Meraki cloud is used as a controller for the management of Meraki devices, with most configurations, client traffic is passed from the AP the client is connected to directly on to the LAN, instead of being forwarded across the LAN to a central controller and then forwarded back to the destination. With Meraki, any configured traffic filtering or policing is performed directly at the AP or at the local firewall instead of on a remote controller.

Meraki’s distributed data plane approach offers the following advantages compared to a more traditional centralized, controller-based deployment:

No reliance on a central controller to process all client traffic: This allows for improved throughput and general performance across the network by reducing latency and path complexity. This is key for taking full advantage of improvements offered by Wi-Fi 6 and Wi-Fi 6E and beyond.

Much smaller failure domains for APs: Instead of hundreds or thousands of APs being down due to a controller failure, only directly impacted APs are down with Meraki.

Lower costs to implement high availability: HA can be implemented without the need to scale out redundant controllers.

Meraki also preserves flexibility by allowing distributed SSIDs to be broadcast while at the same time allowing other SSIDs from the same AP to be backhauled to an MX concentrator. This ability can be used for SSIDs that require additional, centralized control, such as guest or IoT SSIDs.

Authentication and Encryption

When designing your deployment, it’s important to consider the type of clients that will be connecting to the network and how. For most networks, especially large deployments, multiple SSIDs are needed based on differing use cases and security requirements of the clients connecting to the network. Because of this, it’s important to make sure you select the right type of encryption and authentication methods for each SSID based on the intended use case.

Pro Tip

All SSID-level authentication and encryption settings are configured from the Wireless > Access Control page in the Dashboard.

For example, you would not want to use a fully open SSID for internal communication that could contain sensitive data, and likewise it would likely be overkill to require 802.1X authentication for a basic guest SSID. Like all planning decisions, your ideal configuration will be specific to your deployment and intended uses. The following list provides some of the most frequently used authentication and encryption methods:

• Open authentication

• MAC-based authentication (printers)

• Pre-Shared Key

• PSK

• IPSK with or without RADIUS

• Opportunistic Wireless Encryption (OWE)

• WPA2/3 with 802.1X

Pro Tip

Every MR access point can act as a network access server (NAS) to connect to your AAA server for 802.1X authentication.

You can find more details about the configuration and operation of these authentication and encryption methods and other supported options at https://documentation.meraki.com by searching for the related technology or feature name.