Book Image

Software-Defined Networking (SDN) with OpenStack

By : Sreenivas Voruganti, Sriram Subramanian
Book Image

Software-Defined Networking (SDN) with OpenStack

By: Sreenivas Voruganti, Sriram Subramanian

Overview of this book

Networking is one the pillars of OpenStack and OpenStack Networking are designed to support programmability and Software-Defined Networks. OpenStack Networking has been evolving from simple APIs and functionality in Quantum to more complex capabilities in Neutron. Armed with the basic knowledge, this book will help the readers to explore popular SDN technologies, namely, OpenDaylight (ODL), OpenContrail, Open Network Operating System (ONOS) and Open Virtual Network (OVN). The first couple of chapters will provide an overview of OpenStack Networking and SDN in general. Thereafter a set of chapters are devoted to OpenDaylight (ODL), OpenContrail and their integration with OpenStack Networking. The book then introduces you to Open Network Operating System (ONOS) which is fast becoming a carrier grade SDN platform. We will conclude the book with overview of upcoming SDN projects within OpenStack namely OVN and Dragonflow. By the end of the book, the readers will be familiar with SDN technologies and know how they can be leveraged in an OpenStack based cloud.
Table of Contents (16 chapters)
Software-Defined Networking (SDN) with OpenStack
Credits
About the Authors
About the Reviewer
www.PacktPub.com
Preface

Layer 2 (L2) capabilities in OpenStack


In networking terminology, the connectivity to a physical or virtual switch is also known as Layer 2 (L2) connectivity. L2 connectivity is the most fundamental form of network connectivity needed for virtual machines. As mentioned previously, OpenStack supports core and service functionality. The L2 connectivity for virtual machines falls under the core capability of OpenStack Networking, whereas router, firewall, and so on fall under the service category.

The L2 connectivity in OpenStack is realized using two constructs, called network and subnet. Operators can use OpenStack CLI or the web interface to create networks and subnets. And as virtual machines are instantiated, the operators can associate them to appropriate networks.

Creating a network using OpenStack CLI

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:

Creating a subnet using OpenStack CLI

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:

Tip

Unlike a network, for a subnet, we need to use the regular Neutron CLI command in the Liberty release.

Associating a network and subnet to a virtual machine

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.