Does anyone else think that there’s something off with the maths in this doc:
This is what's in the docs:
So, there are two formulas, the first one is to be used for hub-and-spoke deployments and the second one is supposed to be used with full mesh deployments.
I’ve got a couple of remarks:
Full Mesh
Now for the calculations, I’m going to start with the full mesh formula as it’s the simplest one and we can build on that to calculate the other formula.
I’m going to use N for the number of hubs and L for the number of uplinks just like in the docs.
Let’s say we have 3 MX’s and each uses a single uplink:
It’s clear to see that we have 2 tunnels per MX (one less than the number of MX’s) and 3 in total.
It’s easy to deduct a formula from this simple case:
# tunnels per MX = N – 1 # tunnels in total = N x (N – 1) / 2
The division by 2 is because each tunnel is counted twice due to the fact it has 2 endpoints.
Now let’s say the MX’s each use 2 uplinks:
In the drawing the pairs of uplinks belonging to each MX are:
Obviously, we don’t build tunnels between the two uplinks of the same MX so there are no lines between those. Apart from that all lines have been drawn which is what I think is the reality in a full mesh with 2 uplinks per MX: each WAN link will have a VPN tunnel with each other remote WAN link (except the one on the local MX).
A little bit harder to see but still feasible: with 3 MX’s and 2 uplinks, the number of VPN tunnels per uplink is 4, so per MX it’s 8, and the total number of tunnels is 12.
The formulas then become:
# tunnels per MX = (N – 1) x L x L
# tunnels in total = N x (N – 1) x L x L / 2
Again, the division by 2 is because each tunnel is counted twice due to the fact it has 2 endpoints.
I get these numbers:
N | L | # tunnels per MX | # tunnels in total |
2 | 1 | 1 | 1 |
3 | 1 | 2 | 3 |
4 | 1 | 3 | 6 |
5 | 1 | 4 | 10 |
10 | 1 | 9 | 45 |
20 | 1 | 19 | 190 |
30 | 1 | 29 | 435 |
40 | 1 | 39 | 780 |
50 | 1 | 49 | 1225 |
100 | 1 | 99 | 4950 |
200 | 1 | 199 | 19900 |
300 | 1 | 299 | 44850 |
400 | 1 | 399 | 79800 |
500 | 1 | 499 | 124750 |
1000 | 1 | 999 | 499500 |
2 | 2 | 4 | 4 |
3 | 2 | 8 | 12 |
4 | 2 | 12 | 24 |
5 | 2 | 16 | 40 |
10 | 2 | 36 | 180 |
20 | 2 | 76 | 760 |
30 | 2 | 116 | 1740 |
40 | 2 | 156 | 3120 |
50 | 2 | 196 | 4900 |
100 | 2 | 396 | 19800 |
200 | 2 | 796 | 79600 |
300 | 2 | 1196 | 179400 |
400 | 2 | 1596 | 319200 |
500 | 2 | 1996 | 499000 |
1000 | 2 | 3996 | 1998000 |
I highlighted my numbers for the example they give in the docs. I don’t get 2450, not for the number of tunnels per MX and not for the total number of tunnels.
For me the relevant number which you need to check against the value in the datasheet is the second column: the number of tunnels per MX. This number should be lower than the supported number of tunnels in the datasheet.
That number is 196 tunnels when you have 50 MX’s in full mesh. That means MX100, which can support 250 tunnels, would be sufficient and not the MX450 mentioned in the docs?
Hub & Spoke
Now for the hub & spoke case. I’ll be introducing the parameters S for the number of spokes, L1 for the number of uplinks on the hubs and L2 for the number of uplinks on the spokes, just like in the docs.
For the tunnels in between the hubs we can reuse the previous formula. We add to that the tunnels from the spokes to each hub in the second part of the formula. I assume for simplicity that each spoke keeps tunnels with each hub.
# tunnels per MX used as hub = (N – 1) x L1 x L1 + S x L2 x L1 # tunnels per MX used as spoke = N x L2 x L1 # tunnels in total = N x (N – 1) x L1 x L1 / 2 + S x L2 x N x L1
For the last formula I just took the total number from the full mesh and added the total number of tunnels for the spokes, nothing is counted double there.
In the example given that means:
# tunnels per MX used as hub = (4-1) x 2 x 2 + 100 x 2 x 2 = 12 + 400 = 412 # tunnels per MX user as spoke = 2 x 4 x 2 = 16 # tunnels in total = 4 x 3 x 2 x 2 / 2 + 100 x 2 x 4 x 2 = 1624
This again is different from the 1212 given in the docs.
What do you all think? It's entirely possible I'm making mistakes in my reasoning/calculations. In that case, please let me know. Also, do you agree that it's the number of tunnels per MX that counts, and that the total is less important?
I think you are right. Perhaps @CameronMoody could take a closer look at that documentation. At a minimum the maths should be cleaned up and using "x" for both a variable and for a multiplication symbol should be changed.
Thanks for the confirmation! To be fair, it's not that they're using x as a variable. This issue is that it seems like they don't consistently add it where needed in the formulas. This is a bit confusing, especially like in this case in front of a 2, because it could be an issue with superscript failing and it actually being meant as power of 2.
Thanks for you for your post, but I'm asking a question..
First of all: in a Meraki mesh topology, all tunnels are statically or dinamically created ?
This cloud change the real number of the concurrent tunnel supported by every MX...
I havent found nothing about this.
Thank you.
I case of an MX appliance on a spoke site with a cellular interface for back-up (e.g. MX67C), what is the number of links (L2)? I would say the VPN-tunnel over the cellular networks is only active at failover, so remains L2=1 (equal number of physical links).
Is that correct ?
So far as I'm aware the cellular interface on the MX67C/MX68WC are still only for failover in the event that your WAN interfaces both go down. Therefore, L2 is still only 1 in your scenario (assuming you're only using WAN1, and not WAN2) as the cellular link won't kick-in unless the link on WAN1 fails.
Integrated MX cellular can now be configured as an active uplink. So, it would be consider as a WAN in the context of AutoVPN tunnel math.
Very old thread I know, but I wanted to add a link to a google sheet Tunnel Calculator in case anyone stumbles across this thread via search. If you spot any errors in the calculator let me know via PM.
https://docs.google.com/spreadsheets/d/11eeTkL_xALtnGCNwPZRyJ6kJtCrVyzdetnUsDus6HrY/edit?usp=sharing