In the previous chapter, we laid down a virtual switching infrastructure that will support OpenStack Neutron networking features moving forward. In this chapter, we will build network resources on this foundation. I will guide you through the following tasks:
- Creating networks and subnets
- Attaching instances to networks
- Demonstrating DHCP and metadata services
Networks, subnets, and ports—the core resources of the Neutron API—were introduced in Chapter 3, Installing Neutron. The relationship between these core resources and instances, DHCP, and metadata services can be observed in the following sections.
OpenStack can be managed in a variety of ways, including through the GUI, API, and CLI. Neutron provides users with the ability to execute commands from a shell that interfaces with the Neutron API. To enter the Neutron shell, type neutron in a shell on the controller node:
Figure 5.1
Alternatively, Neutron commands can be executed straight from the Linux command line using the Neutron client. The client provides a number of commands that assist with the creation, modification, and deletion of networks, subnets, and ports.
The primary commands associated with network management are:
net-createnet-deletenet-listnet-external-listnet-updatesubnet-createsubnet-deletesubnet-listsubnet-showsubnet-updateport-createport-deleteport-listport-showport-update
Whether you choose a LinuxBridge- or Open vSwitch-based virtual networking infrastructure, the process to create, modify, and delete networks and subnets is the same. Behind the scenes, however, the process of connecting instances and other resources to the network differs greatly between them.
There are two categories of networks that can provide connectivity to instances and other network resources, including virtual routers:
- Provider networks
- Tenant networks
Every network created in Neutron, whether created by an administrator or tenant, has provider attributes that describe it. Attributes that describe a network include the network's type (such as flat, vlan, gre, vxlan, or local), the physical network interface that the traffic will traverse, and the segmentation ID of the network. The difference between a provider and tenant network is in who or what sets these attributes and how they are managed within OpenStack.
Provider networks can only be created and managed by an OpenStack administrator as they require knowledge and configuration of the physical network infrastructure. When a provider network is created, the administrator must manually specify the provider attributes for the network in question. The administrator is expected to have some understanding of the physical network infrastructure and may be required to configure switch ports for proper operation. Provider networks allow for either virtual machine instances or virtual routers created by tenants to be connected to them. When a provider network is configured to act as an external network for Neutron routers, the provider network is known as an external provider network. Provider networks are often configured as flat or VLAN networks and utilize an external routing device to properly route traffic in and out of the cloud.
Tenant networks, unlike provider networks, are created by users and are isolated from other networks in the cloud by default. The inability to configure the physical infrastructure means that tenants will likely connect their networks to Neutron routers when external connectivity is required. Tenants are unable to specify provider attributes manually and restricted to creating networks whose attributes are predefined by the administrator in Neutron configuration files. More information on the configuration and use of Neutron routers begins with Chapter 7, Creating Standalone Routers with Neutron.
To create networks using the Neutron client, use the Neutron net-create command:
usage: net-create [--tenant-id TENANT_ID] [--admin-state-down] [--shared] [--router:external] [--provider:network_type <network_type>] [--provider:physical_network <physical_network_name>] [--provider:segmentation_id <segmentation_id>] NAME
There are three provider attributes that can be defined for a network, which are:
provider:network_typeprovider:physical_networkprovider:segmentation_id
Other attributes that can be set for provider networks include:
router:externalshared
Options that can be set for both provider and tenant networks include:
admin-state-downtenant-id
The network_type provider attribute defines the type of network being created. Available options include flat, vlan, local, gre, and vxlan. For a network type to be functional, the corresponding type driver must be enabled in the ML2 configuration file and supported by the enabled mechanism driver. As an external provider network, an overlay network type, such as GRE or VXLAN, is uncommon. However, an OpenStack administrator can create GRE or VXLAN networks on behalf of tenants by specifying a tenant ID and the appropriate provider attributes.
The physical_network provider attribute defines the physical interface that will be used to forward traffic through the host. The value specified here corresponds to the bridge_mappings or physical_interface_mappings option set in the LinuxBridge or Open vSwitch blocks of the ML2 plugin configuration file.
The segmentation_id provider attribute specifies the unique ID for the network. If you are creating a VLAN network, the value used for segmentation_id should be the 802.1q VLAN ID trunked to the host. If you are creating a GRE or VXLAN network, the segmentation_id value should be an arbitrary but unique integer that is not used by any other network of the same type. This ID is used to provide network isolation via the GRE key or VXLAN VNI header fields for GRE and VXLAN networks, respectively. When the segmentation_id attribute is not specified, one is automatically allocated from the tenant range specified in the plugin configuration file. Users have no visibility or option to specify an ID when creating networks. When all available IDs in the range available to tenants are exhausted, users will no longer be able to create networks of this type.
The router:external attribute is a Boolean value that, when set to true, allows a network to be utilized as a gateway network for Neutron routers. For more information on Neutron routers, refer to Chapter 7, Creating Standalone Routers with Neutron.
The shared switch is a Boolean value that, when set to true, allows a network to be utilized among all tenants. This attribute is available only for networks created by administrators and is not available for networks created by users.
The admin-state-down switch is a Boolean value that, when set to true, means that the network is not available upon creation.
Finally, the tenant-id option allows for the administrator to create networks on behalf of tenants.
If you recall from Chapter 4, Building a Virtual Switching Infrastructure, a flat network is a network in which no 802.1q VLAN tagging takes place.
The syntax to create a flat provider network as an administrator can be seen here:
usage: net-create [--tenant-id TENANT_ID] [--admin-state-down] [--shared] [--router:external] --provider:network_type flat --provider:physical_network <provider label> NAME
The following is an example of using the Neutron net-create command to create a flat network by the name of MyFlatNetwork. The network will utilize an interface or bridge represented by the physnet2 label and will be shared among all tenants:
Figure 5.2
In the preceding output, the tenant ID corresponds to the admin tenant where the net-create command was executed. As the network is shared, all tenants can create instances and network resources that utilize the MyFlatNetwork network.
Attempting to create an additional flat network using the same bridge or interface will result in an error, as seen in the following screenshot:
Figure 5.3
A VLAN network is one in which Neutron tags traffic based on the 802.1q segmentation ID. The syntax used to create a VLAN network as an administrator can be seen here:
usage: net-create [--tenant-id TENANT_ID] [--admin-state-down] [--shared] [--router:external] --provider:network_type vlan --provider:physical_network <provider label> [--provider:segmentation_id <vlan id>] NAME
The following is an example of using the Neutron net-create command to create a VLAN network by the name of MyVLANNetwork. The network will utilize the same bridge or interface represented by physnet2, and the traffic will be tagged as VLAN 200. By specifying the --shared flag, the network can be shared by all tenants. The resulting output is as follows:
Figure 5.4
To create an additional VLAN network that utilizes the same bridge or interface, simply specify a different segmentation ID. In the following example, VLAN 201 is used for the new network, MyVLANNetwork2. The resulting output is as follows:
Figure 5.5
When an instance sends traffic on a local network, the traffic remains isolated to the instance and other interfaces connected to the same bridge or segment. Services such as DHCP and metadata might not be available to instances on local networks, especially if they are located on a different node.
To create a local network, use the following syntax:
usage: net-create [--tenant-id TENANT_ID] [--admin-state-down] [--shared] [--router:external] --provider:network_type local NAME
When using the LinuxBridge driver, a bridge is created for the local network, but no physical or virtual VLAN interface is added. Traffic is kept local to the bridge and connected instances. When using the Open vSwitch driver, instances are attached to the integration bridge and can only communicate with other instances in the same local VLAN.
To list the existing networks in Neutron, use the net-list command, as shown in the following screenshot:
Figure 5.6
The list output provides the network ID, network name, and any associated subnets. The OpenStack administrator can see all networks, while tenants can see shared networks and the networks that they created.
To show the properties of a network, use the Neutron net-show command, as follows:
usage: net-show NETWORK
The output of the command can be observed in the following screenshot:
Figure 5.7
Information about the specified network, including the network type, provider bridge label, segmentation ID, and more, can be observed in the net-show output when executed by an administrator. Network provider attributes are hidden from ordinary, non-admin users.
At times, it may be necessary to update the attributes of a network after it has been created. To update a network, use the Neutron net-update command, as follows:
usage: net-update NETWORK [--router:external][--shared][--admin-state-up][--name]
Provider attributes are among those that cannot be changed once a network has been created. The following attributes, however, can be modified:
namerouter:externalsharedadmin-state-up
The router:external attribute is a Boolean value that, when set to true, allows the network to be utilized as a gateway network for Neutron routers. For more information on Neutron routers, refer to Chapter 7, Creating Standalone Routers with Neutron.
The shared switch is a Boolean value that, when set to true, allows the network to be utilized among all tenants.
The admin-state-up switch is a Boolean value. When this is set to false, DHCP and metadata services are no longer available on the network. The network interfaces within the DHCP namespace are destroyed, and any instance that attempts to obtain or renew a lease will fail. When set to true, DHCP and metadata services are restored.
To delete a network, use the Neutron net-delete command and specify the UUID or name of the network:
usage: net-delete NETWORK
To delete a network named "MyVLANNetwork", you can enter the following Neutron command:
net-delete MyVLANNetwork
Alternatively, you can use the network's UUID, as follows:
net-delete 3a342db3-f918-4760-972a-cb700d5b6d2c
Neutron will successfully delete the network as long as there are no instances or other network resources, including floating IPs or load balancer VIPs, utilizing it.
Networks can be created in the dashboard either by an administrator or a user. Both have their own methods, which are described in the following sections.
In order to create a network in the dashboard as a cloud administrator, perform the following steps:
- Navigate to Admin | System | Networks:
Figure 5.8
- Click on Create Network in the upper right-hand corner of the screen. A window will appear and allow you to specify network properties:
Figure 5.9
The available options include associating the network with a project, setting the network type, setting the admin state as on or off, enabling sharing, and enabling the network to be used as an external network for Neutron routers. Click on the Create Network button to create the network.
As an ordinary user, networks are created under the Project tab in the dashboard. To create a network as a user, log in as the user and perform the following steps:
- Navigate to Project | Network | Networks:
Figure 5.10
From here, note that there are no actions available next to the networks currently defined. Even though the networks are shared, they are not editable by users and can only be edited by an administrator.
- Click on Create Network in the upper right-hand corner of the screen. A window will appear and allow you to specify network properties:
Figure 5.11
From the Network tab, you can define the Network Name and Admin Status (on or off) values. Marking a network as Shared or External, as seen in the admin panel earlier, is only available to the networks created by an administrator.
Users creating networks within the dashboard are not required to create a subnet at the time that the network is created. By unselecting the Create Subnet checkbox in the Subnet tab, the network creation process can be completed:
Figure 5.12
The process to create subnets within the dashboard will be explained later in this chapter.
Once a network is created, the next step is to create a subnet within the network. A subnet in Neutron is a layer 3 object and can be an IPv4 or IPv6 network defined using the classless inter-domain routing (CIDR) notation. CIDR is a method of allocating IP addresses and routing IP packets, and it is based on variable-length subnet masking (VLSM). VLSM allows a network to be divided into various sized subnets, providing the opportunity to size a network more appropriately for local needs.
More information on CIDR and VLSM can be found on Wikipedia at http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing.
A few examples of IPv4 subnets described using the CIDR notation are as follows:
192.168.100.50/24represents the IP address,192.168.100.50; its associated routing prefix,192.168.100.0; and the subnet mask,255.255.255.0(which is 24 "1" bits)172.16.1.200/23represents the IP address,172.16.0.200; its associated routing prefix,172.16.0.0; and the subnet mask,255.255.254.0(which is 23 "1" bits)10.0.10.4/22represents the IP address,10.0.10.4; its associated routing prefix,10.0.8.0; and the subnet mask,255.255.252.0(which is 22 "1" bits)
The CIDR notation can be used to quickly identify the total number of IP addresses in a subnet. For example, the subnet mask, 255.255.255.0, in the CIDR notation is /24. To determine the number of host IP addresses available in /24, subtract 24 from 32 (which is the total number of bits in an IPv4 address.) Take the remainder, which is 8, and use it as x in the following formula:
2^x = number of addresses in a subnet
Using the preceding formula, it can be determined that there are 256 IP addresses in a /24, as 28 = 256. An advantage to working with powers of two is that every incremental increase of the exponent doubles the number of available host addresses. A /23 subnet can be written as 29, resulting in 512 addresses, and a /22 subnet can be written as 210, resulting in 1,024 addresses. On the other hand, every incremental decrease of the exponent halves the number of available addresses. Using the formula, a /25 subnet can be written as 27, resulting in 128 addresses; a /26 can be written as 26, resulting in 64 host addresses; and so on.
Not every address in the subnet might be useable, however, as the first and last addresses are usually reserved as the network and broadcast addresses, respectively. As a result, Neutron will not assign the first or last address of a subnet to network resources, including instances. Use the following formula to determine the total number of useable addresses in a subnet when sizing your network. The x variable represents the number of host bits available in the subnet mask:
2x-2 = number of useable addresses in a subnet
Keep in mind that when creating a subnet, it is important to plan ahead as the subnet mask, or CIDR, is currently not an updateable attribute. When instances and other resources consume all of the available IP addresses in a subnet, devices can no longer be added to the network. To resolve this, a new subnet will need to be created and added to the existing network or an entirely new network, and a subnet will need to be created. Depending on your network infrastructure, this might not be an easy change to implement.
Note
IPv6 is an advanced topic that will not be covered in this book. For more information on IPv6, please refer to the Wikipedia article on the subject at https://en.wikipedia.org/wiki/IPv6.
An informational slideshow on IPv6 concepts has also been made available by the Asia-Pacific Network Information Centre and is available at https://training.apnic.net/docs/eIP602_IPv6-AaS.pdf.
To create a subnet using the Neutron client, use the following subnet-create command:
usage: subnet-create [--tenant-id TENANT_ID] [--name NAME] [--gateway GATEWAY_IP] [--no-gateway] [--allocation-pool start=IP_ADDR,end=IP_ADDR] [--host-route destination=CIDR,nexthop=IP_ADDR] [--dns-nameserver DNS_NAMESERVER] [--disable-dhcp] [--enable-dhcp] [--ip-version {4,6}] [--ipv6-ra-mode {dhcpv6-stateful,dhcpv6-stateless,slaac}] [--ipv6-address-mode {dhcpv6-stateful,dhcpv6-stateless,slaac}] NETWORK CIDR
The tenant-id attribute specifies the ID of the tenant that the subnet should be associated with. This should be the same tenant associated with the parent network.
The name attribute specifies the name of the subnet. While you can create multiple subnets with the same name, it is recommended that subnet names remain unique for easy identification.
The gateway attribute defines the gateway address for the subnet. When the subnet is attached to the instance side of a Neutron router, the router's interface will be configured with the address specified here. The address is then used as the default gateway for instances in the subnet. If the subnet is attached to the external side of a Neutron router, the address is used as the default gateway for the router itself. To see this behavior in action, refer to Chapter 7, Creating Standalone Routers with Neutron. If a gateway is not specified, Neutron defaults to the first available address in the CIDR range.
The no-gateway attribute instructs Neutron to not automatically reserve an IP for use as the gateway for the subnet. It also triggers the injection of a metadata route via DHCP when enable_isolated_metadata is set to true in the DHCP configuration file.
The allocation-pool attribute defines the range of IP addresses within the subnet that can be assigned to instances or as floating IPs. IP addresses cannot be excluded from a single range. However, multiple allocation pools can be defined excluding addresses. For example, to exclude 192.168.1.50-55 from 192.168.1.0/24, the following syntax would be needed:
# neutron subnet-create MyFlatNetwork 192.168.1.0/24 --allocation-pool start=192.168.1.2,end=192.168.1.49 --allocation-pool start=192.168.1.56,end=192.168.1.254
The host-route attribute defines one or more static routes to be injected via DHCP. Multiple routes listed as destination, and nexthop pairs can be separated by a space. The default maximum number of routes per subnet is 20 and can be modified in the /etc/neutron/neutron.conf file. The maximum number of routes per router is 30 and can also be modified in the Neutron configuration file.
The dns-nameserver attribute sets the nameservers for the subnet. The default maximum number of nameservers is five per subnet and can be modified in the /etc/neutron/neutron.conf file.
The disable-dhcp switch disables DHCP services for the subnet.
The enable-dhcp switch enables DHCP services for the subnet. DHCP is enabled by default.
The ip-version attribute defines the version of the Internet protocol in use by the subnet. Possible options include 4 for IPv4 and 6 for IPv6. IPv4 is the default when the version is not specified.
The ipv6-ra-mode attribute defines the router advertisement mode for the subnet when IPv6 is used. Possible options include dhcpv6-stateful, dhcpv6-stateless, and slaac.
The ipv6-address-mode attribute defines the address mode for the subnet when IPv6 is used. Possible options include dhcpv6-stateful, dhcpv6-stateless, and slaac.
Note
Not all combinations of the ipv6-ra-mode and ipv6-address-mode parameters are valid. To review both valid and invalid use cases, refer to the API guide at http://specs.openstack.org/openstack/neutron-specs/specs/juno/ipv6-radvd-ra.html#rest-api-impact.
The NETWORK argument defines the network the subnet should be associated with. Multiple subnets can be associated with a single network as long as the subnet does not overlap with another in the same network. The NETWORK argument can be the UUID or the name of a network.
The CIDR argument defines the CIDR notation of the subnet being created.
To demonstrate this command in action, create a subnet within the MyFlatNetwork network with the following characteristics:
- Internet Protocol:
IPv4 - Subnet:
192.168.100.0/24 - Subnet mask:
255.255.255.0 - External gateway:
192.168.100.1 - DNS servers:
8.8.8.8,8.8.4.4
To create the subnet and associate it with MyFlatNetwork, refer to the following screenshot:
Figure 5.13
To list existing subnets in Neutron, use the subnet-list command, as shown in the following screenshot:
Figure 5.14
The command output provides the ID, name, CIDR notation, and IP address allocation pools of all subnets when executed as an administrator. As a user, the command returns subnets within the project or subnets associated with shared networks.
To show the properties of a subnet, use the Neutron subnet-show command:
usage: subnet-show SUBNET
The output of the command can be observed in the following screenshot:
Figure 5.15
To update a subnet in the CLI, use the Neutron subnet-update command:
usage: subnet-update [--name NAME][--gateway GATEWAY_IP] [--no-gateway][--allocation-pool start=IP_ADDR,end=IP_ADDR] [--host-route destination=CIDR,nexthop=IP_ADDR] [--dns-nameserver DNS_NAMESERVER] [--disable-dhcp] [--enable-dhcp] SUBNET
Not all attributes of a subnet can be updated after it has been created. The following attributes can be updated:
namedns_nameserversenable_dhcp/disable-dhcpgateway_ipallocation_poolshost_routes
The dns_nameserver attribute defines the domain name server for the subnet. To overwrite the existing value with a single name server, use --dns-nameserver. To overwrite the existing value(s) with multiple name servers, use --dns-nameservers, as shown in the following command:
(neutron) subnet-update SUBNET --dns-nameservers <dns 1> <dns 2>
To enable DHCP in a subnet, use --enable-dhcp. To disable DHCP in a subnet, use --disable-dhcp.
The gateway_ip attribute defines the default gateway for the subnet. To overwrite an existing gateway address, use the Neutron subnet-update command with --gateway-ip, as shown in the following command:
(neutron) subnet-update SUBNET --gateway_ip=<gateway addr>
To completely remove a gateway address from the subnet, use the action=clear directive, as follows:
(neutron) subnet-update SUBNET --gateway_ip action=clear
The host_routes attribute defines one or more routes to be injected into a virtual machine instance's routing table via DHCP. To update a subnet to provide a route via DHCP, use the Neutron subnet-update command with the --host-route option, as demonstrated in the following command:
# neutron subnet-update SUBNET --host-route destination=10.0.0.0/24,nexthop=192.168.100.254
To specify multiple routes, use multiple --host-route options, as demonstrated in the following command:
# neutron subnet-update SUBNET --host-route destination=10.0.0.0/24,nexthop=192.168.100.254 --host-route destination=172.16.0.0/24,nexthop=192.168.100.254
Note
Using subnet-update to update the name servers, routes, and gateway IP of a subnet will result in an overwriting of the existing values. To avoid possible downtime or other network connectivity issues, care should be taken to ensure that the environment is not affected by the changes made to subnet attributes.
Subnets can be created in the dashboard either by an administrator or user. The process of creating subnets as either type of user is described in the upcoming sections.
To create a subnet as the cloud administrator, perform the following steps:
- Navigate to Admin | System | Networks and click on the name of the network that you wish to add a subnet to:
Figure 5.16
- Clicking on MyVLANNetwork provides a list of details of the network, including the associated subnets and ports:
Figure 5.17
- To add a subnet to the network, click on the Create Subnet button on the right-hand side:
Figure 5.18
- A window will appear that allows you to define the properties of the subnet:
Figure 5.19
- Each option pictured here corresponds to an option available with the Neutron
subnet-createcommand in the CLI. Clicking on Next reveals additional configuration options:
Figure 5.20
- To complete the creation of the subnet, click on the blue Create button.
In the dashboard, users can create subnets at the time of network creation or add subnets to an existing network. To create a network and subnet as a user, perform the following steps:
- Navigate to Project | Network | Networks and click on the Create Network button:
Figure 5.21
- Clicking on Create Network will open a window where you can specify the network and subnet details:
Figure 5.22
- Clicking on the Subnet tab or Next button allows you to specify information on the subnet, including the network address, CIDR, and gateway information:
Figure 5.23
- Finally, clicking on Subnet Detail or Next allows you to specify details such as IP allocation pools, DNS name servers, and static routes. Click on the blue Create button to complete the creation of the network and subnet:
Figure 5.24
The ability to add additional subnets or delete a network entirely is provided within the menu located under the Actions column, as pictured in the following screenshot:
Figure 5.25