The reference architecture for OpenStack Networking defines at least four distinct types of traffic that will be seen on the network:

Although I have taken the liberty of splitting out the network traffic into dedicated interfaces in this book, it is not necessary to do so to create an operational OpenStack cloud. In fact, many administrators and distributions choose to collapse multiple traffic types onto single or bonded interfaces using VLAN tagging. Depending on the chosen deployment model, the administrator may spread networking services across multiple nodes or collapse them onto a single node. The security requirements of the enterprise deploying the cloud will often dictate how the cloud is built. The various network and service configurations will be discussed in the upcoming sections.

For hosts using a single interface, all traffic to and from instances as well as internal OpenStack, SSH management, and API traffic traverse 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 all available bandwidth.

The following diagram demonstrates the use of a single physical interface for all traffic when using the Open vSwitch driver. On the controller node, a single interface is connected to a bridge and handles external, guest, management, and API service traffic. On the compute node, a single interface handles guest and management traffic:

Figure 1.2

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

To reduce the likelihood of guest network bandwidth consumption impacting management traffic and to maintain a more robust security posture, segregation of traffic between multiple physical interfaces is recommended. At a minimum, two interfaces should be used: one that serves as a dedicated interface for management and API traffic and another that serves as a dedicated interface for external and guest traffic. Additional interfaces can be used to further segregate traffic. The following diagram demonstrates traffic split across two physical interfaces when using the Open vSwitch driver:

Figure 1.3

In the preceding diagram, a dedicated physical interface on the controller node handles OpenStack API and management traffic. Another interface is connected to a bridge that handles external and overlay traffic to and from Neutron routers and other network resources. On the compute node, a dedicated physical interface is used for management traffic and another for overlay traffic to and from instances.

In this book, the environment will be built using three interfaces: one for management and API traffic, one for external or VLAN tenant network traffic, and another for overlay network traffic:

Figure 1.4

In the preceding diagram, a dedicated interface on the controller node handles OpenStack API and management traffic. Another dedicated interface handles overlay traffic, and another is connected to a bridge that handles external traffic. On the compute node, a dedicated interface is used for management traffic, another dedicated interface handles overlay traffic, and another is connected to a bridge that handles VLAN traffic when VLAN tenant networks are in use.

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 a bridge or used as a regular interface. The technology used to accomplish this is known as IEEE 802.1ad Link Aggregation Control Protocol, or LACP. The physical switching infrastructure must be capable of supporting this type of bond. Legacy switching devices required the multiple links of a bond to be connected to the same switch. Modern devices support technology such as vPC and MLAG. They allow links of a bond to be connected to two switches, providing hardware redundancy between switches while allowing users the full bandwidth of the bond in normal operating conditions, with no changes to the server configuration necessary.

In addition to aggregating interfaces, 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 the operating system when the appropriate kernel module is installed. Bonding can be configured in Open vSwitch if desired, but is outside the scope of OpenStack and this book.

Bonding interfaces can be an inexpensive way to provide hardware-level network redundancy to the cloud infrastructure. If you are interested in configuring NIC bonding on your hosts, refer to the Ubuntu bonding page at https://help.ubuntu.com/community/UbuntuBonding.

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 Neutron layer 3 agent is not utilized. Two physical interfaces are used to separate management and instance network traffic:

Figure 1.5

The preceding diagram reflects the use of a single combined controller/network node and one or more compute nodes, with Neutron providing only layer 2 connectivity between instances and external gateway devices. 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. Three physical interfaces are used to provide separate control and data planes:

Figure 1.6

The preceding diagram reflects the use of a single combined controller/network 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 and external provider networks.

The environment built out in this book will be composed of a single controller node running all OpenStack network services and two compute nodes running Nova compute services.

A network node is dedicated to handling most or all the 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. Some Neutron services, such as the L3 and DHCP agents and the Neutron API service, can be scaled out across multiple nodes for redundancy and increased performance.

The following diagram demonstrates a network node hosting all OpenStack Networking services, including the Neutron L3, DHCP, metadata, and LBaaS agents. The Neutron API service, however, remains installed on the controller node. Three physical interfaces are used where necessary to provide separate control and data planes:

Figure 1.7

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