Cisco Meraki support

What information does Entuity collect from Meraki devices?

To manage Meraki switches, routers, WAPS and appliances

To manage Meraki WiFi deployments

To add a Meraki Cloud Management Platform

To view events and incidents on Meraki objects

To receive traps from the Meraki Cloud Management Platform

Polling Meraki port information

To offset the polling of Meraki Cloud Controllers

Entuity offers complete support for the Cisco Meraki cloud-hosted management platform and all Cisco Meraki network devices.

What information does Entuity collect from Meraki devices?

Please see the section on the Meraki dashboards in Entuity for further information.

Wireless access points

• name assigned to the access point (AP).
• IP address of the AP.
• MAC address of the AP.
• user-specified location of the AP.
• Meraki AP Mesh Status (e.g. gateway, repeater).
• model number.
• serial number.
• operational status.
• attached host count.
• list of AP interfaces.
• ICMP latency.
• SNMP latency.
• device reachability.

WAP interfaces

• interface name.
• interface speed (manually defined).
• inbound packet rate.
• outbound packet rate.
• inbound traffic.
• outbound traffic.
• inbound utilization % (available if interface speed is defined).
• outbound utilization % (available if interface speed is defined).
• interface status.

Cloud Management Platform

• router, firewall, IDS, IPS, SD-WAN (MX series).
• switches (MS series).
• access points (MR series).
• cameras (MV series).
• phones (MC series).
• endpoint management.
• license information.
  • current status.
  • expiry date.

Devices

• name.
• management MAC
• serial number.
• network ID.
• model.
• 'claimed' date.
• public IP
• status of device to cloud management platfrom connection.
• LAN IPs.
• WAN IPs.
• cellular failover status.
• location (latitude and longitude).
• tags.
• geographic (post address).

Organizations

• name, ID.
• list of VPN peers.
• list of networks.
• breakdown of each Meraki device type.

Networks

• ID.
• name.
• timezone.
• type.
• tags.
• list of VLANs defined for this network.
• list of devices belonging to this network.

VLANs

• name.
• appliance IP.
• subnet.
• fixed IP assignments.
• reserved IP ranges.
• DNS servers.

VPN peers

• name.
• public IP.
• private subnets 

To manage Meraki switches, routers, WAPS and appliances:

In order to manage Meraki switches, routers, WAPs and appliances, you need to manage the Meraki Cloud Management Platform via its RESTful API.

The Cloud Management Platform should only be managed once, via its RESTful API, on any one of your Entuity servers.

It is recommended that you do not duplicate Cloud Management Platform API polling across multiple Entuity servers for the same API key. This is because the API returns information for all organizations, networks and devices for a given API key, and Cisco significantly throttles the throughput of the Cloud Management Platform API.

To add a Meraki Cloud Management Platform:

1. Follow the steps in How do I manually add a new SD controller asset to my network.
2. In the Asset Type field, select Meraki.
3. Enter the Meraki API connection key in the Credential section.
4. In the Connection URL field, you will need to enter the URL that is documented in the Cisco Meraki Dashboard API guide. Typically, this URL will be https://api.meraki.com/api/v1/.
5. Click Add, otherwise click Cancel. Once the cloud management platform is added to the Entuity inventory, data will be retrieved from the platform and stored in a new Cloud Controller database.

To view events and incidents on Meraki objects:

From Entuity v20.0 P04 upwards, you can view events and incidents for Meraki devices and Meraki uplinks in the Events dashboards and Incidents dashboards at the Meraki network and organization context level, which are above these devices and uplinks in the parent-child hierarcy.

To receive traps from the Meraki Cloud Management Platform:

1. For trap receipt to work, you will need to download the MERAKI-CLOUD-CONTROLLER.mib from the Meraki dashboard and add to Entuity, as described in this article.
2. Because the Cloud Management Platform does not send SNMP traps on the usual SNMP UDP port number, you will need to configure the Entuity trap receiver (prologV2) to listen for traps arriving on this additional port. To do this, you will need to enter the following into the root section of the entuity.cfg file:
   
   trapportnum=[]
   
   where its value is a comma-separated list of ports, e.g. trapportnum=162,16200. This list will capture packets from devices that send traps to port 162 and devices that send traps to port 16200 (for Meraki).
3. For traps to be correctly received by Entuity, the Cloud Management Platform must be managed as a Cloud Management Platform, i.e. traps cannot be sent to Entuity from a Meraki Cloud Management Platform which is not under full management.

Polling Meraki port information

Meraki port information will not be polled by default so as to improve system performance. Instead, you can control logging of RESTful API requests through two config values in the [ccm] section of entuity.cfg:

• ccm.retrievePorts - this is a boolean value that enables or disables port information information gathering.
• ccm.restApiLogInterval - this is an integer value of seconds that represents the interval of time between logging of successful and unsuccessful RESTful API calls during Meraki polling.

To offset the polling of Meraki Cloud Controllers:

Entuity provides config values (that can be edited in the [ccm] section of entuity.cfg) by which you can asynchronize the Meraki polling of 2 Entuity servers. These are:

• ccm.pollingOffset, in seconds, by default set to 1.
• ccm.pollingOffsetBoundary, in seconds, by default set to 0.

Using these parameters, you can specify for each server to wait a different length of time to start polling.

As an example, if you set the pollingOffsetBoundary to 300 seconds, then the virtualization process will start up and find the next 300-second timestamp from epoch start time. This means that the timeline is notched every 300 seconds.

In the following example, pollingOffset=120 and pollingOffsetBoundary=300:

1. The virtualization process starts and sees that the pollingOffsetBoundary is > 0, and it is 300.
2. The time is now 13:24. The next 300 second (5 minute) notch in time is located (using epoch time as a starting point), which is 13:25.
3. pollingOffset is 120 seconds (2 minutes), so 2 minutes are added to 13:25. The process then sleeps until 13:27, at which point it wakes up and starts polling the Meraki devices.

If the pollingOffsetBoundary is set to 0 (default), then polling will start 1 second (the default for pollingOffset) after the process starts.