If you didn’t notice, Meraki’s MR26.X firmware was recently promoted to Generally Available status for new platforms. That means it is now the default firmware build for MR20/70/42E/53E/45/55 networks and has passed the performance, quality, and scale thresholds required for mass adoption.
Besides the usual under the hood optimizations, MR26 introduces three specific enhancements – native Cisco Umbrella integration, alternate management interface, and a new mandatory client DHCP option.
This is notable not just for the new capabilities it delivers, but also the impact it has given the size and scale Cisco Meraki is operating at. Any firmware revisions pushed from the cloud have instant impact globally, so the quality metric tolerances are brutally tight.
Cisco Meraki’s cloud controller is insane. For perspective, it controls more than 4 million enterprise AP’s today – with over 1.5 million AP’s shipped last year alone.
Crazy. Which is why it’s important to share the mainline features shipping with this latest release.
Let’s take a closer look.
Cisco Umbrella integration on Meraki wireless networks
This capability has been a longtime beta option, but Cisco Umbrella (formerly OpenDNS) content filtering, policies, and reporting is now broadly available to the Meraki masses. There is an entire KB on the topic, so please give that a read if you want all the Umbrella MR details, but here’s a quick preview.
Organizations using Meraki wireless running MR26 can enforce their APs to route DNS traffic filtered through Cisco’s Umbrella DNS service. Meraki wireless networks have the flexibility to apply the Umbrella policies per SSID or via Group Policies.
The fist step is to create content policies in the Cisco Umbrella dashboard. Here’s an example.
Next the Meraki and Umbrella dashboards must be linked via the Umbrella Network Devices API Key. From the Umbrella dashboard, generate a new API key under Admin > API Keys.
The Umbrella Network Devices API Key can then be added to the Meraki dashboard under the Cisco Umbrella account section on the Network-wide > Configure > General page.
Once linked, the DNS layer policies can be applied per-SSID on the Wireless > Configure > Firewall & traffic shaping page, under the Block Applications and Content Categories section. The Umbrella policies will be automatically populated in the dropdown selection.
If you’d prefer a more flexible approach, you can add an Umbrella policies to one or more Meraki Group Policies. This enables Umbrella to Active Directory mapping or client-specific enforcement (from the Network-wide > Monitor > Clients page).
To link an Umbrella policy to a Meraki Group Policy simply navigate to the Network-wide > Configure > Group policies page, Layer 7 firewall rules, Link Umbrella policies.
There you have it – Cisco cloud managed wireless now with Cisco cloud DNS protection. All done using an integrated, intuitive UI and API framework. An awesome addition to the MR family.
As of the time of this writing customers still need to request the Umbrella
integration be unlocked by sending a quick note to Meraki Support. This will no-doubt change, but quick PSA in the meantime.
Meraki Alternate Mangement Interface for wireless networks
This one has largely flown under the radar and is potentially very valuable for certain high-security deployments where cloud services and traditional management traffic are segregated.
Before we get into the details, let’s start with a quick explanation of how legacy network management protocols like SNMP, syslog, and RADIUS interactions are sourced on Meraki wireless networks.
By default, management traffic for SNMP, syslog, and RADIUS are all sent from the Meraki AP’s management IP address – the same IP it uses for secure Meraki cloud communication. For most environments this is completely appropriate as it consolidates the management traffic to a single interface.
This single management interface model becomes challenging in environments that require segmentation for cloud interactions and those of local management tools. Decoupling those two historically wasn’t an easy option.
Now it is. To enable, navigate to Network-wide > General.
With the Meraki alternate management interface option enabled, Meraki access points will obtain a second, dedicated IP address for SNMP, syslog, and RADIUS communication. This second management interface is assigned to a VLAN separate than that of the primary uplink to provide differentiated source addressing.
Once enabled at the network level, the alternate management interface IP can be configured from the left side menu of the access point’s details page.
If you need to source legacy management protocol traffic from a separate internal network than that used by the default cloud management IP, you now have that option.
Also, this is really new. So new that it still requires Meraki Support to enable. Send them a note or call if you’re interested. Here’s a link to the full KB.
Mandatory wireless DHCP option
The last new MR26.X firmware feature that I wanted to call out is mandatory wireless client DHCP which can be configured on the Wireless > Access control page.
When selected on a particular SSID, this handy new feature requires wireless clients use an IP address assigned by a DHCP server. If a client is using a static IP address, it will not associate.
This has obvious security benefits in environments where statically assigned addressing would indicate a bad actor or simply prevent service disruption for DHCP clients when conflicting static addressing is inadvertently introduced.
That’s a wrap.
Begin testing/piloting/rolling MR26 in your wireless networks if you haven’t already. It delivers quality and stability improvements in addition to the interesting new capabilities outlined above. Good for wireless operators and clients alike.