<div dir="ltr">We are currently building up our latest iteration of OpenStack to handle this exact setup. I was a bit confused as well as to where the different parts fit together, but I have had some good phone calls with the guys at Cumulus to help me understand how things work together and what technologies are out there to get everything working together.<div><br></div><div>So the basic concept at work here is that right now there are two different parts of Neutron that are working. The first part is the actual networking of the L2 infrastructure. The other portion is the L3+ layers (routing, dhcp, FWaaS, LBaaS).<br></div><div><br></div><div>Currently L2 is being handled by OVS and GRE, but the GRE portion can be replaced with whatever technology you want to use (VLAN, GRE, VXLANs, etc). When you integrate with something like Cumulus Networks, you are pushing this functionality out to the switch. So you will have a given project/tenant in OpenStack have a specific VLAN and that is used between the compute nodes and the leaf (TOR switch). Beyond that level you use VXLAN to push traffic between the leaf and spine switches to keep tenant's traffic isolated. So basically you have VLAN 5 being tenant 5, and that tenant has instances in multiple zones if the connectivity is intra-zone then they just use the VLAN to talk to each instance. However if you have the tenant in a different zone, then it will be pushed up to VXLAN to route the traffic to the correct zone seamlessly. (At least that is how I understood it.)</div><div><br></div><div>L3 and up is another layer to Neutron. In order to avoid the SPoF and overloading you mentioned, we are looking into <a href="http://Akanda.io">http://Akanda.io</a> (the Cumulus link Eric provided is done with one of the Akanda guys). Basically what Akanda is doing is using the compute infrastructure to scale the L3 functionality of Neutron. Using hooks into the L3 portion of Neutron, they spin up a VM that acts as a router for a given tenant (and they monitor it and make sure it is up and running, outside of the tenant's VMs). This allows you to scale your network load... As you add more compute resources you also scale your networking capabilities. This is another DreamHost project that has been spun out and following the same "enterprise services" model that Ceph/InkTank took. I haven't really started using this yet as we are in the process of purchasing the gear to build things out (QuantaMesh LY9 with Cumulus Networks, etc), but from what I understand of the Akanda project, it fits the bill and ticks most of the boxes for mitigating the problems you are talking about. About the only problem I see with it, is that it is missing a portion of the functionality that Neutron is providing (specifically FWaaS as the API was in a state of flux and they are waiting for it to stabilize).</div><div><br></div><div>Let me know if you have any other questions or need further clarification on anything. Also if I made some mistakes in my explanations. Right now a lot of my knowledge is strictly theoretical as I haven't actually implemented anything yet, but this is the direction we are heading.</div><div><br></div><div>Tom Walsh</div><div><a href="https://expresshosting.net/">https://expresshosting.net/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 8, 2015 at 12:35 PM, Gustavo Randich <span dir="ltr"><<a href="mailto:gustavo.randich@gmail.com" target="_blank">gustavo.randich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi,<br><br>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.<br><br></div><div>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.<br></div><br></div>We are trying to avoid assigning a floating IP to every instance, and also avoid the SPoF and bottlenecks of Network Nodes.<br><br></div>What are the alternatives? (Hardware switches supporting VXLAN and acting as gateways?)<br><div><br></div><div>Thanks in advance.<br><br></div></div>
<br>_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to     : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></blockquote></div><br></div>