OpenStack Networking: A look at Neutron network orchestration
A comprehensive collection of articles, videos and more, hand-picked by our editors
ATLANTA -- The OpenStack Summit focused a lot of attention on networking this week, a sign that network as a service from an open source cloud is slowly becoming a reality. But conversations at the summit also revealed significant challenges in the Neutron networking platform.
OpenStack is an open source cloud computing platform that allows cloud providers and enterprises to build cost-effective, agile infrastructure as a service to support applications. The technology will help users build alternatives to services from companies like Amazon and Microsoft -- public cloud platforms that OpenStack allegiants say are expensive and not nearly as flexible as promised.
OpenStack Neutron, the networking piece of the cloud platform, lets users provision virtual network resources and accompanying Layer 4-7 services in the same way they would orchestrate storage or compute resources. The idea is to simplify networking (and other parts of the infrastructure) enough that application developers can create freely without worrying about the needs of underlying infrastructure.
"OpenStack makes networking a deployable instance for consumption," explained Reinhardt Quelle, a cloud architect at Cisco, where he implements WebEx and other large applications in the cloud. Cisco uses both its own cloud and a public cloud provider to host complex applications. "When I deploy my [application] into a cloud provider, I can create a private network with virtual firewalls," Quelle explained. There is little need to tinker with the underlying networks, he said.
But most engineers at the summit said Neutron is fraught with problems that limit its use in production environments. In a survey of users conducted within the OpenStack community earlier this spring, respondents said Neutron is not scalable enough, is lacking resiliency and is too complex.
One Internet service provider engineer at the conference, who asked to conceal his identity, put it simply: "Neutron sucks."
"It's a great concept, but the design doesn't scale," he said. Neutron doesn't have its own router. "It uses a Linux kernel and Linux routing, but that's not good enough."
Inside the cloud, Neutron works with virtual switches and hypervisors to configure ports and devices, and provision virtual overlays and tenants. But a Layer 3 agent is responsible for connecting these tenants out into the data center and the Internet. All traffic in a single cloud environment runs through that same L3 agent, which creates a choke point. That Layer 3 agent also lacks dynamic routing.
Meanwhile, issues with scalability plague the heart of Neutron -- the ability to dynamically provision virtual overlays. Neutron can connect to both virtual and physical network infrastructures. In older forms of OpenStack networking, the orchestration tool was linked directly to switches and could orchestrate virtual local area networks (VLANs) across flat physical networks.
But to enable network as a service (NaaS) requires provisioning of virtual overlays with multiple tenants, and engineers are finding these overlays have serious performance problems.
During a presentation about scaling Neutron networks, eBay/PayPal SDN architect Vinay Bannai said: "The first problem we had was hypervisor scale out. … How many hypervisors can you have?"
People with large overlay networks could require thousands of hypervisors, but that doesn't work in Neutron. Before Neutron, when engineers were working with the networking built into OpenStack compute platform Nova, they could break a group of 2000 hypervisors into more manageable cells and then place those cells into availability zones. That's not possible in Neutron, Bannai said. Instead, eBay runs a combination of bridge networks and overlays, he explained.
But the ISP engineer lamented that working with physical flat or bridge networks, even in hybrid mode, will not allow for true NaaS.
Network vendors will not miss the OpenStack boat
Every major networking vendor, including Cisco, HP, Juniper, Brocade and Dell, had a large presence at the OpenStack Summit.
While each had variations in their approaches, they all essentially aimed to make OpenStack orchestration work across their network environments by making their infrastructure pluggable.
More on OpenStack and Neutron
What's possible with OpenStack networking?
OpenStack Neutron booed by IT pros
OpenStack security myths tackled
Getting to know Neutron networking
Cisco took the stage to explain how OpenStack could work in its Application Centric Infrastructure and with its APIC controller. Cisco recently introduced a policy blueprint to OpenStack that would allow application developers to have more say over how the network is used to support their applications.
Meanwhile, Juniper laid out how its Contrail SDN controller and switches could integrate into the orchestration context, stressing that it could solve the Layer 3 problem with its own routers. Before the summit, Brocade announced partnerships with companies like Piston and Rackspace that would certify Brocade network plug-ins with their OpenStack distributions. Brocade also contributed a proposal that would enable running MPLS between disparate data centers using OpenStack to provision resources as if they were from one pool. Last year, Brocade contributed to a project called Dynamic Network Resource Management that coordinates how network functions are matched to virtual machines as they are provisioned. .
OpenStack works in six-month release cycles, so this week focused on design for the October release of what will be called Juno. There are plenty of proposals that could improve Neutron -- even in time for the next release. Some of those proposals focus on improving Layer 2 and 3 agents, authentication, network resource management and VLAN tagging.