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: <CAAxCcbsBTey=tSznn55BanA2H5PXitgfuC8DFg543nYjT0-igQ@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ