Implement VXLAN

[philips]

Take advantage of in-Kernel VXLAN implementation which would reduce the overhead significantly of the UDP tunnel.

Looking at this briefly we would need to do a few things:

• Test out that it works: https://www.kernel.org/doc/Documentation/networking/vxlan.txt
• Write a Go library to manage it
• Ensure we have the latest iproute2 tools

References: http://en.wikipedia.org/wiki/Distributed_Overlay_Virtual_Ethernet#Implementations

[marineam]

We already ship 3.8.0, which is when the DOVE was added. That is also the current "stable" version in Gentoo. Will scan the release notes for important fixes since then but otherwise I'll consider that part ready to go. I think we need to enable it in the kernel, iirc there's a bug somewhere requesting that too.

[marineam]

This may be applicable: http://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=7cfa3802ca3e9078cd8f6c9638a0c25a63f5ddd8

That landed in 3.11 so we'll need to bump the ebuild to at least that version.

[eyakubovich]

I didn't know that there are alternate ways to manipulate the virtual MAC -> VTEP IP entries (bridge utility, netlink, unicast UDP). That does make it possible to use it without multicast. There's still extra space overhead with this solution: 14 bytes Ethernet header + 8 bytes VXLAN header but it's not a show stopper.

[philips]

One thing I can't figure out is do you have to setup the route per mac
address or can you assign a subnet as we can do with our userspace thing
now?

On Sun, Aug 24, 2014 at 10:34 PM, Eugene Yakubovich <
[email protected]> wrote:

I didn't know that there are alternate ways to manipulate the virtual MAC
-> VTEP IP entries (bridge utility, netlink, unicast UDP). That does make
it possible to use it without multicast. There's still extra space overhead
with this solution: 14 bytes Ethernet header + 8 bytes VXLAN header but
it's not a show stopper.

—
Reply to this email directly or view it on GitHub
#18 (comment).

[pquerna]

One kinda crazy idea, make the multi-cast address your tun/tap device, pop it up to userspace, and then your high level code can decide what to do with broadcast packets. (if there isn't an easier way)

Nevermind, looked more, it seems you just want to use L2MISS and L3MISS messages from netlink and you can avoid all the multicast business.