Open Stack

Mathieu, 
now I'm getting curious, is it possible to combine Linuxbridge and OVS
VXLAN Nodes in the same cloud? 

I thought this does not work as Linuxbridge-vxlan uses multicast for
instances broad- and multicasts (e.g. an arp request), while ovs-vxlan
only does unicast? At least one can specify a vxlan_group, which is a
mulitcast address, for linuxbridge vxlan.


Or is multicasting prohibited by l2_pop driver and the vxlan_group
attribute is not applicable in this case?



-- 
Andreas 
(irc: scheuran)


On Mon, 2015-03-23 at 14:49 +0100, Mathieu Rohon wrote:
> Hi romil,
> 
> 
> I think the main purpose of this DB field is to maintain the
> compatibility in dataplane between OVS and LinuxBridge which, by
> default, don't use the same UDP port for VXLAN.
> 
> It might be useful for a cloud admin which wants to run some nodes
> with LB and some others with OVS.
> 
> 
> I feel like your patch proposal will enable this scenario if the
> tunnel_update() RPC message gets updated with the UDP port too.
> 
> 
> 
> Mathieu
> 
> 
> On Mon, Mar 23, 2015 at 11:40 AM, Romil Gupta <romilgupta19 at gmail.com>
> wrote:
>         Hello everyone,
>         
>         
>         There is regarding the following bug:
>         https://bugs.launchpad.net/neutron/+bug/1373359
>         
>         
>         May I know what is the significance of having the 'udp_port'
>         field in the  'ml2_vxlan_endpoints' table in Neutron DB, Do we
>         have any plans in future that we could use this field for
>         synchronization or any other purpose instead of simply keeping
>         it in the DB.
>         
>         
>         The following patchset will fix the bug mentioned above,
>         https://review.openstack.org/#/c/153891/
>         
>         
>         But the question still remains the same. Do we need to keep
>         this field or we need to remove it? 
>         
>         
>         -- 
>         
>         Regards,
>         Romil 
>         
>         
>         
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev