The “Make a Wish” feature has proved to be a popular outlet for Cisco Meraki users, allowing anyone with a dashboard account to submit ideas for product improvements. Users are able to type in their response to the prompt “I wish this page would…,” giving Meraki developers insight into what changes could add value to the end customer experience.
We have always taken customer feedback very seriously, and recently made enhancements to the wish box to allow for more detailed submissions. Follow along as we make a wish to see what’s new.
1. The “Make a wish” box is located at the bottom of every page in dashboard.
2. When you start typing, a prompt box appears with plenty of space for a thorough explanation of your wish. Based on the words you enter, suggestions for relevant Knowledge Base articles will pop up. Check out the proposed link, perhaps your wish has already been granted!
You can choose either to submit your wish as is, or, you can now also pinpoint areas of the current page that relate to your entry with the “Highlight Page” tool.
After reviewing your text, continue on to the new highlight/black-out functionality.
With this new feature, you can black-out information that you deem sensitive and highlight sections that relate to your feature request. Here, we have blocked out certain client names, and highlighted the current client traffic.
After clicking “Review,” a summary of your wish appears so you can ensure that it accurately reflects your true intention. After making any last-minute edits, the time has come to send in the wish.
Yes! Now what?
Incoming customer wishes are automatically emailed to every engineer on our development team and also put on display in our engineering area, ensuring that we are always thinking about our customers’ requests as we move forward.
The motivation behind wishing enhancement, straight from one of our product managers:
“The impetus for the improvement came from a need to more quickly and completely understand customer needs. We’re getting thousands of wishes per month now, and engineers wanted to make sure that we could differentiate wish specifics and truly understand what customers were asking for. Otherwise we risked too quickly identifying patterns among similar but fundamentally different wishes.
The new Make a Wish allows us to see much more clearly what customers are thinking with each wish – so as more and more enterprises realize the power that Meraki can bring to their networks and wish for more and more features, we can continue to deliver our signature development responsiveness and exceptional customer experience.” –Billy Waldman, Product Management
Try it out for yourself! Get your dreams out of the clouds and onto our radar (and then, perhaps, back into the Cloud).
Located just off Queen’s Lane in central Oxford, St. Edmund Hall is one of the 38 colleges which comprise the University of Oxford in the United Kingdom. But don’t be fooled by the last medieval hall at the University; Andrew Breakspear, IT Officer at St. Edmund Hall, works diligently to seamlessly integrate the college’s historic feel with modern day technology requirements.
An aging wireless infrastructure, coupled with the need for more advanced features, led Breakspear to begin evaluating new network solutions. One Cisco Meraki webinar and a free access point later, Breakspear was sitting in his office prepared to hunker down and spend some time testing and learning how to configure the Meraki AP. What he wasn’t expecting was to have the AP up and running, fully configured in 20 minutes; however, that’s just what happened. Once St. Edmund Hall decided to go with Meraki, getting the other APs running on the network simply consisted of mounting them on walls.
Find out more by watching the short video below. Hear directly from Breakspear on how the college uses integrated features like LDAP and Active Directory for easy authentication, Facebook Login and a segmented network for streamlined guest access, and the Meraki Mobile App for managing and troubleshooting devices remotely.
Apple’s iOS 8 changes the way MAC addresses are exposed in WiFi probe requests, providing an additional layer of privacy for consumers. This post described the impact of those changes to the Cisco Meraki Connected Mobile Experiences (CMX) solution.
CMX and Privacy
CMX analytics helps organizations understand aggregate location data in business analysis and provides customers with high performing WiFi, allowing for personalized experiences. The Cisco Meraki team has always been dedicated to privacy for customers and their end-users, and there are four aspects of privacy that are technologically part of the CMX solution:
Anonymous aggregate information: All analytics in the Meraki dashboard are based on aggregate, anonymized device and location data.
Permission-based: Users have to opt in to join a WiFi network or download an app.
MAC address hashing: a one-way hash function anonymizes MAC addresses of unassociated, probing WiFi devices before storage in the Meraki cloud
Opt Out: End-users can opt-out of location-based services and analytics
Randomization Effects on Analytics
For mobile devices associated to a WiFi network, the CMX value proposition is unchanged, and the CMX solution will continue to deliver:
CMX Connect providing seamless connectivity to WiFi
For unassociated devices, the value proposition of CMX analytics has always been focused on providing broad aggregate trends and customers insights as opposed to individual user location or absolute numbers. Even with MAC randomizing for iOS 8 devices, there is no broad impact on aggregate analysis based on trends and percentages when evaluated over a period of time (MoM, YoY, DoD). Based on our current understanding, a subset of aggregate analytics—particularly loyalty metrics and dwell times for unassociated devices—may be impacted. However, organizations will still be able to leverage CMX analytics to gain better customer insights and business decisions based on users who opt-in and join their Wi-Fi network.
Thanx helps brick-and-mortar retailers and restaurants identify, engage, and reward their best customers without the hassle of integration or new hardware to install. The mobile-based technology allows consumers to earn rewards for their loyalty at merchants across the US by shopping as usual with any registered credit or debit card. Notifications come in real-time right after making any qualifying purchase. For merchants, it’s the web-based consumer insights and data-driven marketing tools that get them really excited about Thanx.
After missing the cut-off for last year’s round of Startup Kits, the Meraki team was glad to see Thanx apply and took the opportunity to hand deliver the kit to their office.
Excited to get started with Meraki cloud management.
In May, Thanx moved into their first office after growing out of their original space in the SOMA neighborhood of San Francisco, where they shared office space with another technology company that provided Internet access. As the sole occupants of the new space, having a reliable and robust network solution was a must.
“Our Meraki equipment arrived just in time for our move into our first office,” said Thanx CEO, Zach Goldstein. “We were able to set up the whole office out of the box and without an IT person on staff. Our engineering and sales teams were up and running on day one – committing code and making VoIP sales calls without missing a beat. We love our Meraki gear.”
Setting into the new Thanx offices.
The reliability of the Cisco Meraki network allows Thanx employees to work happily, whether at their desks or in common areas. Not only are work stations and tablets connected to the network, but a laptop connected to a projector displays real-time product stats on a 16-foot wall, providing the team with the most up-to-date information and customer engagement (and music and World Cup games from time-to-time).
The team using the wireless to work on their laptops while watching the World Cup.
The day to day operations in the office have changed tremendously with the addition of a reliable network. Thanx Operations Manager Susan Zolezzi noted that without the Cisco Meraki gear, this wouldn’t have been possible:
“This is the first place I’ve worked where everything is wireless and I’m amazed how seamless it is. Every one of our devices are connected through our Meraki gear – our laptops, tablets, phones, printer, everything! And I have yet to have a connection issue. Thanks for the awesome set up Meraki!”
Thanx employees are all smiles with the Cisco Meraki network in the office.
Keep checking in or subscribe to our blog for more Startup Kit spotlights.
Datacenters (DCs) are used the world over by companies looking to reap the benefits—cost, management, and computing—made possible by centralizing IT resources. If you’re an organization with multiple branch sites connected to datacenters, ensuring these branches can still access resources if a datacenter goes offline is crucial.
We’re thrilled to announce that new functionality in our Cisco Meraki MX security appliances will enable immediate, automatic failover for branches tunneled to datacenters via VPN. The MX supports DC-to-DC VPN failover for both mesh and hub-and-spoke topologies.
When configuring a Meraki MX for hub-and-spoke datacenter failover, typically the network resembles the image below: a select number of branch sites (“spokes”) are tunneled back to an individual datacenter (the “hub”). Other branch sites may be tunneled to a separate datacenter (e.g. datacenter 2). Both DC1 and DC2 are configured as failover datacenters for the other’s respective branches.
A key aspect of this topology is that branch sites cannot communicate directly with each other; all traffic routes through the designated hub first. So, for Branch A to speak to Branch B in the diagram below, traffic routes from Branch A → DC1 → Branch B. For Branch A to speak to Branch E, traffic routes from Branch A → DC1 → DC2 → Branch E.
Hub-and-spoke DC failover using the Meraki MX. MXs deployed in Branches A-C tunnel to DC1. In the event of DC1 becomes unreachable, these branches will immediately fail over to DC2.
MXs deployed in hub-and-spoke DC-to-DC failover can be configured either as VPN concentrators (shown above) or in NAT mode, typically selected if an MX is to be the default gateway. The number of supported branch sites and datacenters is scalable up to the maximum number of VPN peers allowed by the MX model deployed in the hub (check our MX sizing guide for specifics).
Some common hub-and-spoke datacenter failover scenarios (assume the priority order for Branches A-C is DC1, followed by DC2; the concentrator priority for Branches D-F is DC2, followed by DC1):
If DC1 goes down completely: all connected branches (Branches A-C) will fail over to DC2
If Branch A cannot reach DC1 but Branch B can: Branch A will fail over to DC2 while Branch B will continue to send traffic to DC1
If DC1 is online, and Branch A wishes to access resources in DC2 (on a subnet not shared between DC1 and DC2): this is possible; the traffic path will be Branch A → DC2
If DC1 is online, and Branch A wishes to access resources in DC2 (on a subnet shared between DC1 and DC2): this is not possible; because Branch A has selected DC1 as its priority, all shared subnets will only be accessible via DC1
If DC1 is unavailable, and Branch A wishes to access resources in DC2 (on a subnet shared between DC1 and DC2): this is possible, since Branch A will automatically fail over to DC
If Branch A wishes to communicate with Branch E (both DCs are online): this is possible; the traffic path will be Branch A → DC1 → DC2 → Branch E
Hub priorities can be set individually for each branch network. To configure this, navigate to Configure > Site-to-Site VPN in the Meraki dashboard. Enable VPN, select a hub-and-spoke topology, and then create a list of priority hubs:
Configuring concentrator priorities in hub-and-spoke failover mode.
When configuring a Meraki MX for mesh DC-to-DC failover, typically the network resembles the image below: branch sites have redundant communication pathways between them. So, for Branch A to speak to Branch B in the diagram below, traffic routes directly from Branch A → Branch B.
Mesh DC failover using the Meraki MX. MXs deployed in Branches A-D all tunnel to DC1. In the event DC1 becomes unreachable, all branches will immediately fail over to DC2.
MXs deployed in mesh DC-to-DC failover have some limitations when compared to a hub-and-spoke model. Specifically, datacenter MXs must be configured in VPN concentrator mode, and all branch sites share the same organization-wide concentrator priority list—so by default, all meshed branches will tunnel through the same datacenter, only rerouting to a secondary in the event of failover.
As with the hub-and-spoke failover model, MXs deployed in mesh failover can scale to as many locations as however many VPN peers are supported by the MX model deployed.
Here’s how mesh DC-to-DC failover works (assume DC1 is configured as the priority):
If there’s a shared subnet between online datacenters: DC1 will receive all traffic destined for the shared subnet, since it is the designated primary
If DC1 goes down completely: all connected branches will reroute to DC2 for the duration of DC1’s outage
If Branch A cannot reach DC1 but Branch B can: Branch A will send traffic destined for any shared subnets to DC2 while Branch B will continue to send traffic to DC1. Traffic between Branch A and Branch B is unaffected
If Branch A wishes to access a subnet shared between DC1 and DC2 while both are online: Branch A can only access the shared subnet via DC1 (as determined by the concentrator priority list)
To configure mesh DC-to-DC failover, navigate in the Meraki dashboard to Configure > Site-to-site VPN. As with configuring the hub-and-spoke DC failover, you must first enable VPN and then select to deploy a mesh topology. Organization-wide concentrator priorities can be configured further down on the same page.
Mesh DC failover relies on Organization-wide concentrator priorities to determine the order in which nodes tunnel to particular hubs.
If your organization relies on datacenters for critical data storage, computing, or management, having high availability between these hubs in the event of failure or catastrophe is necessary for risk planning. The Meraki MX now offers DC-to-DC VPN failover in two topologies to ensure smooth access to datacenter resources and avoid costly downtime and disruption—allowing IT admins to sleep easier at night.
As part of our Cisco Meraki MX summer feature release we are thrilled to announce warm spare redundancy for MXs deployed in NAT mode, one of two modes a Meraki security appliance can be configured in (the other being VPN concentrator mode). Warm spare redundancy had previously been limited to MXs deployed as VPN concentrators, so this enhancement allows for failover regardless of MX configuration.
Warm spare redundancy is a technique to ensure service availability in the event of hardware failure. An MX deployed in NAT mode, for example, is typically configured as the network’s default gateway, and may be providing critical services beyond next-generation firewalling such as DHCP, best-in-class intrusion prevention, content filtering, and more. In the rare chance such an MX were to go offline, those services can now be seamlessly transferred to a backup MX.
MX warm spare redundancy can be easily configured by selecting an MX Security Appliance in the Meraki dashboard, and then navigating to Configure > Addressing & VLANs. Under the “Warm spare” section, click to add a warm spare MX.
Adding a warm spare MX for redundancy in the Meraki dashboard.
You will then be prompted to type the serial number (or order number, if you prefer) of the backup MX. That’s it—the redundancy is configured automatically behind the scenes! Since the MX uses the Virtual Router Redundancy Protocol (VRRP) to facilitate high availability, the backup MX can seamlessly take over for a failed primary without causing addressing confusion for other networked devices on the LAN.
Deploy a backup MX as a warm spare by specifying its serial or order number.
Once warm spare redundancy has been configured, you can view the status of the HA pair from the MX’s appliance status page (Monitor > Appliance status). This page will indicate which MX is deployed as the primary, whether the backup MX is online and monitoring the availability of the primary, and whether the backup MX is correctly deployed as a warm spare.
Viewing MX warm spare status in the Meraki dashboard.
The ability to configure and MX for warm spare failover in NAT mode will be pushed out to current Meraki MX customers this summer as part of our MX feature release. We expect general availability in August, so stay tuned!
Imagine a Cisco Meraki network deployed for a US-based business with operations nationwide. There are no overseas offices or data centers. IT has legitimate reasons to interact with India for various outsourced services. The business’s clients are domestic. And yet, chunks of its network bandwidth appear dedicated to traffic with Belarus (to randomly pick on one country).
Assuming there is no legitimate need for your business to have dealings with with Belarus, it’s safe to assume that this traffic is, at best, unofficial, and at worst, malicious. Now, let’s assume that this traffic involves any of the 50+ publicly registered IP ranges for Belarus.
Previously, to block a single country from interacting with a Meraki network, it would’ve been necessary to type every individual country IP address range into separate firewall ACLs. This is no small feat: for example, China has thousands of individual IP ranges allotted to it.
So, we’re thrilled to announce that, with the MX’s new, geography-based IP firewall rules, preventing traffic to or from any individual country is as simple as selecting that country from a drop-down menu in the Meraki dashboard.
How to configure geo-based firewall rules
To enable filtering based on geographic locale, simply navigate to Configure > Firewall in the Meraki dashboard. We’ve updated our familiar Layer 7 firewall rule definition tool to include a country drop-down menu. You have two options when creating a geo-based IP rule: either define the countries you wish to block access to (selectively block), or define the countries you wish to permit access to (selectively allow). For example, you could selectively allow Germany—and only Germany—if you wish to ensure no packets leave German borders. Or, in keeping with our earlier example, you may wish to create a rule to selectively allow both Indian and US traffic—and nothing else.
You can now selectively block or permit traffic between your network and various countries using the MX’s Geo-based IP firewall rules.
Behind the scenes, the MX filters by public IP address blocks assigned to each country, making it easy to enforce geo-based security. These IP ranges are updated monthly, ensuring efficacy.
In addition to being able to restrict or allow traffic based on geography, the MX now provides geographic visibility into traffic flows. Simply navigate to Monitor > Traffic analysis to view where in the world traffic to (or from) your network is arriving from (or destined).
Viewing MX traffic analysis will now show the geography of traffic flow destination.
In sum, geo-based IP firewall rules and border visibility give network admins critical control beyond protocol and application. Many critical security threats today rely on the ability to “phone home” or communicate with servers well beyond the borders—and easy legal reach—of your home country. Protecting your LAN from unsolicited, global traffic may mean the difference between servicing clients and enduring downtime and disruption while rebuilding hacked systems.
Geo-based IP firewall rules are included in our upcoming MX summer update, and will be automatically rolled out to existing Advanced Security customers. For more information about our MX security appliances, check out our website or give us a call!
Today, we’re excited to announce a slew of new features for Cisco Meraki MX Security Appliances that offer more robust failover, enhanced security, and improved flexibility.
New MX functionality includes:
Datacenter (DC-to-DC) failover
Warm spare failover
Geo-based IP firewall rules
These features will be rolled out to our existing MX customers as part of our summer firmware update. We’ll deliver blog posts diving into each feature in the coming days, so stay tuned!
Avoid downtime, disruption
If you’re managing multiple branch sites that tunnel back to datacenters, the Meraki MX’s new datacenter failover support is a mission critical enhancement. Using AutoVPN, you can already tunnel branch connections securely through MXs deployed elsewhere, either in a hub-and-spoke or mesh topology. Now, you can specify concentrator priority for multiple sites, enabling predefined failover to specific locations should a site go offline.
For example, each branch site (“spoke”) in a hub-and-spoke VPN can select which datacenter (“hub”) it wishes to tunnel to by default for shared subnet resources. It can also specify which other hubs to establish secure tunnels with in the event the primary hub becomes unreachable—and this failover will be automatic. The hubs themselves can then be deployed in a mesh topology, ensuring layers of redundancy for branches and datacenters, an exciting enhancement for customers who can’t afford disruption due to datacenter outages.
Meraki MXs now support hub-and-spoke (pictured) and mesh datacenter failover.
We’re also thrilled to announce warm spare failover functionality for MXs running in NAT mode—one of two deployment modes an MX can be configured in (the other being VPN concentrator mode). This feature ensures the integrity of MX service at the appliance level regardless of configuration. In the event an MX goes offline, a secondary MX will automatically take over its duties—ensuring a site is not deprived of functionality like industry-leading intrusion prevention, VPN, application and client control, DHCP service, and more.
Configuring MX warm spare in the Meraki dashboard.
Improved addressing flexibility
To host services—such as web and email—across the Internet, organizations require public IP addresses. As the demand for public IP addresses has grown, the cost of acquiring one has increased (there is a finite supply). Meraki MX security appliances already support 1:1 Network Address Translation (NAT), which allows direct one-to-one mapping of any public IP addresses with internal IPs, as well as port forwarding, the ability to map several services (e.g., web, email) to internal servers through the MX’s public IP address.
With new 1:Many NAT functionality, we’ve combined these features so that mapping between any public IP can be made to multiple different internal IPs and ports.
In short, the MX now provides enormous addressing flexibility for organizations relying on external, routable IP address management for hosting services.
Map any public IP to internal addresses and ports with 1:Many NAT support in the Meraki MX.
Secure your borders
Meraki MX security appliances already provide superior branch protection through integrated Sourcefire intrusion prevention, cloud-based content filtering, and stateful firewalling. Now, you can restrict traffic in your network based on the physical geography of packet origin or destination. This means if you are a US-based business with no legitimate reason to share traffic with, say, Albania, you could prevent all packets originating from that country into your network. Conversely, if you wish to keep network interactions solely within US borders, you can limit traffic to US-based Internet segments. Additionally, it’s now possible to view the geographic location of specific traffic flows in the Monitor > Traffic analytics page.
View geographic origin and destination of traffic flows in the Meraki dashboard.
For More Information
Stay tuned for additional blog posts on these exciting new features, and check out our website for more details about specific MX models for your environment.
Finally, as always, we’re listening to your feedback, so please let us know what you think on our social media feeds or through our dashboard’s “make a wish” feature — and offer any ideas you may have.
The Cisco Meraki team spent last week in Atlanta, Georgia at ISTE 2014, an education-focused conference where attendees are encouraged to collaborate, discover, and share ideas on integrating technology in the learning space. This year, we had twelve different demo stations and had a great time talking with the hundreds of people who came by our booth to chat and check out the solution.
We also completed Mission: Impossible – One Hour WiFi. A live session on setting up an enterprise grade wireless network in under an hour, and then even had attendees authenticate to it.
Having all of our gear on display, from wireless APs to switches to security appliances, let us make the connection between our intuitive cloud-based management dashboard and the devices being controlled from the web browser. In the case of Systems Manager, our free cloud-managed MDM, we demoed features on the mobile devices we were using at the booth, talk about real-life application!
A happy Cisco Meraki customer!
To learn more about why Cisco Meraki is an ideal solution for education, check out tomorrow’s webinar, co-hosted by Dirk DeLo, CTO at Avenues: The World School, an international school with a growth plan for 20+ branches around the world.
We’ve been deep-diving into the slew of new features being released this summer for Cisco Meraki MS switches. Most of these enhancements expand functionality specifically for our Layer 3 models, but one feature that is available across both Layer 2 and Layer 3 families is our new IPv6 visibility.
Why care about IPv6?
To reach resources across the internet (and internally on local networks) devices need IP addresses. The most common implementation of addressing is a standard known as IPv4, which uses a unique, 32-bit number for every internet-accessible device. The problem is that, with only 32 bits of addressing space, IPv4 can’t support more than 4.3 billion devices—a huge number, but insufficient for the myriad mobile gadgets, laptops, smart appliances, etc. that need internet connectivity.
Enter IPv6, a standard using 128-bit addresses. IPv6 allows for 2128 unique device addresses, which some have calculated is enough to
“assign an IPv6 address to every atom on the surface of the earth, and still have enough addresses left to do another 100+ Earths. It isn’t remotely likely that we’ll run out of IPV6 addresses at any time in the future.”
So, IPv6 provides a substantial buffer for years to come, which is why the world is slowly transitioning to using it as the default internet addressing scheme.
IPv6 in Meraki MS switches
Meraki MS switches could always pass IPv6 traffic, but now customers can view IPv6 clients and monitor their application usage in dashboard. Simply navigate to either Monitor > clients to see a network-wide view including IPv6 clients, or drill down into an individual client itself:
Network-wide visibility into IPv6 clients and application usage.
Drilling down into individual IPv6 clients provides more granular detail about traffic flows.
As IPv6 becomes de rigueur, we’ll be adding more functionality around it. Since IPv6 visibility is a feature in our upcoming summer switch update, it will be pushed out automatically to customers. Please send us your thoughts and check out our Meraki MS page for more details on switches and MS features.