[deleted]
Container Networking with Vxlan, BGP and WireGuard
11–20 of 45 posts
Re: Container Networking with Vxlan, BGP and WireGuard
#12Can we have a version using IPv6 instead of legacy IPv4? It would make things a lot simpler (no need for any fancy routing or nat).
IPv6 doesn't save you from any routing problems that IPv4 won't save you from. While IPv6 tries to hide the layer 2/layer 3 distinction from you, it doesn't actually make your physical network magically work differently. Internally IPv6 tries to implement this hiding using multicast - same as the VXLAN suggestion in the article. If you overload your network infrastructure's multicast support, at best you fall back to…
IPv4 numbering sucks. IPv6 lets you stop worrying about that.
In IPv4 you're going to need RFC1918 addresses, and then you're going to have to make sure that _your_ RFC1918 addresses don't conflict with any _other_ RFC1918 addresses that inevitably absolutely everything else is using or else you'll get hard-to-debug confusion. No need in IPv6, you should use globally unique addresses everywhere, there are plenty and you will not run out.
Everybody who has ever used a single byte to store a value they were convinced wouldn't need to be more than a few dozen, and then it blew up because somebody figured 300 ought to fit and it doesn't already knows in their heart that they shouldn't be using IPv4 in 2019.
Re: Container Networking with Vxlan, BGP and WireGuard
#13Earlier quoted context omitted.
Or abandon that cursed mostly-academic codebase entirely and switch to BIRD, which is what people actually run in production.
FRR is used in production and isn't academic, I don't know where you got that impression. Microsoft runs FRR on SONiC. Vyos runs FRR. 6wind runs FRR. Cumulus Networks runs FRR. Juniper runs FRR in certain products. VMware runs FRR. Broadcom is integrating it. I don't think you are very familiar with the scope of changes that have gone in since Quagga. Not to detract from BIRD - which is a great, solid BGP implementat…
You're right! I guess I haven't looked enough into whiteboxes/appliances recently.
Re: Container Networking with Vxlan, BGP and WireGuard
#14Site is having issues atm... but I'll throw something out there I'd really like to see. We encrypt 100% of our machine-to-machine traffic at the TCP level. There's a lot of shuffling of certs around to get some webapp to talk to postgres, then have that webapp serve https to haproxy, etc. I'd be awesome if there was a way your cloud servers could just talk to each other using wiregaurd by default. We looked at settin…
How about MacSec? Supported by Linux as well as various router vendors. https://nextheader.net/2016/10/14/macsec-on-linux/
Re: Container Networking with Vxlan, BGP and WireGuard
#15This article uses Quagga - they really should be using FRRouting, which was forked from Quagga in 2017 by the core Quagga developers and has 4 times as many commits (16000[0] vs 4000[1]), far more features, bugfixes, etc. Quagga has been dead for over a year. [0] https://github.com/FRRouting/frr [1] http://gogs.quagga.net/Quagga
More commits, more features, and more bug(fixe)s are not really selling points for something as critical as BGP routing. Would you trust two compared TCP implementations using those stats as well? For something simple like this post, using quagga is completely fine and probably much better that using the latest Swiss Army knife.
This comment completely misses the point. There is a distinction between "complete" and "dead", to whatever degree any software can be called "complete".
The Quagga source repo[1]'s certificate expired over 6 months ago. Looking at the Bugzilla[2] report (also with an expired certificate) there are 14 blockers, 49 critical and 69 issues that have not been resolved.
So no, I'd agree with the parent comment that using a project as seemingly dead as Quagga for something as critical as BGP routing is putting yourself on shaky ground at the very least.
1. https://gogs.quagga.net/Quagga
2. https://bugzilla.quagga.net/report.cgi?x_axis_field=bug_seve...
Re: Container Networking with Vxlan, BGP and WireGuard
#16This article uses Quagga - they really should be using FRRouting, which was forked from Quagga in 2017 by the core Quagga developers and has 4 times as many commits (16000[0] vs 4000[1]), far more features, bugfixes, etc. Quagga has been dead for over a year. [0] https://github.com/FRRouting/frr [1] http://gogs.quagga.net/Quagga
More commits, more features, and more bug(fixe)s are not really selling points for something as critical as BGP routing. Would you trust two compared TCP implementations using those stats as well? For something simple like this post, using quagga is completely fine and probably much better that using the latest Swiss Army knife.
Yes, I would trust an actively developed fork of a TCP stack that is 2 years ahead of its forked project more than the original. Especially for something as critical as TCP, and equally so for BGP routing. Why use a dead project that hasn't gotten bug fixes for years?
Re: Container Networking with Vxlan, BGP and WireGuard
#17Site is having issues atm... but I'll throw something out there I'd really like to see. We encrypt 100% of our machine-to-machine traffic at the TCP level. There's a lot of shuffling of certs around to get some webapp to talk to postgres, then have that webapp serve https to haproxy, etc. I'd be awesome if there was a way your cloud servers could just talk to each other using wiregaurd by default. We looked at settin…
https://en.wikipedia.org/wiki/Tcpcrypt
How does opportunistic encryption prevent a MITM from forcing the session into unencrypted mode when its established?
Re: Container Networking with Vxlan, BGP and WireGuard
#18In my mind, a "layer 2 subnet" really doesn't mean anything. Subnets are things that happen in IP, that is, layer 3, and layer 2 is the physical connection, ie. Ethernet or WLAN, which don't have the concept of subnets.
Edit: also the OSI layer model was specified in the eighties, and isn't all that accurate in 2019 to describe how our networks actually work.
Re: Container Networking with Vxlan, BGP and WireGuard
#19Earlier quoted context omitted.
IPv6 doesn't save you from any routing problems that IPv4 won't save you from. While IPv6 tries to hide the layer 2/layer 3 distinction from you, it doesn't actually make your physical network magically work differently. Internally IPv6 tries to implement this hiding using multicast - same as the VXLAN suggestion in the article. If you overload your network infrastructure's multicast support, at best you fall back to…
IPv4 numbering sucks. IPv6 lets you stop worrying about that. In IPv4 you're going to need RFC1918 addresses, and then you're going to have to make sure that _your_ RFC1918 addresses don't conflict with any _other_ RFC1918 addresses that inevitably absolutely everything else is using or else you'll get hard-to-debug confusion. No need in IPv6, you should use globally unique addresses everywhere, there are plenty and…
Oh, yes, IPv6 saves you from worrying about addressing, which is a huge headache in IPv4. I agree with that and IPv4 address conflicts are a personal frustration. IPv6 doesn't save you from "fancy routing" and mostly does not save you from "nat," though. That's what I was responding to.
I'm hesitant to use IPv6 because it is not merely IPv4 + more addresses, it's IPv4 + more addresses + a very clever design that hides the L2 vs. L3 distinction by relying heavily on multicast groups + a replacement for ARP + a replacement for DHCP + etc. etc. etc. I know I shouldn't be using IPv4 in 2019, but I don't have a better option. I'm not excited about clever systems, hiding, the assumption that multicast works reliably, losing the last few decades of monitoring and debugging tools, happy eyeballs, etc., and I'm not willing to subject my users to the resulting outages simply because it'll save me the headache of thinking about numbering.
Re: Container Networking with Vxlan, BGP and WireGuard
#20Earlier quoted context omitted.
IPv6 doesn't save you from any routing problems that IPv4 won't save you from. While IPv6 tries to hide the layer 2/layer 3 distinction from you, it doesn't actually make your physical network magically work differently. Internally IPv6 tries to implement this hiding using multicast - same as the VXLAN suggestion in the article. If you overload your network infrastructure's multicast support, at best you fall back to…
Why can't you just do all your v6 routing at l3 and skip l2 and NDP? If you were using WireGuard which is l3 then all you would need is a way to manage the routes. Can you make BGP work without l2? I seem to think you can but I've never tried it. ZeroTier supports a mode where it emulates NDP for v6 and works without having to do multicast or broadcast at all. It does this by embedding its cryptographic hash vl1 addr…
Well, I have hardware routers that know about L2, and I'd like to have them do as much routing as possible. I'm running Quagga to advertise my VXLAN routes to my hardware routers, so packets originated on bare metal can reach my virtualized infrastructure and vice versa. I want them to know that if the machine advertising this particular IPv6 subnet is in the same rack, packets can go there and don't have to go to a dedicated gateway for all my VXLAN traffic.
I could run IPv6 on the inside and IPv4 on the outside, sure. I worry this is going to trigger more edge cases than either running IPv6 the way it was intended or IPv4 the way it was intended.