Community Record
542
Posts
631
Kudos
58
Solutions
Badges
5 hours ago
4 Kudos
How about https://developer.cisco.com/meraki/api-v1/get-organization-appliance-uplink-statuses/ Only need to make one call per org, it includes info on whether a device in HA is primary.
... View more
11 hours ago
2 Kudos
On your timing questions, the answer to both is 'sort of'... Queries/responses take a finite time, some queries may return multiple pages of data, each page counting as a query. There's also the extra ten-query 'burst' allowed in the 'first second', in that situation you get sixty queries in five seconds. I don't recall seeing how the first second is determined, perhaps some period without a query resets the timing. Personally, I don't worry about the rate limit, just follow the retry protocol for handling 429 status, one easy way to do this is to use the Meraki Python library.
... View more
2 weeks ago
1 Kudo
I suggest post on the EA group that you are interested in this feature and would like to help with testing/feedback if possible. On other EA calls there has been opportunity to do this.
... View more
3 weeks ago
You can make a feature request in Dashboard. Otherwise, your options are to contact your Cisco/Meraki account manager(s). Tbh it sounds like CC is where the issue is, so you could also try opening a support case on CC.
... View more
3 weeks ago
You'd need to go through the API documentation in detail and see what's there, possibly also experiment. Overall I think there's not yet full support for IPv6 across the API, it may be you won't find all you need (which then takes you back to making feature requests.)
... View more
3 weeks ago
Yep, loads of API calls... https://developer.cisco.com/meraki/api-v1/api-index/
... View more
4 weeks ago
That'd be a new feature request, you can try suggesting it via the feedback button in Dashboard. As things are, you'll need to look at device-family specific calls to get the info.
... View more
4 weeks ago
2 Kudos
I'm not sue https://developer.cisco.com/meraki/api-v1/get-organization-devices/ gives IPv6 details. You don't say what type of Meraki device, but sounds like it may be MX. These API calls get/update MX WAN interface settings, including IPv6... https://developer.cisco.com/meraki/api-v1/get-device-appliance-uplinks-settings/ https://developer.cisco.com/meraki/api-v1/update-device-appliance-uplinks-settings/ Can't help with Catalyst Center itself, but back when it was called DNA it did not support many Meraki features, it might be you cannot do everything you want from CC.
... View more
4 weeks ago
3 Kudos
This is an Early Access call, it may be that it's still being tweaked/debugged. I'd post the query in the API Early Access group https://community.meraki.com/t5/API-Early-Access-Group/gh-p/api-early-access if you're not a member you can request access. There's also a direct feedback email available, you'll see it if/once you have group access.
... View more
Nov 12 2024
8:45 AM
1 Kudo
For the EA forum, you need to send a request to join, I guess it must tell you how here... https://community.meraki.com/t5/API-Early-Access-Group/gh-p/api-early-access ...I can't see the way to make the rquest as I already have access, I think it is easy to do. But the EA API itself is open, and documented here... https://developer.cisco.com/meraki/api-v1/api-reference-early-access-overview/#interactive-api-docs You will need to go into your Dashboard Organization->Early Access settings and enable Early API Access (plus any other EA features you may want to try).
... View more
Nov 12 2024
7:47 AM
1 Kudo
There are a few calls related to wireless port profiles, for instance... https://developer.cisco.com/meraki/api-v1/create-network-wireless-ethernet-ports-profile/ Don't think there's anything published for DCD so far. It may be worth looking the early access API and giving feedback if there's something like this that could sensibly be added to an EA call before it gets 'frozen' for release.
... View more
Nov 11 2024
6:13 AM
I just tested, it works fine for me. Here's my test script... import os
import sys
import meraki.aio
import asyncio
ORG_ID = os.environ.get("PARA0")
API_KEY = os.environ.get("PARA1")
async def main():
# Instantiate a Meraki dashboard API session
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,
maximum_concurrent_requests=5
) as aiomeraki:
networks = await aiomeraki.organizations.getOrganizationNetworks(ORG_ID, perPage=1000, total_pages="all")
for net in networks:
print(f'{net["id"]} {net["name"]}')
devices = await aiomeraki.organizations.getOrganizationDevices(ORG_ID, networkIds=["put the ID here"], perPage=1000, total_pages="all")
for d in devices:
print(d)
sys.exit(0)
if __name__ == '__main__':
asyncio.run(main())
... View more
Nov 3 2024
6:51 AM
2 Kudos
networkIds is keyword argument, try... response = dashboard.organizations.getOrganizationDevices( org_id, networkIds=['id1'])
... View more
Oct 29 2024
7:16 AM
2 Kudos
I've been looking at how to replicate our existing reporting/analytics without polling using getOrganizationDevicesStatuses but it's not straightforward... The replacements don't include publicIP, which is useful for simply inferring whether it's a single device outage, or one where a device/WAN/other failure is taking out multiple devices. I don't see another simple way to get the publicIP, calls that get it for MX/Z are no use as not all devices are behind an MX/Z. Am I missing an easy way to get publicIP? If not, can it be added at least to the replacement operation getOrganizationDevicesAvailabilities it shouldn't break anything. Also, one of our main use cases is contractual SLA analysis/reporting, which typically is calendar month, sometimes also by local timezone. I'd certainly like to move from our current polling approach to a monthly one, but for that a lookback of at least a couple of days more than 31 days is needed to allow for timezones and any transient problems that delay colection, otherwise we lose data. The https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities-change-history/ documentation says has a maximum lookback of 2678400, exactly 31 x 24 x 60 x 60, meaning that unless we ran it at 235959 on the last day of the month for each timezone, it's possible to lose visibility. In practice we run 'monthly' data gathering early UTC on the 2nd of the following month, simply allowing for where we need to report by local timezone and to giving some buffer in case of a problem. The 'easy' way out would be to run it daily instead of monthly, but IMHO it'd be better if this and other calls with one-month lookback hard limits were extended by a couple of days to fit better with the common customer desire to have monthly reports and the need for a bit of contingency 😀
... View more
Oct 28 2024
7:09 AM
The MT12 leak detector might work. It presumably works by sensing the change in current through the sensor cable, so I'd think you could use it as an open/closed detector.
... View more
Just a fyi for anyone seeing similar, the issue has bubbled through the layers of support and is now with the Meraki engineering team.
... View more
Oct 27 2024
2:48 PM
1 Kudo
Absolutely with you on the need for a better admin-org-token scheme! For other Cisco (non-Meraki) work I've currently got 20+ emails, similar for another vendor's API, fortunately I can do it with aliases to my base email, but it's still a pain, especially with TFA.
... View more
Oct 27 2024
1:32 PM
3 Kudos
I had a similar problem with one of my admin accounts getting locked. After digging into things I found it was due to a compromised server on AWS, nothing to do with ourselves/customers/Meraki. It looked like it was being used to try to brute force the password, which would never work due to TFA, but of course my account was getting repeatedly locked. Amazon would not help, no response from the owner of the compromised server, and Meraki said they couldn't do anything. In the end I gave up on the account and used another email address, though after a couple of years the attempts stopped and I could use the old one again... AFAIK there's nothing visible via API to diagnose this issue. But if you're sure it's an org-specific access issue, not an external attack, i'd think you could use these endpoints to figure out which org is the issue... https://developer.cisco.com/meraki/api-v1/get-organizations/ https://developer.cisco.com/meraki/api-v1/get-organization-admins/
... View more
Oct 25 2024
1:52 AM
That's a good shortcut, do you know how things work if there is a mix of newer and 'legacy' devices on a network? as they may actually be running different firmware versions. APs for instance, according to current release notes, legacy models will be running 26.8.3 even if the wireless network is upgraded to 30.7. I'm not sure what the legacy ones report, is it the version applied to the network, or is it the version they are actually running?
... View more
Oct 24 2024
9:10 AM
Congratulations @thomasthomsen !
... View more
Oct 23 2024
7:12 AM
Hmm, that's quite an old issue in the post you linked, I'm surprised it's not fixed yet. I suggest open a support case - if it is still not fixed, perhaps they can advise a better workaround.
... View more
Oct 22 2024
9:58 AM
2 Kudos
It depends on what you mean by 'network', and where you want to measure usage. If, for instance, each 'network' has an MX or Z with one or more WAN connections, and you want the send/receive usage on those WAN connections, then you can use... https://developer.cisco.com/meraki/api-v1/get-organization-appliance-uplinks-usage-by-network/
... View more
Oct 21 2024
1:12 AM
2 Kudos
Agree with @PhilipDAth a test-wait loop is the safest approach. Certain actions take a while to propagate. I'd loop on a read endpoint like... https://developer.cisco.com/meraki/api-v1/get-network/
... View more
Oct 18 2024
2:14 AM
3 Kudos
Do bear in mind that 'read-only' access is not totally read-only - a read-only account still allows port-cycling and cable-test operations to be performed on switch ports. For instance, cycling a port will result in downstream devices will losing connectivity and PoE. We had a customer find this out the hard way. I.e. you still need to be careful about granting read-only permission and caution users about these operations.
... View more
I got diverted by other things, but more recently the problem was even more apparent, see... https://community.meraki.com/t5/Sensors/Dashboard-reporting-all-MT40s-as-Dormant-Oh-no-they-re-not/m-p/249227#M1021 I opened a case, eventually they accepted the devices are acting as described. I've also supplied a lot of data from our own monitoring (via API) showing the extent of the problem. No sign of any reason/resolution so far. If you are seeing the same sort of problem, please open a case as that'll add more data for support to try and figure out what's wrong.
... View more
My Accepted Solutions
Subject | Views | Posted |
---|---|---|
754 | Oct 8 2024 4:20 AM | |
557 | Sep 27 2024 2:26 AM | |
280 | Sep 26 2024 5:25 AM | |
312 | Sep 19 2024 6:05 AM | |
632 | Sep 2 2024 2:45 AM | |
542 | Aug 23 2024 7:49 AM | |
782 | Aug 20 2024 5:56 AM | |
766 | Aug 8 2024 7:33 AM | |
1073 | Jul 25 2024 8:08 AM | |
1349 | Jul 18 2024 10:48 AM |
My Top Kudoed Posts
Subject | Kudos | Views |
---|---|---|
13 | 1567 | |
9 | 6649 | |
8 | 1447 | |
7 | 481 | |
7 | 542 |