[Openstack] How to plan a transition to VXLAN tunnels
Erik McCormick
emccormick at cirrusseven.com
Fri Jul 10 15:20:51 UTC 2015
On Fri, Jul 10, 2015 at 9:51 AM, Leslie-Alexandre DENIS <contact at ladenis.fr>
wrote:
>
>
> Le 08/07/2015 18:35, Gustavo Randich a écrit :
>
> Hi,
>
> We are trying to figure out how to transition from a network model using
> nova-network and a single VLAN to a model using Neutron and multiple VXLAN
> tunnels.
>
> The main issue is not how to configure and setup the tunnels, but how to
> expose the new virtual machines born inside the tunnels to our "legacy",
> non-VXLAN, non-Openstack networks, i.e. DNS serrvers, databases, hardware
> load balancers, monitoring/metrics servers, etc.
>
> There are a few options. You could have a secondary interface on your VMs
that tie to a VLAN which would be L2 from the compute node to your service
infrastructure. That will mean extra interfaces and bridges on your compute
nodes.
Another interesting option (and one I am currently working on implementing)
is to extend your neutron VXLANs to your physical network using the new
hierarchical port binding features. This is fairly new goo and requires
that you be running Kilo. There was a presentation utilizing Cumulus Linux
switches in Vancouver, and that's what I'm running. You can watch it here:
https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/neutron-hierarchical-port-binding-what-is-it-and-why-you-should-deploy-it
There are probably other fancy ways of doing similar things with other
switches. They just have to be able to act as VTEPs. You also may be able
to run a VTEP on each compute node, but that could potentially cause
unwanted overhead.
You can, of course, also simply add an interface to your tenant routers
into your service infrastructure network and inject a route for any
networks that you need to go that way. With DVR and L3-HA, the single point
of failure is not nearly the issue it once was.
> What I understand from Neutron use of VXLAN/GRE, is that it's only for
> encapsulating L2 traffic into L3 from tenant/project to networking node(s).
> It permits to bypass the L2 configuration (i.e. switches) that exists
> between your servers.
>
> See:
> http://docs.openstack.org/networking-guide/_images/scenario-legacy-ovs-flowns1.png
>
> The decision to route the packet is made by the qrouter/L3 agent on the
> networking node(s).
> Eventually you can create a L2 only network inside Neutron and assign a
> gateway that is a physical device outside your servers.
>
> See: http://docs.openstack.org/networking-guide/deploy_scenario4a.html
>
> I'm also currently on the task to migrate a full nova-network VLAN network
> to a Neutron VLAN topology for fixed IPs and VXLAN/GRE topology for
> floating IPs.
>
> Hope Neutron specialists are around :)
>
> See you,
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
-Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150710/bcd8f453/attachment.html>
More information about the Openstack
mailing list