[Openstack-operators] Neutron and linuxbridge
thuleau at gmail.com
Mon Feb 17 14:01:22 UTC 2014
Some inline comments.
On Mon, Feb 17, 2014 at 10:30 AM, Joe Topjian <joe at topjian.net> wrote:
> 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?
The first Linux VXLAN implementation used multicast to emulate a virtual
broadcast domain. That was the VXLAN recommendation designed on first
drafts. But VXLAN doesn't need multicast anymore and the 3.11 Linux kernel
> 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 ). 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?
Here the blueprint design document
good blog post
associated FOSDEM presentation
to Assaf Muller). The post are OVS oriented but it interesting to
understand the objectives of l2-pop mechanism driver.
Just, to precise, in ML2 plugin you can set more than one MD and mix them.
The l2-pop MD requires at least the LB or OVS MD to work and it works only
with GRE or VXLAN type drivers.
>> 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.
No, the OVS neutron implementation cannot permit to use a higher network
control. For that, you need to implement a new ML2 MD to pilot your OVS/OF
controller (as it done by plugin NEC, MD ODL...).
>> 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 . 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. :)
>>  https://review.openstack.org/#/c/71821/
>>  https://review.openstack.org/#/c/49227/
>> On Sat, Feb 15, 2014 at 12:39 PM, Joe Topjian <joe at topjian.net> wrote:
>>> 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.
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators