Configuring Network Interfaces for OpenStack Networks

In an OpenStack environment, the network traffic can be divided into the following networks:

Administration network

This network is not part of the OpenStack infrastructure. It provides Internet access for all nodes and is used for administration to install software packages and security updates from Oracle Unbreakable Linux Network or Oracle Yum Server, and to provide access to the Docker registry and other services such as NTP and DNS.

Public network

This network provides the external access to OpenStack services. For instances (virtual machines), this network provides the route out to the external network and the IP addresses to enable inbound connections to the instances. This network can also provide the public API endpoints to connect to OpenStack services.

Management/API network

This network is a private internal network used for communication between all the OpenStack services and for high availability. All nodes in the deployment must have an IPv4 address on this network.

Virtual machine network

This network is a private internal network that is used for communication between the OpenStack instances (virtual machines), and also between the instances and the network nodes to provide inbound and outbound connections to the public network.

Storage network

This network is a private internal network that is used for the communication between compute nodes and storage nodes to access the storage.

Once you have decided how you want to implement these networks, you configure the names of the network interfaces on the OpenStack nodes that are connected to these networks by setting properties with the kollacli property set command.

Figure 4 shows the default network configuration and the properties that are used to specify the network interfaces on the nodes. With this configuration, the neutron_external_interface property specifies the name of the network interface on the public network, and the network_interface property specifies the name of the network interface on a single consolidated network used for the management/API, virtual machine, and storage traffic. This configuration requires the minimum number of network interfaces.

Figure 4 Default Network Configuration


While consolidating the management/API, virtual machine, and storage networks into a single network makes it easier to deploy OpenStack services, for performance and security reasons it is best to separate and isolate these networks. Figure 5 shows a fully-expanded network configuration and the properties that specify the network interfaces on the nodes. With this configuration, the neutron_external_interface property specifies the name of the network interface on the public network, and there are separate properties for specifying the names of network interfaces on the management/API (api_interface), virtual machine (tunnel_interface), and storage (storage_interface) networks. This configuration requires the maximum number of network interfaces.

Figure 5 Expanded Network Configuration


If you are starting with a small OpenStack deployment, the network configuration is flexible so you do not have to separate the management/API, virtual machine, and storage networks in one go. You can start with the default consolidated network (network_interface), and then use the properties to separate the networks as your deployment expands.

You specify the network interface names on the nodes using a single property for each network. This works best where the hardware on the nodes is identical. When this is not the case, you can handle the variations by setting properties that are specific to groups or hosts, see Setting Properties for Deployment Groups or Hosts. The network interface names must not contain the dash character (-) because Ansible interprets this as an underscore character (_).