Monthly Archives: July 2024

Month: July 2024

Setting Up Enterprise-Grade Meraki Wireless– Cisco Meraki Switching Design and Recommendations

This section approaches planning a large campus deployment from the ground up to explore how the topics discussed so far in this chapter can be applied in a real-world example scenario.

Defining Roaming

The first step to building and deploying a Meraki wireless network is to define your roaming domains. But before defining your roaming domains, you need to understand what types of roaming exist and how they can impact your roaming domain plans.

First, you have to understand that a roam is any client connection where the client reassociates from the currently connected AP to a new AP and remains connected to the same SSID without being required to complete a full association and authentication. When clients move to a connection outside of the current roaming domain, even with the same SSID, they are required to perform a full reauthentication. With that in mind, there are a few more specific types of roaming that you should be aware of:

• Seamless roaming: This is a roam where the client is able to maintain a stateful connection with a consistent IP and security policy applied both before and after the roam. A good example of this type of roaming is a basic Layer 2 roam between two different APs within the same VLAN with the same SSID/PSK. This allows clients to roam while maintaining any active/open sessions, albeit with the possibility for a slight interruption during the roaming process itself for any real-time traffic.

Note that if the client roaming requires crossing a Layer 3 boundary, the client will require a new IP assignment, which will result in a break in connectivity for any existing sessions and will no longer be considered seamless roaming, even if connecting to the same SSID.

• Fast and secure roaming: This is a more advanced type of seamless roaming with the primary goal of keeping the entire roaming process as short and secure as possible, ideally with an interruption of less than 10 ms. This is important any time clients may be roaming between APs while actively requiring real-time connectivity, such as while making a VoIP or video call. This type of roaming requires a slightly more advanced configuration, such as enabling 802.11r or Opportunistic Key Caching (OKC).

• Distributed Layer 3 roaming: This type of roaming allows devices to effectively perform a seamless roam between APs that cross Layer 3 boundaries without the use of a dedicated concentrator. This allows clients to roam across Layer 3 boundaries while also maintaining a consistent IP and security policy. This can be extremely useful for large deployments where, for whatever reason, it may not be feasible to place all APs in the same VLAN or Layer 2 domain but clients still require seamless roaming between APs, such as between floors in a large building.

In short, distributed Layer 3 roaming functions by designating the first AP to which a client connects as an “anchor” AP. Then, when the client roams to a new AP that does not have access to the original Layer 2 domain, a tunnel is automatically built between the new “host” AP and the last anchor AP to allow the client traffic to be forwarded from the host AP to the anchor AP and allow the client to maintain connectivity with the original Layer 2 domain and provide a seamless roaming experience to the client, despite the new host AP not having direct access to the original client VLAN/Layer 2 domain.

Defining Domains

Properly planning a wireless deployment requires properly understanding and defining the different domains for a network so they can each be properly scoped and planned. This section covers roaming domains, Layer 2 domains, and Layer 3 domains to help you better understand how to define and scope each domain to ensure optimal performance and manageability.

Roaming Domains

Now that you know the different types of client roaming that can happen within a roaming domain, you can begin looking to define the actual roaming domains for your deployment.

One of the most important aspects to know when defining roaming domains for an enterprise wireless network is the expected roaming requirements for clients using the network. By understanding where seamless or fast roaming is and is not required, you can properly designate roaming domains around the deployment and begin optimizing the user experience even before any hardware is deployed.

A roaming domain is determined by the need for clients to have uninterrupted RF coverage across a geographical area. As noted previously, a roaming domain is characterized by an area where clients are able to connect to the same SSID across multiple access points without requiring a complete reauthentication.

Pro Tip

The Meraki Dashboard exists as a hard boundary for client roaming. When roaming between access points in different Dashboard networks, clients are forced to perform a full authentication regardless of any existing connections or other configurations.

Roaming domains can be scaled to appropriately fit the needs of a deployment and can be based on physical, geographic, or other boundaries, such as different buildings or even floors within each building, depending on your expected deployment size and use case for wireless clients.

In the hypothetical large campus deployment depicted in Figure 8-18, roaming domains are designated based on building boundaries and outdoor areas around campus. For example, clients are unlikely to require seamless roaming as they move between different buildings around campus, or between different dorms, while they likely would want to seamlessly roam while moving from one room to another within the same building.

Figure 8-18 Example Campus Broken Down into Multiple Wireless Roaming Domains

This approach allows administrators to designate each building location as a unique roaming domain, while also designating large outdoor areas like a student courtyard or sports fields as separate roaming domains, allowing students to retain seamless connectivity in the areas they are most likely to require it while moving between APs. Since most students are not actively relying on important low-latency streams while walking around campus, the campus can be broken up into separate roaming domains to help ensure the best experience where it matters most.

Pro Tip

In a more traditional Catalyst environment, this type of network/roaming boundary may be mapped to a site tag instead.

Caveats in Setting Up Adaptive Policy– Cisco Meraki Switching Design and Recommendations

For complete security and functionality, Adaptive Policy (SGT) must be supported by every device in the network. If an intermediate device does not support the CMD encapsulation used for SGT, it will drop SGT-tagged frames.

Pro Tip

Adaptive Policy definitions only apply in one direction. To block traffic entirely between two groups, you must manually define a block policy for both directions of traffic.

When considering MS SGT assignments, it is essential to keep the following considerations in mind:

• Hardware requirements:

• Switch and firewall: Ensure that your Meraki switch and firewall model support SGT functionality. Check the datasheet or documentation for hardware compatibility.

• Catalyst in Meraki-managed mode: If using a Cisco Catalyst switch in Meraki-managed mode, verify that the specific Catalyst model and software version support SGT assignments.

• Wireless: If integrating SGT assignments with wireless devices, confirm that your wireless access points are compatible with SGT functionality.

• Compatibility with other Cisco technologies: Consider how SGT assignments interact with your network’s other Cisco technologies. Ensure compatibility with technologies such as Cisco ISE for authentication and authorization.

• Software and licensing requirements: The Adaptive Policy feature is part of the MS Advanced license, which provides additional security features beyond the standard Enterprise license. To use the Adaptive Policy feature, you need to have the appropriate licensing level that includes this feature. Refer to the official Cisco Meraki documentation to get accurate and up-to-date information about licensing requirements and feature availability.

For more detailed information regarding micro-segmentation on the Meraki platform, visit https://documentation.meraki.com and search for the keyword Adaptive Policy or Micro-segmentation.

Operating and Optimizing Meraki Switches

This section covers several tools and tricks available in the Dashboard to help you easily manage your switching deployment, regardless of the scope or scale of your deployment or the changes you are making.

Virtual Stacking

Meraki MS switches offer centralized management of switch ports through site-level virtual stack logic, enabling seamless search and configuration changes across thousands of switch ports in a network. Unlike traditional stacking methods, virtual stacking does not demand a physical connection, allowing switches to be located in different physical places and even consist of various switch models.

Consider the scenario of adding a new service VLAN that would require modifying the allowed-VLAN configuration across multiple trunk ports on multiple switches. In the Dashboard, you can open the virtual stacking page by navigating to Switch> Switch Ports. Once there, you can easily search for all trunk ports using the term is:trunk, as shown in Figure 7-31. You can then select a subset of these ports and make a bulk edit on the switch port.

Figure 7-31 Using Virtual Stacking to Search for and Edit Multiple Trunk Ports in a Network

You can also use combination filters to add more search criteria, such as is:trunk VLAN:native 128 to search for all trunk ports configured with native VLAN 128, as shown in Figure 7-32.

Figure 7-32 Using Combo Filters in Search Criteria

Here are few other useful search filters:

• lldp:mr: To search for switch ports connected to Meraki access points

• lldp:mr56: To search for switch ports connected to MR56 access points

• is:uplink: To search for uplink ports

• vlan:”60″: To search for switch ports on VLAN number 60

• vlan:”native 60″: To search for switch ports with native VLAN number 60

• tag:”myfavport”: To search for switch ports that match the given tag value

Note

These are only a few sample filters. For all available ports, search https://documentation.meraki.com with keywords Searching ports.

You can find more information on virtual stacking shortcuts at https://documentation.meraki.com by viewing the article “Switch Ports.”

Firmware Upgrade Consideration on MS

We recommend allocating a minimum of 30 minutes for a firmware upgrade window on Meraki switches. The actual duration can vary depending on factors such as the time of day and the bandwidth of your Internet connection, which can affect the download speed of the firmware across all your switches.

During the firmware upgrade window, the switches will initiate the new firmware download. Once the download is complete, a 20-minute timer starts before the switches reboot and install the new firmware. Meraki recommends that, outside of an upgrade process, all switches within a network should run the same firmware version. This ensures consistency and compatibility across the network. In some cases, if necessary, the Meraki support team can pin a specific firmware version to a switch. This means the switch will not receive the standard firmware upgrades and will remain on the pinned version until further notice or a different pinning instruction is given.

By allowing sufficient time for the firmware upgrade window and ensuring that all switches within the network run the same firmware version, you can effectively manage firmware updates on your Meraki switches and maintain a stable and up-to-date network environment.

An important and useful feature to be aware of when working with switch firmware upgrades is the staged upgrade feature in Meraki switches, which allows administrators to divide a network of switches into smaller groups. Each group can then have its firmware upgraded at separate times. This approach provides more flexibility and control during the upgrade process.

When planning to upgrade upstream and downstream switches on the same day, it is extremely helpful to schedule a 30- to 60-minute interval between each stage. This time gap allows for the complete download and verification of the new firmware, ensuring it does not disrupt an ongoing upgrade in a downstream switch. Another common use case for staged upgrades is to upgrade a large network over an extended period of time, such as several days or even weeks. For example, initially the upgrade may be pushed to a single IDF closet each round, culminating with the MDF finally being upgraded after all IDF devices have successfully upgraded.

For more information on MS firmware upgrades, go to https://documentation.meraki.com and view the article “MS Firmware Upgrades.”

Policy Enforcement– Cisco Meraki Switching Design and Recommendations

Once traffic has left the source and entered the network, a matching SGT will be applied inline before the IP header based on the source, similar to an 802.1Q tag. From there, the traffic is intended to traverse the network while maintaining the applied SGT to the edge nearest the destination; at this point, the traffic is again inspected, and the destination SGT is determined. Then, the source SGT and destination SGT are compared to the defined security policies (see Figure 7-30) to determine whether the traffic should be forwarded to the destination client or dropped based on the applicable policy. This creates a highly scalable policy framework, as the network device only needs to evaluate the tags of the clients directly attached to it and not the IP prefixes.

Figure 7-30 Adaptive Policy Deployment Logic

SGT Assignment Methods

In an Adaptive Policy network, after creating the Adaptive Policy tags, enabling Adaptive Policy, and classifying clients with relevant tags, the next step is policy enforcement. The critical feature of a tag-based network is that the policy is enforced at the destination network device. This setup makes the policy framework highly scalable, as the network device needs to consider only the tags of the clients directly connected to it, not the IP prefixes. However, this approach necessitates rigid requirements for micro-segmentation, including end-to-end support of the CMD encapsulation. Consider the different methods available for assigning SGTs:

• Static port assignment: Assign a fixed SGT to a specific port on the switch. This method is suitable for devices without a method of network authentication.

• Static SSID assignment: Assign a specific SGT to a single-use SSID, such as a guest network.

• Dynamic via RADIUS: Use RADIUS authentication and authorization for wired and wireless devices, supporting MAC Authentication Bypass (MAB), 802.1X, and Identity Pre-Shared Key (IPSK) with or without RADIUS integration.

• IP prefix to SGT map: Use this method to match traffic based on the IP subnet when no system is available to propagate SGT tags.

End Point Security – Cisco Meraki Switching Design and Recommendations

End device posture compliance, Mobile Device Management (MDM) integration, and supplicant provisioning are crucial in determining a dynamic security policy. Meraki group policy allows the creation and enforcement of network-wide policies across Meraki devices, providing a centralized method for applying rules and restrictions to client devices. These policies support dynamic assignment based on real-time conditions, such as time of day, location, or device posture.

Meraki’s Systems Manager Sentry is a powerful tool and extension of the Dashboard that enables you to directly integrate Dashboard network policies, like Group Policy, with the monitoring power of Systems Manager on end devices. Sentry policies take standard Group Policies a step further by creating a link between Meraki group policies and dynamic tags generated in Systems Manager (Meraki’s MDM solution) that can be used to further enhance the security of the end device. For example, if a device fails to meet certain criteria or compliance requirements, such as geo-fencing, Tor, or OS version, Meraki MDM can automatically assign a dynamic tag to it. This tag, when used in a Sentry policy, triggers specific policies within the Meraki group policy framework, allowing for dynamic policy enforcement, as illustrated in Figure 7-28.

Figure 7-28 Sentry Policy Mapping Between SM Tags and Group Policies in the Dashboard

It is important to note that Sentry policies do not directly apply to MS switches. SM Sentry policies are enforced on Meraki MR access points and MX security appliances. This means that any device connecting to the network via an MR access point or passing traffic through an MX firewall can have Sentry policies applied.

Micro-Segmentation with MS (Adaptive Policy)

Adaptive Policy represents the evolution of traditional segmentation into a modern approach that eliminates the need for constantly mapping ACLs to IP addresses. Traditionally, network security has relied on IP-based access controls. However, as businesses increasingly establish their presence online, the importance of network security for maintaining business continuity has become more critical. Cisco Meraki offers a robust solution for securing network access through ACLs and group policies. However, these group policies can become challenging to scale as organizations evolve and expand.

Micro-segmentation with Meraki switches offers an organization-wide, intent-based policy that integrates seamlessly with the Dashboard in ISE 3.2 (see Figure 7-29). Micro-segmentation is achieved in Meraki using Security Group Tags (SGTs), a feature that is part of Cisco’s TrustSec solution. This enables effective network segmentation and strengthens security by restricting lateral movement of threats within the network. By syncing natively with the Dashboard, Adaptive Policy ensures real-time visibility and control over the network policies, enhancing the overall network security management. Adaptive Policy functions through three key components: identity classification and propagation, security policy definition, and policy enforcement.

Figure 7-29 SGT Tag Propagation Is Supported Across Multiple Meraki Platforms

Identity Classification and Propagation

For Adaptive Policy using SGTs to function, you must first define the groups to be used. An Adaptive Policy group is a class of users or devices in an organization that require access to the same network services. Each SGT relies on a unique number (SGT value) associated with a specific group in an organization that can be defined when creating the group. Adaptive Policy utilizes organization-level policy groups (not to be confused with network-level group policies) defined in the Dashboard under the Organization> Policy Groups page to determine group membership. Here, policy groups can be created and defined based on multiple criteria.

Security Policy Definition

A security policy comprises a defined security SGT, a defined destination SGT, and the permissions for communication between them. Once you have defined the groups, you can define specific access restrictions based on group-to-group communication. For example, devices in the IoT group may have a defined policy that allows communication only to other IoT devices or related servers based on the selected groups within the security policy.

Change of Authorization with ISE Integration – Cisco Meraki Switching Design and Recommendations

Integrating Meraki MS switches and Cisco ISE allows for dynamic security policy enforcement using 802.1X Change of Authorization (CoA). 802.1X CoA enables the RADIUS server, such as Cisco ISE, to change the authorization status of a session at any point during that session. This capability provides dynamic enforcement of security policies based on changes detected on the client or network. You can also leverage 802.1X CoA to perform real-time policy updates and enforcement. For example, suppose an endpoint device undergoes a change in compliance status or security posture, such as a malware detection or policy violation. In that case, Cisco ISE can send a CoA message to the Meraki MS switch to enforce a new access policy or restrict network access for that specific device.

By integrating ISE with Meraki switches, you can leverage the capability of ISE to communicate with LDAP (such as Active Directory) to retrieve user attributes and group membership information. You can then use this information to dynamically assign policies based on the user’s role or group membership. For example, you can configure ISE to retrieve AD group information during authentication. Based on the user’s AD group membership, ISE can assign different policies to the Meraki switch, which will then apply these policies to both wired and wireless connections. Using RADIUS attributes, you can define policies in ISE that align with different user roles or attributes. These policies can include varying levels of network access, security controls, bandwidth limitations, and more. This allows you to grant different privileges to user groups based on their AD group membership.

Additionally, you can utilize Group Policy Objects (GPOs) in your Windows AD environment to further enforce policy settings on both wired and wireless connections, as illustrated in Figure 7-23. You can use GPOs to configure specific security settings, software installations, and other restrictions or configurations based on user or device attributes.

Figure 7-23 Operational Overview of Group Policy to Enforce Policy Settings

By combining the capabilities of ISE, Meraki switches, and group policy, you can achieve granular and dynamic policy enforcement based on user attributes, device posture, and network location, as illustrated in Figure 7-24. This enables you to provide differentiated access and privileges to different user groups, such as administrators, regular IT staff, students, and faculty, based on their organizational roles and responsibilities.

Figure 7-24 ISE Integration and Associated 802.1X Policy Shown on Client Page

Access policies contain the RADIUS host configuration information. You can configure one or more access policies by navigating to Switch > Access Policies in the Dashboard. You can then assign access policies directly to MS switch ports or via port profiles. When configuring integration with Cisco ISE, you must enable RADIUS CoA, as shown in Figure 7-25.

Figure 7-25 Enabling and Configuring RADIUS CoA in the Dashboard

Use Cisco ISE to implement macro segmentation by assigning VLANs based on the department the user belongs to. This allows you to create separate network segments for different organizational departments or groups. Configuring the integration between Meraki and ISE is essential, ensuring that the policies and attributes align to enforce the desired access control and security measures across the network. This includes mapping the appropriate ISE policies to the corresponding Dashboard group policies for consistent and effective network access control.

You can achieve micro-segmentation with ISE by mapping the Filter-ID with the Meraki Dashboard group policy. This allows you to assign additional Layer 3 rules automatically via the Dashboard group policy. Figures 7-26 and 7-27 show an example mapping for an ISE Filter-ID and corresponding Dashboard group policy.

Pro Tip

Integrating ISE Filter-ID mapping with other products such as MR access points also allows features like additional Layer 7 and traffic shaping rules to be enforced via group policy.

Figure 7-26 Mapping an ISE Filter-ID to a Corresponding Meraki Group Policy

Figure 7-27 Matching Meraki Group Policy for the Filter-ID in the ISE Authorization Profile

For more information on MS Group Policy ACLs, visit https://documentation.meraki.com and view the article “Meraki MS Group Policy Access Control Lists.”

Layer 3 capable MS switches also support 802.1X URL redirect, enabling the implementation of a walled garden approach for client authentication. URL redirect is enabled with Change of Authorization (CoA) on Meraki MS switches by default. This functionality allows you to redirect clients to a designated webpage for authentication before providing full network access. The walled garden feature lets you offer limited access to essential resources or permit access to specific websites without needing authentication. This proves valuable when clients require access to particular services or resources before completing the authentication process.

802.1X Authentication – Cisco Meraki Switching Design and Recommendations

On MS switches, like many other switches, you can use 802.1X authentication to verify devices on both wired and wireless networks. This method usually involves an external RADIUS server, such as Cisco Identity Services Engine (ISE), for identity verification and authorization. Meraki MS switches offer four 802.1X host modes for flexibility:

• Single-Host: Allows one device per port after successful authentication (see Figure 7-17).

Figure 7-17 Single-Host Authentication

• Multi-Domain: Supports one authenticated device on each of two different VLANs, such as voice and data VLANs, on a single port (see Figure 7-18).

Figure 7-18 Muti-Domain Authentication

• Multi-Auth: Permits multiple devices on a single data domain, often used when an unmanaged switch with multiple devices connects to a managed switch (see Figure 7-19).

Figure 7-19 Multi-Authentication

• Multi-Host: Authenticates only the first connected device; subsequent devices downstream are not authenticated (see Figure 7-20). This is used when the first device is trusted to authenticate on behalf of downstream devices. The multi-host mode may not provide the highest security, as only the first device is authenticated. It is commonly used when downstream devices are trusted, or downstream devices are authenticated by the connected network element.

Figure 7-20 Multi-Host Authentication and Switching

802.1X Failed Auth VLAN

Cisco Meraki MS switches support a Failed Auth VLAN configuration (see Figure 7-21) to provide basic access to clients that fail 802.1X authentication. This feature assigns a specific VLAN to these clients, offering limited connectivity for scenarios like guest users or devices without valid corporate credentials.

Figure 7-21 Defining a Failed Authentication VLAN in the Dashboard

802.1X Critical Auth VLAN

MS switches support multiple RADIUS servers for redundancy. In case where none of these servers are available, Meraki’s Critical Auth VLAN feature (see Figure 7-22) allows you to define VLANs for data and voice traffic. This ensures continued network access and service availability during RADIUS server unavailability.

Figure 7-22 Defining a Critical Authentication VLAN in the Dashboard

When implementing 802.1X authentication on Meraki MS switches, choose the appropriate host and failure mode configurations based on network requirements and security. Also, ensure the external authentication server, such as Cisco ISE, is correctly configured to handle authentication requests and enforce access policies.

MAC Authentication Bypass

MAC Authentication Bypass (MAB) is commonly used for devices lacking built-in support for 802.1X authentication, such as printers, IP phones, or other legacy devices. By employing MAB, these devices can still be authenticated and granted network access based on their MAC address. When configuring MAB on a Cisco Meraki switch, the switch will transmit the client device’s MAC address to the RADIUS server. The RADIUS server will verify if the MAC address is authorized and allow or deny access accordingly. If authorized, the client device will be granted network access.

It is important to note that while MAB offers a way to authenticate devices based on their MAC address, it is less secure than 802.1X authentication. MAC addresses can be easily spoofed, so additional security measures should accompany MAB to ensure proper network access control. Consider combining MAB with other security measures like VLAN segmentation, ACLs, and regular network traffic monitoring to enhance the security of devices authenticated through MAB.

Port Profiles – Cisco Meraki Switching Design and Recommendations

Meraki port profiles are designed to standardize and simplify port configurations on Meraki switches. You can create predefined port profiles based on specific functionalities or device types, such as printers or desktops. This feature empowers network administrators to apply consistent configurations to multiple ports effortlessly, streamlining the process. As shown in Figure 7-15, different port profiles can be created based on desired functionalities, ensuring ports with similar requirements share the same settings.

Figure 7-15 List of Several Example Port Profiles Shown in the Dashboard

Creating a Meraki port profile is straightforward. Navigate to Switching > Port Profiles in the Dashboard and click Add Profile. In the dialog box that opens, define the profile, including VLAN configurations, PoE settings, and access control policies.

After you have defined port profiles, you can apply them efficiently to individual ports or groups of ports, facilitating quick and accurate deployment of desired configurations across the network.

Somewhat similar to port profiles is Meraki’s Virtual Stacking feature, discussed later in the chapter, which helps you search for ports based on their characteristics or tags and make bulk changes (whereas port profiles allow you to define and assign a standardized configuration at scale).

VLAN Profile

VLAN profiles are designed to simplify VLAN management in large enterprise networks where VLAN numbers may vary across and within sites. This feature is especially beneficial when integrating with a RADIUS/ISE policy. Administrators can map VLAN names to site-specific VLAN numbers with VLAN profiles, as depicted in Figure 7-16. This allows consistent references to VLANs (like WORKSTATION in Figure 7-16) even if VLAN numbers differ across sites. This eases the configuration and management of VLAN assignments, particularly in multi-site scenarios.

Figure 7-16 Using VLAN Profile on MS with ISE Integration

To set up VLAN profiles, go to the Network-wide > VLAN Profile page. There you can create VLAN profiles and define VLAN name mappings for each network. After you have configured VLAN profiles, you can assign them to specific ports or groups of ports. Enabling the Enable Port Profile option on ports ensures that authenticated users and devices are assigned to the correct VLAN based on the VLAN name specified in the ISE policy. This feature applies to both Meraki MR access points and MS switches, providing a comprehensive solution for efficient VLAN assignments throughout the network.

Network Security

This section emphasizes controlling network access to ensure that only authorized individuals or devices can connect. Techniques include implementing secure authentication protocols like 802.1X, utilizing VLAN segmentation to isolate traffic, and employing MAC address filtering. Adhering to the Zero Trust Network Access security policy, network access is granted only to devices that require it, and resource access is strictly based on need to know.

Sticky MAC

Sticky MAC is a security feature on switches that limits the number of MAC addresses a port can learn. It associates specific MAC addresses with a port, allowing only those devices to connect. Although Sticky MAC is helpful for basic security, like assigning a port for a printer, it is not foolproof, as MAC addresses can be spoofed. Therefore, it should not be the only security measure for protecting sensitive resources. Despite its limitations, Sticky MAC offers basic security without external authentication, is easy to set up, and can help prevent unauthorized access through specific ports.

Port Isolation

On Meraki MS switches, the port isolation feature lets you set specific ports as isolated, stopping communication between isolated ports but allowing communication with non-isolated ones. Enabling port isolation means devices on isolated access ports cannot communicate with each other but can still communicate with non-isolated ports, such as the uplink port. This is handy when you want to limit communication between devices on different access ports but still allow them to communicate with specific devices or resources on the network through non-isolated ports.

Port isolation adds an extra layer of security by preventing unauthorized access or potential threats from spreading across the network. By making an access port isolated and designating the uplink port as non-isolated, you can restrict a device on the isolated port from accessing other devices while still allowing communication with the specified non-isolated port.

Dynamic ARP Inspection – Cisco Meraki Switching Design and Recommendations

To mitigate man-in-the-middle (MITM) attacks such as the scenario depicted in Figure 7-13, DHCP information gathered over time by Meraki switches in the network is used to create a mapping for Host: IP: MAC information per switch port. This mapping helps prevent malicious spoofing attacks. Dynamic ARP Inspection (DAI) assigns a trust state to each port on the switch. Trusted ports are exempt from DAI validation checks, allowing all ARP traffic. Untrusted ports undergo DAI validation checks, where the switch scrutinizes ARP requests and responses received on those ports.

Figure 7-13 Potential MITM Attack the Meraki DAI Feature Is Designed to Prevent

To enable DAI in your network, you must define trusted and untrusted ports and enable ARP inspection. Designate ports as trusted if they are connected to trunks, are linked to access points (APs), or have static IP addresses. By default, all other ports are considered untrusted and will be treated as DHCP client ports. To enable DAI, navigate to the Switching > DHCP Servers & ARP section in your network settings and change the DAI Status field to Enabled to activate DAI functionality.

For more information on Dynamic ARP Inspection, visit https://documentation.meraki.com and view the article “Dynamic ARP Inspection.”

SecurePort

Meraki MS SecurePort is a feature that provides secure provisioning of switch ports that have Meraki MR access points connected. As depicted in Figure 7-14, SecurePort automates configuring the switch port, establishing a secure connection, and allowing the access point to download its configuration from the Meraki cloud. By enabling SecurePort, the switch port is configured as a trunk port, with the native VLAN set to the management VLAN of the switch. This ensures the access point can connect securely and obtain a security certificate from the Meraki cloud. The access point is also authenticated via an onboard digital certificate before it is permitted to connect.

Figure 7-14 SecurePort Authentication States

SecurePort offers several advantages:

• It saves time by eliminating the need for manual per-port configuration on the switch.

• It enhances security by preventing the switch port from being used as a back door to access the network. For example, if someone removes an access point to plug in a laptop, the switch port will revert to its previous secure configuration, preventing unauthorized access.

• It ensures that only access points that belong to the organization can connect, as any certificate mismatch will prevent unauthorized access.

For more information on SecurePort features, go to https://documentation.meraki.com and view the article “SecurePort.”

DHCP Snooping – Cisco Meraki Switching Design and Recommendations

The DHCP snooping feature available with MS switches is a network-wide setting that provides enhanced security for all switches or switch stacks within the network. It offers several features to protect against unauthorized or malicious DHCP servers. DHCP snooping will detect and block and/or alert when a new DHCP server is detected on the network. This helps prevent rogue DHCP servers from distributing IP addresses and potentially causing network disruptions. This feature can drop replies from unauthorized or malicious DHCP servers. This ensures that only authorized DHCP servers can provide IP configuration information to network devices. Unauthorized DHCP servers’ responses are dropped and ignored, preventing potential security risks. DHCP snooping can also generate email alerts to notify network administrators when a rogue DHCP server is detected. This immediate notification allows prompt action to investigate and mitigate the threat.

The default configuration of MS switches allows all DHCP servers on the network, for easy installation in existing environments. To configure DHCP snooping to ensure that only trusted DHCP servers provide IP configuration to network devices, navigate to the Meraki Dashboard and go to Switching > Routing and DHCP > DHCP Servers & ARP. From this page, shown in Figure 7-11, you can set the Default DHCP Server Policy option to Block DHCP Servers and explicitly whitelist authorized DHCP servers in the Allowed DHCP Servers list or the Allowed DHCP Servers box.

Figure 7-11 Whitelisting Authorized DHCP Servers

Storm Control

Storm Control on Meraki switches is a feature that helps prevent network downtime caused by abnormal events such as misconfigured or misbehaving network devices or end clients. As shown in Figure 7-12, Storm Control detects and manages three types of storms: broadcast, multicast, and unknown unicast. By setting thresholds for each traffic type, you can customize the behavior of the switch. The system will drop any traffic that exceeds the set threshold. This prevents the excessive traffic from impacting network performance.

Figure 7-12 Setting Storm Control Thresholds for Different Traffic Types

Multicast Best Practices – Cisco Meraki Switching Design and Recommendations

Configuring multicast routing on Meraki MS switches involves using the Protocol Independent Multicast Sparse Mode (PIM-SM) for efficient and scalable distribution of multicast traffic. IGMP snooping, which is enabled by default, can be enhanced with features like IGMP Querier for robust multicast infrastructure. However, if there are no Layer 2 multicast requirements, IGMP snooping should be disabled, as it is CPU dependent.

Pro Tip

For internal applications, it’s recommended to use the 239.0.0.0/8 multicast address space.

Multicast traffic flow can be regulated through access control mechanisms such as IGMP filtering or access control lists (ACLs). It’s also important to plan for a Rendezvous Point and consider blocking SSDP traffic when PIM routing is configured to prevent additional load. You can do so by blocking UDP traffic to destination 239.255.255.250/32 in the Switch> ACL page in the Dashboard.

In a multicast environment, it is common to set Storm Control to 1 percent to drop excessive packets if the limit is exceeded, but your environment may vary depending on what types of multicast applications you have deployed. These considerations ensure an optimized and efficient multicast configuration on Meraki MS switches.

Securing Layer 2 Operations

Securing Layer 2 operations involves implementing various security measures to protect the infrastructure, network access, and endpoints. Here are some key considerations for each aspect, which are described in more detail in the following subsections:

• Infrastructure security: Implement physical security measures to protect network devices.

• Network access security: Implement robust authentication mechanisms, such as IEEE 802.1X, to control access to the network.

• Endpoint security: Implement dynamic endpoint posture-based protection for wired and wireless networks.

• Micro-segmentation (adaptive policy): Explore how the future of network security is developing and changing traditional approaches.

Infrastructure Security

A well-designed and secure infrastructure is essential to a well-functioning network. Meraki offers some (often overlooked) security-related options to help protect the integrity of your infrastructure and the traffic passing through it. This section introduces several security features that can you enable to help ensure the secure operation of your network and reduce the chance of malicious actions impacting the network or its clients.