Container Networking with Vxlan, BGP and WireGuard • Hacker News Board

Re: Container Networking with Vxlan, BGP and WireGuard

#41

Post by KaiserPro » Sun, Aug 04, 2019, 5:32 AM UTC

stargrazer wrote: post #35

KaiserPro wrote: post #26

Earlier quoted context omitted.

I'd argue that the closest thing to a layer 2 subnet is a VLAN.

But there isn't a one to one relationship. A subnet should only be in one vlan, but there are networks where there is more than one subnet in a vlan. Whether that is appropriate or not, that would be a different topic.

Yes, but that's layer 3 +.

A VLAN will isolate macs so that only those adaptors in that VLAN can see each other. Granted, there isn't really a concept of a netmask based subnet, but then that's because you don't really have control over one's physical address.

Now, you can have an adaptor in more than one VLAN, which is the point of them. As I said its not a perfect analogy, but then they are there to achieve different things based on different semantics.

Re: Container Networking with Vxlan, BGP and WireGuard

#42

Post by utopian3 » Sun, Aug 04, 2019, 9:44 PM UTC

stargrazer wrote: post #34

KaiserPro wrote: post #25

One does not simply go from a flat network to overlays. Overlays are slow, difficult, cause really odd failures and are often hilariously immature. They are the experimental graph database of the network world. Just have a segregated network, and let the VPC/dhcp do all the hard stuff. Have your hosts on the default VLAN(or Interface if your cloudy), with its own subnet (Subnets should only exist in one VLAN.) Then i…

I will have to take the other side of that golden rule. Not sure where it came from. But when one has a decent handle on the tools at hand, they work wonderously well. I have bare metal servers tied together with L3 routing via Free Range Routing running BGP/VxLAN. It Just Works. No hard coded vlans between physical machines. Just point-point L3 links. Vlans are tortuous between machines as a Layer 2 protocol, given…

OP was mostly talking about cloud + docket containers. Your use-case is unrelated and seems to make sense.. But I still agree with OP and I believe overlays in the cloud is generally an anti-pattern of unnecessary complexity.

Re: Container Networking with Vxlan, BGP and WireGuard

#43

Post by alexandre_m » Mon, Aug 05, 2019, 1:56 PM UTC

YZF wrote: post #38

alexandre_m wrote: post #37

"Vxlan uses multicast which is often not supported on most cloud networks. So its best used on your own networks." Not entirely correct. Linux has had unicast vxlan for quite some time. Flannel is doing unicast and works pretty much anywhere. See "Unicast with dynamic L3 entries" section: https://vincent.bernat.ch/en/blog/2017-vxlan-linux

VXLAN is just encapsulating L2 VLANs in UDP packets. Sounds like some confusion about linux implementation details.

It depends on the implementation of the control plane and how you maintain the mesh between the different servers (L2L3 for arp resolution, mac learning).

Historically vxlan was a multicast thing, but not anymore.

Flannel (popular among the container networking solutions) will maintain its state in etcd by watching the Kubernetes resources then program the linux data plane with static unicast entries for the neighbors.

Re: Container Networking with Vxlan, BGP and WireGuard

#44

Post by kortilla » Fri, Aug 09, 2019, 6:53 PM UTC

orf wrote: post #15

kortilla wrote: post #10

Earlier quoted context omitted.

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…

You missed the point. It’s a demo doing trivial bgp stuff that hasn’t changed for 15 years.

It’s like someone doing a demo on some text processing where they use grep and the top comment is some jerk saying that map-reduce would be better because some new large systems use it and it’s being actively developed.

Re: Container Networking with Vxlan, BGP and WireGuard

#45

Post by kortilla » Fri, Aug 09, 2019, 7:00 PM UTC

corndoge wrote: post #16

kortilla wrote: post #10

Earlier quoted context omitted.

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?

You shouldn’t. I don’t think you realize how dangerous new features are in core products written in C. See Heartbleed.