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.
We recently announced a fantastic new feature available to all Cisco Meraki customers running combined networks or who have deployed Meraki MS switches: network topology. This feature makes troubleshooting and support more intuitive, provides even greater visibility into networks, and is built into the dashboard at no additional cost—with no additional licensing or upgrade requirements.
If you’d like to see Network Topology demoed on a live production network, check out our latest video here:
This Thursday evening, we will be hosting a tech talk on load balancing for datacenters right here at our Mission Bay office in San Francisco. Interested? Keep reading to learn more, and RSVP here if it strikes your fancy: November 20th, 6:30-9:00 PM.
Mohammad Alizadeh, Principal Engineer at Cisco, will be presenting a paper from this past year’s Sigcomm conference, titled “CONGA: Distributed Congestion-Aware Load Balancing for Datacenters.”
Abstract: Modern datacenter fabrics must provide immense bandwidth — 10s of Tbps across 1000s of ports — to support demanding applications such as big data analytics and large-scale web services. They achieve this by spreading traffic over many paths across dense, mesh topologies. Yet, state-of-the-art multipath load balancing mechanisms in datacenters are inefficient and fragile. In this talk, Mohammad will present CONGA, a new datacenter fabric load-balancing solution that he’s developed as part of Cisco’s Application Centric Infrastructure (ACI) products. CONGA significantly outperforms existing mechanisms like ECMP, reducing job completion times in an HDFS benchmark by over 2x in some scenarios.
Mohammad completed his PhD in Electrical Engineering at Stanford University in 2013. He then joined Cisco through the acquisition of networking startup Insieme Networks. Starting next year, Mohammad will become part of the Electrical Engineering and Computer Science department at MIT as an assistant professor.
Thursday’s Schedule:
6:30 pm – Food and drinks
7:00 pm – Talk by Mohammad Alizadeh
8:00 pm – Q&A
More information about directions, bike and car parking info, etc. will be sent to those who RSVP.
We periodically host tech talks at Meraki to connect Bay Area hackers interested in distributed systems, computer networks, and other technologies. If you would like to nominate a speaker or just want to learn more about the series, feel free to shoot us an email: techtalks@meraki.com.
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.
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.
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.
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
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.
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.
