We have a 4 site full Mesh.
HQ - UK (server access)
Data Center -UK (server access)
Branch office Paris (no servers just clients)
Branch office London (no servers just clients)
All 4 are in a 4 site auto-VPN mesh.
However we now have a Layer 2/Lan extension/p2p link between our data center and HQ so I want to remove the VPN participation of the Server VLAN (15) and route (well switch) traffic over that p2p link.
The problem i'm guessing will happen is that if I remove the server VLAN from going over the VPN then our Paris and London branches will lose access to them.
Is there anyway to just remove the VPN participation between HQ and DC and leave it in for the other sites?
We are trying to stretch the Server VLAN 15 across HQ/DC via the p2p link for DR mainly but what i've found is if it is still participating over the VPN aswell you essentially have a loop and things stop working.
I think I also need to go from full mesh to a 2 site mesh (HQ/DC) and a Spoke London/Paris. Is that correct ?
You can disable a VLAN/Subnet from participating in AutoVPN so it is not advertised to other MXs. Also you could use the Outbound VPN Firewall to block certain traffic as well..
Not sure what kind of link you have. If you want to strecht L2 i dont know how you created a loop.
If you are aiming at routed based you should use a transit subnet between the locations an use static routes with tracking
I'd recommend you have Meraki Support enable a backend setting known as "no Hub to Hub" on the Organization - and change your (two) client-only sites to be Spokes, connecting (presumably) to both HQ and the Data Centre. I'd also recommend using BGP to exchange routes between the MXs in the DC (I presume these are configured as VPN Concentrators?) and your upstream router / L3 switch on the LAN side
I've changed our two branch office to Spoke only connecting to 2 exit hubs (DC and HQ) so this went well and I was thinking of just deleting the VPN between HQ and DC and essentially making all sites spokes and then putting the p2p circuit on a trunk VLAN on the core switch either end and switching/trunking traffic just like we do to a distribution switch. VLAN10 is the native VLAN and all VLANS are allowed. Essentially the L2/p2p link is basically just an ethernet cable.
I see no issues in having an stretched vlan between your DCs. Traffic inside your server vlan would be L2 switched so east-west traffic inside your server vlan would not pass thru Meraki AutoVPN. Of course, this L2 path should be fully redundant (MLAG, for example) in order to avoid issues. In case a local vlan must connect to a server in the stretched vlan, L3 core in your DC will route the traffic.
Server vlan must be enabled in AutoVPN. Both hubs would inject it into AutoVPN. I assume your DCs are deployed in concentrator mode.
I would recommend your offices to be reconfigured as spokes. Both would have two hubs so traffic towards server vlan would take the tunnel against first hub in the list. So you can chose the preferred hub for any of your offices (if both offices share a common template, then both would have the same hub preference)
No we don't use concentrator mode and never have - we just used basic HUB mesh.
I'm not sure I even understand the concentrator concept.
Our network is quite simple - we have an MX 100 at each site and MS core switches. ALL sites were in a mesh topology but now I've removed them to hub spoke for branches but need to remove VPN connectivity between HQ and DC as we have P2P link.
Hi, I try to follow meraki's recommendations for AutoVPN: Auto VPN Hub Deployment Recommendations - Cisco Meraki
Concentrator mode in Hub sites make routing easier. You do not have static routes to configure but you only configure the prefixes to be exported into AutoVPN. Both hubs in your deployment could configure shared prefixes and advertise them from both. You can also configure prefixes that are only present in just one hub site. Spokes will choose the first hub in their list for exact prefixes that both hub sites advertise. I'm not aware you can ask Meraki to turn off hub to hub VPN tunnels behind the scene. However, in case it is possible, take into account one hub could lose connectivity with other hub local (not L2 extended) vlans.