[Openstack-operators] Neutron and linuxbridge
Li Ma
mali at awcloud.com
Fri Feb 28 09:46:12 UTC 2014
Thanks for your reply. I'll try to do it.
---
cheer,
Li Ma
On 2/28/2014 5:09 PM, Édouard Thuleau wrote:
> Hi,
>
> I never use the 'external_network_bridge' flag to set an physiacal
> (aka provider) network.
> I prefer to set external networks with flags
> 'physical_interface_mappings' and set a flat network to use a physical
> interface or a VLAN to VLAN on a physical interface.
> Then I can create the external provider network with command:
> neutron net-create --shared public --provider:network_type flat
> --provider:physical_network public --router:external=True
>
> I attach my devstack configuration files to setup ML2/l2-pop/LB/VXLAN
> environment for a controller/compute node and a compute node.
> They are not perfect. I created them long time ago and I think lot of
> flags are no more useful but they should works. I used them last week.
>
> Édouard.
>
>
> On Thu, Feb 27, 2014 at 3:09 PM, Li Ma <skywalker.nick at gmail.com
> <mailto:skywalker.nick at gmail.com>> wrote:
>
> Hi all, I'm trying to build a testbed for Linux Bridge + VxLAN + ML2
> plugin. Could you provide hints on how to set l3-agent up.
>
> Right now, the fixed IPs are all working well, but floating IPs
> are not
> working. I find that br-ex is not set up in the right way, because
> there
> are no virtual ports on br-ex!
>
> Thanks a lot,
> --
> cheers,
> Li Ma
>
> On 2/17/2014 10:20 PM, Joe Topjian wrote:
> > Nice - thank you very much!
> >
> >
> > On Mon, Feb 17, 2014 at 3:01 PM, Édouard Thuleau
> <thuleau at gmail.com <mailto:thuleau at gmail.com>
> > <mailto:thuleau at gmail.com <mailto:thuleau at gmail.com>>> wrote:
> >
> > Some inline comments.
> >
> >
> > On Mon, Feb 17, 2014 at 10:30 AM, Joe Topjian
> <joe at topjian.net <mailto:joe at topjian.net>
> > <mailto:joe at topjian.net <mailto: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 <mailto:thuleau at gmail.com>
> <mailto:thuleau at gmail.com <mailto: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
> <https://launchpad.net/%7Edirk-computer42/+archive/c42-backport>
> >
> <https://launchpad.net/%7Edirk-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 <mailto:joe at topjian.net>
> <mailto:joe at topjian.net <mailto: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
> <mailto:OpenStack-operators at lists.openstack.org>
> > <mailto:OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> --
>
> cheers,
> Li Ma
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
---
cheers,
Li Ma
More information about the OpenStack-operators
mailing list