Allow to create tunnels between virtual bridges

EmilienM commented 3 years ago

For both hostonly (used as a provider network) and control plane bridges, we now allow them to be plugged to remote hosts bridges via VXLAN tunnels.

The new parameter is tunnel_remote_ips (default: []), where for each IP in the list, we'll create a unique tun interface, connect it to the bridge on a specific VNI (100 for control plane and 101 for hostonly).

Use-cases:

for control plane, in the case of DCN the AZ nodes need to reach the central node control plane.
for provider network, the workloads plugged on this network might want to reach another workload running on another hypervisor, therefore it makes sense to plug the provider networks together.

EmilienM commented 3 years ago

I'll rebase on top of #97

EmilienM commented 3 years ago

@mdbooth @mandre what do you think about this one?

mdbooth commented 3 years ago

Rather than bridging these private networks to an external network, could we instead add tunnels to them, and leave the routing of the tunnel traffic to the host? I'm just throwing this out there because it seems weird to bridge these networks: I have no idea if this is possible or practical. I agree we need a solution to this, though.

Perhaps @adduarte would have insight here.

EmilienM commented 3 years ago

Rather than bridging these private networks to an external network, could we instead add tunnels to them, and leave the routing of the tunnel traffic to the host? I'm just throwing this out there because it seems weird to bridge these networks: I have no idea if this is possible or practical. I agree we need a solution to this, though.

Another solution would be to connect OVS Bridges with patch ports, so no tunnels are involved. I'll test it, but honestly I don't think we should spend too much time on that business.

EmilienM commented 3 years ago

Or another solution again, is to configure the IP addresses on the dummy interfaces, and put the dummy interfaces under the br-ex bridge. So we don't have a bridge for control plane & provider network.

mdbooth commented 3 years ago

I just had a quick look at the OVS docs, and tunnels look pretty simple tbh. Almost certainly simpler than anything we'd hack up. Even an ipsec tunnel looks simple.

EmilienM commented 3 years ago

Whatever solution we pick I think it must be integrated with os-net-config, so it's persistent after a reboot and integrated with network scripts on the host.

EmilienM commented 3 years ago

this is now tested.

EmilienM commented 3 years ago

[root@standalone ~]# ovs-vsctl show
1183f4be-90c6-4425-a794-dacb2910971d
    Bridge br-ctlplane
        fail_mode: standalone
        Port tun-ctlplane-9eb947e6-a1f1-5058-be79-d18ea53077b8
            Interface tun-ctlplane-9eb947e6-a1f1-5058-be79-d18ea53077b8
                type: vxlan
                options: {key="100", remote_ip="192.168.68.132"}
        Port dummy0
            Interface dummy0
        Port br-ctlplane
            Interface br-ctlplane
                type: internal
    Bridge br-hostonly
        fail_mode: standalone
        Port dummy1
            Interface dummy1
        Port tun-hostonly-9eb947e6-a1f1-5058-be79-d18ea53077b8
            Interface tun-hostonly-9eb947e6-a1f1-5058-be79-d18ea53077b8
                type: vxlan
                options: {key="101", remote_ip="192.168.68.132"}
        Port br-hostonly
            Interface br-hostonly
                type: internal
    Bridge br-ex
        fail_mode: standalone
        Port br-ex
            Interface br-ex
                type: internal
        Port eth0
            Interface eth0
    ovs_version: "2.13.4"

ping works with the other host.

shiftstack / dev-install

Allow to create tunnels between virtual bridges #98