netdev - Re: [PATCH net-next] openvswitch: allow linking a VRF to an OVS bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAxCcbsrjvp=vP_0Nz+pYCVMDWSxnDAjdVXWYczNZfaAtc6kZw@mail.gmail.com>
Date:   Tue, 21 Sep 2021 10:12:29 +0200
From:   Luis Tomas Bolivar <ltomasbo@...hat.com>
To:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next] openvswitch: allow linking a VRF to an OVS bridge

On Mon, Sep 20, 2021 at 5:45 PM David Ahern <dsahern@...il.com> wrote:
>
> On 9/20/21 9:34 AM, Antoine Tenart wrote:
> > There might be questions about the setup in which a VRF is linked to an
> > OVS bridge; I cc'ed Luis Tomás who wrote the article.
>
> My head just exploded. You want to make an L3 device a port of an L2
> device.
>
> Can someone explain how this is supposed to work and why it is even
> needed? ie., given how an OVS bridge handles packets and the point of a
> VRF device (to direct lookups to a table), the 2 are at odds in my head.
>

Hi David,

Thanks for your comment. And yes you are right, this probably is a bit
of an odd setup. That said, OVS is not pure L2 as it knows about IPs
and it is doing virtual routing too (we can say it is 2.5 xD)

What we want to achieve is something similar to what is shown in slide 100
here http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf, but instead
of connecting the VRF bridge directly to containers, we have a single ovs
bridge (where the OpenStack VMs are connected to) where we connect the
vrfs in different (ovs) ports (so that the traffic in the way out of OVS can be
redirected to the right VRF).

The initial part is pretty much the same as in the slide 100:
1) creating the vrf
   - ip link add vrf-1001 type vrf table 1001
2) vxlan device, in our case associated to the loopback,
for ECMP (instead of associate both nics/vlan devices to the VRF)
   - ip link add vxlan-1001 type vxlan id 1001 dstport 4789 local L_IP
nolearning
3) create the linux bridge device
   - ip link add name br-1001 type bridge stp_state 0
4) link the 3 above
   - ip link set br-1001 master vrf-1001 (bridge to vrf)
   - ip link set vxlan-1001 master br-1001 (vxlan to bridge)

Then, I'm attaching the vrf device also as an ovs bridge port, so that
traffic (together with some ip routes in the vrf routing table) can be
redirected
to OVS, and the (OpenStack) virtual networking happens there
(br-ex is the ovs bridge)
   - ovs-vsctl add-port br-ex vrf-1001
   - ip route show vrf vrf-1001
       10.0.0.0/26 via 172.24.4.146 dev br-ex
       (redirect traffic to OpenStack subnet 10.0.0.0/26 to br-ex)
       172.24.4.146 dev br-ex scope link

Perhaps there is a better way of connecting this?
I tried (without success) to create a veth device and set one end on
the linux bridge and the other on the OVS bridge.

Best regards,
Luis