To start, you need to determine the organization IDs for the organization you want to monitor. You can do so by sending a GET request to the endpoint as shown in Example 4-1, which will return a list of organization details for all organizations the related API key has access to, as shown in Example 4-2.

Example 4-1 Curl Request to Get a List of Organizations This User Has Access To

curl -L –request GET \
–url https://api.meraki.com/api/v1/organizations \
–header ‘Content-Type: application/json’ \
–header ‘Accept: application/json’ \
–header ‘X-Cisco-Meraki-API-Key: 75dd5334befXXXXXXXXXXXXX163c0a3fa0b5ca6’

Example 4-2 Curl Request Response Containing Organization Details for Each Organization This User Has Access To

{
        “id”: “{ORG_ID_HERE}”,
        “name”: “Meraki Sandbox Org”,
        “url”: “https://n1001.meraki.com/o/7XXXXXrb/manage/organization/overview”,
        “api”: {
            “enabled”: true
        },
        “licensing”: {
            “model”: “co-term”
        },
        “cloud”: {
            “region”: {
                “name”: “North America”
            }
        },
        “management”: {
            “details”: []
        }
    }

Once you have determined the organization ID that you want to use, you can make another GET request (see Example 4-3) to return the current device statuses and details of every device in that organization (see Example 4-4).

Example 4-3 Curl Request to Get Device Statuses for All Devices in the Chosen Organization

curl -L –request GET \
–url https://api.meraki.com/api/v1/organizations/{ORG_ID_HERE}/devices/statuses \
–header ‘Content-Type: application/json’ \
–header ‘Accept: application/json’ \
–header ‘X-Cisco-Meraki-API-Key: 75dd5334befXXXXXXXXXXXXX163c0a3fa0b5ca6’

Example 4-4 Curl Request Response Containing Device Details for Every Device in the Chosen Organization

[
    {
        “name”: “Bridge Gateway”,
        “serial”: “Q2BK-XXXX-ABCD”,
        “mac”: “88:15:44:55:66:77”,
        “publicIp”: “74.84.202.49”,
        “networkId”: “N_6558XXXXX850059”,
        “status”: “online”,
        “lastReportedAt”: “2023-05-12T15:43:19.453000Z”,
        “productType”: “wireless”,
        “model”: “MR32”,
        “tags”: [
            “Bridge”,
            “Gateway”
        ],
        “lanIp”: “192.168.1.5”,
        “gateway”: “192.168.1.1”,
        “ipType”: “dhcp”,
        “primaryDns”: “192.168.1.1”,
        “secondaryDns”: null
    },
    {
        “name”: “Attic Camera”,
        “serial”: “Q2BV-YYYY-ABCD”,
        “mac”: “e0:cb:aa:bb:cc:dd”,
        “publicIp”: “74.84.202.49”,
        “networkId”: “L_65583XXXXX5845837”,
        “status”: “online”,
        “lastReportedAt”: “2023-05-12T15:43:32.448000Z”,
        “productType”: “camera”,
        “model”: “MV21”,
        “tags”: [],
        “lanIp”: “172.16.1.5”,
        “gateway”: “172.16.1.1”,
        “ipType”: “dhcp”,
        “primaryDns”: “8.8.8.8”,
        “secondaryDns”: “8.8.4.4”
    }
]

From there, you simply need to parse the responses and record the status of each device listed. You can do this in many different ways, but for purposes of demonstration, Example 4-5 shows what the parsed response output may look like using Regex, a popular method of parsing JSON responses.

Example 4-5 Parsed Responses to Show Only Relevant Details for the Current Device Status

“name”: “Bridge Gateway”
“serial”: “Q2BK-XXXX-ABCD”
“status”: “online”
“lastReportedAt”: “2023-05-12T15:43:19”
 
“name”: “Attic Camera”
“serial”: “Q2BV-YYYY-ABCD”
“status”: “online”
“lastReportedAt”: “2023-05-12T15:43:32”

Once complete, the remaining portion of the automation would require configuring or scripting this series of commands and actions to take place at an automated interval that best fits the current deployment and monitoring needs. This would allow for a detailed historical record of every device status in the organization that is stored and accessible outside of the Dashboard UI.

Leave a Reply

Your email address will not be published. Required fields are marked *

Explore More

Dashboard Group Policy- MX and MG Best Practices – Cisco Meraki

While each of the security features mentioned previously can be configured on a network-wide basis, there are times when certain clients should have more specific policies applied than the network-wide

Network-wide Multicast Topology – Building a Scalable Foundation with Dashboard – Cisco Meraki

For networks that have multicast routing enabled, you can configure the Layer 3 Topology page to show the current multicast topology as an overlay on top of the existing Layer

Wireless Network Health – Building a Scalable Foundation with Dashboard – Cisco Meraki

Wireless networks sometimes are prone to issues, whether they be deployment related, client related, or even just environmental. Fortunately, the Meraki platform has again embraced the power of the cloud