How to Enable Dynamic, Network-Based Services

This blog post will provide a step-by-step guide to configuring a dynamic in-network service chain. As emphasized in prior blog postings on OpenContrail.org, using well known and defined standards allows a service provider to insert network-based technologies and services while leveraging a well known and understood building block of modifying the next-hop of a destination route to point to the appliance/service VM of choice. This is known as “service chaining.”  Below are five steps I will cover to show how automated service chaining can be done:

1. Configuring a Gateway Router that will provide the bridging of the ‘physical’ VPN world of a customer to a ‘virtual’ world offering services. In this example, the NFV being offered is that of a NAT NFV on a NAT enabled VM. That gateway router will be configured to support L3VPN signaled via BGP for control plane exchanges with the data plane being MPLS over GRE.
2. Ensure the proper VPN’s (both for Enterprise and Internet Transport) are configured on the PE. VPN parameters must match those of the VN’s being configured.
3. Import a capable image of offering the service in question. We will be using Juniper’s Firefly Perimeter product to do this.
4. Using the OpenContrail Web Console to configure the appropriate VN’s that will inject the service in question via a service chain.
5. Spin up the service VM via compute orchestration using Openstack’s Nova component and the network overlay and service chaining using OpenContrail’s vRouter integration.

A video is available which captures the end user experience of how they can enable dynamic cloud based services (NFV) inserted in real-time into their existing VPN offering.

The video entitled “Production-ready Network Function Virtualization through Contrail “ can be viewed below:

[video_lightbox_youtube video_id=”_64no8P2vUw” width=”640″ height=”480″ anchor=”http://opencontrail.org/wp-content/uploads/2013/11/blogpost_810_image17.png”]

The following topology will be our reference for the remainder of this blog:

Topology Reference:

1. Configuring the BGP L3VPN address family between the Gateway router and OpenContrail Control Node.

In this step, we will configure both the Gateway Router and the OpenContrail System to have an L3VPN BGP session in order to exchange virtual VM reachability (service VM’s) between both the physical network and virtual network.

The IP fabric underlay is on subnet: 172.16.0.0/24
The Control Nodes are: 172.16.0.71 and 172.16.0.72
The PE Gateway is configured: 172.16.0.10

IBGP session between PE Gateway and OpenContrail Control Nodes.

Step 1.

Configure the PE BGP parameters on Contrail.

Go to Configure -> Infrastructure -> BGP Peer and Click ‘Create’ at the Top Right Hand

Step 2.

Configure the BGP enabled L3VPN address family on the vendor PE Gateway router.

[ protocols bgp ]

 group JUNOSV-CONTRAIL {
     type internal;
     local-address 172.16.0.10;

    family inet-vpn {
         unicast;
     }
     vpn-apply-export;
     peer-as 64512;
     allow 172.16.0.0/24;
 }

Step 3.

Ensure dynamic MPLSoGRE tunneling is enabled on the PE Gateway router.

[ routing-options ]

dynamic-tunnels {
     JUNOSV-CONTRAIL {
         source-address 172.16.0.10;
         gre;
         destination-networks {
             172.16.0.0/24;
         }
     }
 }

2. Setup Enterprise and Internet Transport VRF’s

In this section, we ensure that the corresponding L3VPN customer is properly configured on the PE Gateway router along with the proper L3VPN VRF to transport Internet Traffic.

The VPN Green customer has the parameters:

RT 64512:100
RD (default/auto allocation based on PE implementation)

 

The Internet Transport VPN has the parameters:

RT 666:100
RD (default/auto allocation based on PE implementation)

 Step 1.

Configure the customer L3VPN VRF on the PE.

[ routing-instances VPN-GREEN ]
 instance-type vrf;
 interface ge-1/1/0.0;
 interface lo0.500;
 route-distinguisher 11.11.11.137:64512;
 vrf-target 64512:100
 vrf-table-label;
 routing-options {
 static {
 route 192.168.100.0/24 next-hop 192.168.200.2;
 }
 }

Step 2.

Configure the customer Internet Transport VRF on the PE. Note the expectation is that IANA allocated routable public blocks are provided as part of the public VN, available through this VRF (LSP) with the appropriate routing on ingress/egress points. In this example we follow RFC 6598 which provides non-routable public blocks for CGNAT purposes for the left (private) VN. This also ensures uniqueness of routes being injected into a customer VPN. It is required that the public VN uses a pool of IP addresses that are indeed publically routable and owned by the service provider.

[ routing-instances INTERNET-TRANSPORT ]
 instance-type vrf;
 interface lo0.200;
 route-distinguisher 11.11.11.137:666;
 vrf-target 666:100
 vrf-table-label;

With the above configuration we expect to learn a default route to the Internet (and/or any specific NET/CIDR blocks) with reachability to an Internet Gateway device within the SP network.

3. Import Service Image via Openstack Horizon GUI (or glance via CLI)

In this step, we import a Juniper Firefly Perimeter image which is preconfigured to perform a NAT function between anything being received on the left virtual network (aka. the internal Private VPN network, aka. 64512:1000) to the right virtual network (aka. The public internet, aka. 666:100).

An alternative to importing an image can be done via the glance CLI on the Configuration node. This will not be covered here.

Step 1.

Login to the Horizon GUI interface:

Go to Project (in this case it’s demo) -> Images & Snapshots -> Create Image

If importing is successful you should see an image called firefly-12-1-nat:

4. Create the supporting parameters via the Contrail Web Console (virtual networks, net blocks, service templates, etc.)

In this section, we will create two virtual networks for the ‘left’ network, also known as private, within the VPN. The other virtual network will be the ‘right’ network also known as public (scary Internet). The VN will have RT’s that match the VRF parameters we configured on the PE Gateway router and net blocks from RFC 6598. We will also create a service template in which future service instances will inherit the template properties.

Virtual Network Overlay Parameters:

Left Network: RT 64512:100, NETBLOCK: 100.64.0.0/24

Right Network: RT 666:100, NETBLOCK: 100.65.0.0/24 (This should be a publicly owned and routeable netblock!)

Associate a default network policy (which is configured for any to any)

Step 1.

Configure the ‘left’ virtual network by going to:

Configure -> Networking -> Networks  (Create Top Right Hand Corner).

By clicking save you should see the following VN created:

Step 2.

Configure the ‘right virtual network by going to:

Configure -> Networking -> Networks  (Create Top Right Hand Corner).

By clicking save you should see the following VN created:

Step 3. Create a service template for Internet NFV Services.

Configure -> Services -> Service Templates  (Create Top Right Hand Corner).

By clicking save you should see the following Service Template created:

5. Complete the Chain! Instantiate a service image based on the Internet NFV Service Template and enable the Service Chain.

In this step we spin up a service VM for a customer (in this example customer Green VPN) and once the VM is orchestrated along with the network virtual overlay(s) we then ‘chain’ the two VN’s with one another; through the service; thus completing the dynamic instantiation of the NAT NFV service.

 Step 1.

Configure -> Services -> Service Instances  (Create Top Right Hand Corner).

Step 2.

Click save and a service instance should spin up. You can confirm this by looking at the Horizon GUI (you can see IP addressing being selected in each VN, both left and right).

You can also confirm this in the Contrail Web Console as shown below:

Step 3.

Create a network policy, which enables the service chain.

Configure -> Networks -> Policies

The OpenContrail (vRouter) is configured for the service VM (green-vpn) that ALL routes being learnt via the right network from the PE Gateway (RT 666:100) to be leaked into the left network (RT 64512:100) but with a new next-hop of left VN VIF (which in this instance’s case is 100.64.0.253 and reachable via the GREEN VPN).

This will pull all default route traffic (assuming a 0.0.0.0/0 is learnt with RT 666:100) to be sent to the ‘left’ interface of the service VM, NAT’d through the service VM itself, and sent out the right VN towards the public network.

Conclusion

The above steps will allow a user to configure a single in-network (routed) service chain using well-known and tested technologies. What should also be pointed out is that all of the above configurations are available through the vnc_api RESTful interface. As shown by the video “Production-ready Network Function Virtualization through Contrail” referenced above; it used a custom web interface using standard REST interfaces that the same Contrail Web Console leverages.