Solved
Yes, in my case the static route is defined in the hub. However that shouldn't really matter. You just need to make sure that you're using the correct networkId in the API call... i.e. the network in which the static route was defined.
In the case of a spoke, the hubs are obligatory as well which may be the problem in your case. You're just getting an Error 404 which isn't very helpful indeed.
Here's another test I did for you:
I'd try it out in postman first. Also, copy the body from the GET call to make it easier to generate the correct body for the PUT. Once it's running in postman, translate it into a python script.
For the MX-65 device...under Site-to-Site VPN option, there is a section called VPN Settings. There you have the option to select 'Yes' or 'No' for the Use VPN option. Using the portal you can opt to select the to use VPN regardless if the subnet is local to the meraki device or is a static route that can be configured under the Addressing & VLANs section.
If you are trying to change the option to 'Yes' for Use VPN going through the API, it only allows you to change this option for locally connected subnets and not any static routes configured.
I was wondering if anyone an a workaround for automating changing the Use VPN for static routes.
Oh I see.
Well I just tested it and I can change "no" to "yes" for a subnet that gets added automatically by a static route. I did notice that the "mode" parameter in the body is obligatory.
Here's what I tested succesfully, that 10.28.0.0/16 is a static route I have defined on my MX, it's not a local subnet:
What error comes up?
It looks as if you are running this through the hub. I currently have multiple devices that are running as spokes going back to a "VPN concentrator" HUB at my data center. The spokes are advertising the local subnets back to the data center HUB.
I am also running a python script being that I have multiple locations that vary in IP scheme. Below are the results that I get.
Yes, in my case the static route is defined in the hub. However that shouldn't really matter. You just need to make sure that you're using the correct networkId in the API call... i.e. the network in which the static route was defined.
In the case of a spoke, the hubs are obligatory as well which may be the problem in your case. You're just getting an Error 404 which isn't very helpful indeed.
Here's another test I did for you:
I'd try it out in postman first. Also, copy the body from the GET call to make it easier to generate the correct body for the PUT. Once it's running in postman, translate it into a python script.
