A User’s Look at OpenStack Networking, Part 1

Understanding the basics: networks, subnets, ports and routers

Many articles have been written about OpenStack networking, almost all through the eyes of a cloud operator — someone who designs or operates OpenStack.

Developers, administrators and other users, however, have a very different view of OpenStack networking. This post is for them. It’s the first in a series that will focus on OpenStack networking from the user’s perspective.

In this post, we’ll introduce OpenStack networking concepts and then show how to use the networking features in the OpenStack dashboard.

Why OpenStack networking is different

OpenStack opens up the creation and use of Virtual Machines (or VMs, also called instances) to users who simply want to get things done without having to manage physical infrastructure. Instances free users to quickly create a place for their applications, without the hassle of setting up servers and other associated hardware.

Users don’t care if they are using a virtual environment or a physical environment. What matters is that the environment fits the task. But virtual spaces are easier to understand and manage. Networking in OpenStack is virtual, giving users an easy self-serve interface that allows them to accomplish their tasks.

That means there’s no more “getting others to string the cables which connect the servers,” because OpenStack does it. There’s no more router and switch configuration, because OpenStack does that too. Even managing the firewall rules can be easily modified using the OpenStack interface. All of the many tasks that others would have to do to get a new server and application working are now under the easy control of an OpenStack user.

OpenStack networking concepts

In OpenStack, the user’s perspective of networking is a simplified model of physical networking. There are a few basic concepts that must be understood: that of a network, a subnet, a port and a router. Let’s consider each of these in the context of OpenStack.


A network can be thought of as an OSI layer 2 segment and all of its associated metadata. It can be thought of as a repository and isolation mechanism into which subnets are placed. Networks are isolated from each other, meaning there is no way to see the traffic of one network from another network.

There are two type of networks: provider networks and project networks. Provider networks are created by OpenStack administrators with the express purpose of providing network access to another part of the environment, both internal to OpenStack and externally.

Usually access to the internet is given through one of these provider networks. As such, provider networks will map into the existing physical networks in the data center and possibly other data centers in the organization. Users can connect to the subnets within these networks, but cannot modify them in any way.

On the other hand, users can create networks for their own use. They can add subnets to their networks at will and use any desired Classless InterDomain Routing (CIDR) address range without regard to the choices of other projects. Project networks can be shared with other projects, but it takes an administrator to do the sharing. A quota system limits the number of networks that a project can create for itself.


Subnets can be thought of as a block of IPv4 or IPv6 addresses and their associated metadata and configuration states. A network is unusable for communications without a subnet.

Keep in mind that a CIDR address block includes a fixed number of addresses, but not all of these are usable. Two are immediately lost, since that very first address is thought of as the subnet address and cannot be assigned, and the last is the broadcast address for the subnet, so also cannot be assigned to a device. Additionally, at a minimum, OpenStack will typically reserve two additional addresses:

  • the gateway address, which by default is the first assignable address of a subnet, and
  • one for a DHCP server to provide addresses for the instances.

This behavior can be altered, but changes should be made after the subnet is created.

Additional addresses may be reserved if the DHCP servers are set to work in a highly available configuration. In this case, additional DHCP servers are started when the subnet is created. Each DHCP server will use one IP from the subnet. The OpenStack admin will know how many DHCP servers will be created by default, typically this is not more than three servers. This knowledge will help in planning the minimum number of addresses needed for a subnet.


A port is a way of connecting a device to a subnet. Ports are another construct for the virtual world which can be visualised as equivalent to a physical NIC card, without some of the limitations. Instances, gateways and DHCP servers all require a port to connect to a subnet. Typically a port will have a MAC address and an IP address.

Restrictions from the physical world do not always carry over to the virtual world. For example, a computer chassis will have a limited number of slots available for NIC cards; a virtual chassis has no such limitation. The maximum number of ports (NIC cards) one can attach to an instance may only be limited by the number of PCI bus addresses. Although one can assign multiple IP addresses to a port, it might be better to create a separate port for each new address.

One final note regarding ports: the OpenStack dashboard only allows an admin to create or manipulate ports, even though this is not considered an admin-only function. Using the default policy permissions that come with OpenStack, a regular user can use the Command Line Interface tools to create and change a port.


In the physical world, routers can be very intimidating devices. They require knowledge of a specialized language used for configuration, and an average system admin typically does not have the knowledge base to configure a router. Typically, a network administrator has to be brought in to set it up.

OpenStack routers are easier to understand and create. They provide two key functions: routing traffic between different subnets (CIDR address ranges) and providing NAT support between project networks and provider networks. The best part about OpenStack routers is that one does not have to explicitly set up those functions. OpenStack does it for you automatically. Simply create the router, add the subnet gateways (interfaces), add the external network/subnet you are done.

In the next article, we will use OpenStack to create the networks and subnets we’ll need to provision utilize our cloud capacity..

Rackspace is the world’s leading OpenStack service provider. To learn more about OpenStack, attend a public training session or schedule private training class with our experts. For a complete schedule of class offerings, please visit the Rackspace Training page.

Phil Hopkins is a principal engineer at Rackspace. He has an Electrical Engineering Degree from the University of South Florida and has been working on Linux systems for more than 15 years. In the past he has taught Cisco Networking classes and worked as a Cisco Admin as well as designing VOIP systems using Asterisk. He is active teaching and writing about OpenStack software defined networks (SDN). He has written and currently teaches an advanced class on OpenStack Networking. Phil has spoken about Cloud Technologies at a number of events including The Red Hat Summit in 2011, OpenStack Summits 2013 through 2016 and Linux Foundation CloudOpen 2014.


Please enter your comment!
Please enter your name here