SD-WAN topology & MX sizing

[FRanky]

Regarding the SDWAN topology sizing, we have to comply with the MX sizing guide which indicates the maximum number of tunnels per MX model :

e.g.: for an M64, this max is 50 tunnels and for an MX84 it's 100 tunnels max and for MX100 it's 250 tunnels max.

1) If we take the hub&spoke VPN topology for an SD-WAN overlay with 'n' deployed sites, this tunnels number 'T' follows the logical rule T=4x(n-1). Hence, if we have 10 sites with 1 hub and 9 spokes (each site having a MX with 2 WAN ports), this makes T=36 tunnels= 4x(10-1) which allows 10xMX64 to be deployed; for 20 sites this makes T=76 and we need 20xMX84 (no more MX64 possible); for 50 sites, T= 196 and we need 50xMX100 _ according to Meraki whitepaper MX sizing guide ('concurrent VPN tunnels*' line)

2) Has anyone made any calculation for an SD-WAN meshed/any to any VPN topology, which naturally upsizes the number of tunnels above the hub&spoke case above? With the same reasoning in terms of number of SD-WAN tunnels but applied to the any-to any case here, I made some rapid calculations:

10 sites	20 sites	50 sites
180 tunnels per MX so we need 10xMX100	760 tunnels per MX so we need 20xMX400	4900 tunnels per MX so we need 50xMX600

Can anyone confirm these orders of magnitude and model sizing, please? Many thanks

[Uberseehandel]

Airlines solved this problem by consolidating on a few hubs to cut down on the number of different flight destinations.
When I have a lot of peers, in a dispersed network, I usually build a ring with a handful of cross ring connects, and build in some routing smarts.

[FRanky]

Yes I understand what you say, BUT how does it apply to SDWAN as this overlay needs to probe the tunnel quality between each other? If you attach some MX of your network to some hubs you're losing this direct & interactive probing between the MX of the other branch you built depending from another hub. Does this SDWAN is still functioning conceptually?

[PhilipDAth]

It is not worked out that way.  VPNs are only built between spokes and hubs.  Spokes do not build VPNs to other spokes.  Hubs do build VPNs to other hubs.

If you have 20 remote branches terminating on 1 hub, then each remote branch has a single VPN and the hub would end up with 20 VPNs.

If you were usual dual Internet connections at each branch and SDWAN, then each branch would have 2 VPNs, and the hub would have 40 VPNs.

[PhilipDAth]

If you really were deploying a full mesh by making every site a hub and assuming each site has a single Internet circuit, then the number of VPNs per site would be:

n x (n-1)/2

So if you have 10 sites that would be 45.

So if you have 20 sites that would be 190.

So if you have 50 sites that would be 1225.

[FRanky]

1-Here you are describing a hub&spoke topology with a single WAN (internet) uplink while my topic is for a dual uplink WAN for each site in the case of SDWAN. The magnitude is more when you have an SDWAN with dual port/WAN at each location and probing against each other the realtime SDWAN thresholds;

2-I've asked the question for the other topology which an SDWAN customer may want and  they may not want to depend on one hub which all the other sites goes only through it to exchange and this is my second question actually of my question:

"2) Has anyone made any calculation for an SD-WAN meshed/any to any VPN topology, which naturally upsizes the number of tunnels above the hub&spoke case above? With the same reasoning in terms of number of SD-WAN tunnels but applied to the any-to any case here, I made some rapid calculations:

10 sites	20 sites	50 sites
180 tunnels per MX so we need 10xMX100	760 tunnels per MX so we need 20xMX400	4900 tunnels per MX so we need 50xMX600

Can anyone confirm these orders of magnitude and model sizing, please? Many thanks

[MerakiDave · Accepted solution]

While I believe an updated version of the MX Sizing Guide is in the works and not released quite yet but should be any day now, for your 10, 20 and 50 site cases with 180, 760 and 4900 VPN tunnels, your appropriate current MX models should be MX100, MX250 and MX450 respectively.

[Billy]

How does the autoVPN works on the Meraki devices? Lets say that we have 50 sites using SD-WAN meshed/any to any VPN topology (2x WAN links for each site).

Does each site establish tunnels with all of the other sites, regardless of whether there's actual traffic going through those tunnels?

Or does it auto establish tunnels when there's actual need for traffic to pass from one specific site to another one and drops the tunnel after an x amount of time that the tunnel is idle?

A branch office for example, would be required to be able to communicate mainly with 3x datacenters and occasionally with a couple more branch offices. Would it still be required to use the MX450 that would be able to handle 4900 VPN tunnels?

[PhilipDAth]

>Does each site establish tunnels with all of the other sites, regardless of whether there's actual traffic going through those tunnels?

If you configure a full MESH - then yes, a tunnel is formed over both WAN connections to every site.  SDWan actively measures every VPN so it can tell how to apply any performance based traffic policies.

If branches don't normally need to talk directly to each other (or only do it occasionally) then you would not configure a full mesh.  Branches can still communicate with each other via a hub.

The below image is an example from one of my clients.  This is a single site that has dual WAN connections and two SDWAN performance classes defined, one for RDP and one for VoIP.  The screen shot is the stats between two of the sites - and you have this for every site you have a VPN connection to.

[Billy]

How did you get that screen with all of those statistics? If I go to Organisation > VPN status I can only see statistics for latency and usage

[PhilipDAth]

You need to try randomly click on things (that is how I found it the first time).

Go:

Security Appliance/VPN Status

Then click anywhere on a listed VPN except the hyperlink name (such as the VPN status, Usage, Latency, etc).

[Billy]

Thanks again!

[PhilipDAth]

ps. I've done a lot of deployments and never done a full VPN mesh yet. I tend to allow branches to only communicate with each other via a hub/DC.

[Billy]

I suspected that this would be the case.Thanks for confirming that PhilipDath.
Communicating through DC/hubs will work for my case