Spoke to Spoke routing without common hub

[srb123]

I'm planning out an Meraki AutoVPN deployment, for a very geographically dispersed client, and thinking about hub sizing and placement.

In the best practices guide they show the regional hub and spoke design outlined in this guide: Meraki Auto VPN General Best Practices - Cisco Meraki

My question is, do 2 spokes need to have a common hub to be able to communicate?

So in their example, can a host RS-A communicate with a host in RS-D?

If no, does enabling iBGP allow hubs to pass the traffic? (We will have iBGP by virtue of using eBGP into Azure vMX.)

I can live with either answer, just need to know.

[rhbirkelund]

You can not configure a site as a Spoke, without also setting a Hub Site.

And yes, unless there is some routing between the two Hub sites, each Spoke need to connect to the same Hub, for traffic to move between spoke sites.

[srb123]

I thought that might be the case.

I was hoping that it wasn’t, it would be nice to define the nearest regional hubs to really small sites, and let those hubs relay the occasional voice call to distant sites. Might’ve meant 60 less tunnels in my particular topology.

But I guess I can set a datacenter as a secondary or tertiary hub for everyone and let it handle it, 60 tunnels is probably nothing in the grand scheme of things.

[Dunky]

The annoying bit is that in an environment where all I need is site-site VPNs to Azure from my sites using the native Azure VPN, Meraki forces me to create a hub - I have no need for a hub so I then have to create rules to block all traffic to ensure my sites cannot talk to each other via an unwanted hub.

[alemabrahao]

The answer is yes. You need a hub and the hub have to be the same for both spokes.

[srb123]

Yep, I know Hubs are essential to is, I think I'll end up having around 8.

[Ryan_Miles · Accepted solution]

Hubs create tunnels between each other. So, in that example diagram yes host A would be able to reach host D

[srb123]

It's curious that I got 2 answers saying it can't, and then 1 saying it can.

Is anyone out there got experience with this? Both answers have good and interesting features and limitations.

If it isn't fully routed, you can create segmentation which might be useful for preventing lateral movement.

If it is fully routed, you can create scalability, and let the hubs form a backbone network between regions, without having to have a huge number of barely used tunnels.

Feels like I just need to get 4 MX's and perform my own experiments, because the answers here, and the ambiguous wording of the Best Practices isn't confidence inspiring.

[alemabrahao]

My friend, what we are trying to say is that the use of a hub is necessary.

If you have two hubs they will automatically close the tunnel between themselves, and the spokes only close the tunnel with their respective hubs, and yes you will receive the route from the hub that is not configured as the hub of your network but keep in mind that in case the hub configured for your network has some kind of outage you will no longer learn the route from the hub that is not configured as a hub for that spoke. Couldn't I be clear?

[srb123]

You are clear, my friend.

And this was never about not having hubs, for me it was about how many and where.

[Ryan_Miles]

Well, #1 I work here 😉 And #2 I've helped deploy tens of thousands of MXs over the past decade for the largest customers Meraki has. So, yes it works 😉

I suppose the main takeaway from this thread if that having a spoke point to at least 2 hubs for redundancy is ideal. That could be a MX HA pair in one DC, but that means the DC is the single point of failure. So, typically you're hubs would live in 2 or more DCs for physical diversity. 

The regional based hub design as shown HERE works fine. And, in that specific diagram each spoke does point to 2 hubs. So, it has the redundancy piece covered. 

[srb123]

Got it. Thanks for helping clear that up, it appears that more and a few people weren’t aware this was possible.

[PhilipDAth]

@Ryan_Miles is correct - spokes don't require a hub in common to talk to each other.

[rhbirkelund]

I'm not that too ashamed to admit when I'm mistaken. I hate it when it happens, but it does so happen. So by all means, correct me if I'm wrong.

If Spoke A is configure with Hub A and no other, and Spoke B is configured with Hub B, and no other in the list, is Spoke A still able to reach Spoke B?

Will Spoke A routingtable be populated with Spoke B subnets via Hub A -> Hub B?

[PhilipDAth]

>Spoke A still able to reach Spoke B?

>Will Spoke A routingtable be populated with Spoke B subnets via Hub A -> Hub B?

Correct.

[rhbirkelund]

Hm.. Thanks for clearing that up! 😄

[srb123]

This is a much better way of asking my question, thank you.