Chapter 3. Common administrative tasks
OpenStack Networking (neutron) is the software-defined networking component of Red Hat OpenStack Platform. The virtual network infrastructure enables connectivity between instances and the physical external network.
This section describes common administration tasks, such as adding and removing subnets and routers to suit your Red Hat OpenStack Platform deployment.
3.1. Create a network
Create a network to give your instances a place to communicate with each other and receive IP addresses using DHCP. A network can also be integrated with external networks in your Red Hat OpenStack Platform deployment or elsewhere, such as the physical network. This integration allows your instances to communicate with outside systems. For more information, see Bridge the physical network.
When creating networks, it is important to know that networks can host multiple subnets. This is useful if you intend to host distinctly different systems in the same network, and would prefer a measure of isolation between them. For example, you can designate that only webserver traffic is present on one subnet, while database traffic traverse another. Subnets are isolated from each other, and any instance that wishes to communicate with another subnet must have their traffic directed by a router. Consider placing systems that will require a high volume of traffic amongst themselves in the same subnet, so that they don’t require routing, and avoid the subsequent latency and load.
1. In the dashboard, select Project > Network > Networks.
2. Click +Create Network and specify the following:
Field | Description |
---|---|
Network Name |
Descriptive name, based on the role that the network will perform. If you are integrating the network with an external VLAN, consider appending the VLAN ID number to the name. For example, |
Admin State | Controls whether the network is immediately available. This field allows you to create the network but still keep it in a Down state, where it is logically present but still inactive. This is useful if you do not intend to enter the network into production right away. |
3. Click the Next button, and specify the following in the Subnet tab:
Field | Description |
---|---|
Create Subnet | Determines whether a subnet is created. For example, you might not want to create a subnet if you intend to keep this network as a placeholder without network connectivity. |
Subnet Name | Enter a descriptive name for the subnet. |
Network Address | Enter the address in CIDR format, which contains the IP address range and subnet mask in one value. To determine the address, calculate the number of bits masked in the subnet mask and append that value to the IP address range. For example, the subnet mask 255.255.255.0 has 24 masked bits. To use this mask with the IPv4 address range 192.168.122.0, specify the address 192.168.122.0/24. |
IP Version | Specifies the internet protocol version, where valid types are IPv4 or IPv6. The IP address range in the Network Address field must match whichever version you select. |
Gateway IP | IP address of the router interface for your default gateway. This address is the next hop for routing any traffic destined for an external location, and must be within the range specified in the Network Address field. For example, if your CIDR network address is 192.168.122.0/24, then your default gateway is likely to be 192.168.122.1. |
Disable Gateway | Disables forwarding and keeps the subnet isolated. |
4. Click Next to specify DHCP options:
- Enable DHCP - Enables DHCP services for this subnet. DHCP allows you to automate the distribution of IP settings to your instances.
IPv6 Address -Configuration Modes If creating an IPv6 network, specifies how IPv6 addresses and additional information are allocated:
- No Options Specified - Select this option if IP addresses are set manually, or a non OpenStack-aware method is used for address allocation.
- SLAAC (Stateless Address Autoconfiguration) - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. This configuration results in an OpenStack Networking subnet created with ra_mode set to slaac and address_mode set to slaac.
- DHCPv6 stateful - Instances receive IPv6 addresses as well as additional options (for example, DNS) from OpenStack Networking DHCPv6 service. This configuration results in a subnet created with ra_mode set to dhcpv6-stateful and address_mode set to dhcpv6-stateful.
- DHCPv6 stateless - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. Additional options (for example, DNS) are allocated from the OpenStack Networking DHCPv6 service. This configuration results in a subnet created with ra_mode set to dhcpv6-stateless and address_mode set to dhcpv6-stateless.
- Allocation Pools - Range of IP addresses you would like DHCP to assign. For example, the value 192.168.22.100,192.168.22.100 considers all up addresses in that range as available for allocation.
- DNS Name Servers - IP addresses of the DNS servers available on the network. DHCP distributes these addresses to the instances for name resolution.
- Host Routes - Static host routes. First specify the destination network in CIDR format, followed by the next hop that should be used for routing. For example: 192.168.23.0/24, 10.1.31.1 Provide this value if you need to distribute static routes to instances.
5. Click Create.
The completed network is available for viewing in the Networks tab. You can also click Edit to change any options as needed. Now when you create instances, you can configure them now to use its subnet, and they will subsequently receive any specified DHCP options.
3.2. Create an advanced network
Advanced network options are available for administrators, when creating a network from the Admin view. These options define the network type to use, and allow tenants to be specified:
1. In the dashboard, select Admin > Networks > Create Network > Project. Select a destination project to host the new network using Project.
2. Review the options in Provider Network Type:
- Local - Traffic remains on the local Compute host and is effectively isolated from any external networks.
- Flat - Traffic remains on a single network and can also be shared with the host. No VLAN tagging or other network segregation takes place.
- VLAN - Create a network using a VLAN ID that corresponds to a VLAN present in the physical network. Allows instances to communicate with systems on the same layer 2 VLAN.
- GRE - Use a network overlay that spans multiple nodes for private communication between instances. Traffic egressing the overlay must be routed.
- VXLAN - Similar to GRE, and uses a network overlay to span multiple nodes for private communication between instances. Traffic egressing the overlay must be routed.
Click Create Network, and review the Project’s Network Topology to validate that the network has been successfully created.
3.3. Add network routing
To allow traffic to be routed to and from your new network, you must add its subnet as an interface to an existing virtual router:
1. In the dashboard, select Project > Network > Routers.
2. Click on your virtual router’s name in the Routers list, and click +Add Interface. In the Subnet list, select the name of your new subnet. You can optionally specify an IP address for the interface in this field.
3. Click Add Interface.
Instances on your network are now able to communicate with systems outside the subnet.
3.4. Delete a network
There are occasions where it becomes necessary to delete a network that was previously created, perhaps as housekeeping or as part of a decommissioning process. In order to successfully delete a network, you must first remove or detach any interfaces where it is still in use. The following procedure provides the steps for deleting a network in your project, together with any dependent interfaces.
1. In the dashboard, select Project > Network > Networks. Remove all router interfaces associated with the target network’s subnets. To remove an interface: Find the ID number of the network you would like to delete by clicking on your target network in the Networks list, and looking at the its ID field. All the network’s associated subnets will share this value in their Network ID field.
2. Select Project > Network > Routers, click on your virtual router’s name in the Routers list, and locate the interface attached to the subnet you would like to delete. You can distinguish it from the others by the IP address that would have served as the gateway IP. In addition, you can further validate the distinction by ensuring that the interface’s network ID matches the ID you noted in the previous step.
3. Click the interface’s Delete Interface button.
Select Project > Network > Networks, and click the name of your network. Click the target subnet’s Delete Subnet button.
If you are still unable to remove the subnet at this point, ensure it is not already being used by any instances.
4. Select Project > Network > Networks, and select the network you would like to delete.
5. Click Delete Networks.
3.5. Purge a tenant’s networking
In a previous release, after deleting a project, you might have noticed the presence of stale resources that were once allocated to the project. This included networks, routers, and ports. Previously, these stale resources had to be been manually deleted, while also being mindful of deleting them in the correct order. This has been addressed in Red Hat OpenStack Platform 11, where you can instead use the neutron purge
command to delete all the neutron resources that once belonged to a particular project.
For example, to purge the neutron resources of test-project
prior to deletion:
# openstack project list +----------------------------------+--------------+ | ID | Name | +----------------------------------+--------------+ | 02e501908c5b438dbc73536c10c9aac0 | test-project | | 519e6344f82e4c079c8e2eabb690023b | services | | 80bf5732752a41128e612fe615c886c6 | demo | | 98a2f53c20ce4d50a40dac4a38016c69 | admin | +----------------------------------+--------------+ # neutron purge 02e501908c5b438dbc73536c10c9aac0 Purging resources: 100% complete. Deleted 1 security_group, 1 router, 1 port, 1 network. # openstack project delete 02e501908c5b438dbc73536c10c9aac0
3.6. Create a subnet
Subnets are the means by which instances are granted network connectivity. Each instance is assigned to a subnet as part of the instance creation process, therefore it’s important to consider proper placement of instances to best accommodate their connectivity requirements. Subnets are created in pre-existing networks. Remember that tenant networks in OpenStack Networking can host multiple subnets. This is useful if you intend to host distinctly different systems in the same network, and would prefer a measure of isolation between them. For example, you can designate that only webserver traffic is present on one subnet, while database traffic traverse another. Subnets are isolated from each other, and any instance that wishes to communicate with another subnet must have their traffic directed by a router. Consider placing systems that will require a high volume of traffic amongst themselves in the same subnet, so that they don’t require routing, and avoid the subsequent latency and load.
3.6.1. Create a new subnet
In the dashboard, select Project > Network > Networks, and click your network’s name in the Networks view.
1. Click Create Subnet, and specify the following.
Field | Description |
---|---|
Subnet Name | Descriptive subnet name. |
Network Address | Address in CIDR format, which contains the IP address range and subnet mask in one value. To determine the address, calculate the number of bits masked in the subnet mask and append that value to the IP address range. For example, the subnet mask 255.255.255.0 has 24 masked bits. To use this mask with the IPv4 address range 192.168.122.0, specify the address 192.168.122.0/24. |
IP Version | Internet protocol version, where valid types are IPv4 or IPv6. The IP address range in the Network Address field must match whichever version you select. |
Gateway IP | IP address of the router interface for your default gateway. This address is the next hop for routing any traffic destined for an external location, and must be within the range specified in the Network Address field. For example, if your CIDR network address is 192.168.122.0/24, then your default gateway is likely to be 192.168.122.1. |
Disable Gateway | Disables forwarding and keeps the subnet isolated. |
2. Click Next to specify DHCP options:
- Enable DHCP - Enables DHCP services for this subnet. DHCP allows you to automate the distribution of IP settings to your instances.
IPv6 Address -Configuration Modes If creating an IPv6 network, specifies how IPv6 addresses and additional information are allocated:
- No Options Specified - Select this option if IP addresses are set manually, or a non OpenStack-aware method is used for address allocation.
- SLAAC (Stateless Address Autoconfiguration) - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. This configuration results in an OpenStack Networking subnet created with ra_mode set to slaac and address_mode set to slaac.
- DHCPv6 stateful - Instances receive IPv6 addresses as well as additional options (for example, DNS) from OpenStack Networking DHCPv6 service. This configuration results in a subnet created with ra_mode set to dhcpv6-stateful and address_mode set to dhcpv6-stateful.
- DHCPv6 stateless - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. Additional options (for example, DNS) are allocated from the OpenStack Networking DHCPv6 service. This configuration results in a subnet created with ra_mode set to dhcpv6-stateless and address_mode set to dhcpv6-stateless.
- Allocation Pools - Range of IP addresses you would like DHCP to assign. For example, the value 192.168.22.100,192.168.22.100 considers all up addresses in that range as available for allocation.
- DNS Name Servers - IP addresses of the DNS servers available on the network. DHCP distributes these addresses to the instances for name resolution.
- Host Routes - Static host routes. First specify the destination network in CIDR format, followed by the next hop that should be used for routing. For example: 192.168.23.0/24, 10.1.31.1 Provide this value if you need to distribute static routes to instances.
3. Click Create.
The new subnet is available for viewing in your network’s Subnets list. You can also click Edit to change any options as needed. When you create instances, you can configure them now to use this subnet, and they will subsequently receive any specified DHCP options.
3.7. Delete a subnet
You can delete a subnet if it is no longer in use. However, if any instances are still configured to use the subnet, the deletion attempt fails and the dashboard displays an error message. This procedure demonstrates how to delete a specific subnet in a network:
In the dashboard, select Project > Network > Networks, and click the name of your network. Select the target subnet and click Delete Subnets.
3.8. Add a router
OpenStack Networking provides routing services using an SDN-based virtual router. Routers are a requirement for your instances to communicate with external subnets, including those out in the physical network. Routers and subnets connect using interfaces, with each subnet requiring its own interface to the router. A router’s default gateway defines the next hop for any traffic received by the router. Its network is typically configured to route traffic to the external physical network using a virtual bridge.
1. In the dashboard, select Project > Network > Routers, and click +Create Router.
2. Enter a descriptive name for the new router, and click Create router.
3. Click Set Gateway next to the new router’s entry in the Routers list.
4. In the External Network list, specify the network that will receive traffic destined for an external location.
5. Click Set Gateway. After adding a router, the next step is to configure any subnets you have created to send traffic using this router. You do this by creating interfaces between the subnet and the router.
3.9. Delete a router
You can delete a router if it has no connected interfaces. This procedure describes the steps needed to first remove a router’s interfaces, and then the router itself.
1. In the dashboard, select Project > Network > Routers, and click on the name of the router you would like to delete.
2. Select the interfaces of type Internal Interface. Click Delete Interfaces.
3. From the Routers list, select the target router and click Delete Routers.
3.10. Add an interface
Interfaces allow you to interconnect routers with subnets. As a result, the router can direct any traffic that instances send to destinations outside of their intermediate subnet. This procedure adds a router interface and connects it to a subnet. The procedure uses the Network Topology feature, which displays a graphical representation of all your virtual router and networks and enables you to perform network management tasks.
1. In the dashboard, select Project > Network > Network Topology.
2. Locate the router you wish to manage, hover your mouse over it, and click Add Interface.
3. Specify the Subnet to which you would like to connect the router. You have the option of specifying an IP Address. The address is useful for testing and troubleshooting purposes, since a successful ping to this interface indicates that the traffic is routing as expected.
4. Click Add interface.
The Network Topology diagram automatically updates to reflect the new interface connection between the router and subnet.
3.11. Delete an interface
You can remove an interface to a subnet if you no longer require the router to direct its traffic. This procedure demonstrates the steps required for deleting an interface:
1. In the dashboard, select Project > Network > Routers.
2. Click on the name of the router that hosts the interface you would like to delete.
3. Select the interface (will be of type Internal Interface), and click Delete Interfaces.
3.12. Configure IP addressing
You can use procedures in this section to manage your IP address allocation in OpenStack Networking.
3.12.1. Create floating IP pools
Floating IP addresses allow you to direct ingress network traffic to your OpenStack instances. You begin by defining a pool of validly routable external IP addresses, which can then be dynamically assigned to an instance. OpenStack Networking then knows to route all incoming traffic destined for that floating IP to the instance to which it has been assigned.
OpenStack Networking allocates floating IP addresses to all projects (tenants) from the same IP ranges/CIDRs. Meaning that every subnet of floating IPs is consumable by any and all projects. You can manage this behavior using quotas for specific projects. For example, you can set the default to 10 for ProjectA and ProjectB, while setting ProjectC's quota to 0.
The Floating IP allocation pool is defined when you create an external subnet. If the subnet only hosts floating IP addresses, consider disabling DHCP allocation with the enable_dhcp=False option:
# neutron subnet-create --name SUBNET_NAME --enable_dhcp=False --allocation_pool start=IP_ADDRESS,end=IP_ADDRESS --gateway=IP_ADDRESS NETWORK_NAME CIDR
For example:
# neutron subnet-create --name public_subnet --enable_dhcp=False --allocation_pool start=192.168.100.20,end=192.168.100.100 --gateway=192.168.100.1 public 192.168.100.0/24
3.12.2. Assign a specific floating IP
You can assign a specific floating IP address to an instance using the nova
command.
# nova floating-ip-associate INSTANCE_NAME IP_ADDRESS
In this example, a floating IP address is allocated to an instance named corp-vm-01:
# nova floating-ip-associate corp-vm-01 192.168.100.20
3.12.3. Assign a random floating IP
Floating IP addresses can be dynamically allocated to instances. You do not select a particular IP address, but instead request that OpenStack Networking allocates one from the pool. Allocate a floating IP from the previously created pool:
# neutron floatingip-create public +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | fixed_ip_address | | | floating_ip_address | 192.168.100.20 | | floating_network_id | 7a03e6bc-234d-402b-9fb2-0af06c85a8a3 | | id | 9d7e2603482d | | port_id | | | router_id | | | status | ACTIVE | | tenant_id | 9e67d44eab334f07bf82fa1b17d824b6 | +---------------------+--------------------------------------+
With the IP address allocated, you can assign it to a particular instance. Locate the ID of the port associated with your instance (this will match the fixed IP address allocated to the instance). This port ID is used in the following step to associate the instance’s port ID with the floating IP address ID. You can further distinguish the correct port ID by ensuring the MAC address in the third column matches the one on the instance.
# neutron port-list +--------+------+-------------+--------------------------------------------------------+ | id | name | mac_address | fixed_ips | +--------+------+-------------+--------------------------------------------------------+ | ce8320 | | 3e:37:09:4b | {"subnet_id": "361f27", "ip_address": "192.168.100.2"} | | d88926 | | 3e:1d:ea:31 | {"subnet_id": "361f27", "ip_address": "192.168.100.5"} | | 8190ab | | 3e:a3:3d:2f | {"subnet_id": "b74dbb", "ip_address": "10.10.1.25"}| +--------+------+-------------+--------------------------------------------------------+
Use the neutron command to associate the floating IP address with the desired port ID of an instance:
# neutron floatingip-associate 9d7e2603482d 8190ab
3.13. Create multiple floating IP pools
OpenStack Networking supports one floating IP pool per L3 agent. Therefore, scaling out your L3 agents allows you to create additional floating IP pools.
Ensure that handle_internal_only_routers in /etc/neutron/neutron.conf is configured to True
for only one L3 agent in your environment. This option configures the L3 agent to manage only non-external routers.
3.14. Bridge the physical network
The procedure below enables you to bridge your virtual network to the physical network to enable connectivity to and from virtual instances. In this procedure, the example physical eth0 interface is mapped to the br-ex bridge; the virtual bridge acts as the intermediary between the physical network and any virtual networks. As a result, all traffic traversing eth0 uses the configured Open vSwitch to reach instances. Map a physical NIC to the virtual Open vSwitch bridge (for more information, see Chapter 11, Configure Bridge Mappings):
IPADDR, NETMASK GATEWAY, and DNS1 (name server) must be updated to match your network.
# vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 TYPE=OVSPort DEVICETYPE=ovs OVS_BRIDGE=br-ex ONBOOT=yes
Configure the virtual bridge with the IP address details that were previously allocated to eth0:
# vi /etc/sysconfig/network-scripts/ifcfg-br-ex DEVICE=br-ex DEVICETYPE=ovs TYPE=OVSBridge BOOTPROTO=static IPADDR=192.168.120.10 NETMASK=255.255.255.0 GATEWAY=192.168.120.1 DNS1=192.168.120.1 ONBOOT=yes
You can now assign floating IP addresses to instances and make them available to the physical network.