Meraki vMX having losses - route table issue/looping

ygurra
Here to help

Meraki vMX having losses - route table issue/looping

Hello everyone,

We are having huge losses with our vMX appliance installed in Azure, first let me introduce the scenario in order to further understand where the problem stands. Below you can find the rough topology which I built for this question:

ygurra_1-1723907203358.png

1- We have a vMX-M appliance created in Azure, which is running in VPN Concentrator/passthrough mode with one interface (one armed architecture) having a private (172.16.0.4) and public IP address at the same time. There are S2S VPNs in place with spoke branch offices as seen from the picture above and these site to sites are UP and running without any issue.
2- In Azure environment, at the same subnet of 172.16.0.0/28 there is built a NVA appliance (palo alto FW) with one interface at the same subnet as vMX appliance and having an IP address (172.16.0.5). 
3- Behind this FW appliance, there are resources to be accessed from the branch offices (with IP range 10.20.0.0/16, splited in smaller subnets for each branch office). 

Saying that we have a route table attached to the common subnet between PaloAlto FW and vMX-M appliance which have the following routes:
a) DST: 172.16.0.0/16  Next-Hop: 172.16.0.5
b) DST: 10.20.0.0/16  Next-Hop: 172.16.0.4

However, this is creating big looping issues where we see packet drops sometimes at high amount which affects some working processes in the communication between branch offices and azure resources. 
I tried disassociating the route table from the subnet used in common between Palo Alto FW and Meraki vMX and started a contionous ping from branch office to the vMX appliance internal IP address (172.16.0.4) and there are no drops at all. However, the removal of this route table affects the communication from branch offices to the Azure resources where it seems vMX appliance is unble to route the traffic to the PaloAlto FW without this route table. 
I tried to find a way to manually add the routes in the Meraki dashboard but since the appliance is running in Passthough mode I was unable to insert a static route (so not possible for this mode). 

My question would be if somebody knows any way how to route the traffic from vMX to NVA (PaloALto FW) without the insertion of route table ? p.s. I also tried OSPF but it did not work. 

If not, then is there a better way to solve this problem which we are facing in that specific scenario ? 

Thank you in advance !

4 Replies 4
GIdenJoe
Kind of a big deal
Kind of a big deal

The Meraki vMX is supposed to be on it's own subnet as a solo device.  It can only default route out for both the VPN tunnels to the branches as the Azure routing table to reach other networks.  You're not supposed to  have a Palo Alto directly as a gateway on that same subnet.

Hi @GIdenJoe ,

 

Thanks a lot for the quick reply. So, do you mean to create a new subnet (i.e. 172.16.0.16/29) for that Meraki interface and attach it a separate route table where there are route entries only concerning the Meraki device ? 
Because in the existing scenario, we have route entries concerning both Meraki and PaloAlto FW interfaces (since they are in the same subnet). Would this be the solution ? 

Thank you again !

GIdenJoe
Kind of a big deal
Kind of a big deal

I'm not sure you need a separate vNet(because this needs peering) but at least you need a different subnet so the vMX lives alone on it's subnet and can only go default gateway towards the Azure routing table for routing both to other subnets in Azure or outside to the internet for the AutoVPN traffic.

PhilipDAth
Kind of a big deal
Kind of a big deal

The answers given already are correct.

 

This section in the documentation deals with the packet loss in Azure issue.

https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Setup_Guide_for_Microsoft_Azure#Packe...

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels