Hello. Thank you for the information. When you say we need to open UDP port 443 on the MX, it's in the case the MX is behind a Firewall right ? It MX is directly connected with a public IP, it's not necessary.   We have the same issue, but MX is directly connected to the Internet. ... View more

Hello.   I received the same email. I tried to look for any v0 call in my code, but nothing.   Then I used the API call "getOrganizationApiRequests" , with option version = 0, to check any usage with this version.   Surprisingly, I have a lot ! But it seems it's a mistake :   { "adminId": "xxxxxxxxxxxx", "method": "GET", "host": "nxxx.meraki.com", "path": "/api/v1/organizations/xxxxxx/appliance/trafficShaping/vpnExclusions/byNetwork", "queryString": "perPage=1000&startingAfter=xxxxxxxxx", "userAgent": "python-requests/2.31.0", "ts": "2024-01-22T01:44:45.110913Z", "responseCode": 200, "sourceIp": "xx.xx.xx.xx", "version": 0, "operationId": "getOrganizationApplianceTrafficShapingVpnExclusionsByNetwork" }     Apparently, every "getOrganizationApplianceTrafficShapingVpnExclusionsByNetwork" call is categorized as version 0, even if in the path we clearly see it's v1.   I'm wondering if there are other calls impacted, and maybe Meraki checks for each Org if there is any v0 call the same way, and as there are some wrong categorization, that's why we receive these emails ? ... View more

Hello,   We already use action batches when possible, and also, we monitor API usage vs response codes, we have reports for this. This is what allowed us to found out that we needed to optimize and limit unnecessary calls.   Again, today, it seems ok, and doing these 1000+ calls is not a problem, but if we just thought "Ok, limit rate is high, we will not face any issue", we would definitely face many issues by now, this is why we prefer to optimize every usage.   And even if there would be a "no limit rate", I think it's always better to optimize when possible. If I can do 1 call instead of 1000+, that's easier to code, faster (for the user), less CPU time on both sides (Green IT and scalability), etc. Better for everyone 🙂    Anyone on Meraki side to check feasability to return full firmware version info in the Org Wide API call ? ... View more

Hello @John_on_API ,   I have some doubts regarding some options, not sure to understand correctly.   I have a list of actions, that I then split in different batches per network. For example, per network  : Create Vlan Change DHCP option Activate VPN   I want : - each batch to run as asynchonous, because each action depends on the previous one, and if there is an error, it must be canceled. - batches to run all at the same time, to make it faster, as there are not dependant on each other.   I use :  batch_helper.BatchHelper(dashboard, orgID, batch_action_list,actions_per_new_batch=3,synchronous_new_batches=True)   linear_new_batches is set to False by default, so batches should run at the same time ?   confirmed_new_batches is set to True by default. It means  that as soon as the batch is submitted, it is started, right ? If I set to False, it will instead wait for all my batches to be submitted to start them ? With the limit of 5, better to let it to True I guess.   Is it right ? Thank you for your time ... View more

You're right. That is also not perfect 😅  If there could be an option on the dashboard to have an exact match as well, like putting in double quotes for example, that would be awesome. ... View more

@CN this is so cool, thanks for sharing and thanks for introducing the idea to us in the first place 🙂   Here's the abstract to save you a click (though, of course, the rest of the paper is worth a perusal and they'll be updating with new info as it becomes available). So exciting to know we have been part of such an impactful project:   ... View more

There is a lot of stuff here as well: https://meraki.cisco.com/collateral/  ... View more

There are a couple of ways to handle tags (The article assumes more than one MX, so the location tags are never removed/deleted hence they always exist in another network).  You can accomplish this by having an empty network hold the tags so they always exist.   1. Create a VPN config holding network:  (Network itself should not contain an MX - Good in the case only 1 MX has VPN config) Organization > Create Network > Select Security appliance name "VPN Tag Hold" 2. Add a tag to the network ^ ie. [location]_primary_up and [location]_backup_up Never remove the tags from this network, so they always exist. 3. Apply this tag to the multiple Non-Meraki Peers availability section This will hold the Non-Meraki VPN peers config as you switch real network availability tags as it cannot be empty. Then you can assign and remove the tags from the live MX network to fail between them without the error they don't exist. The other option would be to have a hold network and a tag per location that represent the MX location itself.  You would then have a VPN configuration in the availability will always have a holding tag from the network that's not used such as vpn_tag_hold (This merely maintains the configuration available in the site to site vpn Non-Meraki peers section.  From there you could always just add/remove the specific network's availability tag (ie. if primary is down, you'd use [location]_backup_up tag in the 2nd 3rd party peer however if the primary is up this config would be removed and you'd have [location]_primary_up in the 1st 3rd party peer availability section)   Cheers, -Raul ... View more