Meraki AutoVPN asymmetric routing probability

Solved
CuongPham
Comes here often

Meraki AutoVPN asymmetric routing probability

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.

コメント 2019-04-11 144438.jpg

Can someone verify this?

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

 

Thanks.

1 Accepted Solution
PhilipDAth
Kind of a big deal
Kind of a big deal

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. 

View solution in original post

8 Replies 8
PhilipDAth
Kind of a big deal
Kind of a big deal

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
Comes here often

Thank you very much for the answer.

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

sledge121
Here to help

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
Conversationalist

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
Kind of a big deal
Kind of a big deal

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
Here to help

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
Here to help

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
Here to help

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