LEARNING OPENSTACK NETWORKING (NEUTRON)

Chapter 1. Preparing the Network for OpenStack

Enterprises, both large and small, run their clouds using OpenStack software. While the clouds themselves may vary in complexity, one thing is common: they are made possible by the scalability and flexibility of OpenStack Compute and Networking services.

Modern cloud computing platforms, such as OpenStack, rely on a method of networking known as software-defined networking, or SDN. Traditional network administration relies heavily on the administrator to manually configure and maintain physical network hardware and connectivity. SDN, on the other hand, allows network administrators to manage network services in an abstract and automated manner. Software-defined networking, and the software-defined data center as a whole, is often regarded as a necessary foundation for scalable and efficient cloud computing.

In this chapter, you will be introduced to the different components and features of OpenStack Networking, codenamed Neutron, as well as various methods in which Neutron can be deployed and configured from both software and hardware perspectives. Throughout the book, the Neutron moniker will often be used in place of the official name.

What is OpenStack Networking?

OpenStack Networking is a standalone service that can be installed independently of other OpenStack services. Other OpenStack services that fall under this category include Compute (Nova), Image (Glance), Identity (Keystone), Block Storage (Cinder), and Dashboard (Horizon). OpenStack Networking services can be split amongst multiple hosts to provide resilience and redundancy, or can be configured to operate on a single node.

OpenStack Networking uses a service called neutron-server to expose an application programmable interface, or API, to users and to pass requests to the configured network plugins for additional processing. Users are able to define network connectivity in the cloud, and cloud operators are allowed to leverage different networking technologies to enhance and power the cloud.

Like many other OpenStack services, Networking requires access to a database for persistent storage of the network configuration.

Features of OpenStack Networking

OpenStack Networking in Havana includes many technologies one would find in the data center, including switching, routing, load balancing, firewalling, and virtual private networks. These features can be configured to leverage open source or commercial software, and provide a cloud operator with all of the tools necessary to build a functional and self-contained cloud. OpenStack Networking also provides a framework for third-party vendors to build on and enhance the capabilities of the cloud.

Switching

Virtual switches are defined as software applications that connect virtual machines to virtual networks at layer 2, or the data-link layer of the OSI model. Neutron supports multiple virtual switching platforms, including built-in Linux bridging and Open vSwitch. Open vSwitch, also known as OVS, is an open source virtual switch that supports standard management interfaces and protocols, including NetFlow, SPAN, RSPAN, LACP, and 802.1q, though many of these features are not exposed to the user through the OpenStack API. In addition to VLAN tagging, users can build overlay networks in software using L2-in-L3 tunneling protocols, such as GRE or VXLAN. Open vSwitch can be used to facilitate communication between instances and devices outside the control of OpenStack, which include hardware switches, network firewalls, storage devices, dedicated servers, and more. Additional information on the use of Linux bridges and Open vSwitch as switching platforms for OpenStack can be found in Chapter 4, Building a Virtual Switching Infrastructure.

Routing

OpenStack Networking provides routing and NAT capabilities through the use of IP forwarding, iptables, and network namespaces. A network namespace is analogous to chroot for the network stack. Inside a network namespace, you can find sockets, bound ports, and interfaces that were created in the namespace. Each network namespace has its own routing table and iptables process that provide filtering and network address translation, also known as NAT. Network namespaces are comparable to VRFs in Cisco, routing instances in Juniper JunOS, or route domains in F5 BIG-IP. With network namespaces, there is no concern of overlapping subnets between networks created by tenants. Configuring a router within Neutron enables instances to interact and communicate with outside networks. More information on routing within OpenStack can be found in Chapter 6, Creating Routers with Neutron.

Load balancing

First introduced in the Grizzly release of OpenStack, Load-Balancing-as-a-Service, also known as LBaaS, provides users the ability to distribute client requests across multiple instances or servers. Havana is equipped with a plugin for LBaaS that utilizes HAProxy as the load balancer. More information on the use of load balancers within Neutron can be found in Chapter 7, Load Balancing Traffic in Neutron.

Firewalling

In Havana, there are two methods of providing security to instances or networks: security groups and firewalls. Security group functionality was originally found in nova-network in OpenStack Compute and has since migrated to OpenStack Networking. This is a method of securing traffic to and from instances through the use of iptables on the compute node. With the introduction of Firewall-as-a-Service, also known as FWaaS, security is handled at the router rather than at the compute node. In the Havana release of OpenStack, FWaaS is an experimental extension with no guaranteed backwards compatibility in future releases. More information on securing instances can be found in Chapter 8, Protecting Instances on the Network.

Virtual private networks

A virtual private network (VPN), extends a private network across a public network such as the Internet. A VPN enables a computer to send and receive data across public networks as if it were directly connected to the private network. Neutron provides a set of APIs to allow tenants to create IPSec-based VPN tunnels to remote gateways. In the Havana release of OpenStack, VPNaaS is an experimental extension with no guaranteed backwards compatibility in future releases; it will not be covered in this book.

Preparing the physical infrastructure

When architecting the network, it is important to first determine the purpose of the cloud. Is the goal to build a highly scalable environment with multiple levels of network redundancy? Or is the goal to provide a sandbox for developers with little thought given to the resilience of the network or compute platform? Do you want an environment that leverages everything OpenStack Networking has to offer in terms of routing, switching, and application networking? Is the environment intended to be an extension of an existing physical network?

OpenStack Networking can serve many roles within different clouds but is better at some technologies than others. The purpose of the cloud itself, along with security requirements and available hardware, will play a big part in determining the architecture of the network and OpenStack's role in the network.

The OpenStack portal www.openstack.org provides reference architectures for Neutron-based clouds that involve a combination of the following nodes:

Controller node
Network node
Compute node(s)

Prior to the installation of OpenStack, the physical network infrastructure must be configured to support the networks needed for an operational cloud. In the following diagram, I have highlighted the area of responsibility for the network administrator:

Figure 1.1

The physical network infrastructure must be configured to support OpenStack Networking. In this diagram, the area marked in red is the responsibility of the network administrator. That may include the need to configure physical switches, firewalls, or routers, as well as interfaces on the servers themselves.

In the next few chapters, I have defined networks and VLANs that will be used throughout the book to demonstrate the various components of OpenStack Networking. Generic information on the configuration of switch ports, routers, or firewalls can be found in upcoming chapters as well.

Types of network traffic

The reference architecture for OpenStack Networking defines at least four distinct types of network traffic:

Management
API
External
Guest

These distinct types of network traffic do not require dedicated interfaces and are often collapsed onto single interfaces. Depending on the chosen deployment model, the cloud architecture may spread networking services across multiple nodes. The security requirements of the enterprise deploying the cloud will often dictate how the cloud is built.

Management network

The management network is used for internal communication between hosts for services, such as the messaging service and database service. All hosts will communicate with each other over this network. The management network can be configured as an isolated network on a dedicated interface or combined with another network as described below.

API network

The API network is used to expose OpenStack APIs to users of the cloud and services within the cloud. Endpoint addresses for services, such as Keystone, Neutron, Glance, and Horizon, are procured from the API network.

It is common practice to configure a single IP address on a dedicated interface that will serve as the listener address for the various services as well as the management address for the host itself. A diagram of this configuration is provided later in this chapter.

External network

An external network provides Neutron routers with network access. Once a router has been configured, this network becomes the source of floating IP addresses for instances and load balancer VIPs. IP addresses in this network should be reachable by any client on the Internet.

Guest network

The guest network is a network dedicated to instance traffic. Options for guest networks include local networks restricted to a particular node, flat or VLAN tagged networks, or the use of virtual overlay networks made possible with GRE or VXLAN encapsulation. For more information on guest networks, please refer to Chapter 5, Creating Networks with Neutron.

The interfaces used for the external and guest networks can be dedicated interfaces or ones that are shared with other types of traffic. Each approach has its benefits and caveats, and those are described in more detail as we progress in the chapter.

Physical server connections

The number of interfaces needed per host is dependent on the type of cloud being built and the security and performance requirements of the organization.

A single interface per server that results in a combined control and data plane is all that is needed for a fully functional OpenStack cloud. Many organizations choose to deploy their cloud this way, especially when port density is at a premium or the environment is simply used for testing. In production clouds, however, separate control and data interfaces are recommended.

Single interface

For hosts using a single interface, all traffic to and from instances as well as internal OpenStack, SSH management, and API traffic traverses the same interface. This configuration can result in severe performance degradation, as a guest can create a denial of service attack against its host by consuming the total available bandwidth. Not recommended for production environments, this type of configuration should only be used for testing or proof-of-concept.

The following diagram demonstrates the use of a single physical interface for all traffic using the Open vSwitch plugin. A physical interface resides in the network bridge and handles external, guest, management, and API service traffic:

Figure 1.2

In this diagram, all OpenStack service and management traffic traverses the same physical interface as guest traffic.

Multiple interfaces

To reduce the likelihood of guest network bandwidth consumption affecting management of traffic and to maintain a proper security posture, segregation of traffic between multiple physical interfaces is recommended. At a minimum, two interfaces should be used: one that serves as the management and API interface and another that serves as the external and guest interface. If required, additional interfaces can be used to further segregate traffic. The following diagram demonstrates the use of two physical interfaces using the Open vSwitch plugin:

Figure 1.3

In this diagram, a dedicated physical interface handles all traffic directed to and from instances or other OpenStack Networking services, such as LBaaS and FWaaS, while another interface handles OpenStack API and management traffic.

Bonding

NIC bonding offers users the ability to multiply available bandwidth by aggregating links. Two or more physical interfaces can be combined to create a single virtual interface, or bond, which can then be placed in the bridge. The physical switching infrastructure, however, must be capable of supporting this type of bond. In addition to aggregating links, bonding can also refer to the ability to create redundant links in an active/passive manner. Both links are simultaneously cabled to a switch or pair of switches, but only one interface is active at any given time. Both types of bonds can be created within CentOS or Ubuntu when the appropriate kernel module is installed. In lieu of built-in bonding techniques, bonding can be configured in Open vSwitch if desired.

Bonding is an inexpensive way to provide hardware-level network redundancy to the cloud. If you are interested in configuring NIC bonding on your hosts, please refer to the following sites:

CentOS 6.5: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces-chan.html
Ubuntu 12.04 LTS: https://help.ubuntu.com/community/UbuntuBonding

Separating services across nodes

Like other OpenStack services, cloud operators can split OpenStack Networking services across multiple nodes. Small deployments may use a single node to host all services, including networking, compute, database, and messaging, while others might find benefit in using a dedicated network node to handle guest traffic routed through software routers and to offload Neutron DHCP and metadata services. The following diagrams reflect a few common service deployment models.

A single controller with one or more compute nodes

In an environment consisting of a single controller and one or more compute nodes, the controller will likely handle all networking services and other OpenStack services, while the compute nodes strictly provide compute resources.

The following diagram demonstrates a controller node hosting all OpenStack management and networking services where the layer 3 agent is not utilized. Two physical interfaces are used to provide separate control and data planes:

A single controller with one or more compute nodes

Figure 1.4

This diagram reflects the use of a single controller and one or more compute nodes where Neutron provides only layer 2 connectivity to instances. An external router is needed to handle routing between network segments.

The following diagram demonstrates a controller node hosting all OpenStack management and networking services, including the Neutron L3 agent. Two physical interfaces are used to provide separate control and data planes:

Figure 1.5

This diagram reflects the use of a single controller node and one or more compute nodes in a network configuration that utilizes the Neutron L3 agent. Software routers created with Neutron reside on the controller node and handle routing between connected tenant networks

A single controller plus network node with one or more compute nodes

A network node is one that is dedicated to handling most or all OpenStack networking services, including the L3 agent, DHCP agent, metadata agent, and more. The use of a dedicated network node provides additional security and resilience, as the controller node will be at less risk of network and resource saturation.

The following figure demonstrates a network node hosting all OpenStack networking services, including the Neutron L3 agent. The Neutron API, however, is installed on the controller node. Two physical interfaces are used to provide separate control and data planes:

A single controller plus network node with one or more compute nodes

Figure 1.6

This diagram reflects the use of a dedicated network node in a network configuration that utilizes the Neutron L3 agent. Software routers created with Neutron reside on the network node and handle routing between connected tenant networks. The API service, neutron-server, remains on the controller node.

Filter reviews by

All

Amazon verified reviews

Flex! Mar 10, 2016

Great info.

Amazon Verified review

Chris Paggen Oct 26, 2015

A really good deep-dive inside Neutron. I found the examples quite good. On several occasions, the author traces packets as they travel from instances, down to Linux bridges, into OVS then on to Neutron step by step. The book clarifies the roles of the various networking-related daemons (l3-agent, dhcp-agent, neutron-server, etc.) in a multi-node Openstack environment, and shows you which daemons run where, why that is the case, and how they all work together.

vinod kumar Singh Jun 11, 2015

Not explained well.

Joe A Mar 21, 2015

most of the links in the book do not work, so it is mostly useless and a big disappointment. I will be returning it.

brian t hayes Mar 21, 2015

many links in this book do not work - rendering the book nearly useless. There should be a single download site for all the correct files. And I paid 40$ for the paperback! :(

LEARNING OPENSTACK NETWORKING (NEUTRON): Architect and build a network infrastructure for your cloud using OpenStack Neutron networking

What do you get with eBook?

LEARNING OPENSTACK NETWORKING (NEUTRON)

Chapter 1. Preparing the Network for OpenStack

What is OpenStack Networking?