Multiple networks

Compute instances support multiple interfaces (multi-NIC), which allows simultaneous active connections to separate networks. The feature allows for separation of administrative and public access, flexible IP addressing, bandwidth protection and configuration of service fail-over solutions.


The server configuration depends on the network scenario. This chapter describes networking with two project networks which can be extended to further networks if required. For other types of networking, see and

Network types

Users create project networks for connectivity within projects. By default, they are fully isolated and are not shared with other projects. OpenStack Networking supports several types of network isolation and overlay technologies: flat, VLAN, GRE or VXLAN.

Flat networks

In a flat network, all instances connect to the same network without going through any intermediary bridge or router. The standard self-service network is of this type, created from a network segment range available to the project with segmentation ID (VLAN, VNI etc.) pre-defined on the physical network.

Since a flat network is a single network segment, no VLAN tagging or other network segregation can be done. Network segment management requires OpenStack administrator access.

This is the simplest network type to set up, but has the disadvantage that any virtual machine is visible from any other on the network.

VLAN networks

VLAN provides a method to split a physical network into separate network segments. A virtual machine can access different VLAN (provider or project networks) through a network trunk.

Only administrators can assign a project a specific network segment ID through the OpenStack provider extension.

GRE and VXLAN networks

VXLAN and GRE are encapsulation protocols that create overlay networks to control communication between compute instances.

Configuration of such network requires OpenStack administrator privileges.

Administration network

The administration network is accessed through a bastion host accessed through a floating IP or a pair of bastion hosts accessed through a virtual IP. It has an IP range used for administrative tasks only.

Internet access to remote servers can be provided either through SNAT or a proxy server. Apart from the bastion hosts, all servers are assumed to be connected both to the payload and the administration networks.

Server configuration

On the server NIC, each network can be connected to its own interface, or two OpenStack ports can share an interface. For the purpose of this chapter, we assume that we have created two networks, a payload network on and an administration network on

Launch server with multiple NICs

The simplest way to enable two server interfaces is to launch it with two NIC declarations:

openstack server create --nic net-id=<payload-net> --nic net-id=<admin-net> --security-group <sg> ...

In this case, each NIC corresponds to a port to the respective network. If the security group is passed by argument, it will be applied to both ports, as can be seen in the output from server show.

Add port with fixed IP

To a server launched on the payload network, say, it is possible to add a port - optionally with a fixed IP address - to connect to the administration network. To create such a port, called server-admin with fixed IP and with an assigned security group allowing SSH ingress connections, execute

openstack port create --network <admin-net> --security-group <ssh-sg> \
--fixed-ip subnet=<admin-subnet>,ip-address= server-admin

The port is assigned to server with

openstack server add port <server-name> server-admin

When adding a port to an existing server, it has to be defined added to the server interface. In Ubuntu, this can be done with netplan. After logging in to the server with, for example, SSH ProxyCommand, verify the interface device name corresponding to the port just added with ip a (marked in Figure 1).

Open the Netplan configuration file for editing

sudo nano /etc/netplan/50-cloud-init.yaml

Add the fixed IP address in the applicable CIDR format as follows

    dhcp4: no
    addresses: []

Note that the entries in the configuration file must have correctly aligned indentation, and that <TAB> cannot be used for this (Figure 2).

The changes are made to take effect with

sudo netplan apply

A alternative and more general method is to configure the interface manually. After logging in to the server, add the fixed IP address in the applicable CIDR format as follows

sudo ip addr add dev ens6
sudo ip link set ens6 up

The configured interface should look like shown in Figure 3.

With proper security groups assigned to the ports, the instance should now be reachable from the administration IP of the bastion host.