[ovs-dev] [PATCH net-next] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode

[wenxu]

On 3/25/2019 9:47 AM, Tonghao Zhang wrote:
> On Mon, Mar 25, 2019 at 9:24 AM wenxu <wenxu at ucloud.cn> wrote:
>> On 2019/3/25 上午2:46, Pravin Shelar wrote:
>>> On Sun, Mar 24, 2019 at 12:03 AM wenxu <wenxu at ucloud.cn> wrote:
>>>> On 2019/3/24 上午5:39, Pravin Shelar wrote:
>>>>> On Sat, Mar 23, 2019 at 2:18 AM wenxu <wenxu at ucloud.cn> wrote:
>>>>>> On 2019/3/23 下午3:50, Pravin Shelar wrote:
>>>>>>
>>>>>> On Thu, Mar 21, 2019 at 3:34 AM <wenxu at ucloud.cn> wrote:
>>>>>>
>>>>>> From: wenxu <wenxu at ucloud.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:ffactions=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.
> One question, why do you flood the ff:ff:ff:ff:ff:ff packets to  many
> tunnel peer, in the cloud, this should be avoid(e.g arp). Because we
> use the control plane to control the packets to vm/host related, not
> all vm/host
>
> It' not only for arp, Some user also needs the IP broadcast service. Anyway it's a use-case.