Meraki

sungod · ‎Jul 20 2023

Catching up on testing after covid, this post has been edited as I went along... The old/new details arrays can differ in size, either can be zero, I've not seen either >2 The only time I see size >1 is where the first element just says it's an alert, and the second says what the alert is/was. As the call is GA now, probably too late, but if it were me I'd have simplified and put the alert description in the value rather than have detail arrays. Or are there other instances where array will be >1 ? total elements timestamp modell old name old value new name new value 4 2023-07-19T21:17:25.795000Z MS350-48LP status alerting status alerting 4 2023-07-19T21:17:25.795000Z MS350-48LP alert DHCP failure on management VLAN alert Disabled gateway (bad DNS) 4 2023-07-19T21:17:25.779999Z MS350-48LP status alerting status alerting 4 2023-07-19T21:17:25.779999Z MS350-48LP alert DHCP failure on management VLAN alert Disabled gateway (bad DNS) 3 2023-07-19T23:59:07.091000Z MS350-48LP status online status alerting 3 2023-07-19T23:59:07.091000Z MS350-48LP alert DHCP failure on management VLAN 3 2023-07-19T23:59:07.036999Z MS350-48LP status online status alerting 3 2023-07-19T23:59:07.036999Z MS350-48LP alert DHCP failure on management VLAN 3 2023-07-19T21:19:29.835000Z MS350-48LP status alerting status online 3 2023-07-19T21:19:29.835000Z MS350-48LP alert Disabled gateway (bad DNS) 3 2023-07-19T21:19:29.818000Z MS350-48LP status alerting status online 3 2023-07-19T21:19:29.818000Z MS350-48LP alert Disabled gateway (bad DNS) 3 2023-07-19T21:18:30.970999Z MX67 status alerting status online 3 2023-07-19T21:18:30.970999Z MX67 alert Disabled gateway (bad DNS) 3 2023-07-19T21:18:15.997999Z MX67 status offline status alerting 3 2023-07-19T21:18:15.997999Z MX67 alert Disabled gateway (bad DNS) 3 2023-07-19T21:17:25.653000Z MS350-48LP status alerting status online 3 2023-07-19T21:17:25.653000Z MS350-48LP alert DHCP failure on management VLAN

sungod · ‎Jul 7 2023

Tbh I would not worry about this. Just wrap the 429 Retry-After logic around your API calls and retry until success, it works extremely well. Then the rate limiting is effectively hidden and you don't have to worry about multiple independent callers getting in each other's way.

sungod · ‎Jun 29 2023

There does seem to be a direct mapping from serial number to model, no formal info though, I think you'd need to maintain your own look-up table. https://community.meraki.com/t5/Security-SD-WAN/Serial-Number-Lookup/m-p/46655#M11682

sungod · ‎Jun 27 2023

I had a screenshot from the testing, it's not very exciting, Splunk is showing all the fields ok, same as I saw them using the test receiver, though they are shown alphabetically sorted by Splunk. Once we go live I think they may want to refine the body, but that's probably customer specific rather than to do with Splunk.

sungod · ‎Jun 27 2023

Hi, I don't have a test system either, am reliant on the customer checking things at their end, I'd used https://webhook.site/ as a test receiver to get things to point I was ready to test with the customer. As well as the header I used, they asked for some specific elements in the body, I don't think these are mandatory, just reflect the way they've set up Splunk for the various things they use it for. My guess is Splunk is so configurable that the body will often need adapting. { "index":"an ID the customer wanted", "source":"another ID the customer wanted", "sourcetype":"here they wanted Cisco-Meraki", "event":{ #in here I simply used the default Meraki template }}

sungod · ‎Jun 21 2023

lastReportedAt is the time that Dashboard last heard from a device. Not the time of the API call. There is no synchronisation of when devices and Dashboard communicate, each is a separate event, so each can have a different LRA time.

sungod · ‎Jun 20 2023

I had a customer request to send alert webhooks into Splunk. Couldn't find it documented, nor on this forum or Splunk's site, and searching only turned up a few people asking how to do it, I gave up and figured it out. To save time if you ever need to do it... Make sure Early API Access is enabled on the organization, this activates the "Add or edit webhook templates" feature on the Network-wide->Alerts page. To start with, create a new template (I suggest start by copying the Meraki one), then edit it to add a Liquid header with this key... Authorization ...and value... Splunk {{ sharedSecret }} ...note that there's a space after Splunk. Click 'generate preview' and you'll see... { "Authorization": "Splunk " } Back to the Alerts page, add your receiver's Name, URL, Shared secret, and choose the payload template you just created. Save and test.

sungod · ‎Jun 16 2023

You can use https://developer.cisco.com/meraki/api-v1/#!list-the-status-of-every-meraki-device-in-the-organization It returns all devices, including both members of MX HA pairs, if desired you can filter to restrict return info to appliances only.

sungod · ‎Jun 5 2023

That link is to a v0 endpoint, v0 is end of life, see... https://community.meraki.com/t5/Developers-APIs/Dashboard-API-v0-End-of-Support-Sunset-amp-Grace-Period/m-p/138696 I suggest update your code to use the v1 endpoints only... https://developer.cisco.com/meraki/api-v1/#!get-organizations https://developer.cisco.com/meraki/api-v1/#!get-organization-admins

sungod · ‎Jun 5 2023

There are other calls that have similar behaviour, it'd have been better to return a 'None' than an error. I'd guess the network needs to have at least one switch to have a topology, so using the call on a system manager network, or an appliance-only network would cause the error. There are two basic approaches... i) figure out the rule and do API calls and code to determine which networks you can make the topology call on, i.e. look for networks that include at least one switch. ii) just make the call on every network and ignore those that give the error. I'd say ii) is the simplest approach, also more reliable as you can be sure you didn't inadvertently miss any topologies.

sungod · ‎Jun 5 2023

There may be some limits but I don't recall seeing any documented. As you are seeing it on a 'small' request it sounds like there may be a problem with the service, it happens sometimes, usually resolves quickly. If the problem persists more than 24 hours or if it's urgent for you, I suggest open a case with Meraki support (use the Dashboard).

sungod · ‎Jun 4 2023

Try https://developer.cisco.com/meraki/api-v1/#!get-organization-devices Call it once, it returns an array of details for all your devices, there is a 'notes' element in the return data.

sungod · ‎Jun 1 2023

These are probably closest to getting you the info (I use these calls to create monthly data on link usage/quality)... https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-uplinks-usage-by-network https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-uplinks-usage-history https://developer.cisco.com/meraki/api-v1/#!get-organization-devices-uplinks-loss-and-latency But I don't recall any endpoints that return actual link speed, i.e. you can only infer up/down speed (or throughput) from usage over time. Note that the first of these calls is early access, so you need to enable EA on the organization(s) you want to use it on.

sungod · ‎Jun 1 2023

You do not use this call in real time. Once a day, or hour, it's a negligible impact on call rate. The correct way to use any API call is within the rate limit wait on retry mechanism, this is built into the Python library, just enable it, it works very well. If coding the API calls direct, see the API documentation on how to correctly handle 429 responses. Even if I issue a thousand API calls 'at once' using async, massively exceeding the rate limit, the result will be that the 429 errors are transparently caught and retries made as necessary, as far as my Python script is concerned all the calls succeed, it never got rate limited 😀 If you want real time details of API calls/responses, I would say the correct approach is to log them from the calling process.

sungod · ‎May 31 2023

Yes, for "API v2" I agree moving to a query-based approach would be good. Over time the v0/v1 approach results in a lot of endpoints, with overlap/inconsistency, and the need to sometimes use multiple endpoints to make what really could be a single query drives up the call rate.

sungod · ‎May 31 2023

Fyi there's already an endpoint for tracking API usage - we use it for a few purposes. https://developer.cisco.com/meraki/api-v1/#!get-organization-api-requests

sungod · ‎May 23 2023

Don't think the USB uplink generates any traffic unless the MX fails over, I've not seen any way to force it while the normal WAN link is working. https://documentation.meraki.com/MX/Cellular/3G%2F%2F4G_Cellular_Failover_with_USB_Modems I'd try this endpoint to see if the return data will help... https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-uplink-statuses

sungod · ‎May 22 2023

When there's a 429 return, the library code looks for Retry-After in the response headers and waits for that period. If that isn't in the headers, it waits for a random time between 1 and nginx_429_retry_wait_time (default is 60, you can specify a different value in the async block.) So the 429s happen, but they don't matter due to the retry mechanism If you're issuing a lot of calls at once, they'll get stacked up by the wait/retry, and maybe you'll hit some internal resource limit, might be worth making the the calls in batches of, say, 2,000.

sungod · ‎May 18 2023

In the async with block, add the parameters to wait on retry and set a high retry count - this is how I do it, seems reliable. The library will start adding waits before retry and the result is that it'll converge on running at about the natural rate limit. 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:

sungod · ‎May 18 2023

The API key permissions are explained here... https://documentation.meraki.com/General_Administration/Other_Topics/Cisco_Meraki_Dashboard_API The API key has the same permissions as the Dashboard account it belongs to.

sungod · ‎May 12 2023

Yeah, it's easy to miss as there's no consistency about how/where (or if) units are defined.

sungod · ‎May 12 2023

https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-uplinks-usage-history the description says that usage is in bytes. https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-traffic-shaping-uplink-bandwidth is kbps, to see this you need to scroll down to the 'schema definition' and expand it.

sungod · ‎May 11 2023

The default rule is the rule of last resort, you don't modify it, you override it with your own rule(s). Rules are applied in order until one matches, the default rule is the very last to be tried (assuming no other rule matched). If you create an SSID firewall rule deny-any-any-any, it will effectively replace the default allow-any-any-any (which will never be applied).

sungod · ‎May 10 2023

as the other endpoints are working and you're following the published documentation, i think it'd be best to open a case with support

sungod · ‎May 9 2023

In case it's because some endpoints are still not released, try enabling 'Early API Access' on the organization. Look in Dashboard --> Organizations --> Early Access --> Early API Access

About sungod

sungod

Community Record

Badges