If you have attended any webinars lately, you may have noticed the new “combined network” view of dashboard being showcased. You can now group independent wireless, switch, and security appliance networks into a single view to make management of various sites easier.
For those of you creating a new network, this will be the default setting. For example, you can add a switch to an existing wireless network, and it will combine them for you. But if you have existing independent networks and are ready to start combining, you can do so right from the dashboard. Under the Organization tab, expand the networks panel on the right, then simply select the wireless, security appliance, or switch network you would like to manage together, and click “combine.” Don’t worry — we will keep all of the configuration and monitoring data when the networks are combined.
There are some great benefits to combining your networks. When you are looking at a specific client, the dashboard creates a combined summary of access policies applied from wireless SSIDs and security appliance settings. Administrators can easily check if there are conflicting policies when troubleshooting client connectivity.
Combined view can also help in troubleshooting by grouping traffic analytics data for traffic seen on switches, wireless APs, and security alliances. Optionally select a device type, SSID, or policy to drill down further.
Many tasks that previously needed to be configured on several different networks, can now be set together. Below, summary report data from for an entire location can be accessed in a unified menu.
Also, check out the Network wide > Alerts and administration page where security appliance, switch, and wireless alerts can be configured all in the same place.
Try out combined view in your own environment to take advantage of these enhancements. As usual, we are always excited to hear your thoughts so keep us posted on what you’d like to see via the “make a wish” box at the bottom of every dashboard page.
Hands up all network admins who’ve heard the words “the network’s slow”. We’ve all been there, and in this post, we’re going to take a look at how policies can be used as one approach to fine-tuning your increasingly congested network. First things first: to fix a problem it first needs to be understood. Fortunately, the Cisco Meraki solution has excellent, comprehensive application-layer visibility into how network bandwidth is being consumed, and it’s also easy to identify the time-sinks — those applications which consume little bandwidth, but plenty of time. Twitter, anyone?
Having identified applications and behavior which could potentially impact overall network experience, it’s time to bring out the tools to begin tuning, and as you’d expect, Cisco Meraki provides a comprehensive toolkit for the job, including:
Network policies
Group based
Access policies
SSID based
Device based
Network policies
Sometimes referred to as global policies, these are the rules which apply to all network users, and therefore the ones to use with most care. The MX Security Appliances and MR Wireless Access Points both provide bandwidth limiters, Layer 3 and Layer 7 category-based firewalls, traffic shaping and content filtering. The dashboard controls are super-intuitive, really exemplifying the benefits of a well thought-out user interface.
Group Based
Applying universal rules may not be the most realistic way to police your network. If we take the example of social networking, it may be considered an essential tool for the marketing team, less so for other departments. Rather than a blanket ban, it makes sense to apply custom policies to each group of users. The admin could allow unrestricted access to social media for one team, while shaping traffic elsewhere to ensure business-critical apps aren’t impacted by all those cute cat videos. For educational environments, it’s possible to configure safe web searching and YouTube for Schools within these group policies. Group policies can be applied to clients manually, or the process can be automated by allocating sets of rules to specific LDAP groups.
LDAP group called ‘Guests’ with custom policy ‘Guest’ to be applied to users within that group.
Access Policies
Access policies deal with the network perimeter, i.e., do we allow a given user onto the network or not? This policy is more common in enterprise environments and can be based on either 802.1X or on a list of approved device MAC addresses. An optional guest VLAN can be provisioned to ensure everyone gets at least some level of network access.
SSID Based
Within the Meraki wireless environment, network admins can apply policies to individual SSIDs. This might be useful if looking to prioritize performance for employees over guest users, for example. Bandwidth limits (per-client or per-SSID on each AP), firewall rules, traffic shaping and content filtering can all be configured separately for each SSID. Oh, and there’s one more thing…
Device Based
Still configured on a per-SSID basis, but useful enough to consider on its own, device based policies are becoming increasingly useful as the number of devices joining our networks grows. A set of custom rules can be applied to a range of devices as we can see here.
Assign policies automatically based on device type
In this way we can ensure that devices officially sanctioned for use on the network can be given preferential treatment over, for example, personally owned devices brought into the workplace.
Putting it all together
What’s really interesting about all this control, is just how granular we can get with our policy design with minimal effort. Consider a rule for Android devices which joined our guest network, restricting YouTube bandwidth to 1 Mb/s and blocking all music streaming services. It takes just two minutes to configure. Today’s networks are far more fluid than those a decade ago. Not only is the volume of traffic so much higher, but the variety of applications and devices has expanded significantly. At a headquarters, where bandwidth is abundant, concerns over network performance may be minimal. On a branch site hanging off a DSL connection, however, controls like these can prove enormously helpful. Is your network running like a finely tuned engine?
Managed Service Providers (MSPs) look to Cisco Meraki for intuitive multi-site management of customer networks, and are keen to fine-tune their customers’ overall experience. When we announced new features for MSPs, customized branding of the Cisco Meraki dashboard was a key enhancement. We’ve now expanded branding options: in addition to modifying dashboard logos, Organization Admins can configure multi-layered policies that apply to all components of the dashboard’s Get help page, support case visibility, and knowledge base search. These policies enable MSP network admins to hide, edit, or replace default Meraki dashboard information.
The dashboard’s Get help page (accessible via Help > Get help) allows network administrators to search the Meraki knowledge base and product manuals, or to contact Meraki Support via phone or a submitted case:
The default dashboard “Get help” page functionality is now customizable.
Now, MSP network administrators can apply layered branding policies — such as hiding the Get help page entirely — to individual service customers (identified by tag or name). Policy options for the Get help page also include:
Providing customized, service-specific search content that replaces the built-in Meraki knowledge base
Presenting custom content instead of the default Meraki product manuals
Linking directly to preferred service provider help desks, rather than Meraki Support
Additionally, branding policies allow MSP network admins to hide access to Meraki’s knowledge base via universal dashboard searches, and to hide or replace the Help > Cases dashboard functionality.
A policy named “MSPInc Base” applied based on network tag.
Once policies have been created for different customer admins, they can be managed in the Organization > Branding dashboard page.
Easily see details of rebranding policies and which dashboard admins they are applied to.
Branding policies are evaluated from top to bottom, with each policy building up changes from the default policy (listed first) and bottom-most policies taking priority over top-most ones.
With these enhancements, MSPs now possess the flexibility to target branding towards customer service level tiers. That is, premium service customer dashboards can be branded with a designated logo and offer unique, premium help desks and documentation.
Ultimately, Meraki’s MSP features are designed for partners to deliver managed services that are profitable and easily scalable, and to enable intuitive per-customer, per-region, and per-site configuration.
Availability and more information
MSPs can enable branding policies for their networks by contacting Meraki Support. For additional information on Meraki’s MSP features, please check out the MSP white paper. Note: Meraki dashboard branding options are only available to qualified MSPs.
