Hi Rob,
Thank you for your answer.
Le 18/03/2019 à 21:39, Rob Janssen a écrit :
When you (and it looks like you do) abolish those internet connection points with NAT, most of the problems are already solved
After carefully reading this list for a while now, that's one of the reasons why we choosed this setup ;-) It's also very close from our old "private" design, which will make migration easier.
But it also has a drawback : our network is not full-mesh. It will mostly be dual-hub-and-spoke (hub-and-spoke with two hubs), with some additional loops between endpoints (where there's budget, and not too much mountains for 5 GHz).
even in cases where the routing is asymmetrical and not optimal.
This is another drawback : all outgoing traffic (to Internet) has to go through one of our gateways, and can not be forwareded to Internet directly by an endpoint via its local (NATted) ISP. In most locations (QRAs, low points), we are using existing end-users ISPs for VPNs. Due to how those ISP created their backbones (the LNS are not located on the island, but are in Paris/France), this will involve additional latency due to multiple and potentially unneeded crossings under the Mediterranean sea.
F/ex, a packet from my home (44.190.11.x) to Internet will use the following path : QRA (Corsica) -> my ISP xDSL PPPoE LNS (Paris) -> TKNet data center (Corsica) -> TKNet BGP endpoint (Paris) -> Internet This may seem a bit odd, but we have the same problem in our job for business VPNs, and there's not much thing we can do (unless all ISPs create a GIX on the island, but this is a little bit out of scope here, HI). Moreover, we hope to be able to reduce the latency by 1/3 via a new transit provider in the DC (current: 45ms, planned : 30ms). It's still a shorter path than a journey via San Diego, HI :-)
73 de TK1BI