Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Service Chaining

 

Now let’s utilize the cSRX to service chaining using the Contrail Command GUI. Service chaining consists of four steps that need to be completed in order:

  1. Create a service template;
  2. Create a service instance based on the service template just completed;
  3. Create a network policy and select the service instance you created before;
  4. Apply this network policy onto the network.
Note

Since Contrail Command GUI is the best solution to provide a single point of management for all environments, we will use it to build service changing. You can still use the normal Contrail controller GUI to build service chaining, too.

First let’s log in to Contrail Command GUI (in our setup https://10.85.188.16:9091/) as shown next in Figure 2, and then select Service > Catalog > Create as shown in Figure 3.

Figure 1: Log in to Contrail Command
Log in to Contrail
Command
Figure 2: Create a New Service
Create a New Service

Insert a name of a services template, here myweb-cSRX-CS, then chose v2 and virtual machine for service modes. Choose In-network and Firewall as service types as shown in Figure 4.

Figure 3: Choosing Service Types
Choosing Service Types

Next select Management, Left and Right, and then click Create.

Figure 4: Create Service
Create Service

Now, select Deployment and click on the Create button to create the service instances as shown next in Figure 6.

Figure 5: Deploy Service Instance
Deploy Service Instance

Name this service instance, then select from the drop-down menu the name of the template you created before you chose the proper network from the prospective of the cSRX being the instance (container in that case) that will do the service chaining. Click on the port tuples to expand it as shown in Figure 7. Then, for each of the three interfaces bind one interface of the cSRX, then click Create.

Figure 6: Expanding the Port Tuples
Expanding the Port
Tuples
Note

The name of the VM interface isn’t shown in the drop-down menu, instead it’s the instance ID. You can identify that from the tap interface name as we mentioned before. In other words, all you have to know is the first six characters for any interface belonging to that container. All the interfaces in a given instance (VM or container) share the same first characters.

Before proceeding, make sure the statuses of the three interfaces are up and they are showing the correct IP address of the cSRX instance as shown in Figure 8.

Figure 7: All Interfaces Up and Running
All Interfaces
Up and Running

To create the network policy go to Overlay > Network Policies > Create as in Figure 9.

Figure 8: Create Network Policy
Create Network Policy

Name your network policy, then in the first rule add left network as the source network and right network as the destination with the action of pass.

Figure 9: Source and Destination
Source and Destination

Select the advanced option and attach the service instance to the one you created before, then click the Create button.

Figure 10: Attaching the Service Instance
Attaching the
Service Instance

To attach this network policy to the network click on Virtual Network in the left-most column and select the left network and edit.

Figure 11: Attach the Policy to the Network
Attach the
Policy to the Network

In Network Policies select the network policy you just created from the drop-down menu list, and then click Save. Do the same for the right network.

Figure 12: Save the Network Policy
Save the Network Policy

Verify Service Chaining

Now let’s verify the effect of this service changing on routing. From the Contrail Controller module control node (http://10.85.188.16:8143 in our setup), select Monitor > Infrastructure > Virtual Router then select the node that hosts the pod , in our case Cent22.local, then select the Routes tab and select the left VRF.

Figure 13: Verify Service Chaining
Verify Service Chaining

You can see that the right network host routes have been leaked to the left network (10.20.20.1/32, 10.20.20.2/32 in this case).

Now let’s ping the right pod from the left pod to see the session created on the cSRX: