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]

Date:   Tue, 21 Sep 2021 13:20:08 +0200
From:   Luis Tomas Bolivar <ltomasbo@...hat.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Antoine Tenart <atenart@...nel.org>, davem@...emloft.net,
        kuba@...nel.org, pshelar@....org, dsahern@...nel.org,
        dev@...nvswitch.org, netdev@...r.kernel.org,
        Eelco Chaudron <echaudro@...hat.com>
Subject: Re: [PATCH net-next] openvswitch: allow linking a VRF to an OVS bridge

On Tue, Sep 21, 2021 at 10:12 AM Luis Tomas Bolivar <ltomasbo@...hat.com> wrote:
>
> 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.

Follow up on this. I found the mistake I was making on the veth-pair
addition configuration (ovs flow was setting the wrong mac address
before sending the traffic through the veth device to the vrf). And it
indeed works connecting the VRF to the OVS bridge by using a veth pair
instead of directly plugin the VRF device as an OVS port.

>
> Best regards,
> Luis



-- 
LUIS TOMÁS BOLÍVAR
Principal Software Engineer
Red Hat
Madrid, Spain
ltomasbo@...hat.com