Troubleshooting network complications can be an extremely time-consuming and difficult process. Issues such as VLAN mismatch are tough to track down among the mountain of configurations needed to get a network operational.
VLAN mismatches occur when two ends of a link are misconfigured to different VLANs. These can happen over access or trunk links. A mismatch on the link that carries the critical traffic required to keep the network functioning – the Native or management VLAN – causes additional headaches and potential security concerns.
The above image represents a native VLAN configuration where management traffic flows untagged across the switch port links normally. The image below represents a VLAN mismatch.
When the switch port on Switch 2 is misconfigured to VLAN 20, the management traffic will continue to flow between Switch 1 and 2, but any traffic returning to Switch 1 is treated as VLAN 20. This mismatched scenario could result in traffic being altogether dropped or potentially be a security concern if VLAN 20 has access to confidential data not normally accessible to VLAN 1 and the data makes it to the destination device.
Meraki uses two methods to detect VLAN mismatches. The first method is to detect if the link is configured with the same VLAN type or number on each switch port of the link. The second method is to observe if the link is identically configured as an access or trunk (multiple VLANs) connection on both sides of a switch port.
To help users spot the issue, Meraki has implemented VLAN mismatch detection that notifies users when an error is found.
The dashboard now indicates when a VLAN mismatch has occurred on a specific port and what exactly is causing the mismatch.
With the notification, users can now immediately diagnose potential issues in seconds and quickly isolate which port needs to be correctly configured.
To find more information on how Meraki handles VLAN mismatches, head to our documentation page. To learn more about all of Meraki’s safety and security features for switches, consider attending one of our upcoming webinars.
Enterprise organizations and partners spend thousands of dollars per site deploying servers for monitoring and reporting on infrastructure located on-site. With the total number of devices globally, including client devices, ever increasing and becoming more critical to business, monitoring and reporting using traditional means such as SNMP simply aren’t cost effective or scalable any longer.
While the Cisco Meraki dashboard provides IT admins a single interface to monitor and manage their Meraki infrastructure, we appreciate that not all organizations will have deployed the entire portfolio of Meraki devices across all their locations. Moreover some customers may have unique use cases that fall outside of what the Meraki dashboard is intended for. For these reasons, Meraki has been heavily investing in APIs over the last few years. To date, Meraki has hundreds of API endpoints being called over 23 million times every day across three powerful APIs: the dashboard, scanning, and captive portal APIs.
The Meraki dashboard API The Meraki dashboard API allows access to most monitoring and configuration functionality in the dashboard via a RESTful API. This allows customers and developers alike to:
Bulk provision thousands of Meraki devices and networks
Build custom monitoring and reporting dashboards
Automate commonly used functionality of the Meraki dashboard
In February we introduced Wireless Health, a powerful tool that consolidates and intelligently utilizes multiple data sets to rapidly identify anomalies impacting end users’ experience. In September we added a collection of new API endpoints for Wireless Health to expand the monitoring and reporting capabilities to any external analytics system or platform.
The dashboard API is a great way to monitor and report on the state of a device, for example, over a period of time. However, if all you want to do is simply be notified when something changes, then the dashboard API might not be the most efficient way to do this. The dashboard API will perpetually ask “what’s your status” to a device and report back its findings. If calls are being made, say, every 5 minutes, that’s a lot of total responses that are being received, and likely only a handful of them will deliver useful information, i.e. when the device goes offline.
MERAKI WEBHOOK ALERTS We’re pleased to announce the availability of Meraki Webhook Alerts for all alerts within the dashboard. Setting up Webhook Alerts is very straightforward:
Add HTTP servers by defining their unique URL and shared secret [ network-wide > alerts ]
Added HTTP servers can now be selected as a recipient for any alert within the dashboard [ network-wide > alerts ]
In addition to webhooks themselves, we’re releasing new API endpoints for configuring all alert settings, which will include support for configuring the above steps via the dashboard API.
Once set up, the webhook will send an HTTP POST to a unique URL, but only when a certain condition or criteria has been met to trigger an alert. So, for example, if you’re only interested in being notified when a device goes offline, Webhook Alerting will be more efficient since it will only transmit information when the status of the device goes from online to offline.
Meraki Webhook Alerts
Meraki Webhook Alerts sends HTTP POSTs to a unique URL that can easily be fed into a receiving service. A receiving service can be as simple as a Webex Teams space, a Google Sheet logging all network alerts, or something more advanced, such as PagerDuty and ServiceNow, that can take the POSTs and create support tickets, send SMS messages to concerned parties, or even automate corrective action.
A notification of a settings change to the Meraki dashboard posted to a Webex Teams space using Meraki Webhook Alerts
Both the dashboard API and Webhook Alerts have their merits and use cases, and together offer administrators, system integrators, and developers powerful and flexible options to create custom monitoring and alerting.
Real-time alerting Webhook Alerts are fundamentally event-driven which makes them the most efficient option for setting up alerts for critical events.
“Tell me immediately when latency for any of my sites’ APs exceeds 200ms” “Tell me as soon as any Meraki device across any location goes offline” “Tell me when an important device on my network loses connectivity”
Webhooks example: real-time alerting based on a threshold or criteria
Monitoring and reporting over time The dashboard API will provide a more complete picture and historical reporting since it’s continually probing for data. It’ll be the more appropriate option to use to answer questions such as
“How many times did the latency of my access points peak above 200ms over the last week” “What was the latency of the access point in conference room 3 last Thursday at 3 pm”
The dashboard API example: continuous monitoring of a variable over time
The introduction of Meraki Webhook Alerts combined with the dashboard API means that customers and developers can now more easily address their custom reporting and alerting requirements without breaking the bank.
The pace at which new security threats are being introduced and propagated online has reached exponential levels, gaining speed with each passing year. Organizations have more locations and devices to protect, and threats are using many different ports to try to gain access or exfiltrate data. Security teams are often understaffed and struggle with complex, siloed systems that do not integrate or share intelligence in a programmatic way. These teams need solutions that are easy to deploy, simple to manage, can scale exponentially, and can integrate with other tools.
Securing your wireless users from malicious attacks — particularly these “DNS blind spots” that exist in many networks and are exploited by 97% of advanced malware — is of paramount importance. Unfortunately, recent surveys indicate that 75% of organizations do not actively monitor and apply security for DNS.
It is within this context that we are excited to announce support for integration between Meraki MR wireless access points (APs) and Cisco Umbrella (formerly OpenDNS).
Umbrella is the industry’s first secure internet gateway, a cloud-delivered first line of defense against threats like malware, ransomware, and phishing. Umbrella enforces security at the DNS layer by identifying requested web domains hosting nasty stuff — malware, phishing, etc. — and block end user access to them. Umbrella also enables more secure DNS querying through a tool called DNSCrypt, which automatically encrypts DNS queries between your network and Umbrella’s servers, effectively eliminating the chance that your queries will be the victim of eavesdropping or man-in-the-middle (MITM) attacks. This secures the “last mile” of a client’s internet connection, which is often left exposed and vulnerable.
There is no additional cost or charge for taking advantage of this integration (which is available to all Meraki wireless customers who have upgraded to our latest MR26.x firmware), but Meraki wireless customers who wish to integrate with Umbrella will need a separate Umbrella license and account with that service.
Enabling Umbrella integration
So, what does this mean for admins of Meraki wireless networks? This integration with Umbrella enables Meraki admins who obtain Umbrella licenses (WLAN, Professional, Insights, or Platform) to seamlessly assign DNS filtering via Meraki group policy or SSID to specific subsets of wireless clients, or to them all.
Enabling Umbrella integration takes only a few steps. First, the Meraki and Umbrella dashboards must be linked via the Umbrella Network Devices API key. Once this API key is generated from within the Umbrella dashboard, it needs to be copied into the Meraki dashboard by navigating to Network-wide > General.
Enabling Meraki + Umbrella integration within the Meraki dashboard.
Once the Meraki and Umbrella dashboards have been configured, linking a Meraki SSID or group policy to an Umbrella security policy is easy (note: Meraki group policies must be set to use ‘Custom SSID Firewall & Shaping Rules’ to link an Umbrella policy to them). After this initial setup, a unique identifier is generated behind the scenes for the specified Meraki SSID or group policy and is used by Umbrella to determine how to evaluate traffic from that Meraki network moving forward.
To link a Meraki SSID to an Umbrella policy, navigate to the Wireless > Configure > Firewall & Traffic Shaping section of the Meraki dashboard. There, you will find a button to link Umbrella policies.
Linking an Umbrella policy to a Meraki SSID.
By default, the last policy physically listed in the Umbrella dashboard’s ordered policy list will be inherited by a Meraki SSID unless a different policy is selected from the dropdown list.
To link a Meraki group policy to an Umbrella security policy, navigate to the Network > Configure > Group policies page in the Meraki dashboard and choose the specific Meraki group policy that you want to link. Under the ‘Layer 7 firewall rules’ section of that policy, you’ll be able to choose which Umbrella policy you’d like to apply.
Applying an Umbrella DNS policy to the Meraki ‘VIP Umbrella Clients’ group policy.
Once a Meraki SSID or group policy has been successfully linked to an Umbrella security policy, clients connecting to that SSID or who have been applied that group policy will have their DNS queries encrypted (if the AP supports 802.11ac) and verified against the corresponding Umbrella policy. Encrypting DNS queries between Meraki APs and Umbrella DNS endpoints helps secure the ‘last mile’ of client web browsing and protects against devastating MITM attacks or packet snooping that can reveal which websites client devices are browsing.
An example Umbrella policy may prohibit access to known malicious web domains or websites that host specific types of content, like gambling or peer-to-peer domains. If the client’s request for access to a given website is allowed, Umbrella will return an encrypted DNS response with the appropriate IP address. If the request is denied, then an encrypted DNS response pointing to the Umbrella block page will be returned instead.
Taken together, Meraki wireless and Umbrella integration provide a significantly more robust security framework for IT admins looking to protect clients from web threats in a more proactive way. Instead of waiting for a malicious site to infect a machine and then using tools like antivirus to detect and remediate, Meraki MR customers can rest easy knowing that they are protected from ever reaching harmful sites in the first place.
Interested customers should contact Meraki Support to have this feature enabled. This feature requires an early-release MR firmware version that can be enabled with Meraki support assistance.
According to Mary Meeker’s 2018 Internet Trends report, over half of the world’s population is now online, making digital services an essential part of billions of people’s lives. Along with the myriad ways that these services have enhanced our lives, legitimate concerns have arisen over the amount of personal data collected and stored by companies with which we choose to transact.
While the vast majority of this data collection is benign, done by companies so that they can provide consenting users with useful tools and services at little to no cost, everyone deserves to know what information about them is being collected, how it’s being stored and safeguarded, and for what purpose it’s being used.
In light of the General Data Protection Regulation (GDPR) recently passed in the European Union, Meraki introduced a series of tools and updates to the Meraki dashboard that give administrators and users greater visibility and control over the data we collect and use to provide Meraki products.
Today, we’re pleased to announce that these tools and updates have been rolled out worldwide to all Meraki customers.
What does this mean for our customers and their network users? There are six main privacy-focused features we’ve introduced that we encourage you to check out:
Data access and portability: Meraki customers can utilize new features in the dashboard to export personal data.
The “right to be forgotten”: Customers can delete personal data stored in the dashboard, both for their own organization and in response to requests from users of their networks.
Restriction of data processing: In the Meraki dashboard, personal data can be identified, hidden, and removed upon a verified request from a network user to restrict processing.
Tracking privacy-related requests: The dashboard event log now includes functionality for tracking and verifying the status of privacy requests described above.
Consent tools: Enhanced splash page functionality allows Meraki customers to provide notice to, and obtain any necessary consents from, users of their networks for the collection, processing, and storage of personal data.
Data hosting visibility: When creating a new account, Meraki customers have the option to select the region where their data will be stored. For verification, the dashboard now displays the hosting region on every page.
We believe deeply in the importance of data privacy and want all of our customers to be as informed as possible about these product updates. To that end, we’ve set up a webpage detailing the solutions and tools we offer and containing additional information regarding our philosophy to privacy.
For administrators, we also have a new Data Privacy page on our documentation site that explains how administrators can configure privacy settings within the dashboard. Additionally, take a look at our Postman documentation and the API Documentation available directly in the dashboard (Help > API Documentation) for more details about our APIs.
As always, please feel free to visit the Meraki Community to chat about all things Meraki, privacy-related or otherwise.
This week the Systems Manager team released a host of exciting new Apple features and made some interface changes in the Meraki dashboard to make endpoint management even easier, automated, and more powerful.
Interface Changes: Settings Page
Interface changes can be seen on the Settings page, where users set configuration profiles and settings for different device types. The new Settings page has been redesigned to streamline management and make configuration settings more easily discoverable when creating profiles.
Also on the new Settings page, you’ll see a host of new features available for iOS and macOS, some of these were made available in the Apple iOS 11.3 and macOS 10.13.4 release. These new features are extremely powerful for all organizations managing Apple devices, but particularly compelling for those in education!
Delay OS updates for up to 90 days on iOS and macOS: Providing time for IT teams to vet and test new OS versions before they are deployed on managed devices.
Keep apps up to date on iOS and macOS: Select for specific App Store apps to automatically update when a new version is available.
Disable Bluetooth settings on iOS and macOS: Limit distractions and security loopholes by locking down the bluetooth functionality on devices through the live tools on a device page. IT teams can use this in conjunction with bluetooth restrictions settings to lock bluetooth settings on or off.
FileVault Personal Recovery Key (PRK) Escrow: Store PRKs for disk encryption on macOS devices.
Login window: Set custom login window messages for macOS devices to alert users of management or convey organizational messages.
Lock screen: Specify a custom lock screen asset tag on iOS to easily identify a device in hand.
App Store Restrictions: Restrict end user app installations and updates for more control of apps and app versions on macOS devices.
AirPrint: Set printer configurations for iOS and macOS devices.
Dock: Change size, magnification, position, minimization effect, and more macOS dock settings.
Setup Assistant: When re-provisioning a macOS device, select to skip steps like Siri setup.
….and more! For a full list, please go to the “New Features” section in the Meraki dashboard.
Current customers can take advantage of these features immediately! We hope you’ll join the Community discussions on this and other topics.
As the needs of our customers and the capabilities of our products have grown over time, so too has our deliberate approach to making the Meraki dashboard as useful and delightful as possible. The Meraki engineering team has been hard at work refining the list pages where you can view all Meraki devices of a particular type (e.g., wireless APs or switches) as well as the detail pages for individual Meraki devices.
We’ve already rolled out most of these changes over the last few months. By May 28, users will see the full set of updates when they log in to the dashboard. Keep reading to see how we’ve enhanced these pages.
Device list page
The device list page now displays a useful summary pane, which gives you an instant look at the status of all of your Meraki devices on the network. For example, you can see how many APs are online and offline, how many are alerting, and how many of your APs are repeaters. This is a small change, but one that we think a lot of customers will quickly appreciate.
Device details page
On the device details page, the map showing the location of the Meraki device is now always visible, no matter which tab of the page you’re on. You can confirm which AP you’re working on without having to toggle to the Location tab. This is especially useful for multi-site deployments.
We’ve also made it much easier to find the RADIUS and VLAN request status on an AP’s details page — it’s right on the summary tab. You can quickly narrow down a connectivity issue to RADIUS, DNS, DHCP, or ARP, or you can click on the LAN tab for more granular information.
Old Tools tab on the left, new Tools tab on the right
Finally, when clicking on the Tools tab, you’ll see all the tools available at one time instead of a dropdown selector. This way, you’ll be able to run and view the results of multiple tools at once.
Please note that after May 28, you’ll no longer be able to revert to the old version of the pages.
Do you have any suggestions for improvements? Feel free to “Make a wish” on the bottom right of any page in the dashboard to get your feedback directly to our engineers!
Early in 2012, a startup company beginning to make waves in the networking industry introduced a new feature for their line of access points. This startup was called Meraki, and the feature launched was Air Marshal. At the time, the functionality satisfied the security requirements of a typical wireless network: automatic containment of rogue APs seen on the LAN, keyword containment of SSIDs, scheduled Air Marshal scanning, and the ability to configure additional APs as Air Marshal sensors for round-the-clock protection.
With the introduction of the MR34 in 2013, Cisco Meraki introduced the dedicated scanning radio and this took the Wi-Fi industry by storm! No longer would admins have to choose between performance or security. With the dedicated scanning radio, the MR was now capable of servicing clients while simultaneously listening to the entire RF spectrum, protecting clients from malicious rogue APs.
The constant surveillance of wireless networks continues to be important, but recent trends in cybersecurity and the growth of Internet of Things (IoT) requires added flexibility when it comes to securing wireless networks.
No, James Spader won’t be lending his hand to protect your wireless network. But, much like his character on the popular TV show, Air Marshal will work to eliminate (or contain) all SSIDs found on “the list.” TV shows aside, Air Marshal traditionally made it simple to automate containment of rogue SSIDs that are seen on the LAN, or contain SSIDs that matched a keyword.
However, some environments may have a network comprised of multiple vendors, or may be a part of a collaboration workspace where numerous companies may feature their own WLANs, connecting to the same wired network infrastructure. In this instance, automatic containment of rogues seen on LAN won’t work, as the non-Meraki APs would cease to function for their clients.
But administrators no longer have to forfeit their security capabilities. With Air Marshal’s new SSID Blacklist table, rogue SSIDs won’t be automatically contained, but security rules can be configured to match on a variety of conditions allowing for an accessible network to be locked down with finely tuned security controls.
Security rules may match on four different conditions: exact matches, MAC address matches, keyword matches, and wildcard matches. The rules defined in the SSID blacklist table will match against SSIDs that are seen on LAN, as well as Other SSIDs that are “heard” by the Meraki APs but are not found on the LAN. Any matches will result in the MRs within the vicinity of the rogue or other SSID to actively contain the SSID, rendering the offending SSID useless for clients who wish to connect. Exact matches will match on the SSID seen (whether the SSID is seen on the LAN or not), while keyword rules will ignore surrounding characters and match on just the keyword specified. BSSIDs (MAC addresses used to identify a Wi-Fi network) can be matched against if specific radios (2.4 GHz or 5 GHz, for example) that are broadcasting need to be contained.
The wildcard match provides the greatest amount of flexibility. Wildcards can be used to substitute a string of characters with a single *, or a single character with a single ?. For example, an SSID Blacklist wildcard rule may match the following text: ‘*12345’. If the MR detects an SSID broadcasting ‘Guest-12345’, then that SSID will be contained. If the rule is configured to match on ‘Guest-12?45’ and the MR detects an SSID broadcasting ‘Guest-12345’ or ‘Guest-12Z45’, then that SSID will also be contained.
Merely containing the SSID isn’t enough, though. Administrators often want to be cognizant of the rogue SSIDs that are being detected and secured by their MR access points. As such, if the administrator has configured email alerts or syslog in their Meraki Dashboard, they’ll stay apprised of their security rules in action.
Good News, You’re on the (White)List
Seemingly every other day, a new company is featured in the media as being the latest victim of a cybersecurity attack. Wireless networks are often considered the edge of the network infrastructure, the first line of defense in many cases. As a result, many administrators and security teams alike want to automatically contain rogue SSIDs seen on the LAN. While this grants the highest level of security enforcement, interoperability issues may arise when factoring in how often wireless display adapters and IoT devices connect to the network.
In the modern enterprise, HDMI cables are being replaced with Wi-Fi Direct adapters to make screen sharing and video streaming simple and intuitive. In the majority of instances, these Wi-Fi Direct devices (an adapter and client device, such as a PC, printer or remote) will often communicate on their own, freshly created wireless network. Sounds easy enough… except for one slight issue. This isn’t an SSID that’s broadcast by your MR access points, and in no time at all, deauthentication frames are being sent over the air in an effort to protect your devices from the suspected intruder. While the security team is rejoicing, the network administrator is still working to find a way to whitelist these devices so that security can be maintained with just enough flexibility for day-to-day employee operations. Enter the SSID Whitelist table:
The newly familiar faces are all here when it comes to the way that SSIDs can be matched to whitelist from containment. Exact matches, keyword, MAC, and wildcard can all be used. However, unlike the SSID Blacklist table, the whitelist table will not send email alerts or syslog messages when SSIDs are matched.
Alert, but Don’t Touch
There may be instances where administrators wish to be alerted when certain SSIDs are “seen” on the LAN or “heard” in the air, without taking any specific blacklist or whitelist actions. Using the same match conditions available for the SSID Blacklist and SSID Whitelist tables, alerting security rules may also be configured. These alerts will be sent via email and syslog alerts, if configured.
In With the New
Security has been at the forefront of Meraki since the introduction of Air Marshal in 2012. With the latest enhancements made to Air Marshal, new security rules can be configured to match on a variety of conditions, enabling administrators to implement granular security policies that are flexible for the modern workplace. These new Air Marshal features encompass the rapid innovation made possible by the Meraki dashboard. The new Air Marshal enhancements are available free of charge for existing MR customers as part of a seamless Dashboard update. For the SSID whitelist and SSID alerting functionality, the MR network must be set to MR25.9 firmware or higher. Visit our documentation for more information on configuring Air Marshal.
Last week, Active Directory integration was released to all MC networks. For customers that manage their corporate directories through AD, a local server can now be used as a single source of truth for phone users.
Active Directory is the most commonly used directory software in the world, and by supporting it on the MC product line, IT administrators will have one less dependency to worry about when managing their communications system.
As always, this new integration was released right to the dashboard, with no need for additional licensing: just another example of how Meraki continually works to increase the value of our solution.
Here at Meraki, we are continually focused on simplifying the IT management experience. One of the areas our engineering team is always paying attention to is how to offer additional benefits to customers who have multiple Meraki product types. We want every product, be that wireless, security, switching or mobility management to be outstanding in their own right, but what about when they come together?
One exceptional example of this integration is Systems Manager Sentry. With Systems Manager MDM holding a wealth of data on client devices, it can automatically configure the network based on rules you provide. Another is Group Policies, where one interface allows network-wide rules, such as firewalling and traffic shaping to be configured, no matter if the connectivity type is wired or wireless.
The Meraki dashboard is central to our cloud technology and is used to manage all our products through a simple, intuitive, and powerful interface. This is continually updated and improved based on customer feedback and internal research. The cloud infrastructure allows for these changes to be seamlessly deployed without user intervention, patches, or downtime.
In February we introduced our #fullstack campaign to highlight the benefits of a combined network view in dashboard. With a combined view, the products are grouped together so that a single site can be viewed in a single navigation pane.
Although Systems Manager deployments could be managed from the same dashboard interface as the other products, it was previously not possible to combine them. Today we announce the beta availability of fully combined networks, with Systems Manager integrated into the navigation pane. If you would like to try out the new interface, go to the Organization Overview page within dashboard and choose Combine.
To celebrate the arrival of the combined #fullstack network, we are running another blog promotion for our subscribers. The winner will receive a full stack of Meraki equipment, comprising the following equipment, supplied with 3 year licences:
1 x MX64 Security Appliance
1 x MS220-8P PoE Ethernet Switch
1 x MR32 Wireless Access Point with BLE beacon technology
20 x Systems Manager licences
To take part in the promotion, all you need to do is subscribe to the Meraki blog by the end of November 2015. Current subscribers are automatically entered to win. Additional terms and conditions apply; subscription is not necessary to enter.
If you are an existing Meraki customer with only one product family today, why not try adding some of the others to learn more about the benefits of the full Meraki stack. Contact us to arrange your evaluation at no charge. You’ll be up and running in a matter of minutes, and we have a dedicated evaluation support team ready to help you at every step.
One of the most compelling benefits of cloud networking has to be the ability to troubleshoot technical issues remotely. Network engineers out there know that obtaining packet captures, an essential tool in the troubleshooting arsenal, can quickly consume time and money when supporting remote offices. Traditionally, an engineer needs to be physically present where the data is moving in order to “tap the wire” and capture detailed traffic for analysis.
In 2012 we solved this problem by giving engineers the ability to take detailed short-burst packet captures on any device in any location served by Cisco Meraki equipment. Combined with our remote cable testing feature, packet capture in the Cisco Meraki dashboard makes it far simpler to support networks on branch sites where dedicated IT resources may not be available.
The basic results of packet captures can be presented directly in the dashboard, but for more thorough data analysis, a .pcap file can be downloaded onto the engineer’s computer and opened with software like Wireshark (formerly known as Ethereal). If you haven’t worked with one before, you’ll be amazed at the detail contained in a .pcap file. It reveals everything that is passing through—from soup to nuts.
Now we’ve gone a step further and removed the need for local software by working with a new cloud service called CloudShark. Detailed packet captures can now be displayed directly in a web browser on any device.
Using CloudShark with Merkai is super easy. By default, any capture sent to the service is immediately viewable in the browser on CloudShark’s own website. If you’re already familiar with Wireshark, you’ll be right at home here. Here’s a sample :
Example Cloudshark Capture
If all of this detail looks overwhelming, the service includes analysis tools for helping you find that elusive needle in a haystack.
CloudShark Analysis Tools
CloudShark also offers the option to host its software locally on your own server. This provides significant additional benefits, useful in larger organizations where many captures may be taken routinely and there may be a requirement to retain this data for future use or compliance purposes. With CloudShark’s Appliance software you can
Build a searchable repository of capture files
Tag captures to associate them to a location, device or trouble/support ticket
Annotate packets and captures
Securely collaborate on encrypted packet captures
Manage user access, even integrating with LDAP/AD
Setting up an Appliance is easy, just download it and install. Add the URL and unique API token to the Cisco Meraki dashboard, and all captures will go directly from the Cisco Meraki cloud to the CloudShark Appliance, encrypted all the way from your Access Point, Security Appliance, or Switch.