Meraki

Chema-Spain · ‎Jul 21 2025

Right, Meraki documentation states the MX will lose all config (including its uplinks config). However, I just have tried moving a MX from my lab (both uplinks with static config) and after unclaim/claim process I has properly registered into the new org. And it also has properly registered in our lab org once we have rolled it back to it. Thanks!

Chema-Spain · ‎Jul 21 2025

Hi, I need to move a MX currently having a static wan IP (the one and only uplink it has) from one org to another. My doubt is about the static uplink config would remain in the device after unclaiming it from the old org or whether I would lose it. We are not sending any FE for this change as it was just a logical change from one org to another. Many Thanks!

Chema-Spain · ‎Jun 4 2025

Issue solved! Provided I realized it was imposible to make IPSec tunnel the automatic autovpn BU with BGP inside, I went back to static routing. BGP inside IPSec tunnel does not solve our issue due to the fact Azure does not allow outgoing bgp attribute manipulation and Meraki does not allow incoming bgp attribute manipulation. As AutoVPN bgp peering at the spokes is ibgp and IPSec Tunnel requires ebgp, MX will always select IPSec. I redeployed the IPSec tunnels just configuring a /16 as remote prefix at both sides. Doing so, we reproduced the issue we had when we tested it: It worked fine in normal situation and it failed when stopping the vMX in Azure. Capturing at one branch MX, I saw packets exiting the IPSec Tunnel with no return. However, that flows did not reach Azure. Route table pane also got hung as last time. Impossible to check it even waiting. Running a traceroute from a branch PC to a vm in the AZ region, it was sent to LBO instead of the IPSsec tunnel. I decided to upgrade the MX firmware from 18.211.5.2 to candidate stable 19.1.8. After the upgrade, automatic BU when stopping vMX worked fine. We tried successfully twice to stop/start vMX. We also did all these for the other branch and also worked fine.

Chema-Spain · ‎May 29 2025

Hi, TAC has answered me. They don't see the issue as a bug but an expected result. Surprisingly, they state the bgp-learnt prefixes at the hub from the AZ RS are considered BGP routes at the spoke sites even when they learn them over AutoVPN tunnels. Great! It makes no sense, they are AutoVPN learnt routes at spoke sites, it is supposed they are not running BGP. I'm aware they do behind the scenes, once you enable BGP in one hub, an ibgp session is eestablished with all other hubs and its spokes. They also said we have two ways to solve the issue. One is forgetting dynamic routing at Azure side and configure local routes. No way, I could split every azure /24 real prefix into 2x /25s. Fine. The problem is these prefixes are not removed from the network even when the vMX is stopped or fails. Another great! The other option is a recent deployment in 19.X. Now you can run bgp inside Non-Meraki IPSec tunnels. Fine, AZ VPN GW also supports it. Good advance from Meraki. I will test it. However, according to the meraki document, only AS-path prepend on egress and weight attribute are sopported. Why not Lpref???? The former does not solve the on-prem MX route decision process issue, it works for the other traffic direction. Weight... maybe. Meraki does not say what value is the default between 0-49. They only say the higher the value, the higher the preference. In case default value is not 0, I could try setting 0 por IPSec tunnels (from the dashboard I can't configure any weight por autovpn prefixes (local or bgp originated). This way it could work... or not. Assuming they consider bgp-originated AutoVPN routes as bgp routes, I hope they would consider bgp-originated IPSec routes ass BGP and not IPSec to maintain its rare route decision algorithm consistency. This way it could compare weights from both paths. Or maybe, provided even weight does not work and it is the same for both paths, MX decides to chose autovpn instead of ipsec for Az same mask prefixes. In AZ it is not possible to manipulate prefix at egress nor in RS nor AZ VPN GW and as-path would be the same for both paths as RS and VPN GW must be running ibgp themselves. In case all this does not work, in order to ensure an automatic BU for AutoVPN tunnel with an IPSec tunnel I guess it could only be done by Meraki behind the scenes. If not, I'm afraid two vMX or manual backup with someone accesing the dashboard in case vMX fails. I can understand mine could be corner case. However, route decision is not properly designed. And local prefixes permanently present in the network regardless of its state is even worse. Regards.

Chema-Spain · ‎May 15 2025

Meraki TAC confirmed BGP-originated AutoVPN prefix should be preferred. Just sent them the packet captures that prove it is not the case. Hope they could find and explanation for this behaviour.

Chema-Spain · ‎May 13 2025

Hi, Thanks for your reply. Same customer already have dual vMX is another Azure Region. No problems there. We've tried proposing that solution but problem is they only have two onprem sites in the region so they don't consider it due cost reasons. At the end of the day, I guess I can do nothing to manipulate azure prefixes to ensure AutoVPN tunnels as preferred. No way to summarize or prepending at VPN GW, no way to publish more specific routes from vMX as they are learnt dynamically from the RS. I will open a ticket to ask Meraki what they mean with BGP routes anyway because from my understanding bgp originated prefixes in Azure hub should be considered as AutoVPN routes at the spoke side. Hence spoke MX should IMO choose AutoVPN path and not IPSec tunnel. As customer wants us to change SDWAN corporate FW from default allow to default deny I'm afraid a rule like source "Az Region prefixes" to "onprem sites in Region prefixes" would be a must. Regards,

Chema-Spain · ‎May 12 2025

Hi, I have a topology with two on-prem sites comprising MXs as spokes of an Azure vMX hub. As hub is not redundant, customer has asked us to deploy non-meraki tunnels against Az VPN GW in the region as AutoVPN tunnels backup. First we had no dynamic routing in Azure but vMX publishing Az vnet address spaces as AutoVPN local networks. Provided I had /24s as real azure subnets, I configured two /25s per /24 as local network. Non meraki tunnels for onprem MXs had real /24s in Azure as remote prefixes. Fine... however it did not work. Appart from having udr routes pointing to vMX that had to be deleted, when stopping the vMX BU did not work due to the fact Meraki keeps publishing local prefixes even when vm is down 😞 OK, we deployed a RS instance in Azure, deleted VM UDRs pointing to vMX and ensured VM effective routes now learnt both onprem prefixes from vMX and summarized onprem prefixes from AZ VPN GW. Great! We checked all was working fine in normal situation and also when stopping the vMX VM from Azure. However, when looking at the onprem MX Route Tables I found different behaviour from both MX. Both running same firmware 18.211.5.2. One of them is showing the green ball for Non meraki tunnel and grey ball for AutoVPN BGP learnt prefix, the other MX is showing grey ball for AutoVPN BGP learnt prefix and a hyphen for non-meraki tunnel. Looking at route preference, the order should be: Directly Connected Client VPN Static Routes Auto VPN Routes Non-Meraki VPN Peers BGP learned Routes NAT* It is supposed BGP learned it means from a direct ebgp peer, right? Provided you are an spoke receiving BGP prefixes over AutoVPN, it is considered as AutoVPN route, right? However, capturing at onprem MX side, I only see traffic towards Azure when selecting IPSec VPN as the interface. Return traffic is taking AutoVPN path. This way I have asimmetrical routing. And it works... what I'm not sure is it would also work when next week we would change AutoVPN SDWAN fw from allow default to deny default, provided syn packets from onprem are not seen by vMX and syn + ack responses from Azure are going to reach the sdwan fw as non existing session and no allow default would be there to catch it. Am I right? Thanks!

Chema-Spain · ‎Feb 12 2025

It is not possible as per design we already deployed two independent MXs in main region for European sites as SDWAN termination point ( behind Azure Load Balancing sandwich with vPA FWs in different AvZones for perimeter solution and Azure RS to ensure Az to onprem flows will take the main MX) and just a simpler design in the other region for just two onprem sites that need to access locally to Azure resources.

Chema-Spain · ‎Feb 12 2025

Thanks to both TyShawn and Philip. I'm still waiting for the customer to test it and give me some feedback.

Chema-Spain · ‎Feb 10 2025

Hi, customer wants to access Meraki devices instead of accessing the dashboard snmp mib. I have been taking a look at Meraki's reference document. According to it, you can provide RO access just activating a snmp community at template level. As customer NMS is located in his DC, snmp traffic will take the AutoVPN path. Hence it would be encrypted. That's fine, as they still use snmp v2C. https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/SNMP_Overview_and_Configuration My doubts are: 1.- OK, MS and MR I guess they are exposing their LAN/Management IP addresses. Just activating the community at template level it would expose an IP per device? 2.- What about the MX? Reading at the documentation it mentions a local internet fw inbound rule must allow snmp flows (Meraki is talking about internet snmp access, not AutoVPN) and that makes me thing they could be exposing just the wan interface public IP address. What if the MX comprises more than one LAN subnet. Would it expose both the wan uplink and also all local vlans?, just one? None? Have anyone tried to access meraki devices using snmp thru AutoVPN so could be in position to solve these doubts? Thanks!

Chema-Spain · ‎Feb 10 2025

Hi Martin, Thanks for your response. I did not mention that in the other Region we have deployed 2 independent vMXs running eBGP with Azure Route Servers and there it works as expected when testing BU. However, in this new region customer does not want to buy a second Meraki vMX license, because Azure resources in this region are only in use for a couple of onprem sites. Anyway, I think there is not much to do here... I'm afraid local networks are going to be present in remote MX tables even when the vMX is stopped. Deploying a RS I guess it is going to be a must provided customer insists in fully automatic BU. Regards,

Chema-Spain · ‎Feb 10 2025

Hi, I'm extending a Meraki SDWAN network into Azure. As customer only has a vMX vm in the region, we have configured a non-meraki tunnel between onprem MX in the region against Az VPN GW to serve as BU circuit in case the vMX fails. Routing between vMX and Azure subnets is static, so vMX must configure Azure prefixes as local networks in AutoVPN. In order to avoid issues in MX spoke sites, the Azure prefixes configured as local networks in AutoVPN have been configured most specific (creating 2 /25 per each real /24 Azure prefix). Non-meraki remote Azure IPSec prefixes in physical MX are configured as real /24s. This way, in normal situation everything works as expected: Physical MXs prefer AutoVPN for Azure prefixes and Azure prefers UDR static routes for onprem pointing to vMX private IP, so connectivity works fine. The issue appears when trying to test BU connectivity. When we stop the vMX VM, local advertised networks in the vMX routing table pass from green to not installed ("- " symbol) in the vMX Route Table. Good! However, the rest of the network still sees them as valid remote routes, causing the traffic to be blackholed. Couriously, spoke notice their preffered hub (the stopped vMX) is down for other spoke networks and change their routes to point towards their second hub. However, vMX local networks remain up in all spokes pointing to the stopped vMX. Provided I configure the vMX off from autoVPN, all other AutoVPN devices in the network tear down the vMX local networks and Bu works (once we have deleted the RT in Azure subnet) IMO, it is rare the own vMX could set their local networks as inactive, while the rest of the network keeps unaware from vMX stop. I know Meraki always starts publishing the lan prefixes of a site just when you associate the network to a template (even when the MX is not already installed). However, in this case, the VM is stopped from Azure, it declares the local networks as inactive...however at the end of the day they are present in all other MX tables unless you remove the vMX from AutoVPN. I'm afraid we have to explore the Azure Route Server design. The issue here is we had deployed RS in another region having inter-regional vnet peering against this region and we have to ensure RS-to-RS does not modify current regions routing (routing in the other region is quite complex) I've already open a ticket to check if there is any way to tear down local advertised routes automatically. Have you ever had a similar issue? Thanks!

Chema-Spain · ‎Nov 25 2024

Hi, Finally I got the feature visible after Meraki TAC configured it behind the scenes. Note first time they only configured support for subnet-to-subnet NAT (I checked it worked fine, only natted subnet was present in hub table), when trying to configure Many-to-1 nat, it failed. After contacting again with the TAC engineer both options were available. This is what I saw: I confirm Many-to-1 nat works fine for Spoke2 site (the one not associated to any template). Regarding Spoke1 site, it works too... however, what dashboard reflects is quite strange: First I deassociated spoke1 from its template (selecting config retention). Then I configured Many-to-1 nat for the subnet. It worked fine, hub site learnt the /32 natted and did not see the private /24 prefix. Fine! I reassociated the network spoke1 to the template. As the subnet is configured as unique in the template, spoke1 changed its subnet to a random one. I configured the proper private /24 addressing and... hub learnt the /32 natted IP. However, nor the template nor the spoke1 show this nat anymore. As a summary: For sites not associated to any template, both subnet to subnet (same mask) and Many-to-1 NAT work fine. For sites associated to template, It also works. However, It is difficult to manage as at the end of the day you do not see what is configured. Nat is not shown anywhere in the dashboard, even when you see the natted prefix in AutoVPN neighbor table. I guess in case you need a change in the natted IP/prefix, you would need to deassociate the network from its template, apply the changes and make the association again. IMO NAT over AutoVPN is not as flexible as what a router or dedicated fw can support. We had customers where you need a mix of dynamic and static entries. This kind of corner cases I guess they won't work here.

Chema-Spain · ‎Nov 18 2024

Still not sure regarding this feature can make it work as needed. And there is another ingredient that would add complexity for sure: having affected sites associated to templates. It could be cumbersome. The fact is templates are the base and strength for Meraki deployments. Asking Meraki TAC to enable the feature in a template, once done from their side, the only option I see as available is natting the internal subnet using same mask. No way to configure many to one NAT. I have asked whether it needs something else from their side to make it visible. I still do not have clear whether that translation for AutoVPN traffic could be 1:1 as it indeed can be configured for internet traffic in port fwd designs. I just have seen there is a kind of local override to configure at network level when site is associated to template. However, I'm not sure it would be enough. Any ideas? Thanks!

Chema-Spain · ‎Nov 12 2024

Hi, Thanks for your response. Source could be any private IP from a class B 10.X/16 addressing.

Chema-Spain · ‎Nov 11 2024

Hi, I have a customer with a particular requirement for AutoVPN traffic. Their current network is comprised of remote sites sharing lan addressing so in their current non-sdwan solution the branch routers are running PAT to ensure each site is presented in the network with an unique /32 IP. They have Meraki switches and routers and they are planning to add Meraki MXs to run an SDWAN network. I was happy when discovered meraki allows a hide feature (only Meraki staff can activate) to apply 1:1 or 1:n VPN subnet translation. In my case, 1:n would fit perfectly. However, I just have discovered they have an internal server in each site that has to be reachable from outside (coming from their private network, not from the internet). It made me think in having both a 1:1 and 1:n VPN subnet translation in place on each remote site. The server hosting this application is sharing local lan subnet with all other devices and it is not a dedicated server for this particular application. The document does not reflect whether it is possible to run both 1:1 and 1:n at the same time. In case it were possible, it is not clear the inside address could be present in the 1:1 transalation once it is part of the 1:n translated subnet. Using Site-to-site VPN Translation - Cisco Meraki Documentation If both premises were successfully accepted by remote MX, I guess it could work: Outbound sessions from the internal server (and their responses) could use the 1:1 translation rule. Inbound sessions against the 1:1 "public" IP would be set to the internal server. No other inbound sessions are required. Outbound sessions from all other servers would be srcnatted into the PAT site IP address. I'm going to ask Meraki for activating this feature in our lab. Prior to this, I was wondering whether you have a similar scenario in place. Thanks!

Chema-Spain · ‎Nov 24 2023

Thanks! By configuring manual Port FWD for our vMX I believe we'll solve the issue with standard public IPs in Azure regarding vMX HA. Good Point. Agree with you regarding Meraki's guide for HA. First picture shows a dedicated vnet for each vMX and second picture shows a common vnet for all resources... great! I'll try changing the design to include the RS. I come from networking area so I'm highly more confortable with BGP instead of AZ Functions 🙂

Chema-Spain · ‎Nov 24 2023

Thanks you both for your quick responses. Totally agree with you dynamic routing using AZ Route Server would be much better than using Azure Functions. Unfortunately when I suggest using RS it was not accepted even when I pointed out the limitations with AZ Functions, posible false positives, etc.

Chema-Spain · ‎Nov 23 2023

Hi, My only experience with vMX in Azure was a single vMX without defining AvZones (so basic public IP for the vMX). vMX is a also a FW and customer accepted to connect it directly to the internet. Now I need to deploy an HA Pair in Azure and in this case my customer wants to sit it behind a vPalo_Alto cluster. They also want to deploy each vMX in a different AvZone in the Az Region. I'm aware that by specifying AvZone in vMX deployment automatically makes them to use AZ Standard Public IPs instead of basic ones. From a previous Philip Dath's post I also know standard would make HA from primary vMX to the secondary one to need more convergence time in case primary one fails. My doubt is: Provided I deploy the vMX instances (they could share a single Meraki SDWAN subnet or run two SDWAN subnets) the vMXs would try to register into Meraki cloud directly (using Az internet access). Both vMX would send all their traffic towards reserved AZ IP for sdwan subnet DGw. How could I get they both to send their underlay traffic thru the PA cluster? Meraki AZ vMX deployment guide says RT are not needed for sdwan subnets, they could lead to packet loss. Or do you recommend sitting the fw behind the vMXs? At the end of the day the vMX FW function already protect themshelves. PA FW will serve as Client VPN access and would protect all Az resources but the vMXs. Thanks for your help.

Chema-Spain · ‎Oct 22 2023

Hi, Meraki HA VRRP does not run over internet links. You must be sure you have connectivity thru any vlan (lan side) between both MX, as vrrp heartbeat runs over lan interfaces. Please take a look at heartbeat section: MX Warm Spare - High-Availability Pair - Cisco Meraki Is it possible that this lan-side connectivity could be unstable? Provided this is not the case, I can give you any other possible explanation for your flaps. Regards.

Chema-Spain · ‎Oct 3 2023

Hi, per your explanation I assume your HS peer is properly configured. VRRP for HA pair could be flapping in case its hello packets (mcast towards 224.0.0.18) between both MXs are dropped by the switches. Please check this is not the case. Regarding your topology warm spare MX would not have access to internet in case sw1 fails. I guess there must be some cable missing between your SW2 and internet edge routers. Regards

Chema-Spain · ‎Oct 2 2023

Hi, regarding your second question: Meraki Hub can properly communicate spokes even when they do not share a common underlay. AutoVPN in hub & spoke model covers that scenario without nothing special to be configured. You only need Hub connectivity to both underlays. Imagine you have dual underlay spoke and one loses underlay1 at the same time the other loses underlay 2. They could still communicate each other. Regarding your first question: An MX hub in concentrator mode does not allow you to configure static routes. You could theorically run ebgp in the underlay against the PE (asking Meraki to make it available). However, IMHO it would be a case that does not fit with the purpose of positioning a MX. eBGP in Meraki MX is intended for learning local subnets and propagate AutoVPN learnt routes towards your eBGP local peer and still use AutoVPN (and its embbeded ibgp for wan connectivity) MX hub in route mode can be configured with lan side static routes. However I guess it does not even support eBGP over lan yet. Regardless of the hub type, uplinks do not support eBGP. Only AutoVPN runs ibgp among meraki MX peers. Regards.

Chema-Spain · ‎Sep 19 2023

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. HTH.

Chema-Spain · ‎Sep 15 2023

Thanks Brash. That is exactly what I wanted to know. 8 hours. Unregistered means not accesible from the dashboard. This could not be such a corner case scenario. An internal meraki issue with device registration or a DNS attach could cause Org MX to lose control plane without losing data plane. Thanks for your help.

Chema-Spain · ‎Sep 15 2023

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) Regards.

About Chema-Spain

Chema-Spain

Community Record

Badges