In this chapter, we will show you the following set of recipes covering the different ways to create and manage the core Neutron entities, namely Network, Subnet, and Port:
Creating a Subnet and Network using Horizon
Viewing the details of a Network using Horizon
Associating a Network to an instance using Horizon
Creating a Network using OpenStack CLI
Creating a Subnet using OpenStack CLI
Creating a Port without an associated instance using OpenStack CLI
Associating a Port to an instance using OpenStack CLI
Configuring the networking quota in OpenStack
Businesses are increasingly adopting cloud-based solutions for their IT requirements. This move to cloud started with the server virtualization where a hardware server ran as a virtual machine on a hypervisor.
The server hardware connects to the Network switches using Ethernet and IP to establish Network connectivity. However, as servers move from physical to virtual, the Network boundary also moves from the physical network to the virtual network. As the cloud platforms leverage virtualization, it is important that they support the physical and virtual networking effectively.
OpenStack is an open source cloud platform that helps build public and private clouds at scale. In OpenStack, the name for the OpenStack networking project is Neutron. The functionality of Neutron can be classified as core and service. In the rest of the book, the terms Neutron and OpenStack networking are used interchangeably.
The OpenStack networking core functionality refers to the Layer 2 (L2) Network connectivity and basic IP address management for virtual machines. Neutron provides the core functionality using entities such as Network, Subnet, and Port. This chapter will provide you with recipes about managing these entities. The OpenStack networking service functionality deals with the Layer 3 (L3) to Layer 7 (L7) capabilities as defined in the OSI Network model.
Neutron also works with the telemetry module called Ceilometer in order to let the cloud operators monitor the health of the OpenStack Networks.
In order to implement the recipes covered in this chapter, you will need an OpenStack setup, as described here:

This setup has one compute node and one node for the controller and networking services. For this chapter, you can also set up a single all-in-one environment. This book is based on OpenStack on the Ubuntu platform. For other platforms, such as Red Hat, the dashboard may have a different theme but there should not be any difference in the functionality.
Network and Subnet are the fundamental networking entities in OpenStack. Using these two entities, virtual machines or instances are provided with Network connectivity. The creation of a Subnet and Network go hand in hand. Both OpenStack CLI and Horizon support the creation of a Subnet and Network. This recipe explains how to create a Subnet and Network using Horizon.
Log in to the OpenStack Horizon dashboard.
In the left navigation menu, click on Project | Network | Networks.
Now click on the + Create Network button. The following screen will be displayed:
The next screen lets you create the Subnet that will be part of the Network.
Enter the Subnet Name and the address range in CIDR format, as shown in the following screenshot:
Click Next. In the next screen, all the fields are optional, so click on Create.
Once the Network and Subnet are created successfully, the entry will appear in the Networks table, as shown here:
The preceding steps covered the most commonly used workflow to create a Network and Subnet using Horizon.
The Network and Subnet entities represent two basic Networking functionalities. A Network defines the Layer 2 (L2) boundary for all the instances that are associated with it. All the virtual machines in a Network are a part of the same L2 broadcast domain. The Subnet, on the other hand, is the range of IP addresses that are assigned to the virtual machines on the associated Network. OpenStack Neutron configures the DHCP server with this IP address range and it starts one DHCP server instance per Network, by default. OpenStack Neutron also allocates one IP to act as the gateway IP unless the user provides a specific IP address for the gateway.
As you can see from the UI, it is possible to create a Network without a Subnet. You can choose between the IPv4 or IPv6 addressing schemes. The Subnet Details section allows operators to enable or disable DHCP for the Network. Optionally, you can also specify the DNS servers and IP pools.
Once a Network and Subnet have been created, you can use Horizon to view useful details such as the ID, Network Type, and Gateway IP. You can also view the topology of the Network that you just created.
For this recipe, you need to know the name of the Network whose details you want to view.
Log in to the OpenStack Horizon dashboard using a user ID with an administrative role.
In the left navigation menu, click on Project | Network | Networks.
On the right-hand side, you will see a list of all the Networks. In the following screenshot, you can see two Networks:
To view the details of a particular Network, click on the Name of the Network:
In the preceding screen, the key fields to note are Network Type, Segmentation ID, and Gateway IP for the Subnet.
To view the topology, click on Network Topology in the left navigation panel:
As you can see, the two Networks are shown as vertical color-coded bars. The Subnets belonging to the Network are indicated at the end of the bars.
When you create a Network, the Horizon dashboard makes a REST API call to Neutron to create a Network. During the installation, the OpenStack administrator configures Neutron with a tenant Network type. This Network type is used by Neutron to create the Network.
Note
Note that if you create and view the Network with a non-administrative role, some of the fields may not be displayed.
While creating the Subnet, we did not select any gateway IP, so Neutron will automatically select the first IP address in the Subnet and configure this as the gateway IP for that Subnet.
Once the Network and Subnet are created, the next step for the end user is to create an instance or virtual machine and associate the Network to the virtual machine. This recipe shows you how to accomplish this.
One of the prerequisites to create an instance is to add a virtual machine image to the Glance image service. In our example, we will add a CirrOS image and use this image to create an instance.
Log in to the OpenStack Horizon dashboard using the appropriate credentials.
In the left navigation menu, click on Project | Compute | Instances.
Now click on the Launch Instance action on the right-hand side of the screen. The wizard to create and start an instance will be displayed:
Enter a name for the instance, choose a Flavor, select a source as Boot from image, and choose the desired image:
To associate the instance to a Network, click on the Networking tab at the top. You should see a screen where the Selected networks field is empty:
In the Available networks field, click on the + sign next to the Network to which the instance needs to be associated. Then click on Launch:
This should result in the creation and booting up of your instance and the Instances table is updated to show you the instance that was just created:
This recipe showed you that as a part of instance creation, the Horizon GUI allows users to choose the Network to which the instance needs to be associated.
As part of the instance creation process, the user chooses the Network to which the instance will be associated. The instance creation and scheduling is the responsibility of Nova and it sends a create Port request to Neutron in order to associate the instance to the selected Network.
In response to the create Port request, Neutron will ensure that the virtual Network on the hypervisor server is configured so as to provide connectivity to the virtual machine. For the very first instance created on the Network, the Neutron server will also start a DHCP process on the Network node. This happens when DHCP is enabled on the corresponding Network. Once a virtual machine boots up, it will send a DHCP request. In response to this request, the DHCP server for that Network will respond with an IP address.
We have seen how to use the Horizon dashboard to create a Network. Let's now do the same with OpenStack CLI. Several CLI commands offer additional capabilities when compared to the dashboard. So it is good to develop a sound knowledge of the CLI commands.
You will need the following information to create a Network using CLI:
The login credentials for SSH to a node where the Neutron client packages are installed (usually the controller node)
A shell RC file that initializes the environment variables for CLI
The next set of steps will show you how to use the Neutron CLI commands to create a Network:
Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed.
Source the shell RC file to initialize the environment variables required for the CLI commands:
openstack@controller:~$ source author_openrc.sh
The contents of a typical shell RC file are as follows:
openstack@controller:~$ cat author_openrc.sh export OS_TENANT_NAME=cookbook export OS_USERNAME=author export OS_PASSWORD=password export OS_AUTH_URL=http://controller:35357/v2.0 openstack@controller:~$ openstack
The command to create a Network is
neutron net-create
, and in the simplest form, the only argument required is the Network name:You can view all the Networks created using the
neutron net-list
command:One of the interesting command-line options for the neutron net-create command is the
--tenant-id
option. This option allows users with an administrative role to create a Network for another tenant. The following screenshot shows you how an administrative user (for an administrative project or tenant) creates a Network for a cookbook tenant:The tenant ID argument works only when the user specifies the unique tenant ID. However, sometimes it is convenient to use the tenant name. The following command automates the conversion from the tenant to the tenant ID. The keyword,
cookbook
, is the tenant name used for this command:
When the user executes the neutron net-create
command, the user name and tenant name attributes are taken from the shell environment variables that were initialized at the beginning. Neutron creates the Network with this user and tenant (or project). However, once the --tenant-id
option is used, the Network is created on behalf of the tenant whose ID is specified.
Users can specify several other arguments while creating Networks. These options are provider:network_type
, --provider:segmentation_id
, and router:external
. While we will be taking a closer look at these parameters in the subsequent chapters, it is important to note that some of these options are available only if users have the administrative privilege.
To view the details of a specific Network, you can use the neutron net-show
command.
Similar to the CLI commands to create a Network, the next recipe will explore the CLI command to create a Subnet. The key aspect of the CLI commands for Subnet creation is that a Network Name is a mandatory attribute.
You will need the following information to get started:
The login credentials for SSH to a node where the Neutron client packages are installed
A shell RC file that initializes the environment variables for CLI
The next set of steps will show you how to use Neutron CLI to create a Subnet:
Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed.
Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the previous recipe.
The command to create a Subnet is
neutron subnet-create
and the mandatory arguments are the Network name and IP address range in the CIDR format. However, it is a good practice to specify a name for the Subnet. For simplicity, we will choose the Network, CookbookNetwork2, that was created earlier because it does not have any associated Subnet yet:Now, when we execute the
neutron net-list
command, we will see thatCookbookNetwork2
has an associated Subnet that we just created:Users can view the list of Subnets using the
neutron subnet-list
command:
Port is another building block in OpenStack Neutron. You will not find a way to create a Port using the Horizon dashboard. As we saw earlier in the Associating a Network to an instance using Horizon recipe, a Port is created implicitly as a part of the create instance operation from the dashboard. However, using CLI, some advanced networking configuration can be accomplished. This recipe shows you how to create a Port using OpenStack CLI.
You will need the following information to get started:
The login credentials for SSH to a node where the Neutron client packages are installed
A shell RC file that initializes the environment variables for CLI
The next set of steps will show you how to use Neutron CLI to create a Port:
Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed.
Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the previous recipe.
The command to create a Port is
neutron port-create
and the only mandatory parameter is the Network name. However, it is a good practice to specify a name for the Port:Note that the Port has been assigned a MAC address as well as an IP address.
You can use the
neutron port-list
command to view a list of all the Ports in the system:
A Port primarily represents an endpoint in a Network. The most common Ports in an OpenStack environment are the virtual interfaces in a virtual machine.
When the neutron port-create
command is executed, OpenStack Neutron allocates a unique MAC address to the Port. The Network name argument effectively helps Neutron in identifying a Subnet and then Neutron assigns an IP address to the Port from the list of available IP addresses in the Subnet.
The post-create
request is also the most common trigger to configure the physical and virtual Networks using the appropriate drivers.
The previous recipe showed you how to create a Port using CLI. The next recipe shows you how we can use an existing Port as part of the instance creation command.
For this recipe, you will have to identify the Port that you want to associate with an instance. For the instance creation itself, the software image needs to be identified.
The next set of steps will show you how to use the Nova and Neutron CLI commands to create an instance that uses an existing Port:
Using the appropriate credentials, SSH into the OpenStack node where the Neutron and Nova client software packages are installed.
Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the earlier recipes.
Execute the
neutron port-list
command and identify the ID of the Port that you want to use to create an instance. Make a note of the MAC and IP addresses assigned to the Port:The CLI command to create an instance is
nova boot
. This command supports an argument called--nic
that allows us to specify a Port ID that we want to associate with the instance:openstack@controller:~$ nova boot --flavor m1.tiny --image cirros-0.3.3-x86_64 --nic port-id=ee6f30a1-6851-435a-89cd-a8e7390325a4 CLIPortVM
Note that the virtual machine name used in the command is
CLIPortVM
. If we execute thenova show
command now, we can see the details about the instance:In the preceding output, you can see that the IP address of the Port created using CLI has been assigned to the instance.
Log in to the Horizon dashboard and navigate to Network Topology, as discussed in the Viewing the details of a Network using Horizon recipe. In Network Topology, move the mouse pointer over the icon representing the instance and click on Open Console as shown here:
In the resulting window, log in to the instance. In our example, we will be using the CirrOS default username and password for the login.
At the shell prompt of the instance, type
ifconfig eth0
. This command will show the virtual interface for this instance. The command output shows the MAC and IP addresses that are assigned to the virtual interface:
This recipe demonstrated how to associate a Port to an instance. At the end of the recipe, we can see that the MAC and IP addresses for this virtual interface (eth0
) match those of the Port that we used in the nova boot
command.
We have seen that Neutron assigns an IP address and MAC address to a Port during their creation. When users execute the nova boot
command with the --nic
option, then Nova takes the IP and MAC addresses of the Port and uses this information to configure the virtual interface of the instance.
This technique of creating a Port prior to the instance creation is helpful if a specific IP address needs to be assigned to an instance or virtual machine. While we will cover this in another recipe later in the book, it is important to note that this capability is not available using the Horizon dashboard.
Quotas are limits defined in OpenStack to ensure that the system resources and capacity are used in a systematic manner. Different users can be given different quota limits based on their requirement and priority. In this recipe, we will show you how to configure a quota related to networking at a project level and for the whole system.
The setting up and enforcement of the quota are done at the project level. If any user in the project tries to exceed the allotted quota, the system will reject the corresponding request. To configure the quota-related parameters, you need to have a good idea about the capacity, scale, and performance requirements of your OpenStack-based cloud.
The following steps will show you how to configure the networking-related quota:
Log in to the OpenStack Horizon dashboard using a user ID with an administrative role.
In the left navigation menu, click on Identity and then Projects. In the Actions column, select Modify Quota for the tenant of your choice, as follows:
In the resulting window, the networking-related quotas are defined as shown in the following screenshot. Make the changes and click Save.
In order to change the networking-related quota at the whole system level, you need to change the settings in the Neutron server configuration file.
With the appropriate credentials, SSH into the node where the Neutron server is running.
Open the Neutron configuration file using your desired editor. For example, the command for vi editor will be as follows:
openstack@controller:~$ sudo vi /etc/neutron/neutron.conf
In the configuration file, look for a section starting with
[quotas]
. All the quota-related settings start withquota_
. Edit these settings as required and save the file.The Neutron server needs to be restarted for these settings to take effect. Restart the Neutron server using the following command:
sudo service neutron-server restart
All the quota settings are stored on a per project (tenant) basis. During the creation of a project using CLI or Horizon, OpenStack (Keystone) fetches the system-wide default quotas from the configuration files and associates them to the project (or tenant). Hereafter, even if the system-wide quotas are changed, the project-level quotas do not change automatically. However, the project-level quotas can be changed anytime using Horizon or CLI, and these changes take effect immediately.
All the OpenStack commands and API calls are checked against the project-level quotas. If any commands or API calls violate the limits, they will be rejected with an appropriate error.