Meraki

sungod

If you are managing the devices using Meraki Systems Manager, you could try https://developer.cisco.com/meraki/api-v1/get-network-sm-device-softwares/ If the devices aren't managed with SM there's no way through the API to access internal device info.

sungod

I just looked at it on one of the orgs we manage, it has > 400 networks and >3000 devices, month to date it is showing 0 rate limits on c. 250,000 calls. These calls are mostly issued in bursts at 0100 UTC. I'm surprised that there are 0 rate limits. Is it correct? Or maybe I have done an excellent job of making my scripts pace themselves 😀

sungod

Yeah, I know, but support always start with "prove it" and a default position that it's my fault. Before I go down that route, I'd first like to know if this is expected behaviour, and/or if others are not getting the same results.

sungod

With the deprecation and other issues affecting the getOrganizationDevicesStatuses endpoint, I'm finally getting round to redoing things to use getOrganizationDevicesAvailabilities and getOrganizationDevicesAvailabilitiesChangeHistory. In testing, getOrganizationDevicesAvailabilitiesChangeHistory is returning out of time-bounds data, and what is returned looks weird... Changes are returned that fall outside the bounds set by t0 t1, I'm using a one-day t0-t1 period in this instance. Most 'changes' that are returned are not changes, i.e. old/new status value are the same. This is from an org with a few hundred devices: t0 2025-02-18T00:00:00Z t1 2025-02-18T23:59:59.999999Z old status new status timestamp offline online 2025-02-16T08:01:00.121999Z online online 2025-02-17T08:01:48.007999Z online online 2025-02-18T08:02:06.424999Z The first two changes are out of t0-t1 bounds, the second two changes are not changes. I'm sure there was no such offline-online change on 16th on every device on every network. Almost every device returns a similar triplet It seems the endpoint is mostly returning spurious/bad data. I decided to try with other orgs. Overall, on three orgs the endpoint is returning only t0-t1 in-bounds data, on three it is behaving as above. But even on the three orgs where only data for 18th is returned, it is mostly 'changes' from online to online, it's not a change, why is it there? I really have no idea what, if any, data can be trusted from this endpoint. Is this expected behaviour? It is not as I expect from documentation. Can anyone from Meraki check/comment on this? I can PM org IDs.

sungod

According to v3 documentation, you should be getting an update for each network far more often (it says both once a minute and every 2-3 minutes). Tbh I would be wary of expecting the client counts from UI/API to match the location API, especially with small numbers of clients. As a next step, I'd try to physically verify the presence of active clients within range, and check if the location API is seeing them (and the UI/API too). Then if there's a definite discrepancy that can't be explained, open a support case.

sungod

If you are seeing 'warnings' in the log, that is irrelevant, it just means a 429 occurred and a retry will be performed, that is correct behaviour, it is not an error. An APIError exception is only raised when the Meraki library 429 retry limit is reached. See the Meraki library code... # Rate limit 429 errors elif status == 429: if 'Retry-After' in response.headers: wait = int(response.headers['Retry-After']) else: wait = random.randint(1, self._nginx_429_retry_wait_time) if self._logger: self._logger.warning(f'{tag}, {operation} - {status} {reason}, retrying in {wait} seconds') time.sleep(wait) retries -= 1 if retries == 0: raise APIError(metadata, response)

sungod

This detects 429, it's from a 4-year old snippet of code, but it's still running ok... try: # get list of devices on network connectstats = await aiomeraki.wireless.getNetworkWirelessDevicesConnectionStats(net['id'], t0=starttime, t1=endtime, ssid=netssid['number']) except meraki.AsyncAPIError as e: if "429 Too Many Requests" in str(e): #print(f'stats had a 429', file=sys.stderr) time.sleep(10 * attempt) continue print(f'mrssids stats Meraki API error: {e}', file=sys.stderr) return except Exception as e: continue # print(f'mrssids stats some other error: {e}',

sungod

If you go to the Network->General settings page and click 'validate' for the post URL(s) does it work? If only one network is affected, I'd be tempted to delete the post URL(s) and then add them back, to see if it 'resets' things. There are a few troubleshooting tips, but fairly basic. https://developer.cisco.com/meraki/scanning-api/troubleshooting-introduction/#scanning-api-data-is-not-received Otherwise, open a support case.

sungod

I've not used that endpoint, but I'd guess it's like others where using shorter time periods can sometimes give odd numbers. Using endpoints direct or with the library should make no difference, the library is just a 'wrapper' around the same endpoints. You open a support case from the Dashboard... click on ? at the top-right of the page, click "Get help & cases", click on the "API and webhooks" button, and there's a button on that page to submit a case.

sungod

We know it's not realtime data, but some cached values held in Dashboard, perhaps in 5 minute buckets. The switches will be reporting the Dashboard at some rate/latency, but that timing is not specified in the documentation. Is it the switches that update Dashboard strictly every 5 minutes? or is it that Dashboard gets data from switches 'whenever', and updates the bucket values ever five minutes? how big are the buckets? are they aligned to some epoch? or do they wobble around? It's unclear. In general I find it best not to rely on data for a recent point in time, or for any short period of time, like less than hours, as there's too much uncertainly, mainly due to lack of precise definitions in the documentation. But as you are getting a response that less happened between now and 35 minutes ago, than happened in a 15 minute sub-interval of that 35 minutes, it seems like reason to open a support case!

sungod

It's built into the Meraki Python library, you can see it in the github repository. If you mean the additional one I sometimes add to scripts that can generate lots of calls, just put the library call inside a loop, then use try/except to detect a 429 (i.e. the internal wait/retry in the library call has had too many retries), if there's a 429, wait a while, then do continue to restart the loop, if all went well, exit the loop. I use an increasing delay inside the loop, ten seconds first time, increasing exponentially to about 5 minutes, after that give up and exit as there's either a fault or someone else is constantly hitting the API and using up the call budget.

sungod

When I've tried maximum_concurent_requests it didn't seem to work. Don't worry about 429s, use wait/retry Of course if there are too many retries the Python library call will eventualy fail (with 429), so you just add an extra delay then try it again. This works for me across many organizations, some with hundreds of networks and thousands of devices, i.e. a lot of concurrent calls, and of course a lot of 429s, which are not a problem as they are handled as above.

sungod

Never bothered to use semaphores. The wait/retry is generally enough. But as I said in another post, if I know there'll be large numbers of concurrent calls, I just break the list into smaller chunks to avoid excessive load on the service. It's a simple method and works at scale.

sungod

Initialising aio per-call sounds likely to cause problems. This sort of thing is how I generally do concurrent calls with aio, here on a list of networks, each instance of the called function then each does a request on one network. # process eligible networks concurrently networkTasks = [processNetworkAppliances(aiomeraki, net) for net in applist] for task in asyncio.as_completed(networkTasks): await task This and all other aio stuff happens inside a single async block... async def main(): # any set-up stuff here async with meraki.aio.AsyncDashboardAPI( api_key=API_KEY, base_url='https://api.meraki.com/api/v1/', print_console=False, output_log=False, suppress_logging=True, wait_on_rate_limit=True, maximum_retries=100 ) as aiomeraki: # everything using aio goes in here # aio stuff is finished, do whatever happens next, if anythng

sungod

The Meraki Python library call does the wait on rate limit itself. You specify maximum retries 10, so as long as the library call needs fewer retries you would not get a 429 exception. I.e. ideally you should not need to do the extra wait/retry in your exception handler. At a high enough rate, I think the 429 mechanism breaks down, so if I know I'll be exceeding the rate limit I tend to add code to limit concurrent calls and/or add some additional back-off/retry that increases retry time exponentially.

sungod

That endpoint returns a maximum of 50 records per call, are you following the pagination process to get all the pages? https://developer.cisco.com/meraki/api-v1/pagination/#pagination If you are using Python, the Meraki Python library can handle pagination for you... https://github.com/meraki/dashboard-api-python

sungod · ‎Jan 28 2025

You can use https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities/ to get most recent status. For status change history over a period of time, use. https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities-change-history/ Both allow you to filter responses to only include appliances. You can use the data from the combine calls to calculate device availability over time.

sungod · ‎Jan 27 2025

Sorry, I pasted the wrong endpoint first time, see the updated posting.

sungod · ‎Jan 27 2025

You can use https://developer.cisco.com/meraki/api-v1/get-organization-switch-ports-statuses-by-switch/ to get all the current port details. Then parse that to choose which ports to shut down... https://developer.cisco.com/meraki/api-v1/update-device-switch-port/ The update action can also be done in an action batch to speed things up. But there's a risk if the port is used but not currently connected that you'd block a needed port, you'd really need to keep some table of 'protected' ports to leave alone, or tag such ports and look out for the tag when deciding. I don't think the statuses endpoint gets the tags but you could use https://developer.cisco.com/meraki/api-v1/get-organization-switch-ports-by-switch/ to retrieve them. Bear in mind that if an attacker has physical access, they could simply pull the cable from a live port and still gain access that way. Using access policies would be better, see... https://documentation.meraki.com/MS/Access_Control/MS_Switch_Access_Policies_(802.1X)

sungod · ‎Jan 23 2025

I use the getOrganizationDevicesAvailabilitiesChangeHistory endpoint, it does work. It has two separate documentation entries, one in Early Access, I'd guess the endpoint is being tweaked. https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities-change-history/ https://developer.cisco.com/meraki/api-v1/api-reference-early-access-api-platform-monitor-devices-availabilities-changehistory-get-organization-devices-availabilities-change-history/ Using device availability is the option I'd recommend. You do need to periodically grab the status 'now', then you can use the change history to calculate from that point. This gets current status, updated every 5 minutes... https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities/ If you only want to check site reachability [defined as an MX responding], you might find it simplest to just ping your sites every 60 seconds.

sungod · ‎Jan 22 2025

I suggest open a support case with Meraki as the MT issues were resolved ok for us.

sungod · ‎Jan 21 2025

Null values are a characteristic of some calls, sometimes in surprising contexts that need detecting/handling to avoid problems in code using the API. For instance, an unconfigured device name that defaults to MAC address in Dashboard UI returning a null name in the API. You could open a support case about the undocumented element. I'd guess that it would have non-null values if the config change targeted a specific client, you could try making such a config change and see what happens.

sungod · ‎Jan 15 2025

Best is to read through the API documentation, there are several endpoints for this sort of info, I use getNetworkWirelessDevicesConnectionStats to get network wide details, and use that to determine the different failure types to present in summary form. In the instance you mention of a network-wide issue, that is something you would need to detect and manage - one AP showing issue == it's the AP, all APs showing the issue == it's the network/other necessary service like DNS, RADIUS etc. If you use the Meraki Python library async I/O calls, you can speed things up a lot, even with hundreds of sites and thousands of APs you can gather the data pretty fast using the call I mentioned.

sungod · ‎Jan 12 2025

I'd think you would need to use a series of calls, for instance... get list of networks in org iterate over list of networks with... https://developer.cisco.com/meraki/api-v1/get-network-wireless-clients-health-scores/ ...to get clients, there could be a LOT select the ones with a imperfect score, and iterate over that list with... https://developer.cisco.com/meraki/api-v1/get-network-wireless-client-connectivity-events/

sungod · ‎Jan 8 2025

When the library had a different problem, I made my own version of rest-session.py, it was quicker that trying to get it fixed by Meraki. Might be simplest to do the same, alter it to behave the way you want.

About sungod

sungod

Community Record

Badges