With a theme of “Operationalizing Open Networking,” the ONUG Spring 2015 conference is giving voice not only to the technologies enabling open networking, but also to the operational aspects of running these networks. This is encouraging because it means we’ve reached the point where open networking is being used in production. If you look at the Open Source networking stack, you can see the pieces are all there to run a full-fledged open networking stack for production systems:

• Open vSwitch: Open Source virtual switch
• OpenStack Neutron: Open networking APIs for OpenStack Infrastructure as a Service Platform
• OpenDaylight, ONOS, OVN: Open Source SDN controllers that work in concert with Neutron

Each of these pieces provides an important part of an Open Network install. Open vSwitch is the lowest layer, providing virtual switching on the host for virtual machines or containers. OpenStack Neutron provides a common cloud networking API and, together with the rest of OpenStack, provides a cloud management layer. Finally, an Open Source network controller such as OpenDaylight, ONOS, or OVN provides a scalable controller, abstracting the Neutron APIs, and implementing them on hosts and physical devices such as switches. All of these components work together to provide scalable open networking.

How do you run these things in production? How do you debug them when failures occur? These are the types of questions you may find yourself asking as you contemplate running these systems in production.

Both Mark McClain and I have been involved in open networking for well over eight combined years now. Mark served as the OpenStack Neutron PTL for the Havana and Icehouse releases, and I have been the PTL of OpenStack Neutron for the Juno and Kilo releases. We’ve helped grow Neutron to the point where it is now approaching 50 plugins and drivers from Open Source projects and vendors to drive virtual networking in OpenStack. Now, Neutron has grown to be the de facto open networking API in the Open Source cloud and networking ecosystem. Our tutorial will show you how to work with OpenStack Neutron to enable rich network virtualization for tenants.

As a quick background for those unfamiliar with it, OpenStack is an Infrastructure-as-a-Service (IaaS) platform. OpenStack Neutron is the networking component of OpenStack. Neutron provides a rich set of APIs allowing operators and tenants of OpenStack clouds to deploy rich virtual networking. The Neutron API exposes the concept of virtual networks, ports, routers, and subnets, allowing the creation of virtual networks utilizing a variety of different underlying technologies. In addition, Neutron allows the configuration and usage of firewalls (FWaaS), load balancers (LBaaS), and VPNs (VPNaaS). All of the objects of Neutron are configurable through an API endpoint in addition to a CLI.

OpenStack Neutron provides a rich set of building blocks as you develop a scalable virtual networking solution; so how do you operate in this new environment? Operationally, many Neutron implementations use overlay networking, though equally as many utilize tried and true technologies like VLANs. Even more interesting, some of the Open Source reference implementations make use of VLANs in addition to overlay technology. For example, the Open vSwitch agent, in concert with the ML2 plugin, uses VLANs local to the integration bridge on the host to segregate local tenant traffic. As another example, the OFAgent utilizes pure OpenFlow rules on the host to segregate tenant traffic locally on the host. Both achieve similar results, but the subtle differences affect the different ways things are debugged locally. Operationally, you will want to understand this when making a decision regarding which plugin and agent combination to explore.

The operational aspects of these types of decisions are worth understanding as you build out your virtual networks. Even the decision around which set of plugins and drivers to use can have drastic operational differences. Neutron supports plugins utilizing Open vSwitch, as well as the tried and true Linuxbridge. If your team has a comfort level with an existing Linuxbridge deployment, you may want to consider this option. Neutron also supports utilizing SDN controllers such as OpenDaylight. These can provide additional operational challenges of their own around deployment.

The bottom line is there are many choices when deploying and using OpenStack Neutron. Mark and I will walk the attendees through some common ones in our ONUG Academy session. We hope to highlight some subtle differences, while focusing on some operational issues you may run into. We’ll walk through common usage scenarios, explaining what’s happening under the hood to highlight how things are constructed and working.

There is no doubt open networking has arrived. The technologies are maturing at a fast pace, and you now have the option of running a scalable open networking environment for your Infrastructure-as-a-Service platform, your container deployment, or even your legacy bare metal environments. Understanding how to deploy these technologies is becoming increasingly important as they continue to become the deployment option of choice in cloud environments.

OpenStack Neutron has been a catalyst for open networking in the networking industry, and as it evolves into its fourth year, we see it continuing its role as the place where open innovation happens in a collaborative fashion to shape the future of networking industry. We hope you can join us for our tutorial as we explore Neutron, and show you how it can help you build a rich cloud platform.

The OpenStack Networking tutorial will take place from 1:30-4:30pm on May 12th as a part of ONUG Academy at Columbia University. Register Now.

Author bio

Kyle is a Senior Director and Chief Technologist of Open Source Networking at HP. He is also the OpenStack Neutron PTL, a core reviewer for the Neutron project in OpenStack, as well as a committer on the OVSDB project in OpenDaylight. He works primarily on open source projects including OpenStack, Open vSwitch, OpenDaylight and libvirt. He is the founder of the Minnesota OpenStack Meetup. Kyle has been writing systems software for more than 15 years. Kyle lives with his wife and family in Minnesota.