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.