Meraki AutoVPN asymmetric routing probability

[CuongPham]

Hi,

I'm thinking, there should be very high chance that a Spoke to Spoke routing is going to be asymmetric.

For example, as in the below diagram, when the Hub priority is different between Spoke, asymmetric routing would happen.

Can someone verify this?

Is this going to cause any problems? Should we do anything to prevent this?

Thanks.

[PhilipDAth · Accepted solution]

I think you are correct.   I don't think it will cause a problem. 

Frequenting when you access things on the Internet the forward and return paths are different,  and well,  the Internet seems to work. 

[CuongPham]

Thank you very much for the answer.

I think we have to keep this in mind, just in case.

[sledge121]

Hi Philip

If the asymmetric routing example detailed in this post does happen, does this mean that the MX is a stateful firewall over its WAN and LAN interfaces but not over its autovpn tunnels?  The reason I'm asking is that the return traffic could be via a different tunnel.

Thanks

Rick

[FMTeuchter]

Correct, Meraki only checks against the VPN ACL when traffic is being sent and not when it is received. 

So if in your example traffic goes Spoke A -> Hub A -> Spoke B -> Hub B -> Spoke A, it will check the rule set of the sending device in the hop. 

[PhilipDAth]

AutoVPN is generally stateful.  If traffic comes in via one pair of WAN uplinks (that AutoVPN is running over), the return traffic takes the same AutoVPN path.

I have not personally verified this behaviour though.  This is how it has been explained to me in the past.

[sledge121]

Now I'm conflicted between your reply and the FMTeuchter reply.

It makes some sense that asymmetric routing happens over the spoke tunnels and the spoke tunnels are not stateful as a reply could come via a different tunnel due to the other spoke having a different hub priority.

It also could make some sense that reply traffic would go via the same tunnel the traffic was received on.

The problem is without Meraki documentation, neither response can be validated.

[sledge121]

Hi CuongPham

I finally got a confirmed answer to your question.  In the scenario you provided your topology is correct, there isn't specific documentation for this scenario but there is documentation on hub priorities which ended up being the simple answer to this.  I queried this scenario just in case the return traffic was symmetric using some kind of 'Meraki Magic' which we keep reading about.  

When spokes have different hub priorities, spoke to spoke routing is asymmetric as the spokes will route via their hub priorities. Spoke tunnels are not stateful, so they can send via one tunnel and receive via a different tunnel. The hubs are agnostic as they are in VPN concentrator mode.

[sledge121]

Hi CuongPham

I finally got a confirmed answer to your question.  In the scenario you provided your topology is correct, there isn't specific documentation for this scenario but there is documentation on hub priorities which ended up being the simple answer to this.  I queried this scenario just in case the return traffic was symmetric using some kind of 'Meraki Magic' which we keep reading about.  

When spokes have different hub priorities, spoke to spoke routing is asymmetric as the spokes will route via their hub priorities. Spoke tunnels are not stateful, so they can send via one tunnel and receive via a different tunnel. The hubs are agnostic as they are in VPN concentrator mode.