sdwan hub routing behavior

[PatTheCat76]

let's say I have hubs A and B.

A in North America (NA) with spoke A connected to hub A

B in Europe (EU)  with spoke B connected to hub B.

in NA I have hub A connected to internet but also to CORE SWITCH A. HUB A has a static route 10.0.0.0/8 to core A.

in EU I have hub B connected to internet but also to CORE SWITCH B. HUB B has a static route 10.0.0.0/8 to core B.

core A and core B are connected together through some private link.

all in the same org so HUB A knows about Spoke A, Hub B and Spoke B.

now when from behind Spoke A I do a trace to spoke B that's in EU it will go like this,

spoke A->hub A-> core A-> Core B-> hub B-> spoke B

I'm expecting something like this

Spoke A-> hub A-> hub B -> spoke B

I guess the only way for me to get what I'm expecting is to remove the 10.0.0.0/8 to core.

what I'm expecting is the cisco router/switch routing behavior, what I mean is a longer prefix such as /24 wins but in meraki case it seems like if I have a 10.0.0.0/8 to core and then 10.10.10.0/24 through autovpn it will just prefer static all the time.

thoughts?

thanks.

[ww]

Does spoke A and Hub A have the spoke B subnet in the routing table with a green dot ?

Is there any dynamic routing between Hub A and Core A?

[PatTheCat76]

in HUB A spoke B subnet does not have a green dot but it says next hope HUB B.

hub a and core a are doing ospf. hub a will give all the spoke routes that are connected to it to core a.

same with hub b with core b.

[ww]

I would contact support to ask about this behavior. Maybe there is some vpn problem between the hubs, or some kind of backend override  or summarization.

It should work as described here

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

[alemabrahao]

Instead of a broad 10.0.0.0/8, define only the subnets that are actually behind the core.This allows AutoVPN to take precedence for more specific prefixes. 

[PatTheCat76]

yeah that's what I was thinking. but what I want to know is

usually in routing I could have a static 10.0.0.0 to X and eigrp or ospf get me 10.10.10.0/24 and the longest prefix will win. in case of meraki it doesn't seem to work that way.

[alemabrahao]

To tell you the truth, I have a scenario similar to yours, two HUBs in different data centers and both with a static route to the 10.0.0.0/8 network, and I have no problems at all.

[PhilipDAth]

That is not expected behaviour, according to my understanding.  For more information about the routing priority, please refer to this link.

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

It says:
"Overlapping Routes

Route priority dictates how traffic is routed when multiple routes exist to the same subnet. However, overlapping routes that are not identical are also present in many deployments. In this case, the most specific route will be used."

What happens if you connect spoke A to hub A (1st priority) AND hub B (second priority)?

Repeat for spoke B, hubs flipped.

[PhilipDAth]

Did you get support to configure the option that prevents hubs from using AutoVPN to connect to each other?  If so, that would cause this behaviour.

I could see someone doing that since you have your own private link between the areas.

[Brash]

Agreed on the above with checking with support.

I've had 2 or 3 times with AutoVPN routing where a backend configuration was in place and caused unexpected routing

[PatTheCat76]

so here is the real information according to cisco support.

static will always win. so if you have a 10.0.0.0/8 to core and then you get autovpns of 10.10.10.0/24 x.x.20.0/24, that 10 static will always win.

they have something in the back that allows them to change the AD of static it basically gives priority to autovpn routes over statics.

thanks.

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