I just asked for an update on my case.  The latest note in it from January 2022 from Meraki Support was they are still waiting to hear from the developers. What's sad is when I first raised awareness about this issue in the forum, a Meraki engineer on the forum said it is not an API bug, but how they are reading the data.  He said he added a note to my case, but I never saw it.  Perhaps, it was in an internally visible only field.  I've checked it using the interactive documentation and get the same result.  Maybe now with multiple people raising the issue, we can get some actual traction on it.  If the can't provide reliable data to with that API endpoint, they should disable that endpoint until they fix it.   ... View more

I've had a open since 4/26/2020 about that end point returning inconsistent results. I run a weekly report and every week there are usually about 100 of our 600 networks that return 500 for all the values.  I haven't spot checked it recently, but previously, a network where that happens one week would show the correct values the following week.  But every week it is always around100 networks that show the incorrect values.  No progress so far on this issue. ... View more

Do you have the device model number in the spreadsheet?  If so, determine the device type by the first two characters of the model field, MX, MS, MR, etc.    ... View more

@ByronZ, @John-K  My observation when receiving "Not running configured version" coincides with a device that has been offline a while and is now in a "dormant" status.  Use the https://developer.cisco.com/meraki/api-v1/#!get-organization-devices-statuses API call to see device statuses for the organization.  We've been doing some hardware upgrades and in some cases I've found the old equipment hasn't been removed from the network yet or the network is test network and only gets brought online at various times.  As a result, these devices show in dormant status and the firmware shows as "Not running configured version".   See if that is the case for you. ... View more

That was my point - I was correcting your earlier statement "Since Templates are not returned when using the call Get Orgs Network".   Agreed, you cannot update the Template notes, currently.  I didn't say you could.   There are a lot of settings that are set by templates that you cannot update via the API in networks bound to a template.  This is an area where the API documentation is lacking - those exceptions should be clearly documented, but currently they are not.  You only discover it when you try to use an API call and you get an error message stating something to the effect "templated networks are not supported by this endpoint".   ... View more

The Network notes field of a Template is inherited by the networks bound to the template.  You may have noticed the templated networks do not have a visible Network notes field in the Dashboard UI.  However, that field shows up in the API data of the network and it contained the Template Notes contents.   @RafaelL - The ConfigTemplateId key/value is returned by that API call if the network is bound to a template. The following line of Python code will assign templateID the value of configTemplateId if the key is present, otherwise, it assigns the value "unbound".   templateID = network.get('configTemplateId', "unbound") If you want to obtain the organization's templates, you have to use this API call.  And, as you can see you receive very little template information from that call.  https://developer.cisco.com/meraki/api-v1/#!get-organization-config-templates   Larry ... View more

The API team made an undocumented change and introduced a bug in November 2021 the week of Thanksgiving that changed the vlan return data type from integer to string.  I confirmed it via the live documentation tool so I knew it wasn't the Python module that was doing it.  When I caught it in my weekly report data the following week, I opened a support case with all the documentation on it I could put together on what had happened to point them to the source of the issue.  I believe it was in February when I was officially informed by support they weren't going to fix it.  Instead of fixing the bug, they just changed the documentation to match the mistake.    When dealing with vlans, the vlan number is an integer, but when dealing clients the vlan is now a string. Does that make any sense?  I had to rewrite portions of my weekly report program to deal with the mixed data types so it would work until they corrected it and so it would continue to work when they corrected it, which they chose not to do.  I had to add the extra code because they can break things overnight, but it takes them at least two weeks and usually more to correct mistakes.     They tried to pull that on vlans with the Python APIv1 module when it was in beta and I called it out.  If you return me a value as an integer, you better accept it back as an integer.  That issue was corrected in the module in the next  beta release.     Data types should be kept consistent across the board plain and simple.  Mixing data types only adds frustration and unnecessary code to address it.  ... View more

Not yet, other non-programming projects have taken priority.  I tried to work on it last week, but every time I started, I got interrupted.  Hoping this week is better and I can get started on it and finish it. It is the last big program I have that uses APIv0. ... View more

That's because the subnet size is dictated by the template configuration and the network inherits that definition.  You may need to re-think your template definitions.  If you are trying to do a one size fits all template and use variable sized subnets per site, it won't work.  We have regional templates named with suffixes of -Large, -Medium, -Small , and -Tiny configured with corresponding subnet sizes.  We have /16 subnets defined per region that we assign the site subnet blocks for the vlans for each site in our IPAM system and configure the gateway IP's on the appliance vlans.     I have a Python program I will be updating in the next couple weeks from API V0 to V1 so I will see if V1 handles it differently than V0 did.  In API V0, I was able to update the vlan subnets of a network using the Meraki API package.       ... View more

Have you tried to use this endpoint? https://developer.cisco.com/meraki/api-v1/#!update-network-appliance-vlan     ... View more

@Willem_vd_Pas - If you are referring to changing this on Layer 3 switches, it was added in API V1.  https://developer.cisco.com/meraki/api-v1/#!update-device-switch-routing-interface-dhcp Description: Update a layer 3 interface DHCP configuration for a switch   Larry     ... View more

The API documentation examples and real world return values often don't agree as you noted.  I encountered that also with the LLDPCDP call.  That's why I love the interactive documentation so I can try it and see what the data really looks like before I start writing code to process the return values.  Additionally, the API data does not always match the Dashboard.   Take care, Larry  ... View more

Why wouldn't the code below work?  I just threw it together to answer your question.  It is how I would do it in Python 3.82 using Meraki API 0.100.1.  This would update the DHCP relay servers on all vlans - adjust accordingly to fit your need. I have used the update vlan API call to update vlans on MX appliances.  You may want to add some error checking logic.  Replace ['se.rv.er.01, se.rv.er.02'] with your new server IP's. I would test it on one network/vlan first to be sure you get the desired result and confirm the new setting works, ie. no typos on the server IP's.    # no api_key specified below it uses environment variable "MERAKI_DASHBOARD_API_KEY" Merakiclient = meraki.DashboardAPI(api_key='',                                       base_url = 'https://api.meraki.com/api/v0',                                     wait_on_rate_limit = True,                                     maximum_retries = 2,                                     log_file_prefix = __file__[:-3],                                     log_path='') orgs = Merakiclient.organizations.getOrganizations() orgid=orgs['id']  # use above API getorgs() call or code the orgid here newRelayServers = ['se.rv.er.01, se.rv.er.02'] networks = Merakiclient.networks.getOrganizationNetworks(orgid) for network in networks:     print('Processing network: ',network['name'])     vlans = Merakiclient.vlans.getNetworkVlans(network['id'])     for vlan in vlans:         print('Processing Vlan: {} - {}'.format(vlan['id'], vlan['name']))         if vlan['dhcpHandling'] == 'Relay DHCP to another server':             result = Merakiclient.vlans.updateNetworkVlan(network['id'], str(vlan['id']),                                                      dhcpRelayServerIps = newRelayServers)             updatedVlan = Merakiclient.vlans.getNetworkVlan(network['id'], vlan['id'])             print('Vlan {} DHCP Relay Servers after update: {}'.format(updatedVlan['id'],                                                          updatedVlan['dhcpRelayServerIps'])) Larry ... View more

Regarding pinging the clients, use the "get clients" API call to obtain a list of clients in the last x time frame.  When I did this, I used 2 hours (7200secs).  If you are using Python, use the ping() function from the Ping3 package on Pypi. Adjust the following accordingly for your purpose.   clientvalidationlist = [] clients = Merakiclient.clients.getNetworkClients(network['id'], timespan = 7200) for client in clients: if ping(client['ip']) != None: clientvalidationlist.append({'mfg': client['manufacturer'], 'desc': client['description'], 'ip': client['ip']}) print('Clients responding to ping: {}'.format(len(clientvalidationlist)))   later in the program use the same concept, except use "for client in clientvalidationlist".   ... View more