Meraki Dashboard API - Clone network while changing IP address and DHCP settings on MX

[UmutYasar]

Hi,

My site MXs will have a similar config except for IP address (will use single vlan) and DHCP settings.

Is there any Dashboard API I can use, to clone an MX config while changing IP address and DHCP settings config?

[GreenMan]

I don't believe there's an endpoint for that, specifically.

Surely using a Dashboard Template would be the easiest approach to this?

Or you could use a combination of the two;  apply a Template   (POST /networks/{networkId}/bind)

then use PUT /networks/{networkId}/appliance/vlans/{vlanId} 

This single call allows changes to both IP and DHCP

[UmutYasar]

@GreenMan I can not use Template because of the sd-wan limitation of single vlan. Can I use the same combination with cloning?

[Bruce]

Hi @UmutYasar, unless you've got a reason to use single VLAN mode on the MX (e.g. OSFP), I'd seriously consider enabling VLANs even if you only use the native. Make sure you can do exactly what you want in single VLAN mode as configuration of the network ports on the MX via the Dashboard or via the API is limited compared to the flexibility when you have VLANs enabled.

[UmutYasar]

@Bruce, Yes, I need to use OSPF, then single VLAN my only solution. I can see that this is limiting MX functionality comparing VLANs enabled. Because of this, I can not use a template (sd-wan limitation), I need to use Cloning instead.

[GreenMan]

Given that OSPF, in the world of MX, is really only useful for Data Centres, I'm surprised you have enough of them to need to automate the setup.   As suggested elsewhere, I'd suggest you enable VLANs, even if you only actively use one.

[UmutYasar]

@GreenMan We need to access DC servers, that we need to establish OSPF. But there is a plan to move the servers to the Microfost Cloud first. In that case, I would enable VLANs. We need to move around 80 campuses to Meraki, that's why I plan to use automation during deployment. If I can use a template and change its IP and DHCP settings and deploy new MX, this will ease the deployment, and good to learn and use these skills after deployment as well.

[Bruce]

@UmutYasar You would only need OSPF at the data centre (head-end) of the Meraki solution. The spokes in the solution shouldn't need OSPF, they will learn about the routes available over the AutoVPN/SD-WAN from the back-end mechanics of the Meraki AutoVPN solution. Also, remember the the OSPF on the MX is one-way - the MX will inform the data centre switch/router of the subnets available via it, but it will not learn about the data centre subnets from the data centre switch/router (you do that by adding the subnets to the AutoVPN yourself).

Are you putting the MX device in the data centre in VPN concentrator mode? If you're looking to migrate about 80 campuses then you probably should be considering it. 

[UmutYasar]

@Bruce Then I don't need to enable OSPF on spokes, that's good news, thank you for that. The Hub I will actually need to put in Head Office and we will have a link to DC from there to reach servers. Over this link Hub will speak OSPF with DC router to announce migrated spokes' subnets that it would learn via autovpn from spokes.

I need to put the MX device in the head office (Hub) in routed (nat) mode actually. I read it should be fine with 80 spokes. Is there any issue you know that I need to consider with nat mode?

[Bruce]

@UmutYasar Good to hear you don't need OSPF on the spokes, that will make your life much easier 🙂 Running OSPF on the Hub MX to announce the migrated networks via OSPF to the data centre is exactly how to do it.

Can't see any reason why the MX device in NAT mode shouldn't work with 80 spokes as long as its sized properly. Its more personal opinion that at that scale I'd have a dedicated VPN concentrator sitting in the head office network behind a dedicated firewall device - but NAT mode should be fine so long as its in Single-VLAN mode to use OSPF.

[GreenMan]

It sounds like your services may actually be hosted in the DC, rather than the Head Office?

If that's the case, why not put the Hub in the DC and build the tunnels from all your sites to the DC Hub - including from the HO?   That way, you don't hairpin traffic in and out of HO and you may not need to pay for the dedicated link.

If you host services in Head Office and the DC, maybe put a Hub in both and build a tunnel from each Spoke to both Hubs - traffic will then take the most direct route - and the HO <-> DC link (if you still want it) will be less congested?

[UmutYasar]

@GreenMan We plan to move servers out of DC (to Azure Cloud) so we don't want to put Hub inside DC. The Head office to DC link will be temp to reach servers in DC during the transition.

[GreenMan]

By Microsoft cloud I assume you mean Azure - in which case, have you considered deploying Virtual MX (vMX) as part of your AutoVPN?   This could work well with the kind of multi-hub setup I described earlier, with branches (Spokes) having tunnels to both HO (for current setup) and Azure (future setup) and allowing a gradual move of applications between the two.

[UmutYasar]

@GreenMan We plan to create ipsec tunnel between Hub and Azure Cloud and get the required server resources.

Do you see any issue with this solution?

In MX Templates best practices guide it's saying;

"It should be noted that service providers or deployments that rely heavily on network management via API are encouraged to consider cloning networks instead of using templates, as the API options available for cloning currently provide more granular control than the API options available for templates."

Do you know if there is any document that shows how to do cloning with APIs?

[GreenMan]

Actually, I learned something new myself, here;   you can clone using the API.  It's covered within the main API documentation, under Create Organization Network

https://developer.cisco.com/meraki/api-v1/#!create-organization-network

and use the copyFromNetworkId parameter

Note that I'm pretty sure you will want to configure your Azure vMX as a Hub, with all of your branches configured as Spokes, tunnelled to that Hub.   In that setup, you would have no tunnels to either your DC or your Head Office.   You don't need to use OSPF at the Hub vMX.

I'm pretty sure you will also want your branches (Spokes) in Routed mode, with VLANs and your Azure vMX Hub in VPN Concentrator mode.