Open Stack

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> 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>> wrote:
> >
> >     Some inline comments.
> >
> >
> >     On Mon, Feb 17, 2014 at 10:30 AM, Joe Topjian <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>> 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>
> >
> >         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>> 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>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> --
>
> cheers,
> Li Ma
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140228/069eb7af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local.conf_ML2_LB_l2-pop_compute
Type: application/octet-stream
Size: 559 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140228/069eb7af/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local.conf_ML2_LB_l2-pop_controler
Type: application/octet-stream
Size: 779 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140228/069eb7af/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: localrc_ML2_LB_l2-pop_compute
Type: application/octet-stream
Size: 785 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140228/069eb7af/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: localrc_ML2_LB_l2-pop_controler
Type: application/octet-stream
Size: 1108 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140228/069eb7af/attachment-0003.obj>