An Icehouse Sneak Peek – OpenStack Networking (Neutron)

Today's datacenter networks contain more devices than ever before; servers, switches, routers, storage systems, dedicated network equipment and security appliances – many of which are further divided into virtual machines and virtual networks. Traditional network management techniques generally fall short of providing a truly scalable, automated approach to managing these next-generation networks. Users expect more control and flexibility with quicker provisioning and monitoring.

OpenStack Networking (Neutron) is a pluggable, scalable and API-driven system for managing networks and IP addresses. Like other aspects of the cloud operating system, it can be used by administrators and users to increase the value of existing datacenter infrastructure. Neutron prevents the network from being the bottleneck or limiting factor in a cloud deployment and gives users real self service over their network configurations.
Starting in the Folsom release, OpenStack Networking, then called Quantum, became a core and supported part of the OpenStack platform, and is considered to be one of the most exicting projects – with great innovation around network virtualization and software-defined networking (SDN). The general availability of Icehouse, the ninth release of OpenStack, is just around the corner, so I would like to highlight some of the key features and enhancements made by the contributors in the community to Neutron.

Modular Layer 2 (ML2) plugin enhancements
The Modular Layer 2 (ML2) plugin is a framework allowing OpenStack Networking to simultaneously utilize the variety of layer 2 networking technologies found in complex real-world data centers. It currently works with the existing Open vSwitch, Linux bridge, and Hyper-V L2 agents as what ML2 define as ‘MechanismDrivers’, and is intended to replace and deprecate the monolithic plugins associated with those. The ML2 framework is also intended to greatly simplify adding support for new L2 networking technologies, requiring much less initial and ongoing effort than would be required to add a new monolithic core plugin.

Starting with Icehouse, ML2 will support SR-IOV PCI passthrough; SR-IOV is a specification that allows a PCIe device to appear to be multiple separate physical PCIe devices. In the case of networking, this allows to assign a Virtual Function of an SR-IOV capable network card to a virtual machine as a network device (vNIC). This enables network traffic to bypass the software switch layer, which can offer better performance characteristics. SR-IOV introduces the need to enhance ML2 with support for requesting certain ‘vnic_type’ to be bound on Neutron port. Depending on the application, Neutron port can now be requested to be realized as normal vNIC (implemented using virtio NIC) or pci-passthrough (using SR-IOV).

Operational status of floating IPs
OpenStack instances receive a private IP address through which they can reach each other. In order to access these instances from other machines in the environment and from external networks like the Internet, the instances will need to be allocated a "floating IP” - which is implemented on the neutron-l3-agent as NAT (iptables) rules. Originally, floating IPs did not have an operational status, so the user had no way to check whether the floating IP has actually been created or not. This functionally was added in Icehouse through a change in the core API.

Enhanced scheduling of virtual routers
Neutron has an API extension to allow administrators and tenants to create virtual routers in order to route between networks and to access external networks. Virtual routers are scheduled in the neutron-l3-agent, which uses the Linux IP stack with iptables to perform L3 forwarding and NAT. In order to support multiple routers with potentially overlapping IP addresses across the environment, the l3-agent defaults to using Linux network namespaces to provide isolated forwarding instances.

Depending on your OpenStack cloud design, you may want to use more than one l3-agent, usually to provide fault-tolerance or high-availability, or to distribute the load of this crucial component.  The default scheduler available in Neutron (‘chance’) is used to place virtual routers on l3-agents randomly, which may or may not fit to your design. Starting with Icehouse, it will now be possible to use a more efficient scheduler (‘leastrouter’) that schedules a virtual router on the l3-agent that has the lower amount of current running routers.

OpenDaylight plugin for Neutron
The OpenDaylight Project is a collaborative open source project hosted by the Linux Foundation. The goal of the project is to accelerate the adoption of software-defined-networking (SDN) and create a solid foundation for Network Functions Virtualization (NFV).

OpenDaylight now has a MechanismDriver for the ML2 plugin to enable communication between Neutron and OpenDaylight. OpenDaylight offers an SDN controller which uses OVSDB (Open vSwitch Database Management Protocol) for southbound configuration of vSwitches, and can now manage network connectivity and initiate GRE or VXLAN tunnels for OpenStack Compute nodes.

New third-party plugins
As mentioned before, Neutron has a pluggable infrastructure which uses plugins to introduce advanced network capabilities. Alongside the open-source plugins (or ML2 MechanismDrivers) such as Linux bridge, Open vSwitch or OpenDaylight, different networking vendors offer their plugin to interact with their hardware or software solution.  Plugins to be included in the Icehouse release are coming from Brocade, Big Switch Networks, Embrane, Midonet, Mellanox, Nuage, Radware, Ryu, IBM, and others.

Continuation of Nova network
With the introduction of Neutron, development effort on the initial networking code that remains part of the Compute component (Nova) has gradually lessened. While many still use nova-network in production, there has been a plan to remove the code in favor of the more flexible and featured OpenStack Networking. As there are still some use-cases where nova-network fits, and as there is no clean migration path from nova-network to Neutron, it was decided that nova-network will not be deprecated in the Icehouse release. In addition, to a limited degree, patches to nova-network will now again begin to be accepted to support deployments in production.

Get Started with OpenStack Icehouse
If you want to try out OpenStack Icehouse, or to check out yourself some of the above features, please visit our RDO site. We have documentation to help get started, forums where you can connect with other users, and community-supported packages of the most up-to-date OpenStack releases available for download. You can also try the OpenDaylight integration with Neutron in this simple step-by-step procedure.

If you are looking for enterprise-level support, or information on partner certification, Red Hat also offers Red Hat Enterprise Linux OpenStack Platform.