Cisco Meraki products are built from the ground up for cloud management and come out of the box with centralized management, layer 7 device and application visibility, real-time web-based diagnostics, monitoring, reporting, and much, much more.
Data source description
Currently, the Cisco Meraki collector generates changelog, security, and connection events. The collector processes the Meraki responses and sends them to the Devo platform, which will categorize all the information received on the following tables:
Source
Description
Devo data tables
Meraki organization changelog
Displays changes made in any network within the current Organization since it was created. This includes configuration changes made to all types of devices, not just administrative changes to the Dashboard. Each time a change is made an event in the ChangeLog will be generated.
cloud.meraki.api.changelog
MX security events
Display security events generated by MX Appliances for each existing network. These events are logged as a result of the Connection Monitoring tests failing.
network.meraki.api.security_events
Appliance/Switch/Wireless Event Log
Display network events generated by all managed MR/SM/MS/MV devices for each existing network.
Verify that you have a valid user account with appropriate permissions by logging into Cisco Meraki.
...
Hover over the toolbar on the right-hand side to open the Dashboard.
Go to Organization > Settings.
...
Setup
Meraki collector works over the API to retrieve the data, so is needed to enable the access via API Key and generate a Key to allow the collector get the data following the steps below:
Log in to your Meraki account
Go to Organization → Settings.
Image Added
Go to the API Access Dashboard and tick the checkbox Enable access to the Cisco Meraki Dashboard API.
Image RemovedImage Added
Once you have enabled access to the API, we need to create the API Key. To do this, click the profile link below the checkbox, or by clicking your username and selecting your username, and clicking My Profile.
Image RemovedImage Added
Go to API Access> → API Keys and click Generate New API Key.
Note
...
If Meraki dashboard IP filtering is enabled, make sure to allow access for the collector IP or IP range.
Be careful, the API key will inherit the permissions of the user who creates it, so it must be created with a user with at least "organization - read only" permissions.
Run the collector
Once the data source is configured, you can either send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).
Rw ui tabs macro
Rw tab
title
Cloud collector
We use a piece of software called Collector Server to host and manage all our available collectors. If you want us to host this collector for you, get in touch with us and we will guide you through the configuration.
Rw tab
title
On-premise collector
This data collector can be run in any machine that has the Docker service available because it should be executed as a docker container. The following sections explain how to prepare all the required setup for having the data collector running.
Structure
The following directory structure should be created for being used when running the Cisco Meraki collector:
In Devo, go to Administration → Credentials → X.509 Certificates, download the Certificate, Private key and Chain CA and save them in <any directory>/devo-collectors/cisco_meraki/certs. Learn more about security credentials in Devo here.
Editing the config-cisco_meraki.yaml file
In the config-cisco_meraki.yaml file, replace the <short_unique_identifier>, <api_key> values and enter the ones that retrieved in the previous steps. In the <short_unique_identifier> placeholder, enter the chosen value.
Code Block
globals:
debug: false # File system persistence ON
id: not_used
name: cisco_meraki
persistence: # Directory where the persistence will be saved in case of using filesystem
type: filesystem
config:
directory_name: state # Cloud Devo config EU (for US use us.elb.relay.logtrust.net)
outputs:
devo_1:
type: devo_platform
config:
address: eu.elb.relay.logtrust.net
port: 443
type: SSL
chain: chain.crt
cert: <your_domain>.crt
key: <your_domain>.key
inputs:
cisco_meraki:
id: <short_unique_identifier> # The value of this field will be used internally for having independent persistence areas
enabled: true
debug: true
requests_per_second: 5 # Setting up requests per second. 5 recommended.
services: # Services available for this collector are Alerts, Secure Score and Secure score control profile
network-events:
api_key: '<api_key>' # API Key obtained in the Meraki profile
start_time: '2021-01-01T00:00:00.000000Z' # Collector Initial time.
security_events:
api_key: '<api_key>' # API Key obtained in the Meraki profile
start_time: '2021-01-01T00:00:00.000000Z' # Collector Initial time.
changelog:
api_key: '<api_key>' # API Key obtained in the Meraki profile
start_time: '2021-01-01T00:00:00.000000Z' # Collector Initial time.
Note
The “start_time” fields must have the following format:
The Security-events Service may generate error logs if you do not have an MX appliance.
Download the Docker image
The collector should be deployed as a Docker container. Download the Docker image of the collector as a .tgz file by clicking the link in the following table:
The following Docker Compose file can be used to execute the Docker container. It must be created in the <any_directory>/devo-collectors/cisco_meraki/ directory.
To run the container using docker-compose, execute the following command from the <any_directory>/devo-collectors/cisco_meraki/ directory:
Code Block
IMAGE_VERSION=<version> docker-compose up -d
Note
Replace <version> with the required value.
Change log for 1.x.x
Release
Released on
Release type
Details
Recommendations
v1.3.0
Status
colour
Purple
title
FEATURE
Status
colour
Yellow
title
VULNS
Status
colour
Green
title
IMPROVEMENTS
New features:
The resilience has been improved with a new feature that restart the collector when the Devo connections is lost and it cannot be recovered.
Improvements:
The underlay IFC SDK has been updated to v1.1.3.
Vulnerabilities mitigation:
All critical and high vulnerabilities have been mitigated.
Upgrade
v1.3.2
Status
colour
Yellow
title
VULNS
Vulnerabilities mitigation:
All critical and high vulnerabilities have been mitigated.
Upgrade
v1.3.4
Status
colour
Green
title
IMPROVEMENTS
Status
colour
Red
title
BUG FIX
Improvements:
When the Meraki API returns an HTTP CODE 429 (Too many requests), the collector handle it to avoid overflooding.
Bug fixes:
Some error messages were logged at the debug level and are now logged at the error level correctly.
Upgrade
v1.3.5
Status
colour
Green
title
IMPROVEMENTS
Status
colour
Red
title
BUG FIX
Improvements:
The number of debug traces has been increased to provide better visibility when troubleshooting.
Bug fixes:
Logging AssertionError trace thrown when requesting invalid product types from networks without those product types is now logged in debug level.
Upgrade
v1.3.6
Status
colour
Green
title
IMPROVEMENTS
Status
colour
Red
title
BUG FIX
Improvements:
The number of debug traces has been increased to provide better visibility when troubleshooting.
The network_security_events (MX) service has been enhanced with new logic that avoids requesting MX events from networks without MX appliances. This reduces the number of unnecessary API requests to Meraki that were returning 400 HTTP CODE.
Meraki Python package has been upgraded from v1.18.2 to v1.22.1
The events are sent to Devo in batches, increasing the performance.
Bug fixing:
Fixed a bug where the data extraction services via network_event_log and network_security_events stopped pulling events after retrieving the first page of 1,000 events. This behavior was causing some delay in the ingest in networks with a high volume of events.
Fixed how persistence of the network_security_events service is handled and it now stores a unique save point for each available network instead of one for all networks.
Fixed a bug where events were being sent to Devo without proper ordering. Now all events are ordered from the origin by the API.