BACK

We are very excited to introduce two new wireless access points, the Cisco Meraki MR32 and MR72. They are dual–band, 2×2 802.11ac APs and include integrated Beacon (Bluetooth Low Energy) technology. Beacons enhance location capabilities and enable more active customer engagement, such as with iBeacons, and with the MR32 and MR72 there’s no need to deploy dedicated iBeacon hardware. The new APs also include the rich, cloud-managed feature set common to the entire Meraki wireless portfolio and feature the dedicated security radio technology found in other Meraki APs.

New Meraki MR32 and MR72

The new Meraki MR32 and MR72 APs

WiFi, Security, and Bluetooth Together

The new APs feature three integrated WiFi radios. The APs include one radio each for:

  • 2.4 GHz, for 802.11b/g/n clients
  • 5 GHz, for 802.11ac and 802.11a/n clients
  • dedicated security and automated RF optimization (see this post for more on the benefits of this radio)

They also include new Beacon (Bluetooth Low Energy, or BLE) technology via an integrated Bluetooth radio, for applications such as iBeacon and other location services. There’s no need to place the AP into a dedicated Bluetooth mode —all four radios (WiFi and Bluetooth) operate simultaneously.

Integrated Beacons

New Beacon technology, based on BLE, enables applications that more actively engage your on–site visitors and customers. Beacons broadcast periodic advertisements over Bluetooth. Visitors’ devices hear the advertisements and trigger opt–in location services, such as a push notification on a smartphone or indoor navigation assistance. iBeacons, Apple’s opt–in form of BLE, enable such services and are integrated into the MR32 and MR72. Beacon–enabled services add to the rich location capabilities already available on the Meraki APs through CMX (Connected Mobile Experience).

 

New outdoor goodies

The MR72 looks very similar to the MR32, but its sleek looks hide rigorous environmental credentials. It’s designed to withstand extreme temperature ranges, from -40°F to 140°F (-40°C to 60°C) and earned an IP67 rating due to its high degree of resistance to dust and water. Along with the new MR72, we’re introducing four new exterior antennas:

  • omni–directional, dual–band (pair)—provides broad coverage for general purpose applications
  • Sector antenna, 2.4 GHz—provides narrow–width coverage or point–to–point mesh connectivity between wireless APs
  • Sector antenna, 5 GHz—provides narrow–width coverage or point–to–point mesh connectivity between wireless APs
  • Dual-band patch antenna (2.4 and 5 GHz)—provides directional coverage for general purpose applications
New Meraki sector antenna

New Meraki sector antenna

We’ll have more information about the new antennas in a blog post next week.

Learn More

The MR32 is available now and the MR72 (and new antennas) will be available in January 2015. You can learn more about these new APs and the integrated Beacon technology during a special webinar next week. You can also check the wireless product page to compare specs of the Meraki APs to see which might be the right fit for your environment. We can’t wait for you to try one out.

BACK

For those of you who have been checking out our awesome, new network topology feature, we’re excited to announce additional functionality: tracing client devices in the Cisco Meraki dashboard’s topology view. This lets you see exactly what Meraki equipment a device is connected through—all the way out to the perimeter of your network. When troubleshooting client connectivity in complex deployments, the topology feature can save time by quickly showing whether networked devices between the client and the Internet are alerting or down.

Tracing clients in the Meraki topology map is easy: from within the dashboard, you can drill down into a client’s details page and click on the “topology” link:

This will bring up the network topology view, with Meraki devices highlighted by green icons. Below, you can see that the Windows client device in our example is connected to an access point that physically links back through four switches before hitting our MX security appliance, Godzilla:

If device labeling is checked, it’s easy to confirm that the AP highlighted in the topology view is the same as that identified in the client’s details page.

Another way to trace a client device is to simply search for its MAC address from the dashboard’s topology page. In the example above, the client’s MAC address is being filtered in the topology search box—resulting in a single online device matching the criteria. You can also search by partial MAC addresses:

In the image above, searching on a partial MAC address revealed three online devices matching that search criteria.

So, in seconds, it’s possible to view the networked Meraki devices a client connects through—and easily verify the health and status of those devices. Depending on the complexity and size of a network deployment, this can save significant troubleshooting time.

For more information about our network topology feature, please check out our blog post.

Related Posts

BACK

If you missed our special switch webinar, The World Is Not Enough…(Without 1-Hour Switching), fear not! We’ve uploaded a recording so you can watch how we added switches to a remote site, optimized them for VoIP, locked down the wired network, and configured features like warm spare failover—all through our web-based dashboard.

Check out the video here:

To register for upcoming Meraki webinars, check out our webinar page. Also, we have several videos of live demos and recorded webinars hosted on our YouTube channel. Learn more about what our Meraki MS switches can do for you here—or by visiting our switch product page.

 

Related Posts

BACK

We’re excited to announce a new feature that just went live for all of our Cisco Meraki MX Security Appliance customers: customizable third-party VPN policies. This means that an MX can be integrated into a greater number of VPN networks without needing to modify the settings of non-Meraki VPN peers.

You can now tweak the following security parameters on your MX for an IPsec connection to a non-Meraki peer:

  • Phase 1:
    • Encryption
    • Hash/authentication
    • Lifetime
    • Diffie Hellman group
  • Phase 2: all the settings listed in Phase 1 plus
    • Perfect Forward Secrecy (PFS)
    • PFS Diffie Hellman group (if on)

Configuring Phase 1 and Phase 2 parameters from the MX for a VPN tunnel to a non-Meraki peer.

 

Being able to adjust these settings allows greater VPN flexibility. To modify these parameters, navigate to Configure > Site-to-site VPN in the Meraki dashboard and scroll down to the “Organization-wide settings” section. In configuring “Non-Meraki VPN peers,” note that there is now a clickable link under the “IPsec policies” column. Clicking this link will display modifiable VPN settings.

In addition to deeper connectivity control, we’ve also provided presets to help customers with configuring commonly used Cloud services like Amazon Web Services (AWS) and Azure—which often require customized VPN connections.

Preset for AWS VPN connection.

 

For more information about configuring VPN with Meraki MX security appliances alongside non-Meraki peers, please check out our Knowledge Base. For information about deploying site-to-site VPN between MX security appliance in seconds, check out a quick 3-minute video about Auto VPN, our VPN whitepaper, and our website.

 

 

Related Posts

BACK

The newly released Cisco Meraki Systems Manager Enterprise gives organizations the ability to ensure the security of devices and the content on them. But what about employees on the go that need access to resources hosted on local networks that are typically retrieved using Cisco AnyConnect, which provides encrypted network connectivity to mobile devices?

With Systems Manager Enterprise, admins can ensure not only that the AnyConnect app is installed on the device, but that the device itself remains in compliance while the AnyConnect app is deployed. Systems Manager Enterprise allows organizations to ensure complete security of their devices. Admins can quickly create new security policies in dashboard or check against existing Cisco Identity Services Engine (ISE) policies; devices must satisfy the defined security policy in order to have settings, content, and apps assigned.

Security compliance policies defined in dashboard are dynamic, meaning that should a compliant device violates its prescribed policy, applications can be removed/added and settings can be modified automatically. Employees use AnyConnect to securely access remote resources, so organizations will want the mobile device they are using to also be secure. For instance, if a device is jailbroken or rooted, an admin can easily create a policy that automatically removes the AnyConnect profile from the compromised mobile device.

Similarly, if a user installs a blacklisted app, they will be violating the predefined policy and the AnyConnect app will be removed from the device. With this added level of security, the user will no longer be able to use AnyConnect to connect to the VPN on their compromised device, ensuring the security of remote resources.

The possibilities are endless with Systems Manager Enterprise. Admins can easily establish any number of security policies and profiles that will automatically ensure enterprise security compliance for mobile devices as well as local and remote resources, all in a few clicks of the mouse. Learn more about Systems Manager Enterprise here.

BACK

Updates to PCI Requirements

Changes to the Payment Card Industry (PCI) Data Security Standards (DSS) include a new emphasis on education, awareness, and an approach to security as a shared responsibility. The changes aim to drive implementation of security best practices while providing flexibility for the business needs of an organization. Of particular interest to network administrators, new or updated items require organizations to:

  • Have a current diagram that shows cardholder data flows.
  • Evaluate evolving malware threats for systems not commonly affected by malware.
  • Protect POS terminals and devices from tampering or substitution.
  • Maintain an inventory of system components in scope for PCI DSS.

These are just a few of the changes in the 3.0 standards. View highlights of version 3.0 changes in this PCI Security Standards Council document (a table of updated requirements begins on page 5). The complete PCI DSS 3.0 document is available here.

 

Timeline

Organizations should keep the PCI 3.0 timelines in mind and consider these as they prepare to undergo the audit process. While the changes in version 3.0 were first proposed in 2013, and the updated 3.0 standards came into effect on 1 January 2014, version 2.0 remains active until the end of 2014. Until July 1, 2015, some of these new requirements are considered best practices only, giving organizations time and flexibility to adapt to the changes.

 

Meraki PCI Certification

For the fourth consecutive year, the Cisco Meraki cloud architecture and product portfolio are PCI level 1 certified (the highest level of certification). Past articles on the Meraki blog highlight the secure nature of the Meraki out–of–band architecture and more information about the architecture, security, and compliance can be found on the Trust section of the Meraki website.

BACK

In disaster situations, relief groups often lack a stable network to transmit potentially life-saving communications. After Category 5 Super Typhoon Haiyan struck the Philippines in 2013, the Cisco Tactical Operations Team decided to take action and created the Cisco Rapid Response Kit (CRRK): a low-cost, alternatively-powered network to serve as a preliminary response in the early hours of a relief effort.

Inside the black box

The CRRK provides both wired and wireless voice and data connectivity to emergency relief groups. It includes a portable satellite terminal, Cisco Meraki MX60W, Cisco SF 100D-08P switch, and Cisco 6921 phone (see table below for details).

Hardware and feature sets included in the CRRK

Built with airline carry-on compliance in mind, these kits can offer a lightweight initial network response in the first hours of a disaster, while more extensive resources are being prepared. They can be easily deployed by non-technical workers, and yet still provide advanced security, satellite connectivity, and wireless network features.

Included is the Cisco Meraki MX60W, which provides all-in-one wireless, branch networking, and security. The MX supports cellular uplink and Auto VPN, making it easy to configure secure, IPsec site-to-site VPN tunnels for locations in remote areas. With the Meraki cloud management platform, network engineers can manage the network remotely while remaining safely outside the disaster area.

These kits are often needed in environments where grid power and fossil fuels for generators may not be available, due to damage or lack of infrastructure. Knowing this, the rapid response kit is operable with traditional as well as alternative sources of energy, such as battery packs, solar or wind power systems, or fuel cells. Teams can operate with power sources providing as little as 0.6 Kilowatt hours (KWh) for an extended duration, or 1.2 KWh for an indefinite period – and still have power left over to charge a small number of laptops, tablet devices, or other equipment.

The kit was first put into action during the Carlton Complex wildfire in Eastern Washington earlier this year. The largest fire in Washington State history, the fire covered an area five times the size of Seattle.

Two Cisco Tactical Operations team members set up two CRRKs in less than ten minutes. These kits provided wired and wireless connectivity to support a Type 1 incident management team, several state and local agencies, and thousands of firefighters and support personnel in the south zone of the fire.

Due to the great success of the kit, the CRRK is now being sent to West Africa to aid with communication amongst health workers in the ongoing Ebola crisis.

Check out the following pictures from the Carlton Complex wildfire for a look into how off-the-shelf networking can aid humanitarian relief efforts.

 Cisco TacOps team members deploying a Rapid Response Kit

   Members of the Carlton Complex Incident Management team working on the relief network

A Cisco Meraki MR66 access point deployed on a Blue Sky mast for the firefighter WiFi network

 

Related Posts

BACK

The number of logins for each user in an organization is endless. Each new system, platform, or tool inevitably introduces a new set of logins for users, and it falls to the admin to manage those logins. It is also up to the admin to revoke access as users change roles or leave the organization. Not only must RADIUS or Active Directory be updated, but also any other tools the user had access to. This list is often extensive and can create complexity while also compromising security. We wanted to do our part to assist with this problem, so the Cisco Meraki team has added a feature for streamlining access to the Meraki dashboard: SAML (Security Assertion Markup Language), also knows as single sign on.

SAML eliminates the need to manage additional network-wide logins by setting up a trust relationship between the customer’s identity provider and the dashboard. By doing so, customers can easily access dashboard.meraki.com without having to enter additional credentials, greatly enhancing the user experience. SAML can be configured in the Organization > Settings tab.

The “Customer URL” will be entered into the customer’s Identity Provider, which will redirect authenticated users to the Meraki dashboard. The “X.509 cert SHA1 fingerprint” must be obtained from the identity provider and enables the user authentication to be passed along to the dashboard. The “SLO logout URL” specifies where the user will be redirected after logging out of the Meraki dashboard.

Extending the Meraki dashboard beyond IT

With the dashboard integrated into internal corporate services, dashboard tools can easily be extended to other parts of an organization. Finance teams can monitor facility usage to justify spending, marketing teams can align retail location foot traffic with marketing campaigns, and operations teams can optimize supply chain based on customer density. Customized dashboard access can be granted to each of these users groups by specifying the SAML roles. Below we have created a Customer, Engineering, and Marketing SAML role with varying levels of access.

For example, the Marketing users can be granted just “monitor only” visibility into the Meraki dashboard. Now, when the Marketing users log into the dashboard, they will only have visibility into analytics data in the dashboard shown below, and not configuration panels.

Here is a quick snapshot of what the user will experience when logging into the dashboard using SAML single sign on.

For complete setup instructions, check out the Meraki knowledge base with an overview of SAML setup as well as sample setups for OneLogin and AD FS.

Related Posts

BACK

Locking down wired security often means preventing unauthorized users from plugging devices directly into wall jacks or VoIP phones to gain access to internal resources. To prevent this intrusion, network admins using Cisco Meraki MS switches can apply port access policies that prompt for authentication once traffic is detected on a switch port.

But what if you’re deploying legacy VoIP phones on your network, phones that can’t respond  to authentication requests? Leaving these phones connected through open ports poses a security risk since it’s possible that clients will plug directly into the network through the phone’s Ethernet jack. A typical setup would look like this:

Meraki MS switches neatly solve this problem with the ability to allow voice VLAN clients (i.e. VoIP phones) to bypass authentication, while requiring any devices connected through the phone to authenticate.

To enable this feature, navigate to Configure > Access policies in the Meraki dashboard for your switches. This page is where you define authentication server credentials and the type of authentication required for connecting clients (i.e. 802.1x for username credentials or MAC-based RADIUS for authorized client devices).

The relevant section here is the “Voice VLAN clients” section, where you can decide whether clients connecting to a voice VLAN (typically VoIP phones) can bypass authentication themselves, or whether they will need to authenticate like any other client.

Simply allow legacy VoIP phones to bypass authentication, but know that clients connected to the LAN through the phone will still be prompted for credentials. This prevents a malicious device from gaining unauthorized access to your LAN via a non-authenticating VoIP phone.

Related Posts

BACK

Today, we’re thrilled to announce an innovative new feature that makes troubleshooting and support more intuitive, provides even greater visibility into networks, and is available out-of-the-box with no additional configuration or licensing needed: network topology. This feature automatically maps your network deployment, shows direct and redundant links across wired and wireless infrastructure, and is essential for troubleshooting network issues that would otherwise require manual mapping, overlay monitoring software, or keeping track of MAC address tables.

A typical network topology view mapping switches, APs, and a perimeter security appliance.

Network topology is available for all Meraki customers running combined networks with Meraki gear (MS, MX, or MR), or for customers running uncombined switch networks. To reap the full benefits of topology, however, Meraki MS switches should be deployed.

You can find the topology feature in combined networks under Network-wide > Topology in the Meraki dashboard; otherwise, check Monitor > Topology in your uncombined switch network.

How it works

The network topology feature intelligently maps equipment in your network, giving you a hierarchical, physical layout of how your gear interconnects. There are several things you can do with network topology, like searching for network devices by name, tag, or device type to quickly view how equipment is deployed.

Looking at gear in a corporate network tagged “guest,” and running a guest SSID or guest VLAN. Gear not meeting our search criteria is automatically dimmed.

In the topology view, squares represent MX security appliances, rectangles represent MS switches, and circles represent MR access points. Non-Meraki equipment is also detected if it is one hop away (and will appear as an empty diamond); depending on the protocols supported by a non-Meraki device, the topology view may be able to discern LLDP data like model type, IP, and manufacturer.

You can also quickly see alerting or disconnected equipment that may require additional troubleshooting, and (if the alerting device is a Meraki AP, switch, or security appliance), click into that device to troubleshoot further.

An alerting Meraki MS switch, telling us it’s having a power supply problem.

Learning which physical links in your network are most heavily-trafficked is also easy; simply hover over individual network links to learn statistics about that connection’s negotiated speed, usage, and number of directly connected clients using it in the past day. If you are trying to diagnose physical bottlenecks in your network, there is no easier way to find it.

You can even see if either a link or specific switch ports have been blocked by the Spanning Tree protocol (STP) to help prevent data loops.

By default, if entire links have been disabled by STP, they will be hidden from view. If you opt to view all physical links—not just those currently forwarding traffic thanks to STP—all you need to do is select the checkbox to “show redundant links.”

In a nutshell

Network topology is an incredibly useful tool for visibility into—and troubleshooting of—networks.

There is no need to schedule a firmware update to have topology functionality; the tool is now live in the Meraki dashboard.

To have the full functionality described in this post, a Meraki MS switch must be deployed in the network—without switches, visibility will be restricted to devices that are a single hop away from MX security appliances or MR access points.

Topology shows non-Meraki equipment, and depending on the protocols supported, useful information like model, IP, etc.

To sum up, we’re really excited about our new network topology feature and want to hear what you think. Please reach out or make a wish and give us your thoughts!

Related Posts

Try our technology.

Smart, cloud-managed IT solutions that make life simpler.

Start Trial Now