openstack-quantum-neutron-plug-in-there.html

---
date: 2013-10-02T07:34:00.000+02:00
tags:
- cloud
- overlay networks
title: 'OpenStack Quantum (Neutron) Plug-In: There Can Only Be One'
url: /2013/10/openstack-quantum-neutron-plug-in-there/
---

<p>OpenStack seems to have a great architecture: all device-specific code is abstracted into plugins that have a well-defined API, allowing numerous (more or less innovative) implementations under the same umbrella orchestration system.</p>
<p>Looks great in PowerPoint, but to an uninitiated outsider looking at the network (Quantum, now Neutron) plugin through the lenses of <ahref="http://docs.openstack.org/grizzly/openstack-network/admin/content/">OpenStack Neutron documentation</a>, it looks like it was designed by either a vendor or a server-focused engineer using NIC device driver concepts.<!--more--></p>
<pclass="update">2013-10-03: Slightly changed the wording of the previous paragraph to explain my observation bias. For another perspective on Quantum beginnings, please read the comments.</p>
<p>You see, the major problem the Quantum plug-in architecture has is that <em>there can only be one Quantum plugin </em>in a given OpenStack deployment, and that plugin has to implement all the networking functionality: layer-2 subnets are mandatory, and there are extensions for layer-3 forwarding, security groups (firewalls) and load balancing.</p>
<pclass="update">2014-09-14: The situation is a bit better in OpenStack Icehouse release with ML2 Neutron plugins. More details in the second half of this blog post.</p>
<divclass="separator"><ahref="/2013/10/s1600-Quantum+Generic.png" imageanchor="1"><imgborder="0" src="/2013/10/s400-Quantum+Generic.png"/></a></div>
<p>This approach worked well in early OpenStack days when the Quantum plugin configured virtual switches (similar to what VMware’s vCenter does) and ignored the physical world. You could choose to work with Linux bridge or Open vSwitch and use VLANs or GRE tunnels (OVS only).</p>
<p>However, once the networking vendors started tying their own awesomesauce into OpenStack, they had to replace the original Quantum plugin with their own. No problem there if the vendor controls end-to-end forwarding path like <ahref="/2013/01/nec-launched-virtual-openflow-switch/">NEC does with its ProgrammableFlow controller</a>, or if the vendor implements end-to-end virtual networks like <ahref="/2013/08/what-is-vmware-nsx/">VMware does with NSX</a> or <ahref="/2012/08/midokuras-midonet-layer-2-4-virtual/">Midokura does with Midonet</a> … but what most hardware vendors want to do is to control their physical switches, not the hypervisor virtual switches.</p>
<p>You can probably guess what happened next: there’s no problem that cannot be solved by <ahref="http://en.wikipedia.org/wiki/Indirection">another layer of indirection</a>, in this case a layered approach where a networking vendor provides a top-level Quantum plugin that relies on sub-plugin (usually OVS) controlling the hypervisor soft switches.</p>
<divclass="separator"><ahref="/2013/10/s1600-Quantum+Vendor.png" imageanchor="1"><imgborder="0" src="/2013/10/s400-Quantum+Vendor.png"/></a></div>
<p>Remember that OpenStack supports a single plugin. Yeah, you got it right – if you want to use the above architecture, you’re usually locked into a single networking vendor. Perfect vendor lock-in within an open-source architecture. Brilliant. Also, do remember that your vendor has to update the plugin to reflect potential changes to Quantum/Neutron API.</p>
<pclass="update">2013-10-03: <ahref="https://twitter.com/FlorianOtel/status/385307251893760000">Florian Otel pointed out</a> the <ahref="https://blueprints.launchpad.net/neutron/+spec/metaplugin">Meta plugin</a>. It might improve matters, but the <ahref="http://docs.openstack.org/grizzly/openstack-network/admin/content/ch_limitations.html">documentation claims it's still experimental</a>.</p>
<p>I never claimed it was a good idea to mix multiple switching vendors in the same data center (it’s not, regardless of what HP is telling you), but imagine you’d like to have switches from vendor A and load balancers from vendor B, all managed through a single plugin. Good luck with that.</p>
<p>Alas, wherever there’s a problem, there’s a solution – in this case a Quantum plugin that ties OpenStack to a network services orchestration platform (<ahref="/2013/05/tail-f-network-control-system-first/">Tail-f NCS</a> or Anuta nCloudX). These platforms can definitely configure multi-vendor network environments, but if you’re willing to go this far down the vendor lock-in path, you just might drop the whole OpenStack idea and use VMware or Hyper-V.</p>
<divclass="separator"><ahref="/2013/10/s1600-Quantum+Tail-F.png" imageanchor="1"><imgborder="0" src="/2013/10/s400-Quantum+Tail-F.png"/></a></div>
<p>OpenStack Icehouse release gives you a different option: a generic plugin that implements the high-level functionality, works with virtual switches, and provides a hardware abstraction layer (Modular Layer 2 – ML2) where the vendors could plug in their own “device driver”. </p>
<divclass="separator"><ahref="/2013/10/s1600-Quantum+ML2.png" imageanchor="1"><imgborder="0" src="/2013/10/s400-Quantum+ML2.png"/></a></div>
<p>This approach removes the vendor lock-in of the monolithic vendor-supplied Quantum plugins, but limits you to the lowest common denominator – VLANs (or equivalent). Not necessarily something I’d want to have in my greenfield revolutionary forward-looking OpenStack-based data center, even though Arista’s engineers are quick to point out you can implement VXLAN gateway on ToR switches and use VLANs in the hypervisors and IP forwarding in the data center fabric. No thanks, I <ahref="/2012/05/virtual-networks-skype-analogy/">prefer Skype over a fancier PBX</a>.</p>
<p>Finally, there’s an <ahref="https://wiki.opendaylight.org/view/OpenDaylight_OpenStack_Quantum_Plugin:Main">OpenDaylight Quantum plugin</a>, giving you total vendor independence (assuming you love riding OpenFlow unicorns). It seems OpenDaylight already supports layer-3 OpenFlow-based forwarding, so this approach might be an interesting option a year from now when OpenDaylight gets some traction and bug fixes.</p>
<p><strong>Cynical summary</strong><strong>:</strong> Reinventing the wheel while ensuring a comfortable level of lock-in seems to be a popular pastime of the networking industry. Let’s see how this particular saga evolves … and do keep in mind that some people <ahref="http://blog.gardeviance.org/2013/07/there-can-be-only-one.html">remain</a><ahref="http://blog.gardeviance.org/2013/07/the-trouble-with-openstack.html">deeply skeptical</a> of OpenStack’s future.</p>