Describing OpenStack Networking for Public Applications
Many cloud applications are public-facing services, or have at least one instance requiring public access. A domain operator ensures that existing data center networks are properly configured and available for use by cloud users. The domain operator can advise the cloud user when to choose between a tenant or provider network, and how to appropriately configure DNS and DHCP parameters.
To deploy an instance for public access there are two methods; use a provider network, or use a tenant network that has a routed connection to an external network.
Use a provider network if you have no need for flexibility, or the networking services offered by OpenStack. A tenant network gives you the flexibility to change firewall rules as required, or change the network layout of an application without requiring a network administrator.
Defining Provider and External Networks
Provider networks are the most common type of network used by OpenStack clients. Provider networks can only be created by a user with administrative privileges. After being created and shared, provider networks can be used by any cloud user or project. Provider networks can be of type local, flat, VLAN, GRE, VXLAN, or GENEVE.
Creating a provider network in OpenStack creates a mapping to a network that is outside the OpenStack platform. This allows instances to be connected to the network at layer 2, possibly sharing the same network with external hosts. Because this is a physical network outside of OpenStack, DHCP allocation and DNS must be configured in collaboration with the network administrators.
OpenStack requires at least one external network and this is created during overcloud deployment. An external network is a provider network that is marked as external. By marking a provider network as external, it can be connected to an OpenStack router as a gateway network. This configuration uses Network Address Translation (NAT) by default.
To use this method, an instance must be deployed to a tenant network that is connected to a router with the gateway set to the external network. For external traffic to reach the instance, the cloud user must associate a floating IP address with the instance, and also create security group rules for each traffic type, such as SSH, ICMP, or HTTP.
Considerations When Using Provider Networks
When using tenant networks, you can choose any subnet range and any DHCP configuration without affecting any other cloud user or project. When using provider networks, however, you are constrained to working within the existing infrastructure configuration. For example, the network range to use in the associated subnet is determined by the network administrators. Configuring a network range that does not match will result in your network traffic being unroutable, and no communication to or from the instance will work.
If a DHCP server is already configured for the subnet then you should not configure DHCP on the provider network. Configuring a DHCP allocation pool without consulting the network administrators may result in IP address conflicts, preventing communication for your instance.
If you are configuring DHCP for the provider network, then you need to obtain a list of DNS servers from the network administrators. Not all DNS servers may be reachable from all networks, so configuring DNS settings incorrectly might result in name resolution failure.
The options to configure the provider network type are not arbitrary; they must be selected to align with the physical network design. Network administrators determine what is required and configure the physical network accordingly. The most common network types presented to OpenStack include flat and VLAN networks.
Managing Networks Using the CLI
External, provider, and tenant networks can be created using the CLI, however you must have administrative privileges to create a provider network.
Use the openstack network create command to create the provider network. The external, shared, provider-network-type, and provider-physical-network options are required.
The --share option allows all projects to use the virtual network. The --external option specifies that the virtual network is external. Not all provider networks are external; the --internal option creates an internal provider network. The --provider-network-type and --provider-physical-network options connect the flat virtual network to the flat physical network.
[user@demo ~(admin)]$ openstack network create \
> --external \
> --share \
> --provider-network-type flat \
> --provider-physical-network datacentre \
> provider-demo
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
...output omitted...
| mtu | 1500 |
| name | provider-demo |
| port_security_enabled | True |
| project_id | e6b7f37fadf943e1aae06a5c2e55d646 |
| provider:network_type | flat |
| provider:physical_network | datacentre |
| provider:segmentation_id | None |
| qos_policy_id | None |
| revision_number | 6 |
| router:external | External |
| segments | None |
| shared | True |
| status | ACTIVE |
| subnets | |
| tags | |
| updated_at | 2020-07-17T13:44:28Z |
+---------------------------+--------------------------------------+
Use the openstack subnet create command to create a subnet for the provider network. Specify the subnet range, DHCP setting, the gateway, the DNS name server, the allocation pool, the network and the subnet name.
[user@demo ~(admin)]$ openstack subnet create \
> --subnet-range 172.25.250.0/24 \
> --no-dhcp \
> --gateway 172.25.250.254 \
> --dns-nameserver 172.25.250.254 \
> --allocation-pool start=172.25.250.101,end=172.25.250.189 \
> --network provider-demo \
> provider-subnet-172.25.250
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| allocation_pools | 172.25.250.101-172.25.250.189 |
| cidr | 172.25.250.0/24 |
| created_at | 2020-07-17T13:51:02Z |
| description | |
| dns_nameservers | 172.25.250.254 |
| enable_dhcp | False |
| gateway_ip | 172.25.250.254 |
| host_routes | |
| id | 1f5e3ad7-25b0-4e49-ad7e-d6673e2882c9 |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | provider-subnet-172.25.250 |
| network_id | 29840e5f-3c29-4937-b6f8-237b51c21899 |
| project_id | e6b7f37fadf943e1aae06a5c2e55d646 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-07-17T13:51:02Z |
+-------------------+--------------------------------------+
Managing Networks Using the Dashboard
On the Admin tab, navigate to → .
Click Create Network to create a new network. Enter provider-demo as the network name. Select a project and a provider network type from the list available. Choose a physical network. If the provider network is to be shared between multiple projects, click Shared. The network can be either internal or external.
Click Next to create the subnet. Provide the subnet name, network address, and a gateway IP. Click Next to make the final settings for the subnet.
Disable or enable DHCP and provide an allocation pool, for example 172.25.250.101,172.25.250.189. Enter a DNS name server, for example 172.25.250.254. Click Create.
