Meraki

sungod · ‎Oct 22 2021

As above, there's no charge. What happens is that 'excess' calls will return code 429 to indicate that the call failed due to the rate limit. Any application that might make calls frequent enough to hit the rate limit needs to be coded to back-off and retry appropriately. If you use the Python Meraki library, it includes handling of rate limiting, though it's not always sufficient (i.e. when using the aio library).

sungod · ‎Oct 12 2021

This looks like the only call that returns app data, you'd need to try it against a test device to see if the return data gives what you are looking for... https://developer.cisco.com/meraki/api-v1/#!get-network-sm-device-softwares You will need to find your organization ID, you can find it with... https://developer.cisco.com/meraki/api-v1/#!get-organizations Also you need the network ID of a system manager network, use this to find all networks and choose an SM one... https://developer.cisco.com/meraki/api-v1/#!get-organization-networks To create a script to automate things, the loop would be... get all networks in the org with... https://developer.cisco.com/meraki/api-v1/#!get-organization-networks iterate through that list, testing the productTypes element for each network that is a system manager network, run the get-network-sm-device-softwares call to get the device data I recommend using the Python API library as it does a lot of the low level stuff for you... https://pypi.org/project/meraki/

sungod · ‎Oct 11 2021

To get all networks (including the name) in an organization, you can use... https://developer.cisco.com/meraki/api-v1/#!get-organization-networks That'll give you all you are after with just two API calls. If you've not tried it, the Python library simplifies using the API... https://pypi.org/project/meraki/1.12.0/

sungod · ‎Oct 11 2021

If you are using MX appliances for WAN connection, you can use... https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-uplink-statuses This will get you the status of every uplink in the organization, it includes the public IP.

sungod · ‎Oct 6 2021

In the example you posted it looks like you are using the V0 API which I think is now deprecated, do you see the same with V1? Fwiw I use the API across several organizations for monitoring/stats/analytics, using quite a few different endpoints, currently with the Python V1 library. Defensive programming with plenty of error recovery is essential, the error recovery in the library is certainly not always enough. There will be faults at times, some may take quite a while to fix, but there will also be transient faults, including Internet/other issues unrelated to Meraki's infrastructure, all can disrupt things. One thing that may reduce issues is using an organization's specific shard rather than the generic api.meraki.com, there's another recent thread about this. You mention polling every minute, if that is on multiple networks/devices in an organization you might also be hitting the rate limit at times. I guess you prefer the same approach on multiple vendors, but it seems odd to do such frequent polling of an orchestrator that can itself send you alerts as/when they occur, maybe you could get what you need more reliably via webhooks?

sungod · ‎Oct 3 2021

You can use this call on each network, it includes IP address... https://developer.cisco.com/meraki/api-v1/#!get-network-devices

sungod · ‎Sep 24 2021

Don't think there's an org-wide call for clients. You can just use getOrganizationNetworks to get the list of networks, then iterate over that with getNetworkClients to give you the complete client list, or use a filter argument to limit response to the one you want based on client MAC.

sungod · ‎Sep 13 2021

Fyi the problem with the getNetworkWirelessDevicesConnectionStats call has been fixed. It's possible the latency stats call will also work now, I suggest try a test.

sungod · ‎Sep 13 2021

Sometime since last week this problem has been fixed, I had an update from support. I've now tested on three orgs (hundreds of networks, thousands of devices), all are now returning data ok using the v1 API.

sungod · ‎Sep 11 2021

The API service is not 100% reliable. From experience, it's failry common to have transient/one-off failures. Others may continue for hours, days, or even months - there's at least one V1 endpoint that stopped working in January, it still doesn't work, I have a case open for this, Meraki say it's not a priority to fix it! You can code to handle transient failures with delay-retry loops, for long term ones you can try using the equivalent V0 endpoint instead (assuming there is one). If something has just started failing and it is persistent, I suggest open a case, at least then it will be known, it may then get fixed, there was an issue with some shards a couple of weeks back, it was resolved in a few days.

sungod · ‎Sep 11 2021

For SNMP you would need to set up a SNMP server to receive the traps, then configure Dashboard to send to that server. It's limited compared to webhooks. For webhooks you also need a server, but it's probably faster/simpler to try out. https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Meraki_Device_Reporting_-_Syslog%2C_SNMP%2C_and_API#Meraki_Dashboard_Webhooks https://developer.cisco.com/meraki/webhooks/ See here for using with a simple JSON server... https://developer.cisco.com/meraki/build/meraki-webhooks-with-json-server/ With the lack of documentation on precisely what will be sent, it's not possible to say if you'll get what you are looking for, so you need to try and see if you are lucky! Quickest way could be to use Heroku to host the JSON server for free... https://github.com/jesperorb/json-server-heroku#deploy-to-heroku ...then configure an MX test network to send webhooks to your server, cut the power the MX for a short period and see what webhooks sends when the MX restarts.

sungod · ‎Sep 10 2021

Yes, but have you actually looked at the webhook/SNMP data to see if it gives the reason? Until you try it, you won't know.

sungod · ‎Sep 10 2021

I've never seen appliance lost power/reboots reported in Dashboard network event log, nor in the events returned by getNetworkEvents (using V1 API). It always seemed a curious omission, as on the device page summary tab, the 'connectivity' timeline bar does pop-up a message saying there was a reboot and the cause (typically lost power or firmware update), clearly the information is there. I haven't tried, but my guess is webhooks or SNMP would be the best bet, as I think they can give alerts for device going offline/online, you'd need to set up something to receive them.

sungod · ‎Aug 31 2021

How about use /networks/{networkId}/clients to build a lookup table of MAC to ID/name Then /networks/{networkId}/wireless/clients/connectionStats to get the stats by MAC

sungod · ‎Aug 30 2021

Yes, just tried running on an affected org and also looks ok now. Thanks for the update.

sungod · ‎Aug 29 2021

Since 27th August this v1 call has started failing with 500 Internal Server Error on at least two of our organizations (shard: n71 and n383 fail every time), while another org (on m154) is fine. API v0 call works fine on the affected orgs. It is clearly a v1 specific fault on some organizations. Using the meraki developer API page to test the call returns this novel response! (copy/paste from the result data window on page https://developer.cisco.com/meraki/api-v1/#!get-organization-networks ) <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>Page not found - Cisco Meraki</title> <style type="text/css"> body { display: flex; flex-direction: column; justify-content: flex-start; align-items: center; margin: 0 2em; font-family: Helvetica, Arial, sans-serif; line-height: 1.45; color: #222325; /* same as $gray-10 in mkiColorVariables.json */ } .header__container, .content__container, .footer__container { max-width: 800px; width: 100%; } .header__container { padding: 2em 0; border-bottom: 1px solid #D7D7D9; /* same as $gray-80 in mkiColorVariables.json */ } .header__merakiLogo { height: 2.125em; } .header__merakiLogo--gray { fill: #898b8e; } .header__merakiLogo--green { fill: #67b346; } h1.content__title { font-size: 1.728em; /* from typographyBase.scss */ font-weight: 300; margin-bottom: 1em; } .content__container { margin-bottom: 1em; } .content__container a { color: #1D770B; /* same as $linkColor in variables.scss */ } .footer__container { padding: 1em 0; text-align: right; border-top: 1px solid #D7D7D9; /* same as $gray-80 in mkiColorVariables.json */ } .footer__text { font-size: 0.833em; color: #898A8C; /* same as $gray-50 in mkiColorVariables.json */ } </style> </head> <body> <div class="header__container"> <svg class="header__merakiLogo" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 130 25"><title>Cisco Meraki</title><rect class="header__merakiLogo--gray" x="13.29" y="16.46" width="2.06" height="8.17"/><path class="header__merakiLogo--gray" d="M32,18.8a3.64,3.64,0,0,0-1.73-.44,2.18,2.18,0,1,0,0,4.36A3.63,3.63,0,0,0,32,22.29v2.19a6.53,6.53,0,0,1-1.88.29,4.23,4.23,0,1,1,0-8.46,6.29,6.29,0,0,1,1.88.29Z"/><path class="header__merakiLogo--gray" d="M10.46,18.8a3.59,3.59,0,0,0-1.73-.44,2.18,2.18,0,1,0,0,4.36,3.59,3.59,0,0,0,1.73-.43v2.19a6.49,6.49,0,0,1-1.88.29,4.23,4.23,0,1,1,0-8.46,6.23,6.23,0,0,1,1.88.29Z"/><path class="header__merakiLogo--gray" d="M38.45,18.4a2.15,2.15,0,1,0,2.13,2.15,2.11,2.11,0,0,0-2.13-2.15m4.31,2.15a4.31,4.31,0,1,1-4.31-4.23,4.2,4.2,0,0,1,4.31,4.23"/><path class="header__merakiLogo--gray" d="M23.17,18.32a7.05,7.05,0,0,0-1.61-.25c-.83,0-1.27.27-1.27.67s.6.67.94.78l.57.18A2.46,2.46,0,0,1,23.74,22c0,2.05-1.81,2.74-3.38,2.74a12.56,12.56,0,0,1-2.22-.22V22.67a7.73,7.73,0,0,0,1.95.31c1,0,1.5-.3,1.5-.77s-.41-.65-.92-.81l-.44-.14c-1.15-.36-2.1-1-2.1-2.39,0-1.53,1.14-2.55,3-2.55a8.91,8.91,0,0,1,2,.26Z"/><path class="header__merakiLogo--gray" d="M2,7.68a1,1,0,0,0-2,0V9.83a1,1,0,1,0,2,0Z"/><path class="header__merakiLogo--gray" d="M7.66,4.87a1,1,0,0,0-2,0v5a1,1,0,0,0,2,0Z"/><path class="header__merakiLogo--gray" d="M13.28,1a1,1,0,0,0-2,0V11.87a1,1,0,1,0,2,0Z"/><path class="header__merakiLogo--gray" d="M18.9,4.87a1,1,0,0,0-2,0v5a1,1,0,1,0,2,0Z"/><path class="header__merakiLogo--gray" d="M24.52,7.68a1,1,0,0,0-2,0V9.83a1,1,0,1,0,2,0Z"/><path class="header__merakiLogo--gray" d="M30.14,4.87a1,1,0,0,0-2,0v5a1,1,0,1,0,2,0Z"/><path class="header__merakiLogo--gray" d="M35.77,1a1,1,0,1,0-2,0V11.87a1,1,0,1,0,2,0Z"/><path class="header__merakiLogo--gray" d="M41.39,4.87a1,1,0,0,0-2.06,0v5a1,1,0,0,0,2.06,0Z"/><path class="header__merakiLogo--gray" d="M47,7.68a1,1,0,0,0-2,0V9.83a1,1,0,1,0,2,0Z"/><path class="header__merakiLogo--green" d="M68.43,24.64,62.06,8.9V24.64H60.73V7.13h2l6.44,16,6.08-16h1.95V24.64H75.9V9l-6,15.61Z"/><path class="header__merakiLogo--green" d="M91.28,21.18A5.11,5.11,0,0,1,86,25c-3.43,0-6-2.36-6-6.69s2.5-6.69,5.76-6.69,5.71,2.19,5.71,7H81.36c.12,3.6,2.16,5.25,4.69,5.25a3.77,3.77,0,0,0,3.84-2.7Zm-9.9-3.65h8.75c-.17-3.24-2-4.84-4.35-4.84S81.63,14.37,81.38,17.54Z"/><path class="header__merakiLogo--green" d="M94.57,24.64V12h1.07l.19,2.43a3.67,3.67,0,0,1,3.55-2.8,4.51,4.51,0,0,1,1.31.2v1.29a4.93,4.93,0,0,0-1.39-.22c-1.85,0-3.43,1.8-3.43,4.84v6.91Z"/><path class="header__merakiLogo--green" d="M102.35,15.28c.19-2.16,2.12-3.65,4.91-3.65S112,13.21,112,15.79v8.85h-1.07l-.19-2.09A5,5,0,0,1,106.22,25c-2.46,0-4.23-1.33-4.23-3.57s1.31-3.48,4.86-4.06l3.79-.63v-1.1c0-1.82-1.29-2.94-3.45-2.94s-3.31,1-3.48,2.58Zm8.29,4.86V17.78l-3.4.58c-3,.51-3.89,1.46-3.89,3,0,1.7,1.31,2.55,3.21,2.55A4,4,0,0,0,110.64,20.14Z"/><path class="header__merakiLogo--green" d="M115.32,24.64V7.13h1.31v10L122.69,12h1.78L118,17.51l7.3,7.12h-1.77L116.63,18v6.69Z"/><path class="header__merakiLogo--green" d="M126.92,8.93V7.13h1.58v1.8ZM127,24.64V12h1.31V24.64Z"/></svg> </div> <div class="content__container"> <h1 class="content__title">Page not found</h1> <p class="content__primaryText">The page you are looking for may have been moved or does not exist.</p> <p class="content__secondaryText">To log in to the Cisco Meraki Dashboard, go to <a href="https://dashboard.meraki.com">https://dashboard.meraki.com</a>.</p> </div> <div class="footer__container"> <span id="footer" class="footer__text">© Cisco Systems, Inc.</span> </div> <script type="text/javascript" charset="utf-8"> //<![CDATA[ (function () { var year = new Date().getFullYear(); document.getElementById("footer").innerHTML = '© ' + year + ' Cisco Systems, Inc.'; })() //]]> </script> </body> </html>

sungod · ‎May 21 2021

Have you looked at the return data? It is an array of zero or more clients, if you want client count, you simply count the clients in the return data.

sungod · ‎May 21 2021

Depends exactly what data you are looking for. You can use a call that does allow both t0 and t1 to be specified, then you have flexibility over when you run things, for instance... https://developer.cisco.com/meraki/api-v1/#!get-network-clients-usage-histories ...if a client has usage in the period, it clearly was connected.

sungod · ‎Apr 29 2021

Switch port PoE use is one of the things we report for our customers. Use this call https://developer.cisco.com/meraki/api-v1/#!get-device-switch-ports-statuses Port PoE usage is reported as Watt-hours consumed over the timespan specified when making the call. So if you want average power usage over period T, set the timespan to T and normalise to Watts by Wh/T (with T in hours). Note that this call doesn't use a t1 parameter, so whether you use t0 or timespan it will always return data looking back from the time of the call. I just run it daily at the same time to build up long term stats. Afaik switch PoE budgets still aren't visible, but it's simple enough to use a look-up table, just need to remember to add new switches to the table when they are released.

sungod · ‎Apr 14 2021

Hmmm, I just tested as it looks related to another API problem, it is indeed returning nulls, looks like a fault. Below is cut & paste (part-masked serial numbers) from devnet test page https://developer.cisco.com/meraki/api-v1/#!get-network-wireless-devices-latency-stats with timespan 86400 on a network with active APs that clearly should have stats... Response: 200 OK DataInfo Copy[ { "serial": "Q3AJ-TC.......", "latencyStats": null }, { "serial": "Q3AJ-BP.......", "latencyStats": null }, { "serial": "Q3AJ-YW.......", "latencyStats": null }, { "serial": "Q3AJ-TD.......", "latencyStats": null }, { "serial": "Q3AJ-DE.......", "latencyStats": null } ] It looks just like the problem that exists with the getNetworkWirelessDevicesConnectionStats call returning nulls... https://community.meraki.com/t5/Developers-APIs/Has-getNetworkWirelessDevicesConnectionStats-stopped-working/td-p/107333/jump-to/first-unread-message Note that both calls are requesting wireless stats network-wide, both are returning device IDs ok, but with nulls instead of the appropriate data, imo that suggests something is broken in the v1 API server that both calls rely on. The getNetworkWirelessDevicesConnectionStats call has been broken since 6-7 January, that is over four months now. Latest Meraki support feedback from internal teams is that "this issue is not treated with high priority". Fyi the only workaround I found is to rewrite to use the equivalent v0 API call, but that's not a long term solution and of course it gets messy having to mix v0/v1 APIs in applications Can any of the Meraki people say what expectation customers should have for v1 API calls being fixed?

sungod · ‎Apr 12 2021

Well, you could get the same value, but to do that you would need to take your sample at the same time(s) that the Overview figures are calculated, I'd guess this is done daily. But unless you happen to take a sample at the same time, the API will always get a result that is equal or greater than shown in Overview due to usage since the daily sample. This assumes all my guesses about how it works are close enough 😊

sungod · ‎Apr 7 2021

Based on what I see on some of our demo networks, the network usage figure on the Organization->Overview is the sum of all traffic over seven days, probably a cached value rather than real time, i.e. updated on some schedule, not when the page is redrawn. You could use https://developer.cisco.com/meraki/api-v1/#!get-network-traffic with timespan set to 604800 then simply sum the sent and recv for each application. Note that this call requires traffic analysis with hostname visibility to be enabled on the network(s) you want to get data for. I just tested it on one of our lab networks... Sum of API data 48,986,330 KB Figure in overview 46.84 GB, it's lower, but if it is a cached value that would be expected. Btw my experience is that trying to externally match figures displayed by orchestrator screens (not only Meraki) is often futile... i) The orchestrator is unlikely to be using the external API, nor the basis of internal calculations publicly documented. ii) The orchestrator may not be showing the correct numbers anyway! There's a non-Cisco orchestrator that has been misreporting traffic for years, by huge amounts, both in its user interface and in what is accessed via API, it took a while before the vendor accepted our evidence, even longer to find the cause and fix it.

sungod · ‎Apr 5 2021

Can any of the Meraki people on this site get an update on this? It is now almost four months since this API call stopped working in V1 (the equivalent V0 call works). There's been a case open since January but support give no updates.

sungod · ‎Apr 5 2021

In Dashboard and the current API I believe the only power consumption data is for switch port PoE... powerUsageInWh ...in the https://developer.cisco.com/meraki/api-v1/#!get-device-switch-ports-statuses call. We gather this for customer reporting to show daily switch PoE maximum vs. switch PoE budget (needs a manual lookup table of budget for each model), used/free ports are also tracked plus warnings and errors. In our case this is for capacity planning rather than tracking consumption over time, for that you'd need to sample shorter periods.

sungod · ‎Mar 8 2021

You seem to be running once per minute with an 800 second lookback from 'now', the only Nones that I see in your sample occur in the last record. I'd guess the most recent data have not yet reached the cloud. If you instead use a t0-t1 window that starts, say, 20 minutes ago and ends 5 minutes ago, do you still get the Nones?

About sungod

sungod

Community Record

Badges