Open Stack

Nice - thank you very much!


On Mon, Feb 17, 2014 at 3:01 PM, Édouard Thuleau <thuleau at gmail.com> wrote:

> 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:
>> https://launchpad.net/~dirk-computer42/+archive/c42-backport
>>
>> 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
> release also.
>
>
>> 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?
>>
>
> Here the blueprint design document
> https://docs.google.com/document/d/1sUrvOQ9GIl9IWMGg3qbx2mX0DdXvMiyvCw2Lm6snaWQ/edit, a
> good blog post
> http://assafmuller.wordpress.com/2013/10/14/gre-tunnels-in-openstack-neutron/ and
> associated FOSDEM presentation
> http://bofh.nikhef.nl/events/FOSDEM//2014/UD2120_Chavanne/Sunday/Tunnels_as_a_Connectivity_and_Segregation_Solution_for_Virtualized_Networks.webm (thanks
> 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 [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/6a5276f6/attachment.html>