What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!

Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!

50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.

Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.

Thousands of reference materials covering every tech concept you need to stay up to date.

Subscribe now

View plans & pricing

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.

Description

If you are an OpenStack-based cloud operator with experience in OpenStack Compute and nova-network but are new to Neutron networking, then this book is for you. Some networking experience is recommended, and a physical network infrastructure is required to provide connectivity to instances and other network resources configured in the book.

What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!

Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!

50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.

Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.

Thousands of reference materials covering every tech concept you need to stay up to date.

Subscribe now

View plans & pricing

Frequently bought together

Linux Shell Scripting Cookbook, Second Edition

€37.99

€36.99

€24.99

Total € 99.97

Filter reviews by

All

Amazon verified reviews

Navin Kumar Jaiswal Dec 25, 2014

Awesome book.

Amazon Verified review

Michael Bright Jan 04, 2015

This is an impressive guide to OpenStack “Neutron” Networking, written by James Denton of Rackspace - one of the leading companies in the OpenStack ecosystem. I was lucky to pick up a copy at the recent OpenStack summit in Paris, which RackSpace - James himself actually - were generously distributing.The book is organized into 8 chapters covering an introduction to OpenStack networking and installation followed by more detailed configuration of networks, routing, load balancing and firewalls. It provides a very complete and detailed coverage of Neutron networking in a recent OpenStack release (Havana). Every chapter finishes with a useful summary of what’s just been covered.I was initially surprised by the second chapter detailing an OpenStack installation, which seemed unnecessary and simplistic, but I guess it’s necessary to provide a common base for the rest of the book which is essentially a cookbook. So the book starts by a manual installation of OpenStack Havana on a CentOS base. Chapter 3 pursues with Neutron installation.A cookbook it definitely is, and you will get the most out of this book by working through the many configurations described throughout the book. Nevertheless, the book is still a good read if you only read along. I particularly appreciated Chapter 4 “Building a Virtual Switching Infrastructure”, for it’s clear description of different networking models, bridging and the use of LinuxBridge or OpenvSwitch. There’s also coverage of the OpenFlow flow rules managed by OVS. This chapter then describe how to configure one of these core layer2 plugins.The ML2 plugin framework is also mentioned and covered in an appendix, but not in great detail still being a work in progress. Note that LinuxBridge and OVS are already deprecated in the IceHouse release of OpenStack … that’s how fast OpenStack moves.Once the initial OpenStack and Neutron installation/configuration is covered it’s good to see that instructions cover both command-line and dashboard means of making modifications. Chapters 5 and 6 cover operations such as creation of networks, subnets and routers in great detail.Chapters 7 and 8 terminate the book discussing what today are the main applications of Neutron networking: load balancing and firewalls. Load Balancing as a Service (LBaaS) is covered in detail describing it’s use for creating highly available applications across a group of load-balanced servers as well as limitations in the current Havana (and IceHouse) releases. Firewall as a service (FWaaS) is described as experimental in the IceHouse OpenStack release.Appendices cover Neutron extensions for third-party plugins and the ML2 (“Modular Layer2”) plugin framework which will be the basis for all future network plugins for Neutron networking.OpenStack is a huge and fast moving open source project, and Neutron is arguably one of the more complex areas, so Kudos to James for providing this excellent snapshot of this critically important cloud technology. I can’t wait for the second edition …. in a couple of years.

shogo Nov 19, 2014

openstackはいろいろな部品からできているため、多くの参考書は概要や技術の触りだけを説明しているものがほとんどです。"Learning OpenStack Networking (Neutron)"はNetworking serviceに特化しながらも、各コンポーネントをインストールするところから解説付きで説明しています。よくあるAll-In-Oneのインストールではなく、二台のサーバーにマニュアルインストールをしていく構成ですので、各ステップを消化していけばopenstackの動きがわかるようにできています。openstackを実際にハンズオンで試したい、というネットワーク技術者であれば非常に有意義な本です。neutron...各サービス（LBaaS, FWaaS）の説明とハンズオンその他コンポーネント...インストール手順の説明とハンズオン

f. e. nar Oct 19, 2014

Greetings;This is the 1st book dedicated to Networking in Openstack, that's why I have pre-ordered it as soon as I see it. Author is a real time development engineer in related area and it has advantages & dis-advantages.Advantages: Since he is Subject Matter Expert, he does not "BS", he presents his knowledge from practice, lab-implementation side.Dis-Advantages: Like in every engineer (including myself) who writes a technical document, Author has assumed reader is full aware what is going on behind the scenes; such as "Openflow rules within OVS", such as usage of Neutron L3 Agent may cause bottle neck for high bandwidth traffic and it is a single point of failure.I recommend this book to new beginners of Openstack to learn little bit more about Neutron and have a general idea about forthcoming fancy features...I am looking forward for 2nd Edition with wider & deeper coverage.Ps; Ready to pay more for more knowledge :-)

Charles M Corona Dec 19, 2014

This book is a great guide for working with OpenStack and Neutron. It gives you a much better understanding of how to untangle deploy the messy world of Neutron.

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

What do you get with a Packt Subscription?

LEARNING OPENSTACK NETWORKING (NEUTRON)

Chapter 1. Preparing the Network for OpenStack

What is OpenStack Networking?