Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Container Networking with Vxlan, BGP and WireGuard

flockport.com

Post reply on HN
Print view View original

1–10 of 45 posts

Re: Container Networking with Vxlan, BGP and WireGuard

#3

Post by exabrial »

Site 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 setting it up, but it'd need to be automated somehow for anything above a handful of systems :/

Re: Container Networking with Vxlan, BGP and WireGuard

#4

Post by geofft »

chaz6 wrote: post #2

Can 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 broadcast, which is just like reconfiguring your physical network to bridge all your layer 2 segments into one: if that won't work for you in IPv4, it won't work in IPv6. (And at worst, it stops routing correctly.) If you don't have multicast support at all in your network infrastructure, which as the article points out isn't common to have on cloud networks, then IPv6 won't be able to help you. You'll still need fancy routing and tunneling to make things work, whether you address machines with IPv4 and IPv6.

In my experience, IPv4 has the strong advantage of being familiar and well-supported, which means that when (not if) your network infrastructure starts to act up, it's easier to figure out what's going on. IPv6 works great if you have robust, reliable multicast support on all your devices and nothing ever goes wrong.

Re: Container Networking with Vxlan, BGP and WireGuard

#5

Post by amaccuish »

exabrial wrote: post #3

Site 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

Re: Container Networking with Vxlan, BGP and WireGuard

#6

Post by corndoge »

This 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

Re: Container Networking with Vxlan, BGP and WireGuard

#7

Post by q3k »

corndoge wrote: post #6

This 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

Or abandon that cursed mostly-academic codebase entirely and switch to BIRD, which is what people actually run in production.

Re: Container Networking with Vxlan, BGP and WireGuard

#8

Post by api »

geofft wrote: post #4
chaz6 wrote: post #2

Can 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…

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 addresses into v6 addresses.

Re: Container Networking with Vxlan, BGP and WireGuard

#9

Post by corndoge »

q3k wrote: post #7
corndoge wrote: post #6

This 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

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 implementation - but it is disingenuous to say FRR isn't used in production.

Re: Container Networking with Vxlan, BGP and WireGuard

#10

Post by kortilla »

corndoge wrote: post #6

This 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.

Post reply on HN