The Cisco Meraki Dashboard contains several logging subsystems that each have unique data retention and export options available. Datasets like event, configuration, and analytics are used for starkly different purposes (business intelligence, operations, risk management, etc.) and are reflected in the native logging capabilities. Questions are often asked around how long Meraki stores logs or other metrics, which as you’ll discover shortly, can have many different answers depending on the dataset in question. The same applies for export, syslog, and other local offload options available. Different datasets, different options. Traffic Analytics Summary Reports Location Analytics Event Logs Threat Logs Configuration Change History Enhanced Privacy Features Summary Table

My hope is that this is useful summary of the diverse logging documentation that’s already available in Dashboard itself or squirreled away other official documentation archives. If in-doubt, reference Meraki’s KB.

And finally – this should serve as sufficiently comprehensive list of data types and their characteristics but the cloud Dashboard is an ever-evolving platform. Updates and improvements are a feature of the ecosystem.

Traffic Analytics

Data Retention: 1 Month

Can be disabled on an organization or per network bases

All Cisco Meraki devices perform deep packet inspection on ingress/egress flows – enabling Layer 7 app visibility across wireless, wired, and VPN networks. This means that with little to no configuration, hundreds of applications are automatically identified and reported natively in the Meraki Dashboard.

Traffic Analytics, also referred to as hostname visibility, allows administrators to view detailed application statistics for an entire network as well as for individual clients. This is especially helpful for viewing real-time and historical application consumption and for creating application shaping policies to better manage those flows.

To enable enhanced client/app visibility on a per-network basis, select the target network, then navigate to Network-wide > General and set “Hostname Visibility” to “Report specific hostnames“.

Doing so adds a Traffic Analytics page to the Network-wide > Monitor tab and unlocks deeper client application reporting when viewing individual clients. The app data starts being collected once the hostname visibility feature is enabled.

Network Application Statistics

If hostname reporting is enabled, the Traffic Analytics page (Network-wide > Monitor > Traffic Analytics) provides an application-centric view of detected applications over a given timescale. The time period can be modified at the top of the page to daily, weekly, or monthly.

Client Application Reporting

Navigating to Network-wide > Clients displays aggregate client and application information. Clicking the ”show details” link under the application pie chart displays a sortable view of applications consumed across clients.

Selecting an individual client opens the Client Details page. From there information about the applications, ports, and content viewed by a particular client can be seen (assuming hostname visibility has been enabled).

Clients remain listed in the Network-wide > Clients view for 30 days after they were last seen by an AP, switch, or security appliance. If clients are inactive for more than 30 days, they will automatically be removed (as will any policies manually associated to them).

Custom Applications

Hundreds of applications and web destinations are fingerprinted automatically by the Meraki Dashboard. If required, custom applications can be added based on a mix of HTTP domain name, IP address, and port range. Matching custom app flows are then displayed in the Network-wide > Clients page application pie chart.

To add a custom application for an individual network, navigate to Network-wide > General > Traffic analysis > Add a slice.

To add a custom application for the organization, navigate to Organization > Settings > Traffic analysis > Add a slice.

Disabling Traffic Analytics

Traffic analytics and hostname visibility can be disabled under Network-wide > General > Traffic analysis > Disabled: do not collect traffic types.

Traffic Analytics Data Retention

L7 application usage statistics are available in Dashboard for up to 30 days.

Summary Reports

Data Retention: 6 Months

The Meraki Dashboard Summary Report page (Organization > Monitor > Summary Report) offers a consolidated view into statistical information for wireless, switch, and security appliance networks. The page is meant to serve as a high-level report into the Top X (clients, apps, OS, threats, etc.) that are consuming Meraki network infrastructure. Besides top category views, the Summary Report page displays network usage trends, MX device utilization detail, and bandwidth anomalies over the selected timescale.

Summary reports can be viewed with the following filter options:

Individual network

Networks with a specific tag

Organization-wide

Summary Report Export Options

Meraki Summary Reports can be exported for offline review via an Excel spreadsheet download.

Additionally, email summary reports can be sent on demand or scheduled for delivery on a reoccurring basis.

Summary Report Retention Note

While the Summary report timeframe selection allows for any start date, the output is formatted such that anything beyond 6 months is likely going to be difficult to parse.

Location Analytics

Client Heatmap Data Retention: 6 Months

Client Proximity Data Retention: 9 Months

Data stored with anonymized client details

Extended retention can be done using an external REST collection server

Cisco Meraki access points are able to build a wifi presence model for clients my monitoring device’s probe requests and 802.11 data frames. The signal strength heuristics are then process via a multilateration technique to determine location relative to multiple APs within signal of the client device.

Wifi clients do not have to be associated to the local wireless network for the positioning information to be captured and used. Non-associated devices (like a mobile phone in a purse) send periodic probe requests to discover surrounding wireless networks even when not actively in use. The dedicated scanning radio monitors all channels and uploads metadata of relative device position to the cloud.

In Dashboard, the Wireless > Location heatmap page displays a visualization of client location and movement patterns overlaid on a Google map interface or custom floor plan.

The location heatmap shows the aggregation of client position, count, and dwell time. The more intense red areas represent densely populated areas or those in which clients remained active for long periods of time.

Grey circles displayed in the heatmap show the location of unassociated clients or those where just probe requests were seen.

Blue circles indicate clients connected to a SSID.

Wifi Presence Metrics

There are several different wifi presence metrics captured and organized on the Organization > Location analytics page for dynamic reporting.

Wireless location analytics are becoming increasingly valuable across industry verticals. Retailers use the wifi and BLE intelligence to optimize conversion, measure retail KPIs, and engage customers directly via app and splash interactions. Manufacturing and healthcare uses often center around high-value asset tracking and alerting.

Regardless of the business value, analytics are a native function of the Cisco Meraki wireless platform and are consumable directly in-Dashboard using the pages discussed above or via a real-time exportable REST API for business intelligence processing and reporting.

The location and identification elements are exported via an encrypted HTTP POST of JSON data to a specified ingestion server. Data from all access points in a network are aggregated in the Meraki cloud and relayed to an organization’s capture servers.

Location Analytics Client Identity and Privacy

Client location metadata is collected via probe requests, data frames, and bluetooth beacon frames to aggregate presence information. These inputs contain MAC addresses of client devices and as such Cisco has built privacy into the analytics platform to anonymize any stored identity information by default.

Client MAC addressess discovered as part of the location leaning process are anonymized using a 1-way hash to prevent identifiability once stored in the cloud. As a result, Cisco has no visibility into client identity as it relates to location or positioning for any customer networks worldwide.

In addition, Cisco Meraki hosts a global opt-out feature allowing users to submit the MAC addresses of their devices. Once submitted, the Meraki cloud automatically is prevented from learning the MAC addresses using the location analytics engine for real-time export via the Scanning API.

While client MAC addresses are not stored in their raw format in the Cisco Meraki cloud, the real MAC addresses are sent non-hashed via scanning API to customer capture servers ingesting the API stream. This allows organizations that want to use client identity information for business intelligence purposes to do so in a secure and private manner outside of the cloud platform.

More information on how location analytics works can be found in this excellent KB on documentation.meraki.com.

Event Logs

Data Retention: 3 Months

Extended retention can be achieved using an external syslog server

The Cisco Meraki Dashboard includes an integrated, historical event database that can be accessed and queried by accounts with the appropriate privileges. Every Meraki device generates event logs based on live conditions and streams those events to the cloud via its secure, persistent mTunnel connection. The cloud then acts as an event log aggregator, processing and storing network events over time for later retrieval.

Event logs are organized in Dashboard on a per-network basis. Since networks are often mapped to a unique location/office/campus, events lookups should be started by first navigating to the appropriate network dropdown selection. Also, it’s important to consider that event logs are stored at the network-level in Dashboard itself, not on the Meraki device. Devices generate and queue event logs locally, but once the cloud confirms recipt of the records they are cleared to accommodate new entries.

Accessing the Event Log

The Event Log can be accessed via the Network-wide > Monitor > Event log page.

Events can be filtered by the following elements:

Client

Cisco Meraki Device

Date and Time

Event Type

If the network is combined (includes multiple device types) the drop-down menu at the top of the page allows an admin to select the relevant device the events would have been generated from.

*Note: if Clients is shown as an option, choosing it will show historical MDM events for all Systems Manager clients in the network.

A full list of event log types available per-platform can be found on the official Cisco Meraki Event Log KB.

Extended Event Log Retention: Syslog

If more than three months of event log history is required for administrative, legal, or compliance requirements then an external log server can be used. Every Meraki devices supports local offload of events in real-time via the industry standard syslog protocol.

Events sent to the syslog collector are transmitted directly to the destination from the management IP of the Meraki device. The cloud does not act as an intermediary – enabling messages to remain within to the organization’s private network boundaries.

Syslog export of events can be configured under Network-wide > General > Reporting > Syslog Servers.

More details on syslog event types and syntax samples can be found here.

Threat Logs

Data Retention: 1 Month

Extended retention can be achieved using an external syslog server

MX security appliances offer advanced threat detection and prevention capabilities when running an Advance Security license. This protection comes in the form of two unique threat toolkits – Sourcefire IDS/IPS and the AMP anti-malware engine.

The Sourcefire intrusion detection and prevention process uses network behavioral signatures to alert and block known malicious patterns as they transit routed interfaces of the MX appliance. MX runs the full list of Sourcefire signatures and automatically checks for updates every hour by default.

Cisco AMP, which stands for Advanced Malware Protection, inspects the disposition of files as they enter and exit the MX’s WAN interface. AMP uses global threat feeds from Cisco’s Talos Security Intelligence and Research Group to automatically download information on known and emerging threats. Contaminated files are quickly becoming the dominate malware vector, requiring dedicated file analysis systems like AMP.

Files marked as malicious by the AMP cloud (or found to be by the 2 million AMP sensors in the wild) are automatically blocked and reported. If a file is novel, has an unknown disposition, and later is found to be malicious via a sandbox detonation, an event will be generated – retroactively changing the disposition from unknown to malicious and prominently displayed as such in the Security Center Dashboard console.

Security Center

All IDS/IPS and AMP event reporting is consolidated into a unified Security Center threat console natively within the Meraki Dashboard.

Security Center allows security admins to filter the data displayed using different timescale options (2 hours/day/week/month) as well as event type, disposition, and blocked/allowed. The output can additionally be filtered down to a single client or event for targeted analysis.

Details around how to navigate the reporting interface and event information can be found in the official Security Center KB.

Security Center isn’t displayed under the Security appliance menu until one or more of the threat tools are enabled. To activate the Sourcefire IDS/IPS or AMP, select the specific MX network then navigate to Security appliance > Configure > Threat protection.

Extended Threat Event Retention: Syslog

Much like the the Dashboard network event log discussed above, IDS/IPS events can be externally logged in real-time via the MX’s syslog export feed. This enables integration support for third-party SIEM collectors and offers long-term threat log retention for customers that need to store more than 30 days of threat event history.

To enable syslog export of IDS/IPS events, navigate to Network-wide > General > Reporting and add the IDS alerts syslog role.

Configuration Change History

Data Retention: 12 Months

All configuration changes made within an organization’s Dashboard are recorded and available under Organization > Monitor > Change Log. This can be especially valuable for identifying changes made by specific network administrators or when rollback to a previous configuration state is required.

The configuration change history is sorted by most recent events first and can be filtered to only display changes made by specific admins or those performed to a particular network.

There are 8 columns displayed that help identify the who, what, where, and when elements associated with any individual change event. More details can be found here.

CSV Export Option

If you’d prefer to export the change log for more advanced search or parsing options, you can click the Download as CSV button in the upper right hand corner of the Change log page.

The CSV export includes the full 12 months of change history.

Enhanced Privacy Features

Cisco Meraki takes customer privacy very seriously. Privacy controls have been built into the core cloud infrastructure such that customer configuration and client metadata is containerized per organization. There isn’t a Dashboard mechanism to leak such data between customer accounts.

Additionally, only network management information (not user data) flows from devices to the Meraki cloud – preventing dataplane traffic from being sent to the cloud. Client MAC addresses stored for location tracking purposes are hashed and randomized as a precaution. Meraki has also received a certification of compliance with EU/US and Swiss-US Privacy Shield Frameworks and Principles set by the US Department of Commerce.

Additional Privacy Options

For privacy-conscious organizations that would like the ability to set time-based limits on how long historical client metadata will or would like to selectively purge client metadata, two enhanced client privacy controls are available.

Both privacy controls are available by default to all European Union (EU) cloud customers. The features are available to customers outside of Europe by simply sending a request to Meraki Support.

Client Expiration

Client expiration settings allow time-based limits to be set on how long historical client data will be viewable in Dashboard networks. Data will expire from:

AP client history

Bluetooth clients history

Client details page

Event logs

Radius login history

Scheduled reports

Splash login history

Summary reports

Traffic analysis

To enable client privacy expiration, navigate to Network-wide > Configure > General > Client privacy.

Forget Clients

A Forget Client button can be made available on the Client List and Client Details page which removes a client and their usage data from the client list for a network. The historical client data will be made inaccessible on dashboard, but will continue to contribute to aggregate statistics and network usage totals.

If a forgotten client connects to this network in the future, it will be treated as a new client. This action will have the following effects on this client:

Remove usage data

Remove traffic analysis data

Remove event log entries

Remove the client’s detail page

Remove from the client List

The Forget Client button option can be found by browsing to the Network-wide > Clients page.

More information on Cisco Meraki’s privacy compliance can be found on the official Privacy and Data Protection Compliance page.

Summary Table