[retronet] WireGuard and MPLS vs VXLAN…

[Grant Taylor]

On 09/09/2018 10:37 AM, Grant Taylor via retronet wrote:
> I want to spend some time working with WireGuard and seeing how well 
> it's going to scale with multiple users.  Do we need to have multiple 
> WireGuard interfaces?  Can we put everybody on one central WireGuard 
> interface?  What about people that have multiple RetroNet node?  Do we 
> put members on separate VXLAN Network IDs (a.k.a. VNIs)?  In short, how 
> do we take this to the next level and make things function at scale.

I did some more work with WireGuard and can now answer some of the 
questions:

Q:  Do we need to have multiple WireGuard interfaces?
A:  I was able to successfully put VPNs to multiple members on a single 
WireGuard interface.

I did run into an issue when I first tested things.  WireGuard 
apparently picks which VPN to use based on the IPs that are allowed on a 
VPN with another member.  Originally I had all the VPNs in a common /24. 
  I ended up changing to a /30 range for each VPN.  This allowed 
WireGuard to properly choose which VPN to use under a WireGuard interface.

Q:  Can we put everybody on one central WireGuard interface?
A:  I had not problems putting multiple VPNs on the same WireGuard 
interface.  (Ignoring the addressing issue.)

I don't know how many people we will be able to put on a single 
WireGuard interface, much less if we will run into a scaling issue on 
the RetroNet core VPN concentrators.

Q:  What about people that have multiple RetroNet node?
A:  I think we will need to be somewhat judicious in how we identify 
member nodes.  I don't foresee this becoming a problem.

Q:  Do we put members on separate VXLAN Network IDs (a.k.a. VNIs)?
A:  ¯\_(ツ)_/¯

I still don't know how to answer this.  I suspect we will want different 
VNIs to filter / switch / route VPNs for people that pass through the 
RetroNet core instead of direct member-to-member VPNs.

I do think that even the member-to-member VPNs can go under the same 
single WireGuard interface on member's equipment.  The allowed IPs will 
very likely handle disambiguating that.

We may want to use different VNIs for different protocols in RetroNet 
Core.  That way we don't have to have support for all protocols on all 
core equipment.  IP stuff goes one way, IPX goes another, and DECnet 
goes over there, etc.

Q:  How do we take this to the next level and make things function at scale.
A:  I don't foresee any issues with the configuration that I've proposed 
thus far.  Of course I didn't foresee the issues with MPLS either.  So … 
this is still subject to change, possibly considerable change.

In my (not so) humble opinion, RetroNet has now progressed from a belly 
crawl, to standing and walking forward.  It may be slowly, but I do 
think there has been a LOT of progress on RetroNet in the last 48 hours.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.chivanet.org/pipermail/retronet/attachments/20180909/a2517a81/attachment.bin>