Chapter 3. Managing project networks Project networks help you to isolate network traffic for cloud computing. Steps to create a project network include planning and creating the network, and adding subnets and routers. 3.1. VLAN planning When you plan your Red Hat OpenStack Platform deployment, you start with a number of subnets, from which you allocate individual IP addresses. When you use multiple subnets you can segregate traffic between systems into VLANs. For example, it is ideal that your management or API traffic is not on the same network as systems that serve web traffic. Traffic between VLANs travels through a router where you can implement firewalls to govern traffic flow. You must plan your VLANs as part of your overall plan that includes traffic isolation, high availability, and IP address utilization for the various types of virtual networking resources in your deployment. Note The maximum number of VLANs in a single network, or in one OVS agent for a network node, is 4094. In situations where you require more than the maximum number of VLANs, you can create several provider networks (VXLAN networks) and several network nodes, one per network. Each node can contain up to 4094 private networks. 3.2. Types of network traffic You can allocate separate VLANs for the different types of network traffic that you want to host. For example, you can have separate VLANs for each of these types of networks. Only the External network must be routable to the external physical network. In this release, director provides DHCP services. Note You do not require all of the isolated VLANs in this section for every OpenStack deployment. For example, if your cloud users do not create ad hoc virtual networks on demand, then you may not require a project network. If you want each VM to connect directly to the same switch as any other physical system, connect your Compute nodes directly to a provider network and configure your instances to use that provider network directly. Provisioning network - This VLAN is dedicated to deploying new nodes using director over PXE boot. OpenStack Orchestration (heat) installs OpenStack onto the overcloud bare metal servers. These servers attach to the physical network to receive the platform installation image from the undercloud infrastructure. Internal API network - The OpenStack services use the Internal API network for communication, including API communication, RPC messages, and database communication. In addition, this network is used for operational messages between controller nodes. When planning your IP address allocation, note that each API service requires its own IP address. Specifically, you must plan IP addresses for each of the following services: vip-msg (ampq) vip-keystone-int vip-glance-int vip-cinder-int vip-nova-int vip-neutron-int vip-horizon-int vip-heat-int vip-ceilometer-int vip-swift-int vip-keystone-pub vip-glance-pub vip-cinder-pub vip-nova-pub vip-neutron-pub vip-horizon-pub vip-heat-pub vip-ceilometer-pub vip-swift-pub Note When using High Availability, Pacemaker moves VIP addresses between the physical nodes. Storage - Block Storage, NFS, iSCSI, and other storage services. Isolate this network to separate physical Ethernet links for performance reasons. Storage Management - OpenStack Object Storage (swift) uses this network to synchronise data objects between participating replica nodes. The proxy service acts as the intermediary interface between user requests and the underlying storage layer. The proxy receives incoming requests and locates the necessary replica to retrieve the requested data. Services that use a Ceph back end connect over the Storage Management network, since they do not interact with Ceph directly but rather use the front end service. Note that the RBD driver is an exception; this traffic connects directly to Ceph. Project networks - Neutron provides each project with their own networks using either VLAN segregation (where each project network is a network VLAN), or tunneling using VXLAN or GRE. Network traffic is isolated within each project network. Each project network has an IP subnet associated with it, and multiple project networks may use the same addresses. External - The External network hosts the public API endpoints and connections to the Dashboard (horizon). You can also use this network for SNAT. In a production deployment, it is common to use a separate network for floating IP addresses and NAT. Provider networks - Use provider networks to attach instances to existing network infrastructure. You can use provider networks to map directly to an existing physical network in the data center, using flat networking or VLAN tags. This allows an instance to share the same layer-2 network as a system external to the OpenStack Networking infrastructure. 3.3. IP address consumption The following systems consume IP addresses from your allocated range: Physical nodes - Each physical NIC requires one IP address. It is common practice to dedicate physical NICs to specific functions. For example, allocate management and NFS traffic to distinct physical NICs, sometimes with multiple NICs connecting across to different switches for redundancy purposes. Virtual IPs (VIPs) for High Availability - Plan to allocate between one and three VIPs for each network that controller nodes share. 3.4. Virtual networking The following virtual resources consume IP addresses in OpenStack Networking. These resources are considered local to the cloud infrastructure, and do not need to be reachable by systems in the external physical network: Project networks - Each project network requires a subnet that it can use to allocate IP addresses to instances. Virtual routers - Each router interface plugging into a subnet requires one IP address. If you want to use DHCP, each router interface requires two IP addresses. Instances - Each instance requires an address from the project subnet that hosts the instance. If you require ingress traffic, you must allocate a floating IP address to the instance from the designated external network. Management traffic - Includes OpenStack Services and API traffic. All services share a small number of VIPs. API, RPC and database services communicate on the internal API VIP. 3.5. Adding 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: In the dashboard, select Project > Network > Routers . Select your virtual router 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. Click Add Interface . Instances on your network can now communicate with systems outside the subnet. 3.6. Example network plan This example shows a number of networks that accommodate multiple subnets, with each subnet being assigned a range of IP addresses: Table 3.1. Example subnet plan Subnet name Address range Number of addresses Subnet Mask Provisioning network 192.168.100.1 - 192.168.100.250 250 255.255.255.0 Internal API network 172.16.1.10 - 172.16.1.250 241 255.255.255.0 Storage 172.16.2.10 - 172.16.2.250 241 255.255.255.0 Storage Management 172.16.3.10 - 172.16.3.250 241 255.255.255.0 Tenant network (GRE/VXLAN) 172.16.4.10 - 172.16.4.250 241 255.255.255.0 External network (incl. floating IPs) 10.1.2.10 - 10.1.3.222 469 255.255.254.0 Provider network (infrastructure) 10.10.3.10 - 10.10.3.250 241 255.255.252.0 3.7. Creating a network Create a network so that your instances can communicate with each other and receive IP addresses using DHCP. For more information about external network connections, see Bridging 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 prefer a measure of isolation between them. For example, you can designate that only webserver traffic is present on one subnet, while database traffic traverses another. Subnets are isolated from each other, and any instance that wants to communicate with another subnet must have their traffic directed by a router. Consider placing systems that require a high volume of traffic amongst themselves in the same subnet, so that they do not require routing, and can avoid the subsequent latency and load. In the dashboard, select Project > Network > Networks . Click +Create Network and specify the following values: 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, webservers_122 , if you are hosting HTTP web servers in this subnet, and your VLAN tag is 122 . Or you might use internal-only if you intend to keep the network traffic private, and not integrate the network with an external network. Admin State Controls whether the network is immediately available. Use this field to create the network in a Down state, where it is logically present but inactive. This is useful if you do not intend to enter the network into production immediately. Create Subnet Determines whether to create a subnet. For example, you might not want to create a subnet if you intend to keep this network as a placeholder without network connectivity. Click the button, and specify the following values in the Subnet tab: Field Description 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 hop for routing any traffic destined for an external location, and must be within the range that you specify 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 isolates the subnet. Click to specify DHCP options: Enable DHCP - Enables DHCP services for this subnet. You can use DHCP to automate the distribution of IP settings to your instances. IPv6 Address - Configuration Modes. If you create an IPv6 network, you must specify how to allocate IPv6 addresses and additional information: No Options Specified - Select this option if you want to set IP addresses manually, or if you use a non OpenStack-aware method for address allocation. SLAAC (Stateless Address Autoconfiguration) - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. Use this configuration to create an OpenStack Networking subnet 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 the OpenStack Networking DHCPv6 service. Use this configuration to create a subnet 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. Use this configuration to create a subnet with ra_mode set to dhcpv6-stateless and address_mode set to dhcpv6-stateless. Allocation Pools - Range of IP addresses that you want DHCP to assign. For example, the value 192.168.22.100,192.168.22.150 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. Important For strategic services such as DNS, it is a best practice not to host them on your cloud. For example, if your cloud hosts DNS and your cloud becomes inoperable, DNS is unavailable and the cloud components cannot do lookups on each other. Host Routes - Static host routes. First, specify the destination network in CIDR format, followed by the hop that you want to use 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. Click Create . You can view the complete network in the Networks tab. You can also click Edit to change any options as needed. When you create instances, you can configure them now to use its subnet, and they receive any specified DHCP options. 3.8. Working with subnets Use subnets to grant network connectivity to instances. 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. You can create subnets only in pre-existing networks. Remember that project networks in OpenStack Networking can host multiple subnets. This is useful if you intend to host distinctly different systems in the same network, and 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 wants to communicate with another subnet must have their traffic directed by a router. Therefore, you can lessen network latency and load by grouping systems in the same subnet that require a high volume of traffic between each other. 3.9. Creating a subnet To create a subnet, follow these steps: In the dashboard, select Project > Network > Networks , and click the name of your network in the Networks view. Click Create Subnet , and specify the following values: 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 CIDR 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 protocol version you select. Gateway IP IP address of the router interface for your default gateway. This address is the hop for routing any traffic destined for an external location, and must be within the range that you specify 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 isolates the subnet. Click to specify DHCP options: Enable DHCP - Enables DHCP services for this subnet. You can use DHCP to automate the distribution of IP settings to your instances. IPv6 Address - Configuration Modes. If you create an IPv6 network, you must specify how to allocate IPv6 addresses and additional information: No Options Specified - Select this option if you want to set IP addresses manually, or if you use a non OpenStack-aware method for address allocation. SLAAC (Stateless Address Autoconfiguration) - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. Use this configuration to create an OpenStack Networking subnet 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 the OpenStack Networking DHCPv6 service. Use this configuration to create a subnet 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. Use this configuration to create a subnet with ra_mode set to dhcpv6-stateless and address_mode set to dhcpv6-stateless. Allocation Pools - Range of IP addresses that you want DHCP to assign. For example, the value 192.168.22.100,192.168.22.150 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 hop that you want to use 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. Click Create . You can view the subnet in the Subnets list. You can also click Edit to change any options as needed. When you create instances, you can configure them now to use its subnet, and they receive any specified DHCP options. 3.10. Adding 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 in the physical network. Routers and subnets connect using interfaces, with each subnet requiring its own interface to the router. The default gateway of a router defines the 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. To create a router, complete the following steps: In the dashboard, select Project > Network > Routers , and click Create Router . Enter a descriptive name for the new router, and click Create router . Click Set Gateway to the entry for the new router in the Routers list. In the External Network list, specify the network that you want to receive traffic destined for an external location. Click Set Gateway . After you add a router, you must configure any subnets you have created to send traffic using this router. You do this by creating interfaces between the subnet and the router. Important The default routes for subnets must not be overwritten. When the default route for a subnet is removed, the L3 agent automatically removes the corresponding route in the router namespace too, and network traffic cannot flow to and from the associated subnet. If the existing router namespace route has been removed, to fix this problem, perform these steps: Disassociate all floating IPs on the subnet. Detach the router from the subnet. Re-attach the router to the subnet. Re-attach all floating IPs. 3.11. Purging all resources and deleting a project Use the openstack project purge command to delete all resources that belong to a particular project as well as deleting the project, too. For example, to purge the resources of the test-project project, and then delete the project, run the following commands: 3.12. Deleting a router You can delete a router if it has no connected interfaces. To remove its interfaces and delete a router, complete the following steps: In the dashboard, select Project > Network > Routers , and click the name of the router that you want to delete. Select the interfaces of type Internal Interface , and click Delete Interfaces . From the Routers list, select the target router and click Delete Routers . 3.13. Deleting 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. Complete the following steps to delete a specific subnet in a network: In the dashboard, select Project > Network > Networks . Click the name of your network. Select the target subnet, and click Delete Subnets . 3.14. Deleting 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. You must first remove or detach any interfaces where the network is still in use, before you can successfully delete a network. To delete a network in your project, together with any dependent interfaces, complete the following steps: In the dashboard, select Project > Network > Networks . Remove all router interfaces associated with the target network subnets. To remove an interface, find the ID number of the network that you want to delete by clicking on your target network in the Networks list, and looking at the ID field. All the subnets associated with the network share this value in the Network ID field. Navigate to Project > Network > Routers , click the name of your virtual router in the Routers list, and locate the interface attached to the subnet that you want to delete. You can distinguish this subnet from the other subnets by the IP address that served as the gateway IP. You can further validate the distinction by ensuring that the network ID of the interface matches the ID that you noted in the step. Click the Delete Interface button for the interface that you want to delete. Select Project > Network > Networks , and click the name of your network. Click the Delete Subnet button for the subnet that you want to delete. Note If you are still unable to remove the subnet at this point, ensure it is not already being used by any instances. Select Project > Network > Networks , and select the network you would like to delete. Click Delete Networks .

Commands:
openstack project list +----------------------------------+--------------+ | ID | Name | +----------------------------------+--------------+ | 02e501908c5b438dbc73536c10c9aac0 | test-project | | 519e6344f82e4c079c8e2eabb690023b | services | | 80bf5732752a41128e612fe615c886c6 | demo | | 98a2f53c20ce4d50a40dac4a38016c69 | admin | +----------------------------------+--------------+ openstack project purge --project 02e501908c5b438dbc73536c10c9aac0