Migrating All MXs to New MXs

[CyberDingo]

This is going to be a very specific question, but Meraki support has been giving me the run around without solid solutions, so I am going to ask here to see if anyone has any recommendations. 

My company is cutting ties from a MSP managing our MXs (SD-WANs) at all our locations (networks). We purchased all new devices and licenses to replace our current set-up. The goal is to replace all our current devices and licenses owned by the MSP with these new devices and licenses owned by my company. 

In addition, our MSP set our organization up as a per-device licensing model. We would like to switch to what the majority of users have, co-termination license model. From speaking with Meraki support, it is not possible to switch a an Organization, within an account, from a per-device license model to a co-termination license model, even if purchasing all new licenses for every device. 

The solution posited from support is to create an identical Organization, configured the same as the current Organization, and migrate all the devices over. After having done this and labbing the transition, I have found that Meraki requires VPN set-ups between Organizations to be created as "Non-Meraki VPN peers" even if they are both Meraki MX devices. They are not able to use the AutoVPN feature between Organizations.

The problem I run into with this is that we are hoping to slowly migrate our Organization over one network at a time, as our I.T. team is centrally located and cannot be at all locations within my company at once. This creates the main problem; the "Non-Meraki VPN peer" does not account for MXs that use dynamic public IPs, and therefore have changing IPs. We have a few locations that are not static IPs, and I do not want to lose connectivity when they switch IPs. Our sites have to be able to VPN with each other.

I admit that this could come down to me not fully understating the IKEv2 ability to connect via hostname. I've read the KBAs but it still is not clear to me how to use Local ID and Remote ID.

In addition, this can get very complicated trying to handle the two Organizations with same subnets not conflicting with each other.   

Right now I feel stuck. I am not sure how to move forward with this migration. If anyone has any recommendations, I would greatly appreciate it. 

[alemabrahao]

Here are some suggestions for you.

MX licensing can now support mixed licensing in Co-termination licensing model with Per Device SD-WAN+ licenses, so, it's important to note that once you switch to the per-device licensing model, you cannot change back to the co-termination licensing model.

When moving devices between organizations, the static IP addressing set on the devices will change when moved to a different organization. The dashboard configuration that is applied to the device will not migrate to the new organization. It is recommended to pre-configure the receiving network to match the existing network before moving the device.

As you mentioned, Meraki requires VPN setups between Organizations to be created as "Non-Meraki VPN peers" even if they are both Meraki MX devices. This is because all MX security appliances within the same organization will be able to use the AutoVPN feature to establish a Site-to-site VPN between themselves. However, if two MX Security Appliances are in separate organizations, they will not be able to set up an automatic VPN.

For the issue of dynamic public IPs, it seems there's no straightforward solution. One user suggested using a DDNS service, but this might not be ideal.

One suggestion is to have a new subnet (VLAN) for your new devices behind the new MX. You can keep your original subnet behind the original MX and create a new transit VLAN that both MX's share. Then add routes in both MX's to allow the original subnet and the new subnet to communicate with each other.

Please note that these are suggestions. It's always best to consult with a network professional or Meraki support for advice tailored to your specific situation.

[CyberDingo]

Thank you for your thoughtful response and confirming my suppositions. 

I am very frustrated right now as there does not seem to be any realistic path forward, and Meraki support has not been helpful. I am not sure what to do next.  

[cmr]

If you have a hub and spoke setup, at the main hub install the new MXs behind the existing in single ended VPN concentrator mode.

Then you can migrate one spoke at a time and just change the routing between the two MXs in the hub site each time.

At the end you can rebuild the hub MX into routed mode to replace the existing MSP one.  That will involve some disruption, but if you get a move on you could do that bit on Christmas day 😉

If you don't want that disruption, you could always have another new MX at the edge of the hub site, or any vendor's firewall.

[CyberDingo]

Thank you for the response. I appreciate your recommendations. Unfortunately this will not work as I am moving from a per-device license to a co-term license set-up and can't set one up in per-device Organization before moving it to a co-term Organization. 

In addition, our locations are so far spread out that we cannot reach all the locations to migrate them over in one day. 

[cmr]

@CyberDingo you don't need to move any devices or do everything at once:

Step 1: Create new co-term org and network for hub, set up MX in single ended mode with default route into existing hub site.

Step 2: Create network for first spoke in new org and set up new MX

Step 3: Delete network of first spoke site from old PDL org and add route to existing PDL MX at hub site, pointing to new MX in co term org's hub site.

Step 4: Install new MX at the first spoke site and enjoy the end of phase 1.

Repeat for each spoke and at the end you have the choice of changing the hub MX from single ended to routed, or taking another option.

[Badr-eddine]

Hello,

For your migration challenge, I propose two solutions without relying on third-party VPN peers:

1. Dynamic Routing Solution:
- Implement OSPF or eBGP between the L3 device, old MX, and new MX at the hub.
- Configure the L3 device to redistribute routes, ensuring both MXs are aware of each other's subnets.
- As spokes are migrated, the new MX dynamically advertises updated subnets to the L3 device, maintaining seamless connectivity.

2. Static Routing Alternative:
- Place the old and new MXs in the same VLAN for direct communication.
- On the new MX, create a summary route pointing to the old MX to handle traffic for all spokes, adjusting the metric accordingly.
- As spokes are migrated, add specific static routes on the old MX for corresponding subnets, directing traffic to the new MX.
- Document routing changes thoroughly, communicate adjustments to the team, and regularly test connectivity during the migration.
- Once all sites are migrated, remove the summary route and unnecessary static routes from the old MX to complete the transition.

I think those solutions ensure a controlled and organized migration process without relying on external  VPN peers.

Feel free to ask if I overlook something!

[PhilipDAth]

That is indeed a horrible situation.

I can think of a couple of strategies depending on how many spokes you have.  I would use this method if you have less than 30 spokes - and assuming you need the spokes to all be able to talk to each other (if this requirement does not exist then things get simple).

This is how I would handle it:

• Create newOrg and place the new devices and licenses into it.
• Put an MX at HQ that belongs to newOrg into VPN concentrator mode.
• Initially, on the new MX in newOrg create a static route for every spoke in OldOrg, pointing to the LAN IP of the MX in OldOrg, and publish all of those static routes into AutoVPN.
• When you move a spoke from oldOrg to newOrg, move the static route from the MX in newOrg to the MX in oldOrg (except the next hop will now be the LAN IP of the MX in newOrg).  Make sure you publish the static route in AutoVPN.
  • This will ensure all spokes can always talk to each other.
  • You can do this at a larger scale by publishing supernets instead.

You won't be able to get conflicting subnets, because at all times both newOrg and oldOrg will know about every route in the combined systems.

This approach will allow you to do a slow migration.