A network defines the Layer 2 (L2) boundary for all the instances that are associated with it. All the virtual machines within a network are part of the same L2 broadcast domain.

The Liberty release has introduced a new OpenStack command-line interface (CLI) for different services. We will use the new CLI and see how to create a network:

A subnet is a range of IP addresses that are assigned to virtual machines on the associated Network. OpenStack Neutron configures a DHCP server with this IP address range and it starts one DHCP server instance per network, by default.

We will now show you how to create a subnet using OpenStack CLI:

To give a complete perspective, we will create a virtual machine using the OpenStack web interface and show you how to associate a network and subnet to a virtual machine.

In your OpenStack web interface, navigate to Project | Compute | Instances:

Click on the Launch Instance action on the right-hand side, as highlighted in the preceding screenshot. In the resulting window, enter the name for your instance and how you want to boot your instance:

To associate a network and a subnet with the instance, click on the Networking tab. If you have more than one tenant network, you will be able to choose the network you want to associate with the instance. If you have exactly one network, the web interface will automatically select it:

As mentioned previously, providing isolation for tenant network traffic is a key requirement for any cloud. OpenStack Neutron uses network and subnet to define the boundaries and isolate data traffic between different tenants. Depending on Neutron configuration, the actual isolation of traffic is accomplished by the virtual switches. VLAN and VXLAN are the most common networking technologies used to isolate traffic, in addition to protocols such as GRE.

Operators can create routers using OpenStack CLI or web interface. They can then add more than one subnet as an interface to the router. This allows the networks associated with the router to exchange traffic with one another.

The command to create a router is as follows:

This command creates a router with the specified name.

Once a router is created, the next step is to associate one or more subnetworks to the router. The command to accomplish this is as follows:

The subnet represented by subnet1 is now associated to the router router1. Using the OpenStack dashboard, you can view the association between a router and a subnet. Navigate to Project | Networks | Network Topology. This should display the router, router1, connected to the network, network1, to which the subnet belongs, as shown in the following screenshot:

You can hover the mouse over the router router1 to see that the subnet is indeed added as an interface and is assigned an IP address.

In order to secure traffic going from one VM to another within a given network, we must create a security group. The command to create a security group is as follows:

The next step is to create one or more rules within the security group. As an example, let us create a rule which allows only UDP, incoming traffic on port 8080 from any source IP address:

The final step is to associate this security group and the rules to a virtual machine instance. We will use the nova boot command for this:

Once the virtual machine instance has a security group associated with it, the incoming traffic will be monitored and depending upon the rules inside the security group, data traffic may be blocked or permitted to reach the virtual machine.

We have seen that security groups provide a fine grain control over what traffic is allowed to and from a virtual machine instance. Another layer of security supported by OpenStack is Firewall as a Service (FWaaS). FWaaS enforces security at the router level, whereas security groups enforce security at a virtual-machine-interface level.

The main use case of FWaaS is to protect all virtual machine instances within a network from threats and attacks from outside the network. This could be virtual machines part of another network in the same OpenStack cloud or some entity in the Internet trying to perform an unauthorized access.

Let's now see how FWaaS is used in OpenStack. In FWaaS, a set of firewall rules is grouped into a firewall policy and then a firewall is created that implements one policy at a time. This firewall is then associated to a router.

A firewall rule can be created using the neutron firewall-rule-create command, as follows:

This rule blocks the ICMP protocol so applications such as Ping will be blocked by the firewall. The next step is to create a firewall policy. In real-world scenarios, the security administrators will define several rules and consolidate them under a single policy. For example, all rules that block various types of traffic can be combined into a single policy. The command to create a firewall policy is as follows:

The final step is to create a firewall and associate it with a router. The command to do this is as follows:

In the preceding command, we did not specify any routers and the OpenStack behavior is to associate the firewall (and in turn the policy and rules) to all the routers available for that tenant. The neutron firewall-create command supports an option to pick a specific router as well.

Virtual machine instances created in OpenStack are used to run applications. Most applications are required to support redundancy and concurrent access. For example, a web server may be accessed by a large number of users at the same time. One of the common strategies to handle scale and redundancy is to implement load balancing for incoming requests. In this approach, a load balancer distributes an incoming service request onto a pool of servers, which processes the request, thus providing higher throughput. If one of the servers in the pool fails, the load balancer removes it from the pool and the subsequent service requests are distributed among the remaining servers. Users of the application use the IP address of the load balancer to access the application and are unaware of the pool of servers.

OpenStack implements load balancing using HAproxy software and a Linux namespace.

As mentioned previously, tenant isolation requires data traffic to be segregated and secured within an OpenStack cloud. However, there are times when external entities need to be part of the same network without removing the firewall-based security. This can be accomplished using a Virtual Private Network (VPN).

A VPN connects two endpoints on different networks over a public Internet connection, such that the endpoints appear to be directly connected to each other. VPNs also provide confidentiality and integrity of transmitted data.

Neutron provides a service plugin that enables OpenStack users to connect two networks using a VPN. The reference implementation of the VPN plugin in Neutron uses Openswan to create an IPSec-based VPN. IPSec is a suite of protocols that provides a secure connection between two endpoints by encrypting each IP packet transferred between them.

OpenStack, being an open source platform, bundles open source networking solutions as the default implementation for these networking capabilities. For example, routing is supported using namespace, security using iptables, and load balancing using HAproxy.

Historically, these networking capabilities were implemented using customized hardware and software, most of them being proprietary solutions. These custom solutions are capable of much higher performance and are well-supported by their vendors. Hence they have a place in the OpenStack and SDN ecosystem.

From its initial releases, OpenStack has been designed for extensibility. Vendors can write their own extensions and then can easily configure OpenStack to use their extension instead of the default solutions. This allows operators to deploy the networking technology of their choice.

One of the most powerful capabilities of OpenStack is the extensive support for APIs. All OpenStack services interact with one another using well-defined RESTful APIs. This allows custom implementations and pluggable components to provide powerful enhancements for practical cloud implementation.

For example, when a network is created using the OpenStack web interface, a RESTful request is sent to the Horizon service. This in turn, invokes a RESTful API to validate the user using the Keystone service. Once validated, Horizon sends another RESTful API request to Neutron to actually create the network.

In the following chapter, we will see how these RESTful APIs provide support for crucial SDN capabilities in an OpenStack-based cloud.