[Openstack-operators] Neutron and linuxbridge

Joe Topjian joe at topjian.net
Mon Feb 17 09:30:08 UTC 2014

Hi Édouard,

Thank you for the info. Please see inline.

On Mon, Feb 17, 2014 at 9:20 AM, Édouard Thuleau <thuleau at gmail.com> wrote:

> Hi Joe,
> Which version of the Linux kernel do you use? Do you need to set multicast
> on your fabric?

I'm using 3.11 in Ubuntu 12.04.4. I'm also using a newer version of
iproute2 from this ppa:

AFAIK, I don't require multicast. Is there a good reason or use of
multicast at the cloud/infrastructure level?

We worked in Havana to improve the overlay propagation on the fabric and we
> made a mechanism driver for the ML2 plugin called 'l2-pop' (one bug still
> persist on H [1]). Did you use it?

I'm using the linuxbridge mechanism driver at the moment. I'm unable to
find any documentation on the l2pop driver. Could you explain what it is
and why I should use it?

> In my opinion, the LB agent with VXLAN is very simpler (no flows, kernel
> integrated, 1 bridge = 1 network, netfilter aware...) and as effective than
> OVS agent. And I think, it's more stable than OVS.

Speaking of flows, a topic that has come up in discussion is the use of
OVS, OpenStack, and OpenFlow. We have some network guys who are getting
into OpenFlow, OpenDaylight et al. With the current Neutron OVS
implementation, is it incorrect to say that there is no way to take
advantage of a higher level of network control at the moment? Meaning: it
seems to me like the OVS implementation is simply being used as a complex
drop-in replacement of the linux bridge system.

> The only one inconvenient, it needs for the moment, a recent Linux kernel
> (and iproute2 binaries, obviously). I recommend the release 3.11 (version
> distributed with Ubuntu LTS 12.04.4 actually) to have all the powerful of
> the VXLAN module (edge replication for multicast, broadacst and unknown
> unicast). Some distributions backport that module on older kernel (like
> RedHat, it seems to me).
> Another improvement, a local ARP responder (to avoid ARP broadcasting
> emulation overlay which is costly) is available with VXLAN module and
> recent iproute2 version and the l2-pop MD uses it, while the OVS agent
> doesn't yet support it [2]. Just a remark, when it's used, unknown unicast
> (packets where destination does not match entry in fdb populated by the
> l2-pop MD) are drop by default (it's not configurable. A kernel an iproute2
> improvement needed).

Thank you for noting this.

> In my opinion, the default agent that OpenStack CI should use for testing
> must be the LB agent. I think it's more stable and easy to debug.

Since I'm not a developer, I can't comment on the CI aspect, but I'd be
inclined to agree. I share your opinion, but more about a basic, generic
reference installation of Neutron for new users. Now I'm trying to learn
more about why one would choose OVS over LB in order to validate that
opinion. :)

> [1] https://review.openstack.org/#/c/71821/
> [2] https://review.openstack.org/#/c/49227/
> Regards,
> Édouard.
> On Sat, Feb 15, 2014 at 12:39 PM, Joe Topjian <joe at topjian.net> wrote:
>> Hello,
>> I'm curious if anyone uses the linuxbridge driver in production?
>> I've just finished setting up a lab environment using ML2, linuxbridge,
>> and vxlan and everything works just as it did with OVS.
>> I see benefits of a *much* simpler network layout, a non-deprecated vif
>> driver, and none of the OVS issues that have been discussed on this list.
>> But maybe I'm missing something... what are the reasons of using OVS over
>> linuxbridge? All of the official installation guides use it and I've never
>> seen anyone mention linuxbridge on this list.
>> Joe
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140217/e09856be/attachment.html>

More information about the OpenStack-operators mailing list