19 Mar
2019
19 Mar
'19
9:24 a.m.
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