Preparing the Network

for OpenStack
In today's data centers, networks are composed of more devices than ever before.
Servers, switches, routers, storage systems, and security appliances now exist
as virtual machines and virtual network appliances. These devices place a large
strain on traditional network management systems, as they are unable to provide
a scalable, automated approach to managing next-generation networks. Users now
expect more control and flexibility of the infrastructure with quicker provisioning,
all of which OpenStack promises to deliver.

This chapter will introduce many features that OpenStack Networking provides
as well as various network architectures supported by OpenStack.

What is OpenStack Networking?

OpenStack Networking is a pluggable, scalable, and API-driven system to manage
networks and IP addresses in an OpenStack-based cloud. Like other core OpenStack
components, OpenStack Networking can be used by administrators and users to
increase the value and maximize the utilization of existing data center resources.

Neutron, the code name of OpenStack Networking, is a standalone service that can
be installed independently of other OpenStack services such as Nova (compute
service), Glance (image service), Keystone (identity service), Cinder (block storage),
and Horizon (dashboard). OpenStack Networking services can be split among
multiple hosts to provide resiliency and redundancy, or they can be configured to
operate on a single node.

[1]

www.it-ebooks.info
Preparing the Network for OpenStack

OpenStack Networking exposes an application programmable interface, or API,

to users and passes 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, Neutron requires access to a database for
persistent storage of the network configuration.

Features of OpenStack Networking

OpenStack Networking includes many technologies one would find in a 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 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
A virtual switch is defined as a software application that connects virtual machines
to virtual networks at layer 2, or the data-link layer, of the OSI model. Neutron
supports multiple virtual switching platforms, including Linux bridges provided by
the bridge kernel module 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 VLAN tagging.
However, 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.

[2]

www.it-ebooks.info
 Chapter 1

Routing
OpenStack Networking provides routing and NAT capabilities through the use of
IP forwarding, iptables, and network namespaces. Inside a network namespace, we
can find sockets, bound ports, and interfaces that were created in the namespace.
Each network namespace has its own routing table, interfaces, and iptables processes
that provide filtering and network address translation. By leveraging network
namespaces to separate networks, 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 or other networks
in the cloud. Router namespaces are also leveraged by the advanced networking
services Firewall as a Service and Virtual Private Network as a Service, which
will be discussed later in this book. More information on routing within OpenStack
can be found in Chapter 7, Creating Standalone Routers with Neutron; Chapter 8, Router
Redundancy Using VRRP; and Chapter 9, Distributed Virtual Routers.

Load balancing
First introduced in the Grizzly release of OpenStack, Load Balancing as a Service,
also known as LBaaS, provides users with the ability to distribute client requests
across multiple instances or servers. Users can create monitors, set connection limits,
and apply persistence profiles to traffic traversing a virtual load balancer. The Kilo
release of OpenStack introduced version 2 of the LBaaS API in an experimental
status. The v2 API is a vast improvement over version 1, and by the Liberty release,
it should be stable. OpenStack Networking is equipped with a plugin for LBaaS that
utilizes HAProxy in the open source reference implementation. More information on
the use of load balancers within Neutron can be found in Chapter 10, Load Balancing
Traffic to Instances.

Firewalling
In the current release of OpenStack, there are two methods of providing security to
instances: security groups and firewalls. When using security groups, instances are
placed into groups that share common functionality and rule sets. Iptables rules are
configured on compute nodes and filter traffic in and out of Linux bridges connected
to each instance. In a reference implementation, when using virtual firewalls
provided by Firewall as a Service, also known as FWaaS, security is handled at the
edge of the network on a Neutron router rather than at the compute node. Through
the Liberty release of OpenStack, the FWaaS API remains in an experimental status
with no guaranteed backward compatibility in future releases. More information
on securing instances can be found in Chapter 6, Managing Security Groups, and
Chapter 11, Firewall as a Service.

[3]

www.it-ebooks.info
Preparing the Network for OpenStack

Virtual private networks

A virtual private network, or 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 users to create IPSec-based VPN tunnels
from Neutron routers to remote gateways when using the open source reference
implementation. More information on creating and managing virtual private
networks can be found in Chapter 12, Virtual Private Network as a Service.

Network functions virtualization

Network functions virtualization, or NFV, is a network architecture concept that
proposes using traditional virtualization techniques to replace standalone network
appliances used for various network functions. These functions include intrusion
detection, caching, gateways, WAN accelerators, firewalls, and more. Support for
NFV within OpenStack is growing, but requires a major shift in the current design
model to support features such as VLAN trunking directly to virtualized instances,
unaddressed interfaces, and others that may be required by network devices.
In Juno, support for SR-IOV, also known as single root I/O virtualization, was
introduced. Using SR-IOV, instances are no longer required to use para-virtualized
drivers or to be connected to virtual bridges within the host. Instead, the instance
is attached to an SR-IOV port that is associated with a virtual function (VF) in the
NIC, allowing the instance to access the NIC hardware directly. Explaining how to
configure support for SR-IOV is outside the scope of this book, but more information
can be found on the OpenStack Wiki at https://wiki.openstack.org/.

Preparing the physical infrastructure

When architecting the network, it is important to first determine how the cloud will
be used. Is a highly scalable environment with multiple levels of network, hardware,
and service redundancy required? Or, are your needs less complex, requiring
nothing more than a sandbox for application development, with little concern
given to the resiliency of the network or compute platform? Are all of the advanced
networking features that OpenStack Networking has to offer in terms of routing,
firewalling, and load balancing required? Or, are you looking to leverage existing
physical hardware in the data center to accomplish those tasks?

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.

[4]

www.it-ebooks.info
 Chapter 1

The official OpenStack website (www.openstack.org) provides reference

architectures for OpenStack clouds leveraging Neutron networking that involves a
combination of one or more of the following nodes:

• Controller node
• Network node
• Compute node

Before the installation of OpenStack can begin, 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, which can include a dedicated management interface, a network
dedicated to overlay network traffic, and one or more networks that provide external
connectivity to instances. As shown in the preceding diagram, the configuration
of interfaces and networks represented in the top half of the diagram are the
responsibility of the network or system administrator. These responsibilities include
the configuration of physical switches, firewalls, or routers as well as interfaces
on the servers themselves. The bottom half of the diagram represents interfaces
and devices such as virtual switches and virtual machines that will be configured
automatically by OpenStack.

[5]

www.it-ebooks.info