On Sun, Mar 24, 2019 at 6:24 PM wenxu <we...@ucloud.cn> wrote: > > On 2019/3/25 上午2:46, Pravin Shelar wrote: > > On Sun, Mar 24, 2019 at 12:03 AM wenxu <we...@ucloud.cn> wrote: > >> On 2019/3/24 上午5:39, Pravin Shelar wrote: > >>> On Sat, Mar 23, 2019 at 2:18 AM wenxu <we...@ucloud.cn> wrote: > >>>> On 2019/3/23 下午3:50, Pravin Shelar wrote: > >>>> > >>>> On Thu, Mar 21, 2019 at 3:34 AM <we...@ucloud.cn> wrote: > >>>> > >>>> From: wenxu <we...@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: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. > > OK, So it is hard to use ovs learn action, but it is doable. Given IP_TUNNEL_INFO_BRIDGE is not adding too much complexity to OVS, I am fine adding this feature.
Thanks.
