Cisco: Meraki [API] PowerPack Release Notes, version 111.1

Version 111.1 of the Cisco: Meraki [API] PowerPack adds multiple Dynamic Applications and Device Classes, and improves the discovery process for devices.

Version 111.1 is a special release to address an issue in version 111 that caused uplink status data to report on the wrong device. If you are using version 111, ScienceLogic recommends upgrading to version 111.1.

  • Minimum Required SL1 Version: 8.14.0

Before You Install or Upgrade

Ensure that you are running version 8.14.0 or later of SL1 before installing Cisco: Meraki [API] version 111.1.

For details on upgrading SL1, see the appropriate Release Notes.

Installing or Upgrading the PowerPack

If you are upgrading from a version of the Cisco: Meraki [API] PowerPack earlier than version 106, ScienceLogic does not guarantee the success of the upgrade.

Additionally, customers that are upgrading directly from the version 107 Limited Availability release might need to perform the following steps for collection to work:

  1. Locate the Cisco Meraki physical device and click its bar graph icon ().
  2. On the Device Summary page, click the Events tab.
  3. Locate all the events labeled "Cisco: Meraki Cloud Controller discovered as a component of organization...", select their checkbox(es), and then click the Del button to delete the events.
  4. After the events are deleted, the "Cisco: Meraki Cloud Controller Creation" run book action will run automatically and collection will work.

To install or upgrade to Version 111.1 of the Cisco: Meraki [API] PowerPack, perform the following steps:

  1. Familiarize yourself with the Known Issues for this release.
  2. If you have not done so already, upgrade your system to the Minimum Required SL1 Version: 8.14.0 or later release.
  1. Download Version 111.1 of the Cisco: Meraki [API] PowerPack from the Support Site to a local computer.
  2. Go to the PowerPack Manager page (System > Manage > PowerPacks). Click the Actions menu and choose Import PowerPack. When prompted, import Version 111.1 of the Cisco: Meraki [API] PowerPack.
  3. After importing the PowerPack, you will be prompted to install the PowerPack. Click the Install button to install the PowerPack.

After installing the PowerPack, you might want to disable the "Data Collection: Async Dynamic App Collection" process prior to discovering your Meraki system. Asynchronous collection can cause slower device discovery. For more information, see the Monitoring Cisco Meraki (API) manual.

After upgrading the PowerPack, you must delete all SNMP Dynamic Applications that were included in previous versions of the PowerPack. These Dynamic Applications will not function correctly with newer versions of the PowerPack, and upgrading the PowerPack will not automatically remove them.

Features

This release of the "Slack Automation" PowerPack includes the following features:

  • Dynamic Applications to discover and monitor Cisco Meraki devices, networks, and organizations

  • Device classes for each type of Meraki component device SL1 monitors
  • Event policies that are triggered when Meraki component devices, networks, and organizations meet certain status criteria

  • Sample credentials for discovering Cisco Meraki devices:
  • A SOAP/XML credential for users who connect to the Meraki API through a third-party proxy server
  • A SOAP/XML credential for users who want to discover only select devices
  • A Basic/Snippet credential for users who do not fall into either of the two above categories

  • Run book action and automation policies that perform the following actions:
  • Create a virtual device that represents a Meraki organization during discovery
  • Vanish devices and child devices

The PowerPack includes some event policies that can generate events in SL1 based on emails SL1 receives from Cisco Meraki. To enable SL1 to generate these events from email, you must first configure your Meraki devices to send email to SL1 using certain formatting rules. You must then configure SL1 to generate events from the inbound Meraki emails. For instructions, see the Monitoring Cisco Meraki (API) manual.

ScienceLogic recommends configuring webhooks in SL1 and Meraki to receive these alerts if you are using SL1 version 11.2 or later. For more information about webooks, see the Events manual. Contact your client success manager if you have additional questions on how to implement Meraki webhooks.

The email event policies included in the PowerPack each have an expiration delay setting that specifies the amount of time after which an active event is automatically cleared from SL1 if the event has not reoccurred. However, clearing an event for reaching its expiration delay setting does not mean that the initial condition that caused the event has been resolved.

Enhancements and Issues Addressed

The following enhancements and addressed issues are included in version 111.1 of the Cisco: Meraki [API] PowerPack:

  • Addressed an issue with a collection library that caused uplink status data to report on the wrong device. (Case: 00332667)
  • Removed "Availability" from the list of Component Identifiers for the following Dynamic Applications:
    • Cisco: Meraki Device Discovery [API] (collection object: MAC)
    • Cisco: Meraki Network Discovery [API] (collection object: Type)

ScienceLogic recommends removing "Availability" if you are upgrading to Version 111.1 of the Cisco: Meraki [API] PowerPack.

To remove the "Availability" Component Identifier:

  1. Go to the Dynamic Application manager page (System > Manage > Applications).
  2. Click the wrench icon () of the Dynamic Application you want to edit, and then click the Collection tab.
  3. From the Collection Object Registry, select the collection object that is set as the Availability identifier.
  4. In the Component Identifiers field, press the Ctrl key while simultaneously clicking Availability to remove it.
  • Added over one hundred new device classes.
  • Calls to the Meraki API were updated to include a unique identifier for SL1 so the API can track how many calls SL1 is making.
  • Added the "Cisco: Meraki Organization VPN Status" Dynamic Application. This allows up/down monitoring for VPN connections on Meraki MX devices. You can now view the VPN status for devices in a Meraki organization and the networks in that organization.
  • Added the "Cisco: Meraki Organization VPN Uplink Status" Dynamic Application. This allows up/down monitoring for WAN interfaces, including backup uplinks and cellular backup uplinks on Meraki MX devices. You can now view the uplink status for an organization and the Meraki MX and Z series appliances in that organization.
  • Updated the description of the "Cisco: Meraki Uplink Performance" Dynamic Application and changed the polling frequency to 5 minutes.

    The "Cisco: Meraki Uplink Performance" Dynamic Application description now includes a recommendation to keep the polling frequency of the Dynamic Application at 5 minutes to avoid gathering inaccurate latency data. If this setting is changed upon upgrading the PowerPack, ScienceLogic recommends changing it back to 5 minutes.

  • Added the "Cisco: Meraki Organization License Configuration" Dynamic Application and three new event policies tied to alerts to track Meraki co-termination licenses.

This Dynamic Application does not support per-device licensing.

  • Addressed an issue in the "Cisco: Meraki Cloud Controller Creation [API]" run book automation that was failing and preventing Meraki organization, network, and device discovery. (Case: 00309515)
  • Renamed the "Meraki Cloud Controller" device class to "Meraki Organization".
  • Created a new "Meraki Cloud Controller" device class that can be manually aligned to the Meraki virtual device.
  • Improved the discovery of Cisco: Meraki devices in the following ways:
    • Added a new "Class Identifier 2" collection object for the "Cisco: Meraki Device Discovery [API]" Dynamic Application.
    • Implemented a new naming convention for the Cisco: Meraki device's model name during device discovery. The model name is divided into two parts when SL1 assigns a device class:
      • The first two characters are assigned to the "Class Identifier 1" collection object.
      • The rest of the characters in the model name are assigned to the "Class Identifier 2" collection object.
    • Added 15 new device classes that will be assigned when the "Class Identifier 1" collection object matches, but no match occurs on the "Class Identifier 2" collection object. These device classes have a weight of 10, so they are not prioritized if a device matches both class identifiers.
    • Adjusted the "Cisco Systems | Meraki" default device class in the "Cisco: Meraki Device Discovery [API]" Dynamic Application to be selected when there are no device classes in the database that match the model of the Cisco: Meraki device.

ScienceLogic does not recommend adding your own device classes. However, if you want to manually add a new device class, you must do the following:

  1. Assign the Cisco: Meraki device's first two characters to Class Identifier 1.

  2. Assign the rest of the Cisco: Meraki device's characters to Class Identifier 2.

  3. Assign a value for the Weight field.

For more information about these steps, see the Creating a Custom Component Device Class section in the Monitoring Cisco: Meraki API manual.

Known Issues

The following known issues affect version 111.1 of the Cisco: Meraki [API] PowerPack:

  • The Meraki API may not always send a "retry header". If this occurs, the PowerPack does not retry the API call, which will result in a gap in data when it occurs. This will be addressed in a future version of the PowerPack.
  • If a Cisco Meraki device name includes a special character, the device name will appear in hexadecimal values on the Device Components page.
  • The Meraki Cloud Controller will not be modeled after discovery if the Meraki organization has an apostrophe in its name.
  • Due to a limitation in the number of requests that Meraki can handle per second, data collection gaps might occur when monitoring larger-scale systems.
  • The PowerPack cannot filter out particular organizations during discovery and will discover every organization that the API key returns.