vPath or how to create a service chain in a virtualization environment

How to ensure control over the traffic between the components of a virtualized application with minimal time? Is there a technology that allows you to transfer traffic along a chain through several service components, for example, a firewall, packet filter and traffic balancing system, without making any changes to the network configuration or to the configuration of the applications themselves? Under the cat, we'll talk about Cisco vPath technology, which allows you to elegantly create service chains in virtualization environments and not depend on the manufacturer of the hypervisor.

1. Task statement

Initial data:

• there is an application that consists of several components, for example, WEB, APP, DB;
• components are virtual machines (VMs) and are located within a cluster of hypervisors;
• all components are connected to the same network segment and use one default gateway to communicate with the outside world.

The component diagram of the connection to the network component of the application looks like in Fig. one.
')

Fig. 1 Logical diagram of the organization to connect the application to the network

By default, the interaction matrix between application components and the outside world looks like this.


Fig. 2 Initial interaction matrix between application components

The traffic that is transmitted between the components of the application is not controlled in any way - everything is allowed to everyone.

Statement of the problem in general:

• without changing the application configuration, provide the ability to control traffic between application components;
• control implies the possibility of transparent embedding of service elements in the path of transmission of traffic between application components;
• A service element can be a virtual machine that performs packet filtering, load balancing, deep application-level inspection, traffic compression, network traffic analysis, etc. etc.;
• the key part of the task - there may be several service elements, and the complexity of embedding should not depend on their number;
• it should be possible to build service elements in chains.

Example of the real problem number 1 - package filter embedding

The ability to control traffic between applications gives a service element called a packet filter, such as the Cisco VSG . A packet filter is embedded in the data path between the virtual machines. After embedding the filter, the interaction matrix changes and looks as follows.


Fig. 3 Transparent package filter embedding

Note to Fig. 3 : the figure shows the logical operations that the packet filter performs. In general, one virtual machine can cope with this task. This note is also relevant for the schemes that are listed below.

What packet filter does:

• allows incoming traffic from users from the outside segment only to the WEB component of the application;
• traffic from the outside segment to the application components APP and DB is prohibited;
• allowed traffic between pairs of WEB-APP and APP-DB components using known protocols and ports;
• all other traffic is prohibited.

Example of the real problem number 2 - the creation of service chains

Based on the experience of real projects, often application owners, network and security administrators want more from their infrastructure than just packet filtering. Setting a task close to that with which we encounter every day in projects looks something like this.


Fig. 4 Service chains between application components

User traffic destined for the WEB-components of the application passes through the first service chain:

• First, the traffic should go to the load balancer, for example Cisco Netscaler 1000V ;
• then go through a rough cleaning on the packet filter;
• then get to the firewall for more fine cleaning, for example Cisco ASAv *;
• and only then the balanced, cleared and inspected traffic should be transferred to the WEB component.

* The current version of ASAv 9.2 (1) does not have vPath support. Its implementation is planned in the near future.

On the path of traffic, other service chains may occur with a different set and order of service components. In our example, the second service chain consists of a packet filter and a firewall.

2. The solution of the problem by traditional methods

When creating a service chain with traditional methods, the problem of redirecting traffic from one service component to another is solved by changing the network topology. Let's see how you can solve the “Real Problem No. 2” just reviewed. The only possible data transfer path is created between the service virtual machines and the application, see Fig. five.


Fig. 5 Creating a service chain by changing the topology

Service components are embedded on the physical traffic path. Any logical change in the service chain leads to a physical change in the network topology. As can be seen from Fig. 5. instead of one switch and one VLAN in the original task, we have 2 logical switches (inside / outside) and 9 VLANs. You can independently calculate how many times the complexity of the topology increases when using the traditional topological method compared to what vPath offers. In place of a VLAN there may be a VXLAN topological complexity from this does not decrease.

3. The main issue of the article

So what can Cisco offer to facilitate the creation of service chains for applications that are virtualized? How, without increasing the complexity of the infrastructure, to get a flexible tool that does not depend on the hypervisor?

4. The main answer of the article

Cisco proposes to use vPath technology, which provides an elegant creation of service chains in a virtualized environment. vPath is a feature of the Cisco Nexus 1000V Distributed Virtual Switch. The Cisco Nexus1000V switch is available today for all major hypervisors — Hyper-V , KVM *, vSphere . Let's look at how the vPath architecture is structured, how it is configured, and what encapsulation looks like.

* The first Nexus 1000V release for KVM version 5.2 (1) SK1 (2.2) does not have vPath support. Its implementation is planned for future releases.

5. vPath architecture

To use vPath technology, you need:

• Cisco Nexus 1000V Virtual Switch;
• service virtual machine that supports vPath.

Let's turn to the initial logic of the organization of the network connection of the application, which was presented in Fig. 1. Figure 6 shows the changes that need to be made when introducing vPath.


Fig. 6 Basic architectural components of vPath

What has changed?

• the standard switch, which is “attached” to the hypervisor, has been replaced with a Nexus 1000V switch;
• WEB, APP, DB virtual machines migrated from the standard switch to the Nexus 1000V;
• We also added vPath support service virtual machines that perform the already familiar filtering, balancing and firewall roles.

You can add as many service machines as you need to perform traffic operations, or you can get by with one packet filter, as we have already seen in Example of the real task No. 1. In real scenarios, service functions will probably be combined to reduce costs and topological complexity. No additional switches and new VLAN / VXLAN appeared. Topologically, the scheme has not changed.

Nexus 1000V Architecture

Before we go further and figure out how the vPath works, let's get acquainted with the Nexus 1000V switch device.


Fig. 7 Nexus 1000V Switch Architecture

Nexus 1000V, as can be seen from Fig. 7, has two components:

• VEM module (Virtual Ethernet Module) - software code that is embedded in the hypervisor and provides traffic switching;
• VSM module (Virtual Service Module) - a component that provides centralized management and configuration of VEM modules.

Nexus 1000V in its architecture is very similar to a physical modular switch, where VSM plays the role of a supervisor (control module), and VEM plays the role of a line card.

All interface settings that are used to connect a virtual machine to a VEM module are stored in a structure called Port Profile.

To demonstrate the capabilities of vPath, we will use the Nexus 1000V, which is deployed in our local lab. Ports of virtual machines in our laboratory are configured as follows.

port-profile type vethernet V-CONT.WEB switchport mode access switchport access vlan 21 no shutdown state enabled port-profile type vethernet V-CONT.APP switchport mode access switchport access vlan 21 no shutdown state enabled port-profile type vethernet V-CONT.DB switchport mode access switchport access vlan 21 no shutdown state enabled 

While the configuration of all ports is identical. But since for each of the ports we want to implement our own service chain, we set up three different profiles.

VPath basic idea

The basic idea is to create a mechanism that allows you to abstract away from the existing network topology and pass traffic on the necessary service components transparently for both network devices and target virtual machines. Remember that in all of our source examples, virtual machines are located in the same VLAN?

How does vPath do this?

The VEM module keeps records of all data streams that are transmitted through it. This data is collected in the Flow Table. The stream is identified by 6 entities: source IP address, destination IP address, source port, destination port, protocol, VLAN. Every time a new stream appears on the network, a new entry appears in the stream table.


Fig. 8 Table of streams transmitted via the VEM module

The first packet of each newly detected stream is sent to the service device. Thus, the VEM module “asks” the service device a question: can I transfer it further or not? When a packet is sent to a service device, an additional header is added to it with vPath encapsulation.


Fig. 9 Logic diagram of vPath

The service device inspects the package according to the rules and policies that have been configured on it by the security administrator, application or network. Then the service returns the source packet to the VEM module with the vPath encapsulation, which contains the answer - yes, you can send the packet further, or - no, this packet must be discarded, because it does not satisfy the security policy.

The VEM module received the package from the service device:

• records the response in the Action field of the thread table;
• sends the packet to the destination port without vPath-encapsulation, if the Forward command was in the Action field;
• pushes the packet further along the chain using the vPath header if the Redirect command was in the Action field;
• drops the packet if the Drop command was in the Action field.

If the nature of the service does not require constant data transfer through the service element, such as in the case of the Cisco VSG packet filter, then all subsequent packets are transmitted bypassing the service element using the response of the service device recorded in the cache.

Below is a simplified vPath operation algorithm for the case when you need to organize packet filtering between application components.


Fig. 10 Algorithm of vPath for Cisco VSG

6. Configure vPath

We now turn to the practical setting of the vPath mechanism on our laboratory bench. We have implemented the following topology.


Fig. 11 Laboratory bench topology

First, we register the service nodes to which we will redirect traffic.

 vservice node ASA-1 type asa ip address 10.0.21.1 adjacency l2 vlan 21 fail-mode close vservice node VSG-1 type vsg ip address 10.0.21.254 adjacency l2 vlan 21 fail-mode close 

Check that the Nexus 1000V "sees" the registered modules and their status - Alive.

 N1K# show vservice brief -------------------------------------------------------------------------------- License Information -------------------------------------------------------------------------------- Type In-Use-Lic-Count UnLicensed-Mod asa 2 -------------------------------------------------------------------------------- Node Information -------------------------------------------------------------------------------- ID Name Type IP-Address Mode State Module 1 VSG-1 vsg 10.0.21.254 v-21 Alive 4, 2 ASA-1 asa 10.0.21.1 v-21 Alive 4, <  > 

Create a service chain of 2 previously registered modules.

 vservice path WEB-CHAIN node VSG-1 profile WEB_SP order 1 node ASA-1 profile TEST-EDGE-SP order 3 

Check that the Nexus 1000V "sees" the service chain.

 N1K# show vservice brief <  > -------------------------------------------------------------------------------- Path Information -------------------------------------------------------------------------------- Name:WEB-CHAIN NumOfSvc:2 Mod:4, Node Order Profile VSG-1 1 WEB_SP ASA-1 3 TEST-EDGE-SP -------------------------------------------------------------------------------- <  > 

We connect the service chain, which consists of the ASA and VSG to the profile that defines the connection of the WEB virtual machine to the network.

 port-profile type vethernet V-CONT.WEB org root/tenant-01 vservice path WEB-CHAIN 

Check that the Nexus 1000V "sees" the configured chain.

 N1K# show vservice brief <  > -------------------------------------------------------------------------------- Port Information -------------------------------------------------------------------------------- PortProfile:V-CONT.WEB Org:root/tenant-01 Path:WEB-CHAIN Node Profile(Id) VSG-1(10.0.21.254) WEB_SP(9) ASA-1(10.0.21.1) TEST-EDGE-SP(8) Veth Mod VM-Name vNIC IP-Address 15 4 r1-web-v2 1 10.0.21.10 <  > 

Now we will make so that the traffic which is transferred towards the APP and DB virtual computers, was transferred through the packet filter.

 port-profile type vethernet V-CONT.APP org root/tenant-01 vservice node VSG-1 profile APP_SP port-profile type vethernet V-CONT.DB org root/tenant-01 vservice node VSG-1 profile DB_SP 

As a result, with the help of several configuration lines, the laboratory implemented the following traffic pattern inside VLAN = 21. However, we did not create new auxiliary switches or VLANs. In Fig. 12 shows the service chain, which turned out.


Fig. 12 Service chain configured in the example.

As can be seen from the presented configuration, it is extremely simple compared to the changes that would have to be made if it were necessary to change the network topology to fit into the service elements. Once again, the original topology has not changed.

7. vPath encapsulation

vPath packs source packages into its header as follows.



Fig. 13 vPath encapsulation

If the service virtual machine is located in the same segment, then the L2 transport header is added to the source packet. If the service machine is located in another segment, then a transport L3 header is added. The body of the original frame does not change. Between the transport header and the source packet is the vPath header.

The vPath header consists of 3 required components:

• basic header;
• service header;
• platform header.

Fig. 14 vPath header

Basic title:

• contains the version of the protocol and the identifier of the service chain.

It should be noted that the service chain itself is not included in the header. There is only its unique identifier. Information about the chain is stored in a special Service Table, which, like the FlowTable, is on each VEM module. This table is programmed centrally from the VSM module when the owner of the system makes changes to the configuration.

Service header:

• implements the approval procedure for the vPath version used;
• transfers information about profile identifiers on service devices;
• implements the Request / Response procedure between the VEM module and the service device.

Platform Header:

• carries information specific to the platform that implements the vPath;
• contains the port ID of the source;
• contains a segment type identifier - VLAN, VXLAN;
• contains a segment identifier - VLAN number, VXLAN number.

Here is the package that the VEM module received from the virtual machine and redirects to the service module. The latter must decide whether it is possible or not to send this package through the service chain further. In the service header, we see that the REDIRECT function is running. The service module is connected to the VEM module via L2.


Fig. 15 Package that the VEM sends to the service module

The next screen shot is the package that the VEM module received from the service module after the package inspection. The Service Context Header field contains the RESPONSE identifier, and the ACTION field is set to PERMIT, meaning that this packet can be forwarded.


Fig. 16 Package that VEM receives from the service module after inspection

8. Conclusions

In the article we discussed the problem of creating service chains in the data center. A large number of virtualized infrastructure owners face this problem when deploying applications. Solving a problem by changing the network topology to fit service devices leads to more complex network configuration. We got acquainted with an easy way to solve this problem by deploying the Nexus 1000V switchboard and using vPath technology, which is configured by several simple commands.