Meraki

MartinS

One thing we see with other devices/vendors are there are a lot of different CPUs to measure. My guess is this is measuring the CPU that runs the OS, but if traffic passing doesn't touch that as it's passing by via the ASICs or alike, the CPU may stay low. Then again, run something like the ThousandEyes agent and I bet the CPU jump up occasionally..

MartinS

Do you know what the maximum quantity allowed on this call is please? Sadly the documentation just specifies a minimum.

MartinS

Does seem like an omission to me, although I'd be a bit concerned that a webhook could take quite a long time to make its way out of the Meraki system?

MartinS

Hi, we can help with this using our 'Business Hours' functionality. We also have a system for managing maintenance windows. The difference with maintenance windows is we won't send an alert if we see something go wrong during the window, but if it's still down when the window closes, we'll cache and send the alert then. Business Hours - Highlight Help Maintenance Windows - Highlight Help Cisco Networking App Marketplace | Highlight

MartinS

Time to get rid of Cacti and get a proper monitoring system 😉 Lots of good options here Cisco Networking App Marketplace | Cisco

MartinS

The MIBs supported by MX devices are extremely limited, as @duwijakarta21 has said, they only support MIB2 and Interface MIBs. You can use SNMP for general device up/down, interface up/down, and traffic in/out on an interface, but that's about it. Regarding temp - that's certainly not in SNMP, but I'm also not sure it's in the dashboard API either? I quick search online suggests that data isn't available from the networking devices.

MartinS

If you're interested in NOC type wallboard, that's exactly what we do - we don't use webhooks for a few reasons but we 100% collect the data from the Meraki dashboard API Take a look at the Cisco Networking App Marketplace

MartinS

I've just looked over our install base (we're collecting data from 10,000+ devices for this metric) and I'm not seeing anything broken here. Note that Meraki only collects that data if the local or remote devices have 2 WAN interfaces - if you're running a VPN between two devices with a single WAN on each Meraki won't run that test unless you contact support and tell them to turn it on.

MartinS · ‎Feb 13 2025

Sorry it's hard to know what's going on without seeing more detail. If you'd like, I'm happy to put your org into our service observability app and we can see from that what the API is reporting as up or down? https://marketplace.cisco.com/en-US/listing?q=Highlight&locale=en-US

MartinS · ‎Feb 13 2025

Hi, yes that call is deprecated - you need to use the Get Organization Devices Availabilities call What errors or output are you getting?

MartinS · ‎Feb 13 2025

I think I would start with Get Organization Devices Availabilities - Meraki Dashboard API v1 - Cisco Meraki Developer Hub For alert statuses Get Organization Assurance Alert - Meraki Dashboard API v1 - Cisco Meraki Developer Hub

MartinS · ‎Feb 13 2025

Could you explain a bit more what you're trying to do please? Exactly what statuses are you looking to get?

MartinS · ‎Feb 6 2025

Nice! That's very useful data - but just beware of one thing that if the device goes offline completely, and so can't report back to the Meraki shard, from what we've seen the data can't be completely trusted. You need to correlate this data with device availabilities or change history to get it properly accurate.

MartinS · ‎Feb 5 2025

Yes well figured out, pagination is important on these calls as there is #a lot# of data returned. Don't forget that if you don't want the data back on all switches there are query parameters/filters you can apply which cut the amount of data returned.

MartinS · ‎Jan 30 2025

Thanks @ww - I hope not as that isn't what documentation says it is. The docs say: Description: List access point client count at the moment in an organization I've raised this as a bug with Case 12708934 @Oren flagging for your attention please!

MartinS · ‎Jan 30 2025

Hi, We're a big fan of the new Org-wide getOrganizationWirelessClientsOverviewByDevice call - but we've just seen an example where the client count returned by the API is completely different to that shown on the Meraki dashboard: For example one of my home APs currently has 9 connected clients according to the dashboard, while this API call is returning there are 26 clients connected. Is anyone else seeing this please?

MartinS · ‎Jan 23 2025

If the device is down, the dashboard can't get the data for the test. It's not safe to assume a device that the Meraki dashboard can't contact is experiencing 100% packet loss on any/all of its uplink tests, so you'll get whatever the last result before contact was lost.

MartinS · ‎Jan 22 2025

Yes it's a lot of calls and it quite a lot of work to sort the data out and report on it cleanly. This is where I'm going to plug the Meraki Marketplace as there are a number of us Ecosystem partners who can do this for you in a matter on minutes: Cisco Meraki Marketplace Declaration of interest - I work for www.highlight.net

MartinS · ‎Jan 8 2025

All is explained here - Deprecated operations - Meraki Dashboard API v1 - Cisco Meraki Developer Hub

MartinS · ‎Dec 11 2024

Not a fan of 'security by obscurity' here - I would suggest that if knowing a public IP causes you a security problem, you need to address that security problem

MartinS · ‎Dec 5 2024

Yep, it's frustrating that latency isn't included in an API endpoint (as far as I know), but as I say it is fixable by contacting Meraki support and ask them to enable 'VPN statistics' for the Org

MartinS · ‎Dec 4 2024

Yes, really we need a way to carve out API resources so we don't impact, or are impacted by other API apps. @Oren please please please!

MartinS · ‎Dec 4 2024

There are some nice Org wide calls for this now (some in beta), so scaling to thousands of switches on a 5 min polling interval via the dashboard API is totally possible (we do this!)

MartinS · ‎Dec 4 2024

Hi, Are you talking about this Dashboard latency: Or this latency dashboard page: The API call you've mentioned gets stats on the latter, and these Latency, Jitter, Packet Loss and MOS values are there to support the SD-WAN performance based routing functionality and are only collected either if one end of the tunnel has dual uplinks, or you ask support to turn it on if you only have single uplinks.

MartinS · ‎Nov 27 2024

Yes that's the correct API endpoint for Cellular signal strength. I'm afraid the Meraki documentation on that endpoint isn't the best, give me a shout if anything doesn't make sense as we use the call a lot. Martin

About MartinS

MartinS

Martin Saunders

Community Record

Badges