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: <77e15196-69a1-e505-f1af-d8b5507c6839@ucloud.cn>
Date:   Mon, 25 Mar 2019 09:24:00 +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/25 上午2:46, Pravin Shelar wrote:
> On Sun, Mar 24, 2019 at 12:03 AM wenxu <wenxu@...oud.cn> wrote:
>> 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.
>>
> I was referring to mac-learning feature in OVS i.e. using learn
> action. I wanted to see if there is something that you are not able to
> do with OVS learn action.
>
Ovs mac learn action is only work for the specific vxlan tunnel port（ fixed tun_dst, tun_id) like following.

ovs-vsctl set in vxlan options:remote_ip=172.168.0.1 options:key=1000

( This is the same problem for Linux bridge, It achieve this through IP_TUNNEL_INFO_BRIDGE mode work

with the fdb of lower vxlan device)


But it is not work for the flow based tunnel (remote_ip=flow),  There will be huge number of the tunnel peer.

It' hard to manage the tunnel port with the specific mode.