Imagine a basic OpenStack cloud that consists of a single network on VLAN 100 for use with instances. The network architecture within the compute node resembles the following:

Figure 4.6

In Figure 4.6, three virtual machine instances are connected to a Linux bridge named brqXXXX via their respective tap interfaces. When an instance was launched in the network mapped to VLAN 100, a virtual interface named eth1.100 was automatically created and connected to a network bridge by Neutron. The eth1.100 interface is bound to the physical interface, eth1. As the traffic from instances traverses the Linux bridge and out towards the physical interface, the eth1.100 interface tags this traffic as VLAN 100 and drops it on eth1. The ingress traffic towards the instances through eth1 is inversely untagged by eth1.100 and sent to the appropriate instance through the bridge.

Using the brctl show command, the preceding diagram can be realized in the Linux CLI as the following:

Figure 4.7

The bridge ID in the output is dynamically generated based on the parent NIC of the virtual VLAN interface. In this bridge, the parent interface is eth1.

The bridge name, beginning with the brq prefix, is generated based on the UUID of the corresponding Neutron network that it is associated with. Each network uses its own bridge.

If more than one VLAN is needed, another Linux bridge will be created that contains a separate virtual VLAN interface. The new virtual interface, eth1.101, is connected to a new bridge, brqYYYY, as seen in Figure 4.8:

Figure 4.8

On the compute node, the preceding diagram can be realized as the following:

Figure 4.9

A flat network in Neutron is meant to describe a network in which VLAN tagging does not take place. Unlike VLAN tagged networks, flat networks require the physical interface of the host associated with the network to be connected directly to the bridge. This means that only a single flat network can exist per bridge and physical interface.

Figure 4.10 demonstrates a physical interface connecting to the bridge in a flat network scenario:

Figure 4.10

In Figure 4.10, eth1 is connected to the bridge named brqXXXX along with three tap interfaces that correspond to guest instances. The Linux kernel does not perform any VLAN tagging on the host.

On the compute node, the preceding diagram can be realized as the following:

Figure 4.11

When multiple flat networks are created, a separate physical interface must be associated with each flat network. Figure 4.12 demonstrates the use of a second physical interface used for flat networks:

Figure 4.12

On the compute node, the use of two physical interfaces for separate flat networks can be realized as the following:

Figure 4.13

With two flat networks, the host does not perform any VLAN tagging on the traffic traversing these bridges. The instances connected to the two bridges require a router to communicate with one another.

When VXLAN networks are created, the LinuxBridge agent creates a corresponding VXLAN interface using the iproute2 user-space utilities and connects it to a network bridge in lieu of a tagged or physical interface. The VXLAN interface is programmed with information such as the VNI and local VTEP address.

When the L2 population driver is configured, Neutron prepopulates the forwarding database with static entries consisting of the MAC addresses of instances and their respective host VTEP addresses. As a packet from an instance traverses the bridge, the host determines how to forward the packet by looking in the forwarding database. If an entry is found, Neutron will forward the packet out the corresponding local interface and encapsulate the traffic accordingly. To view the bridge table on each host, use the bridge fdb show command.

When creating a local network in Neutron, it is not possible to specify a VLAN ID or even a physical interface. The LinuxBridge plugin agent will create a bridge and connect only the tap interface of the instance to the bridge. Instances in the same local network will be connected to the same bridge and are free to communicate among one another. Because the host does not have a physical or virtual VLAN interface connected to the bridge, traffic between instances is limited to the host on which the instances reside.

Figure 4.14 demonstrates the lack of physical or virtual VLAN interfaces connected to the bridge:

Figure 4.14

In Figure 4.14, two local networks exist that utilize their respective bridges: brqXXXX and brqYYYY. Instances connected to the same bridge can communicate with one another but with nothing else outside of the bridge. There is no mechanism to permit traffic between instances on different bridges or hosts when using local networks.