Download code from GitHub
OpenStack Networking, otherwise known as Neutron, is an API-driven system for managing virtual and physical network resources in an OpenStack cloud. The job of Neutron is simple: it is meant to provide Networking as a Service (NaaS) to cloud environments. Users can leverage the Neutron API to build network architectures in the cloud that define the availability of their applications. Neutron strips away from the user much of the complexity of building rich network architectures in the cloud. In this book, you will learn about some of the basic networking features offered by Neutron, and you will build a small environment that will expose you to various methods of interacting with the Neutron API to build simple network configurations.
Many cloud environments rely on virtual compute technologies made available by hypervisors such as Kernel-based Virtual Machine (KVM), Xen, and Hyper-V, among many others. Neutron's core purpose is to connect virtual machine instances to a virtual network spanning the cloud and connect the virtual network to the physical network infrastructure. The containerization of applications made possible by Linux Containers (LXC), Docker, and other container technologies means that Neutron should also be responsible for providing network connectivity and features to containers in the future.
Neutron relies on the use of its pluggable and extensible architecture to construct and configure virtual and physical network resources. Many physical devices, such as switches, routers, firewalls, and load balancers, are implemented in software in reference implementations. A reference implementation is one that relies on the use of plugins, drivers, and agents made available for free by the Neutron community. A common reference plugin is the Modular Layer 2 (ML2) plugin, which is used to define a logical networking framework that agents can use to construct the virtual network. Common reference agents include the Open vSwitch (OVS) and Linux bridge agents, which are used to construct their respective virtual switching infrastructures based on networks that users have defined with the Neutron API.
In a reference implementation, Neutron relies on virtual bridges and switches to connect virtual instances, containers, and other network resources to the network. Neutron includes support for standard Linux bridges and virtual switches created with OVS. OVS is an open source virtual switch that supports dozens of technologies and protocols, including NetFlow, Switch port Analyzer (SPAN), Remote SPAN (RSPAN), Link Aggregation Control Protocol (LACP), and 802.1q VLAN tagging. However, much of its extended functionality and features are not exposed to users through the OpenStack API. Neutron also supports the use of overlay networking technologies such as Generic Routing Encapsulation (GRE) and Virtual Extensible LAN (VXLAN), among others, to connect virtual bridges and switches across nodes to one another over a common network. More information on how Neutron leverages virtual switching technologies can be found in Chapter 5, Switching.
Neutron provides routing and network address translation capabilities that allow instances and other virtual network devices to access networks other than their own. When a user creates a virtual network, that network is isolated from all other networks. Users can create virtual routers and attach one or more virtual networks to a router. Once attached, devices in the network are capable of communicating with other attached networks and, in some cases, remote networks such as the Internet. Neutron also provides inbound connectivity through the use of floating IPs. A floating IP is a 1-to-1 relationship between the instance on the virtual network and an IP address on a real network. More information on various routing features of Neutron can be found in Chapter 6, Routing.
Neutron includes support for networking technologies such as load balancers, firewalls, and virtual private networks, and has software-based reference implementations for each of these technologies, using software such as HAProxy, iptables, StrongSwan, and OpenSwan. The Neutron API can be used to construct logical models that are then implemented by various plugins and agents across the cloud. The networking features discussed in this subsection will not be covered in detail in this book, but they are important features of Neutron networking.
Load Balancing as a Service (LBaaS) provides users with the ability to create and manage load balancers that balance traffic across multiple virtual machine instances. Users can create monitors, set connection limits, apply persistence profiles to traffic traversing a load balancer, and more. The reference plugin uses HAProxy as the software load balancer, but plugins exist that allow Neutron to interface with physical load balancers from vendors such as Citrix, F5, Radware, and others.
Firewall as a Service (FWaaS) provides users the ability to create and manage firewalls that filter traffic to and from virtual machine instances and other network devices. The reference plugin implements virtual firewalls inside existing Neutron routers using iptables, and third-party plugins exist that allow Neutron to interface with physical firewalls.
Virtual Private Network as a Service (VPNaaS) provides users with the ability to create site-to-site Internet Protocol Security (IPSec) tunnels between Neutron routers and other VPN gateways. The reference plugin implements IPSec connections inside existing Neutron routers using software such as StrongSwan or OpenSwan, and third-party plugins exist that allow Neutron to interface with physical VPN gateway devices.
Most OpenStack clouds are made up of physical infrastructure nodes that fit into one of the following four categories:
Controller nodes: These usually run the application programming interface (API) services for all of the OpenStack components, including Glance, Nova, Keystone, and Neutron. In addition, controller nodes run the database and messaging servers and are often the point of management of the cloud via the Horizon dashboard. Most OpenStack API services can be installed on multiple controller nodes and can be load balanced to scale the OpenStack control plane.
Network nodes: These usually run DHCP and metadata services and can host virtual routers when the Neutron L3 agent is installed. In smaller environments, it is not uncommon to see controller and network node services collapsed onto the same server or set of servers. As the cloud grows in size, most network services can be broken out among other servers or installed on their own server for optimal performance.
Compute nodes: These usually run a hypervisor, such as KVM, Hyper-V, or Xen, or container software, such as LXC or Docker. In some cases, a compute node may also host virtual routers, especially when Distributed Virtual Routing (DVR) is configured. In proof-of-concept or test environments, it is not uncommon to see controller, network, and compute node services collapsed onto the same machine. This is especially common when using DevStack, a software package designed for developing and testing OpenStack code. All-in-one installations are not recommended for production use.
Storage nodes: These are usually limited to running software related to storage, such as Cinder, Ceph, or Swift. Storage nodes do not usually host any type of Neutron Networking service or agent and will not be discussed in this book.
When Neutron services are broken out among many hosts, the layout of services will often resemble the following diagram, though it can vary from environment to environment:
In this book, we will build a test environment on a single node that demonstrates basic OpenStack network functionality. This distribution of services will look like this:
In a reference implementation of Neutron, the following components can be found installed and running across the cloud infrastructure:
One or more Neutron API servers
A core network plug-in and driver
One or more DHCP agents
One or more metadata agents
One or more network plugin agents
The Neutron API is a powerful tool responsible for taking in user-defined network topologies and passing them to network plugins for implementation. Users can interface with the Neutron API using command-line utilities, Python libraries, or directly via HTTP.
Neutron supports plugins, drivers, and agents that extend network functionality and implement networks and features defined by users. In this section, we will cover these concepts.
There are two major plugin types within the Neutron architecture:
Core plugins: They are responsible for adapting the logical network described by the API into something that can be implemented by the L2 agent and IP Address Management (IPAM) system running on the host. The ML2 plugin is used in reference implementations.
Service plugins: They provide additional network services, such as routing, load balancing, and firewalling, and are all available in reference implementations.
The ML2 plugin relies on different types of drivers to determine the types of networks to implement and the mechanisms used to implement them. Type drivers describe different types of network supported by Neutron, including flat, VLAN, VXLAN, GRE and local. Mechanism drivers are used to implement the described networks in software or on physical hardware.
Third-party vendors have implemented support for their respective network technologies by developing their own plugins that implement the Neutron API and extend network services. Vendors including Cisco, Arista, Brocade, Radware, F5, and VMware have created plugins that allow Neutron to interface with OpenFlow controllers, load balancers, switches, and other physical and virtual network hardware. While third-party drivers are outside the scope of this book, we will cover some of the common type and mechanism drivers in Chapter 5, Switching.
The Neutron server is the centralized controller of the network and is responsible for providing an API to users and storing information about the network in the database. However, the actual commands to implement the network are executed on the compute and network nodes by agents that run on those nodes. Neutron agents receive messages and instructions from the Neutron server on the message bus and execute the changes accordingly.
The Dynamic Host Configuration Protocol (DHCP) is a protocol used for dynamically distributing network configuration parameters, such as IP addresses and routes, to network interfaces. Many cloud instances require the use of DHCP to acquire their IP address and other network information. Neutron is capable of providing DHCP services to all networks created in the cloud, and it uses a DHCP agent to manage those services. In a reference implementation, a Neutron DHCP agent runs on one or more infrastructure nodes and spawns a dnsmasq process for each network where DHCP is enabled.
OpenStack provides metadata services, which enable users to retrieve information about their instances that can then be used to configure or manage the running instance. Metadata includes information such as the hostname, fixed and floating IPs, and public SSH keys. In addition to metadata, users can access user data and scripts that are provided during the launching of an instance and are executed during the boot process.
The Neutron metadata agent proxies requests from instances to the Nova metadata API, and it is accessible to instances via http://169.254.169.254/metadata.
The Neutron plugin agents are services that run on compute and network nodes and are responsible for configuring and implementing the virtual network on the local node. Plugin agents listen for messages from the Neutron server and construct the local network based on information in those messages. An example of how the agents work together with the Neutron server to build the virtual network can be observed in the following diagram:
In the preceding diagram, the following actions take place among various Neutron components:
Neutron receives a request to connect virtual machine instances to a new network. The API server invokes the ML2 plugin to process the request.
The ML2 plugin passes the request to the OVS mechanism driver, which creates a message using information available in the request. The message is cast to the respective OVS agent for processing over the management network.
The OVS agent receives the message and configures the local virtual switch.
Meanwhile, the DHCP agent also receives messages related to this request and configures the DHCP server on the network node. Once this is done, the virtual machine instances will interface with the DHCP server and receive their IP address over the data network.
Neutron is one of the more complicated OpenStack components to configure and maintain, and the list of features in this chapter is by no means comprehensive. The payoff of Neutron's complexity is that users are able to programmatically build elaborate and consistent network topologies. Neutron provides reference implementations using open source components for all of the features it supports, and its extensible framework allows third parties to build plugins and drivers that can interface with other virtual and physical network devices in order to bring additional features and functionality to the cloud. To successfully deploy Neutron and harness all it has to offer, it is important to have a strong understanding of core networking concepts. In this book, we will cover some fundamental network concepts of Neutron and build a foundation for deploying instances.
In the next chapter, we will use the RDO OpenStack distribution and its included installer to configure an all-in-one deployment that will enable us to explore virtual switching and routing concepts in further detail.
