<div dir="ltr">Hi,<div><br></div><div>I never use the 'external_network_bridge' flag to set an physiacal (aka provider) network.</div><div>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.</div>
<div>Then I can create the external provider network with command:</div><div><div>neutron net-create --shared public --provider:network_type flat --provider:physical_network public --router:external=True</div><div><br></div>
</div><div>I attach my devstack configuration files to setup ML2/l2-pop/LB/VXLAN environment for a controller/compute node and a compute node.</div><div>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.</div>
<div><br></div><div>Édouard.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 3:09 PM, Li Ma <span dir="ltr"><<a href="mailto:skywalker.nick@gmail.com" target="_blank">skywalker.nick@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all, I'm trying to build a testbed for Linux Bridge + VxLAN + ML2<br>
plugin. Could you provide hints on how to set l3-agent up.<br>
<br>
Right now, the fixed IPs are all working well, but floating IPs are not<br>
working. I find that br-ex is not set up in the right way, because there<br>
are no virtual ports on br-ex!<br>
<br>
Thanks a lot,<br>
--<br>
cheers,<br>
Li Ma<br>
<div class=""><br>
On 2/17/2014 10:20 PM, Joe Topjian wrote:<br>
> Nice - thank you very much!<br>
><br>
><br>
> On Mon, Feb 17, 2014 at 3:01 PM, Édouard Thuleau <<a href="mailto:thuleau@gmail.com">thuleau@gmail.com</a><br>
</div><div class="">> <mailto:<a href="mailto:thuleau@gmail.com">thuleau@gmail.com</a>>> wrote:<br>
><br>
> Some inline comments.<br>
><br>
><br>
> On Mon, Feb 17, 2014 at 10:30 AM, Joe Topjian <<a href="mailto:joe@topjian.net">joe@topjian.net</a><br>
</div><div class="">> <mailto:<a href="mailto:joe@topjian.net">joe@topjian.net</a>>> wrote:<br>
><br>
> Hi Édouard,<br>
><br>
> Thank you for the info. Please see inline.<br>
><br>
> On Mon, Feb 17, 2014 at 9:20 AM, Édouard Thuleau<br>
</div><div class="">> <<a href="mailto:thuleau@gmail.com">thuleau@gmail.com</a> <mailto:<a href="mailto:thuleau@gmail.com">thuleau@gmail.com</a>>> wrote:<br>
><br>
> Hi Joe,<br>
><br>
> Which version of the Linux kernel do you use? Do you need<br>
> to set multicast on your fabric?<br>
><br>
><br>
> I'm using 3.11 in Ubuntu 12.04.4. I'm also using a newer<br>
> version of iproute2 from this<br>
> ppa: <a href="https://launchpad.net/~dirk-computer42/+archive/c42-backport" target="_blank">https://launchpad.net/~dirk-computer42/+archive/c42-backport</a><br>
</div>> <<a href="https://launchpad.net/%7Edirk-computer42/+archive/c42-backport" target="_blank">https://launchpad.net/%7Edirk-computer42/+archive/c42-backport</a>><br>
<div><div class="h5">><br>
> AFAIK, I don't require multicast. Is there a good reason or<br>
> use of multicast at the cloud/infrastructure level?<br>
><br>
><br>
> The first Linux VXLAN implementation used multicast to emulate a<br>
> virtual broadcast domain. That was the VXLAN recommendation<br>
> designed on first drafts. But VXLAN doesn't need multicast anymore<br>
> and the 3.11 Linux kernel release also.<br>
><br>
><br>
> We worked in Havana to improve the overlay propagation on<br>
> the fabric and we made a mechanism driver for the ML2<br>
> plugin called 'l2-pop' (one bug still persist on H [1]).<br>
> Did you use it?<br>
><br>
><br>
> I'm using the linuxbridge mechanism driver at the moment. I'm<br>
> unable to find any documentation on the l2pop driver. Could<br>
> you explain what it is and why I should use it?<br>
><br>
><br>
> Here the blueprint design<br>
> document <a href="https://docs.google.com/document/d/1sUrvOQ9GIl9IWMGg3qbx2mX0DdXvMiyvCw2Lm6snaWQ/edit" target="_blank">https://docs.google.com/document/d/1sUrvOQ9GIl9IWMGg3qbx2mX0DdXvMiyvCw2Lm6snaWQ/edit</a>, a<br>
> good blog<br>
> post <a href="http://assafmuller.wordpress.com/2013/10/14/gre-tunnels-in-openstack-neutron/" target="_blank">http://assafmuller.wordpress.com/2013/10/14/gre-tunnels-in-openstack-neutron/</a> and<br>
> associated FOSDEM<br>
> presentation <a href="http://bofh.nikhef.nl/events/FOSDEM//2014/UD2120_Chavanne/Sunday/Tunnels_as_a_Connectivity_and_Segregation_Solution_for_Virtualized_Networks.webm" target="_blank">http://bofh.nikhef.nl/events/FOSDEM//2014/UD2120_Chavanne/Sunday/Tunnels_as_a_Connectivity_and_Segregation_Solution_for_Virtualized_Networks.webm</a> (thanks<br>
> to Assaf Muller). The post are OVS oriented but it interesting to<br>
> understand the objectives of l2-pop mechanism driver.<br>
><br>
> Just, to precise, in ML2 plugin you can set more than one MD and<br>
> mix them. The l2-pop MD requires at least the LB or OVS MD to work<br>
> and it works only with GRE or VXLAN type drivers.<br>
><br>
><br>
><br>
> In my opinion, the LB agent with VXLAN is very simpler (no<br>
> flows, kernel integrated, 1 bridge = 1 network, netfilter<br>
> aware...) and as effective than OVS agent. And I think,<br>
> it's more stable than OVS.<br>
><br>
><br>
> Speaking of flows, a topic that has come up in discussion is<br>
> the use of OVS, OpenStack, and OpenFlow. We have some network<br>
> guys who are getting into OpenFlow, OpenDaylight et al. With<br>
> the current Neutron OVS implementation, is it incorrect to say<br>
> that there is no way to take advantage of a higher level of<br>
> network control at the moment? Meaning: it seems to me like<br>
> the OVS implementation is simply being used as a complex<br>
> drop-in replacement of the linux bridge system.<br>
><br>
><br>
> No, the OVS neutron implementation cannot permit to use a higher<br>
> network control. For that, you need to implement a new ML2 MD to<br>
> pilot your OVS/OF controller (as it done by plugin NEC, MD ODL...).<br>
><br>
><br>
><br>
> The only one inconvenient, it needs for the moment, a<br>
> recent Linux kernel (and iproute2 binaries, obviously). I<br>
> recommend the release 3.11 (version distributed with<br>
> Ubuntu LTS 12.04.4 actually) to have all the powerful of<br>
> the VXLAN module (edge replication for multicast,<br>
> broadacst and unknown unicast). Some distributions<br>
> backport that module on older kernel (like RedHat, it<br>
> seems to me).<br>
><br>
> Another improvement, a local ARP responder (to avoid ARP<br>
> broadcasting emulation overlay which is costly) is<br>
> available with VXLAN module and recent iproute2 version<br>
> and the l2-pop MD uses it, while the OVS agent doesn't yet<br>
> support it [2]. Just a remark, when it's used, unknown<br>
> unicast (packets where destination does not match entry in<br>
> fdb populated by the l2-pop MD) are drop by default (it's<br>
> not configurable. A kernel an iproute2 improvement needed).<br>
><br>
><br>
> Thank you for noting this.<br>
><br>
><br>
> In my opinion, the default agent that OpenStack CI should<br>
> use for testing must be the LB agent. I think it's more<br>
> stable and easy to debug.<br>
><br>
><br>
> Since I'm not a developer, I can't comment on the CI aspect,<br>
> but I'd be inclined to agree. I share your opinion, but more<br>
> about a basic, generic reference installation of Neutron for<br>
> new users. Now I'm trying to learn more about why one would<br>
> choose OVS over LB in order to validate that opinion. :)<br>
><br>
><br>
><br>
> [1] <a href="https://review.openstack.org/#/c/71821/" target="_blank">https://review.openstack.org/#/c/71821/</a><br>
> [2] <a href="https://review.openstack.org/#/c/49227/" target="_blank">https://review.openstack.org/#/c/49227/</a><br>
><br>
> Regards,<br>
> Édouard.<br>
><br>
><br>
><br>
> On Sat, Feb 15, 2014 at 12:39 PM, Joe Topjian<br>
</div></div><div class="">> <<a href="mailto:joe@topjian.net">joe@topjian.net</a> <mailto:<a href="mailto:joe@topjian.net">joe@topjian.net</a>>> wrote:<br>
><br>
> Hello,<br>
><br>
> I'm curious if anyone uses the linuxbridge driver in<br>
> production?<br>
><br>
> I've just finished setting up a lab environment using<br>
> ML2, linuxbridge, and vxlan and everything works just<br>
> as it did with OVS.<br>
><br>
> I see benefits of a *much* simpler network layout, a<br>
> non-deprecated vif driver, and none of the OVS issues<br>
> that have been discussed on this list.<br>
><br>
> But maybe I'm missing something... what are the<br>
> reasons of using OVS over linuxbridge? All of the<br>
> official installation guides use it and I've never<br>
> seen anyone mention linuxbridge on this list.<br>
><br>
> Joe<br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
</div>> <mailto:<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
<br>
cheers,<br>
Li Ma<br>
<br>
</font></span></blockquote></div><br></div>