Open Stack

Hi Andreas,

Linuxbridge is also able to use Unicast, but currently, it is only
available when l2pop is activated.
AFAIR, I saw the mix of LB agents and ovs agent working, with vxlan, l2pop
and and ARP responders turned on everywhere. You also have to tune your
vxlan module, or ovs, to make sure that every agents (LB and OVS) use the
same UDP port for vxlan.
Romil's patch might be a first step to get rid of this tuning of modules.

On Tue, Mar 24, 2015 at 9:40 AM, Andreas Scheuring <
scheuran at linux.vnet.ibm.com> wrote:

> 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
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150324/bda4b289/attachment.html>