The use of multiple interfaces can be expanded to utilize bonds instead of individual network interfaces. The following common bond modes are supported:
- Mode 1 (active-backup): Mode 1 bonding sets all interfaces in the bond to a backup state while one interface remains active. When the active interface fails, a backup interface replaces it. The same MAC address is used upon failover to avoid issues with the physical network switch. Mode 1 bonding is supported by most switching vendors, as it does not require any special configuration on the switch to implement.
- Mode 4 (active-active): Mode 4 bonding involves the use of aggregation groups, a group in which all interfaces share an identical configuration and are grouped together to form a single logical interface. The interfaces are aggregated using the IEEE 802.3ad Link Aggregation Control Protocol (LACP). Traffic is load balanced across the links using methods negotiated by the physical node and the connected switch or switches. The physical switching infrastructure must be capable of supporting this type of bond. While some switching platforms require that multiple links of an LACP bond be connected to the same switch, others support technology known as Multi-Chassis Link Aggregation (MLAG) that allows multiple physical switches to be configured as a single logical switch. This allows links of a bond to be connected to multiple switches that provide hardware redundancy while allowing users the full bandwidth of the bond under normal operating conditions, all with no additional changes to the server configuration.
Bonding can be configured within the Linux operating system using tools such as iproute2, ifupdown, and Open vSwitch, among others.The configuration of bonded interfaces is outside the scope of OpenStack and this book.
The following table demonstrates the use of two bonds instead of two individual interfaces:
Service/function |
Purpose |
Interface |
VLAN |
SSH |
Host management |
bond0 |
10 |
APIs |
Access to OpenStack APIs |
bond0 |
15 |
Overlay network |
Used to tunnel overlay (VXLAN, GRE, GENEVE) traffic between hosts |
bond1 |
20 |
Guest/external network(s) |
Used to provide access to external cloud resources and for VLAN-based project networks |
bond1 |
Multiple |
In this book, an environment will be built using three non-bonded interfaces: one for management and API traffic, one for VLAN-based provider or project networks, and another for overlay network traffic. The following interfaces and VLAN IDs will be used:
Service/function |
Purpose |
Interface |
VLAN |
SSH and APIs |
Host management and access to OpenStack APIs |
eth0 / ens160 |
10 |
Overlay network |
Used to tunnel overlay (VXLAN, GRE, GENEVE) traffic between hosts |
eth1 / ens192 |
20 |
Guest/external network(s) |
Used to provide access to external cloud resources and for VLAN-based project networks |
eth2 / ens224 |
30,40-43 |