OpenStack Networking Cookbook

By Sriram Subramanian , Chandan Dutta Chowdhury
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Getting Started with OpenStack Networking

About this book

Networking in OpenStack has evolved from Nova Network to Neutron. This has resulted in a rich suite of networking services available to OpenStack users and administrators. Advanced services such as routers, firewall, and load balancers use building blocks such as network and subnets. Recent improvements support powerful customization using plugins. The evolution of Neutron continues as it integrates with tools like Ceilometer and Heat.

This book will explore the built-in capabilities of Neutron to effectively deploy cloud solutions. You will begin with the most fundamental constructs of OpenStack Networking for switching and routing. You will then learn how to provide your tenants with services like firewalls and load-balancers. The step-by-step recipes will help you configure and troubleshoot networking problems in your cloud. This book will also introduce you to advanced topics like Ceilometer, Heat, and other upcoming tools in OpenStack

Publication date:
October 2015
Publisher
Packt
Pages
282
ISBN
9781785286100

 

Chapter 1. Getting Started with OpenStack Networking

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

 

Introduction


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.

 

Creating a Subnet and Network using Horizon


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.

Getting ready

In order to create a Network and Subnet, you will need the following information, minimally:

  • The Network name

  • The Subnet name

  • The IP address range for the Subnet—the range should be in CIDR format

How to do it…

  1. Log in to the OpenStack Horizon dashboard.

  2. In the left navigation menu, click on Project | Network | Networks.

  3. Now click on the + Create Network button. The following screen will be displayed:

  4. Enter the Network Name and click Next.

  5. The next screen lets you create the Subnet that will be part of the Network.

  6. Enter the Subnet Name and the address range in CIDR format, as shown in the following screenshot:

  7. Click Next. In the next screen, all the fields are optional, so click on Create.

  8. 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.

How it works…

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.

There's more…

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.

 

Viewing the details of a Network using Horizon


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.

Getting ready

For this recipe, you need to know the name of the Network whose details you want to view.

How to do it…

  1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role.

  2. In the left navigation menu, click on Project | Network | Networks.

  3. On the right-hand side, you will see a list of all the Networks. In the following screenshot, you can see two Networks:

  4. To view the details of a particular Network, click on the Name of the Network:

  5. In the preceding screen, the key fields to note are Network Type, Segmentation ID, and Gateway IP for the Subnet.

  6. To view the topology, click on Network Topology in the left navigation panel:

  7. 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.

How it works…

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.

 

Associating a Network to an instance using Horizon


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.

Getting ready

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.

How to do it…

  1. Log in to the OpenStack Horizon dashboard using the appropriate credentials.

  2. In the left navigation menu, click on Project | Compute | Instances.

  3. 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:

  4. Enter a name for the instance, choose a Flavor, select a source as Boot from image, and choose the desired image:

  5. 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:

  6. 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:

  7. 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.

How it works…

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.

There's more…

If there is exactly one Network for a given tenant, then the dashboard automatically selects this Network when an instance is created. Additionally, note that the tenants can associate more than one Network to an instance. This will create multiple interfaces in the virtual machine.

 

Creating a Network using OpenStack CLI


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.

Getting ready

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

How to do it…

The next set of steps will show you how to use the Neutron CLI commands to create a Network:

  1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed.

  2. Source the shell RC file to initialize the environment variables required for the CLI commands:

    [email protected]:~$ source author_openrc.sh
    
  3. The contents of a typical shell RC file are as follows:

    [email protected]:~$ 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
    [email protected]:~$ openstack
    
  4. The command to create a Network is neutron net-create, and in the simplest form, the only argument required is the Network name:

  5. You can view all the Networks created using the neutron net-list command:

  6. 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:

  7. 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:

How it works…

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.

There's more…

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.

 

Creating a Subnet using OpenStack CLI


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.

Getting ready

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

How to do it…

The next set of steps will show you how to use Neutron CLI to create a Subnet:

  1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed.

  2. Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the previous recipe.

  3. 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:

  4. Now, when we execute the neutron net-list command, we will see that CookbookNetwork2 has an associated Subnet that we just created:

  5. Users can view the list of Subnets using the neutron subnet-list command:

How it works…

When the user executes the neutron subnet-create command, Neutron creates a Subnet with the specified IP address range and other parameters. Neutron also associates the Subnet with the specified Network.

 

Creating a Port without an associated instance using the OpenStack CLI


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.

Getting ready

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

How to do it…

The next set of steps will show you how to use Neutron CLI to create a Port:

  1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed.

  2. Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the previous recipe.

  3. 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:

  4. Note that the Port has been assigned a MAC address as well as an IP address.

  5. You can use the neutron port-list command to view a list of all the Ports in the system:

How it works…

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.

 

Associating a Port to an instance using OpenStack CLI


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.

Getting ready

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.

How to do it…

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:

  1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron and Nova client software packages are installed.

  2. Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the earlier recipes.

  3. 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:

  4. 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:

    [email protected]:~$ nova boot --flavor m1.tiny --image cirros-0.3.3-x86_64 --nic port-id=ee6f30a1-6851-435a-89cd-a8e7390325a4 CLIPortVM
    
  5. Note that the virtual machine name used in the command is CLIPortVM. If we execute the nova show command now, we can see the details about the instance:

  6. In the preceding output, you can see that the IP address of the Port created using CLI has been assigned to the instance.

  7. 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:

  8. 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.

How it works…

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.

There's more…

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.

 

Configuring the networking quota in OpenStack


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.

Getting ready

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.

How to do it…

The following steps will show you how to configure the networking-related quota:

  1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role.

  2. 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:

  3. In the resulting window, the networking-related quotas are defined as shown in the following screenshot. Make the changes and click Save.

  4. 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.

  5. With the appropriate credentials, SSH into the node where the Neutron server is running.

  6. Open the Neutron configuration file using your desired editor. For example, the command for vi editor will be as follows:

    [email protected]:~$ sudo vi /etc/neutron/neutron.conf
    
  7. In the configuration file, look for a section starting with [quotas]. All the quota-related settings start with quota_. Edit these settings as required and save the file.

  8. 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
    

How it works…

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.

About the Authors

  • Sriram Subramanian

    Sriram Subramanian is an experienced professional with over 19 years' experience of building networking and network management products. Since 2011, Sriram has been working with Juniper Networks, leading engineering teams responsible for OpenStack Neutron plugins, VMware integration, and network management products. He is a technologist with a passion for virtualization and cloud networking. Sriram blogs regularly at http://www.innervoice.in/blogs and loves experimenting with new technologies and programming. He is the author of OpenStack Networking Cookbook, Packt.

    Browse publications by this author
  • Chandan Dutta Chowdhury

    Chandan Dutta Chowdhury is a tech lead at Juniper Networks Pvt. Ltd, working on OpenStack Neutron plugins. He has over 11 years of experience in the deployment of Linux-based solutions. In the past, he has been involved in developing Linux-based clustering and deployment solutions. He has contributed to setting up and maintaining a private cloud solution in Juniper Networks.

    He was a speaker at the OpenStack Tokyo summit, where he presented the idea of adding firewall logs and other Neutron enhancements. He is speaker at the Austin summit where he talks about making enhancements to the Nova scheduler. He loves to explore technology.

    Browse publications by this author