Meraki AutoVPN autosummarization

[Chema-Spain]

Hi, this post is not to ask for help but to make you aware of a potential issue you might not know when deploying Meraki AutoVPN.

Have you ever experience a rare route table behaviour in a MX where some entries you supposed to be active are not?

I just have faced this issue in this environment:

One Onprem spoke MX - One vMX in Azure

Main path is AutoVPN. Manual BU is non-meraki tunnel against AZ VPN GW. (static entries in AZ subnet RT pointing onprem prefixes towards vMX Virtual Appliance to be removed in case of any issue with AutoVPN tunnel)

As Meraki does not allow to publish exactly the same prefixes from both AutoVPN and IPSec tunnel, in non-meraki tunnel we published the real prefix masks and in AutoVPN we configured more specific prefixes for AZ subnets.

This way we expected to see the more specific AutoVPN prefixes as active in onprem spoke MX. However, that was not the case.

Real subnets in Azure 172.30.6.0/24 and 172.30.7.0/24. As mentioned above, both configured as /24s in nonMeraki tunnel against AZ VPN GW

vMX hub injected subnets over AutoVPN 172.30.6.0/25, 172.30.6.128/25, 172.30.7.0/25, 172.30.7.128/25.

Result?

Spoke route table showing all /25s inactive, both /24 prefixes active, traffic from onprem to Az taking nonMeraki path instead of AutoVPN.

After opening a ticket, Meraki explains me what happens here: Autosummarization in AutoVPN is enabled by default. So all 4 /25s are summarized as /23 according to their explanation. However, you never see this /23 prefix (nor active nor inactive, it is not there) in the spoke route table.

After Meraki disabling autosummarization behind the scenes (only them can do it and applies to a whole Meraki Org) all /25s prefixes became active and traffic start behaving as expected.

At this point I recalled I suffered a similar issue in the past in a customer with 2 hubs. All spoke lan addressing were inside 10/8 and at the same time some prefixes inside 10/8 were also present in the hub sites. We configured the hubs to inject 10/8 prefix in AutoVPN and the result was every spoke only learnt the 10/8 and not other more specific prefix. After opening a ticket they disabled autosummarization and only then every spoke started to learn other prefixes.

I suppose Meraki applies Autosummarization in AutoVPN by default in order to ensure large deployments are properly managed without filling MX route tables. However, in many cases I think it would be at least something to be configured by the customer. I'm going to open a make a wish for this...

HTH.

Regards.

[jimmyt234]

Yep - learnt about this the hard why like you did by having routing issues and Meraki support informing me of this secret back end route summarisation configuration that was enabled, issue was resolved after them disabling.

[Chema-Spain]

I did not mention it could have been even worse to troubleshoot. I've checked this case in my lab (autosummary in place here):

NonMeraki prefix 172.30.30.0/28

AutoVPN 172.30.30.0/29, 172.30.30.8/29

In this case all 3 prefixes are seen inactive in spoke RT. Reason? AutoVPN summarizes both /29 in a /28... and that enters in conflict with nonMeraki announcement. This conflict makes you to have no active route at all. You could go crazy in case you are not aware of AutoVPN default autosummarization.

I also checked in case you delete one of the /29s from MX hub then both /28 and the other /29 remain active. This is normal as AutoVPN has no prefix to be summarized.

[Ryan_Miles]

Appreciate the post. This does creep up on people in certain situations. And, I agree it should be configurable by the end user (of just off by default).

If you have a Meraki SE that supports you I would provide them this feedback so they can roll it up to the powers that be.