If a branch office MX has a primary & backup tunnel, can it be setup to never take the backup

[DennisS]

We have East & Midwest data centers. The DC are linked together with P2P circuits and we're running BGP between them for dynamic routing.

• Branch office MXs have AutoVPN tunnels to each DC
• Primary AutoVPN is the nearest DC & backup is the farther DC
• DC MXs advertise a default 0.0.0.0 route to each branch office

If a Midwest branch needs to access a East DC resource, traffic flow is symmetric:

• Branch primary AutoVPN tunnel => Midwest DC
• Midwest DC => P2P => East DC

Return Traffic

• East DC resource => P2P => Midwest DC
• Midwest MX AutoVPN tunnel to branch

We encounter asymmetric routing when we advertise a specific prefix from one DC. For example, we advertise 10.1.1.0/24 prefix only from East DC MX.  Same Midwest branch needs to access a 10.1.1.x East DC resource, traffic flow is asymmetric:

• branch backup AutoVPN tunnel => East DC

Return Traffic

• East DC 10.1.1.x resource => P2P => Midwest DC
• Midwest MX AutoVPN tunnel to branch

Is it possible to setup the backup AutoVPN solely as a backup connection should the primary tunnel go down?

Would source based default routing be a possible solution? 

https://documentation.meraki.com/MX/Networks_and_Routing/Source_Based_Default_Routing#:~:text=Source...

[alemabrahao]

Hi @DennisS,

This might solve it, but it's looking more like a configuration issue on BGP, check if Route Prioritization has been configured.

[DennisS]

Hi Allesandro,

The only configuration we can control from the spoke side is hub priority, the nearest DC is the primary.

What we're seeing is what's explained in the DC-DC Deployment guide

In a dual- or multi-datacenter configuration, identical subnets are advertised from each datacenter with a VPN concentrator mode MX...  For subnets that are unique to a particular hub, traffic will be routed directly to that hub. For subnets that are advertised from multiple hubs, spokes sites will send traffic to the highest priority hub that is reachable.

What would be idea is, spoke MX's exclusively select the highest priority hub except during an outage.

Additional background... our Security Team would like to deploy an internal firewall between our DC CORE switches & MX concentrator.  Firewalls will drop asymmetric traffic.

[ww]

I think you could run ebgp to the fw  bgp AS on both mx.

Advertise the subnet 10.1.1 subnet from the fw.

Secundary mx will do AS prepend

[DennisS]

Our DC concentrator is setup the way you described except route advertisements are conducted from our COREs.

• eBGP between CORE & firewall
• eBGP between firewall & MX

As expected, the backup DC concentrator prepends the branch/spoke prefix "towards" the DCs properly.

The problem is from the spoke end. How can I prevent a spoke from taking the backup AutoVPN connection if it learns a more specific prefix from it.

[ww]

Thats not possible to control from the spoke side

If you filter the route advertisement for 10.1.1.x from the fw to the mx. Will the spoke take the default route when going to 10.1.1.x?

Or maybe advertise that subnet to both mx concentrators

[DennisS · Accepted solution]

That's not possible to control from the spoke side...  That's the conclusion I'm coming to. The minute a unique prefix is advertised from one DC, spokes could end up taking the backup hub connection. And because our DCs exchange routes, DC "return" traffic prefers the spoke's primary AutoVPN connection due to MX prepending.

Not a big deal right now since our DCs are the only egress points for internet traffic (did I mention this is a SDWAN MPLS deployment) so we simply advertise the default route to branch offices.

Later on when we setup local internet egress, we'll need to advertise the same RFC1918 prefixes to spokes and let the DC COREs forward traffic accordingly.  It's not idea since we'd prefer branch traffic to go directly to the respective DC but I don't see an alternative setup.

[alemabrahao]

It should work this way. I also have two DCs but I don't remember having route asymmetry.

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior

Route Priority

Each type of route configured on the MX has a specific priority in comparison with other types of routes. The priority is as follows:

1. Directly Connected
2. Client VPN
3. Static Routes
4. AutoVPN Routes
5. Non-Meraki VPN Peers
6. BGP learned Routes
7. NAT*

NOTE: For BGP route selection please refer to: https://documentation.meraki.com/MX/Networks_and_Routing/BGP

*If no routes are defined, then the traffic is NATed and sent out an active Internet interface. This only occurs while the MX is configured in Routed mode.

[DennisS]

We stumbled upon asymmetry while testing failover scenarios.