Just as applications migrated from physical servers to VMs, network functions are moving from dedicated hardware to VMs. In order to provide rich networking for virtualized applications, it is important that SDN solutions support the ability to redirect application traffic through different network functions such as firewalls, DPI, load balancers, and so on. This ability of the SDN platform is referred to as service chaining and the specialized network functions are referred to as service instances.

Advanced network services such as firewalls, IDP, load balancers, and so on, usually operate at L4 to L7 of the networking stack. This means that an L3-based overlay network is well suited to support chaining since OpenContrail takes care of L3 packet forwarding. Service chaining in OpenContrail mostly deals with traffic steering, which is the ability to force network traffic in a well-defined and controlled manner so that the traffic flows can be processed by Service Instances.

MPLS as a technology supports a predefined path for IP packets to travel through the network. The MPLS Label Switched Path (LSP) is very useful in service chaining, where labels and routes can be programmed at different vRouters and VRF, such that traffic is engineered in and out of various VM instances that are part of the service chain. Competing SDN platforms such as OpenDayLight have to rely on physical network hardware to provide this level of traffic steering, which is neither practical nor flexible when it comes to large-scale cloud networks.

OpenContrail creates special routing instances for the Service Instances, allowing them to insert themselves transparently into the network path between two VMs. They do this by advertising themselves as the next hop for the traffic originating from a VM and also creating a new MPLS label for themselves.

We will now take a simple example and walk you through the service chaining workflow in the OpenContrail GUI. The goal of this exercise is to show a service chain where VMs from two different networks are connected by a virtual firewall, as shown here:

Components used for service chaining example

The first thing we need to accomplish this service chain is to create an image in OpenStack Glance that corresponds to a firewall VM. For the purpose of this chapter, we have created an image named demo-firewall-image-cirros using a standard Cirros image. For real deployments, you must use an appropriate NFV appliance:

Next, we will go ahead and create the two virtual networks and provision one end-user VM in each of the virtual networks. Once configured, you can see the Ports table in OpenContrail to confirm the setup:

The first important step in the creation of service chaining is to create a service chain template. In the OpenContrail UI, navigate to Configure | Services | Service Templates and click on the + sign on the right-hand side. This will result in the Create Service Template form being displayed:

Enter an appropriate Name for the template and select the Version as v1 and Service Mode to be In-Network. We will choose the demo-firewall-image-cirros as the image for the service VM. Since we are creating a simple linear service chain, we will have to select at least two interfaces for this service VM, left and right. In a real deployment, it is common to have another interface, called management, to help the user manage the virtual network function (service). Click on Save to save the template.

The next step is to create an instance of the service using the template. In the OpenContrail UI, navigate to Configure | Services | Service Instance and click on the + sign on the right. This action will display the Create Service Instance form, as shown in the following screenshot:

Once again, enter a name for the instance and then select the correct service template for this instance. The next step is very important, assigning the virtual networks to the interfaces of the service instance. To match our initial deployment diagram, we will assign left-network to the left interface of the service instance. Similarly, we will add the right interface for the instance. Upon clicking Save, OpenContrail will attempt to spawn the VM instance using Nova APIs.

Once the service instance is launched, we can view its details using the OpenStack UI as shown in the following screenshot:

We can also see how the virtual network topology changes before and after the service creation:

We can see that the firewall service instance is now attached to both networks. OpenContrail will have programmed the routing instances such that traffic from either network passes through the service VM.

We can also use the OpenContrail UI to configure fine-grained policies on this service VM. Navigate to Configure | Networking | Policies and click on the + sign on the right. This will show a form to create granular policies and associate them to a specific service instance, as shown in the following screenshot:

On the preceding screen, we are creating a firewall rule to allow HTTP traffic in both directions between the two virtual networks.

The preceding procedure shows how flexible and simple OpenContrail workflows allow cloud operators to create rich network topologies using virtual network functions. This is truly a powerful capability and underscores the software aspect of the OpenContrail SDN and NFV platform.