OpenStack uses the libvirt KVM/QEMU driver to provide platform virtualization in default Nova configurations. When an instance is booted for the first time, Neutron assigns a virtual port to each network interface of the instance. KVM creates a virtual network interface called a tap interface on the compute node hosting the instance. The tap interface corresponds directly to a network interface within the guest instance. Through the use of a bridge, the host can expose the guest instance to a physical network.

Neutron supports many types of virtual and physical switches and includes built-in support for Linux bridges and Open vSwitch virtual switches.

A Linux bridge is a virtual switch on a host that connects multiple network interfaces. When using Neutron, a bridge usually connects a physical interface to one or more virtual or tap interfaces. A physical interface includes Ethernet interfaces, such as eth1, or bonded interfaces, such as bond0. A virtual interface includes VLAN interfaces, such as eth1.100, as well as tap interfaces created by KVM. You can connect multiple physical or virtual network interfaces to a Linux bridge.

The following diagram provides a high-level view of a Linux bridge leveraged by Neutron:

Figure 4.1

In Figure 4.1, the Linux bridge, brqXXXX, is connected to a single physical interface, eth1, and three virtual interfaces, tap0, tap1, and tap2. The three tap interfaces correspond to a network interface within the respective guest instance. Traffic from eth0 in a virtual machine instance can be observed on the respective tap interface on the host as well as on the bridge interface and the physical interface connected to the bridge.

Open vSwitch operates as a software-based switch that uses virtual network bridges and flow rules to forward packets between hosts. Most Neutron setups that leverage Open vSwitch utilize at least three virtual switches or bridges, including a provider, integration, and tunnel bridge. These virtual switches are cross connected with one another, similar to how a physical switch may be connected to another physical switch with a cross connect cable.

More information on how Linux bridges and Open vSwitch bridges connect instances to the network will be covered later in this chapter.

Configuring the bridge interface

In this installation, the eth2 physical network interface will be utilized for bridging purposes. On the controller and compute nodes, configure the eth2 interface within the /etc/network/interfaces file, as follows:

auto eth2
iface eth2 inet manual

Close and save the file and bring the interface up with the following command:

# ip link set dev eth2 up

Confirm that the interface is in an UP state using the ip link show dev eth2 command, as shown in the following screenshot:

Figure 4.2

If the interface is up, it is ready for use in a Linux or Open vSwitch bridge.

Note

As the interface will be used in a bridge, an IP address cannot be applied directly to it. If there is an IP address applied to eth2, it will become inaccessible once the interface is placed in a bridge. Instead, consider applying the IP address to the bridge if you must have connectivity to this interface.

Neutron supports overlay networking technologies that allow virtual networks to scale across the cloud with little to no change in the underlying physical infrastructure. To accomplish this, Neutron leverages L2-in-L3 overlay networking technologies, such as GRE and VXLAN. When configured accordingly, Neutron builds point-to-point tunnels between all network and compute nodes in the cloud using the management or another dedicated interface. These point-to-point tunnels create what is called a mesh network, where every host is connected to every other host. A cloud consisting of one controller running network services and three compute nodes will have a fully meshed overlay network that resembles Figure 4.3:

Figure 4.3

Using the ML2 plugin, GRE- and VXLAN-based networks can be created by users at scale without any changes to the underlying switching infrastructure. When GRE- or VXLAN-based networks are created, a unique ID is specified that is used to encapsulate the traffic. Every packet between instances on different hosts is encapsulated on one host and sent to the other through a point-to-point GRE or VXLAN tunnel. When the packet reaches the destination host, the tunnel-related headers are stripped, and the packet is forwarded through the connected bridge to the instance.

The following diagram shows a packet encapsulated by a host:

Figure 4.4

In Figure 4.4, the outer IP header source and destination addresses identify the endpoints of the tunnel. Tunnel endpoints include compute nodes and any node running the L3 and DHCP services, such as a network node. The inner IP header source and destination addresses identify the original sender and recipient of the payload.

Because GRE and VXLAN network traffic is encapsulated between hosts, many physical network devices cannot participate in these networks. As a result, GRE and VXLAN networks are effectively isolated from other networks in the cloud without the use of a Neutron router. More information on creating Neutron routers can be found in Chapter 7, Creating Standalone Routers with Neutron.