netdev - Re: [PATCH net-next] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO

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: <59198021-b7fd-6fd8-2a43-b45899fdda10@ucloud.cn>
Date:   Sun, 24 Mar 2019 15:03:38 +0800
From:   wenxu <wenxu@...oud.cn>
To:     Pravin Shelar <pshelar@....org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        ovs dev <dev@...nvswitch.org>
Subject: Re: [PATCH net-next] openvswitch: Make metadata_dst tunnel work in
 IP_TUNNEL_INFO_BRIDGE mode

On 2019/3/24 上午5:39, Pravin Shelar wrote:
> On Sat, Mar 23, 2019 at 2:18 AM wenxu <wenxu@...oud.cn> wrote:
>> On 2019/3/23 下午3:50, Pravin Shelar wrote:
>>
>> On Thu, Mar 21, 2019 at 3:34 AM <wenxu@...oud.cn> wrote:
>>
>> From: wenxu <wenxu@...oud.cn>
>>
>> There is currently no support for the multicasti/broadcst aspects
>> of VXLAN in ovs. In the datapath flow the tun_dst must specific.
>> But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
>> And the packet can forward through the fdb of vxlan devcice. In
>> this mode the broadcast/multicast packet can be sent through the
>> following ways in ovs.
>>
>> ovs-vsctl add-port br0 vxlan -- set in vxlan type=vxlan \
>>         options:key=1000 options:remote_ip=flow
>> ovs-ofctl add-flow br0 in_port=LOCAL,dl_dst=ff:ff:ff:ff:ff:ff,\
>>         action=output:vxlan
>>
>> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.1 \
>>         src_vni 1000 vni 1000 self
>> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.2 \
>> src_vni 1000 vni 1000 self
>>
>> This would make datapath bit complicated, can you give example of such use-case?
>>
>> There is currently no support for the multicast/broadcast aspects
>> of VXLAN in ovs. To get around the lack of multicast support, it is possible to
>> pre-provision MAC to IP address mappings either manually or from a controller.
>>
>> With this patch we can achieve this through the fdb of the lower vxlan
>> device.
>>
>> For example. three severs connects with vxlan.
>> server1 IP 10.0.0.1 tunnel IP  172.168.0.1 vni 1000
>> server2 IP 10.0.0.2 tunnel IP  172.168.0.2 vni 1000
>> server3 IP 10.0.0.3 tunnel IP  172.168.0.3 vni 1000
>>
>> All the broadcast arp request from server1, can be send to vxlan_sys_4789
>> in IP_TUNNEL_INFO_BRIDGE mode. Then the broadcast packet can send through
>> the fdb table in the vxlan device as following:
>>
>> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.1 \
>>         src_vni 1000 vni 1000 self
>> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.2 \
>> src_vni 1000 vni 1000 self
>>
>>
>> Not any for multicast case. This patch make ovs vxlan tunnel using the fdb
>> table of lower vxlan device.
> Have you tried OVS mac learning?
>
The key point is that it makes ovs vxlan tunnel can make use of the fdb table of lower vxlan device.

The fdb table can be configurable or mac learning from outside.

For the broadcast example.  In the ovs, it can only achieve this through multiple output actions to simulate the broadcast.

ovs-ofctl add-flow br0 in_port=server1,dl_dst=ff:ff:ff:ff:ff:ff,actions=set_field:172.168.0.1->tun_dst,output:vxlan,\

    set_field:172.168.0.2->tun_dst,output:vxlan.

But there are some limits for the number of output actions.