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.
Contents
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 https://pannet.atlassian.net/l/c/006L363L and https://pannet.atlassian.net/l/c/Hvc6WppC
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 10.0.0.0/24 and an administration network on 10.1.0.0/24.
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 10.1.0.100 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=10.1.0.100 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
ens6:
dhcp4: no
addresses: [10.1.0.100/24]
gateway4: 10.1.0.1
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 10.1.0.100/24 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.