Simpler. Faster. Smarter.
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.
A new set of MX uplink bandwidth control endpoints were recently added to the Dashboard API. You can now provision the maximum bandwidth values programmatically on a per-uplink basis (WAN1/WAN2/cellular) for any appliance.
Interested in active/active Meraki MX data center headend design? The purpose of this writeup will be to show you just that – how you can build a highly-scalable, multi-box MX VPN headend architecture capable of supporting the most demanding SD-WAN scale and performance scenarios.
This model is one that’s been repeated many times over and is the preferred headend scaling approach for maximizing both performance and redundancy. The reality is it’s a very simple approach while remaining flexible enough to be tailored to a variety of organizational and geographic requirements.
Too many updates to share, but since many of you asked about the absence in changelog announcements, I thought I’d check in and share a few lesser-known additions that dropped recently.
So here’s the deal; I’ll make this brief. You all are a very smart bunch. Our Cisco Meraki enterprise team hires smart people. And we now have openings in three markets.
NorCal, Atlanta, and NYC.
I made a change. A career change. The kind of big career change every technical professional considers at some point in their career.
Management.
I’ve got several large work projects in flight which has put a temporary damper on my longform technical writing time. The good news is that one of those projects is pretty interesting (long-haul mesh wireless between two Casinos) and would make for a useful tutorial on design, configuration, and wireless mesh best practices. More to come on that.
For now we’re going to keep this one short. Starting with a few hidden gems.
The SM team recently added the ability to control whether or not cellular data is allowed for iOS managed apps.
Firewall and WAN refresh projects have many components, but one of the first steps after vendor selection is hardware sizing. Even when working on POC/POV projects, rightsizing the hardware upfront provides a truer day-two experience and requires less rework once complete.
My goal is to walk you through a consultative sizing process to properly size Meraki MX appliance models for any deployment. The process outlined below applies equally to small, multisite MX deployments as it does to super-scale 10,000+ site deployments. I’ve been involved in the planning, pilot, and deployment phases of dozens of such projects and wanted to share my method.
The Cisco Meraki Dashboard contains several logging subsystems that each have unique data retention and export options available. Datasets like event, configuration, and analytics are used for starkly different purposes (business intelligence, operations, risk management, etc.) and are reflected in the native logging capabilities.
Questions are often asked around how long Meraki stores logs or other metrics, which as you’ll discover shortly, can have many different answers depending on the dataset in question. The same applies for export, syslog, and other local offload options available. Different datasets, different options.
