Shulou(Shulou.com)06/02 Report--

Author: Umberto Manferdini translator: TF compilation Group

If you have seen any demonstration of Tungsten Fabric (note: original Contrail, in this series of articles, the function of Tungsten Fabric is the same as that of Contrail, and where Contrail appears in the article is replaced by Tungsten Fabric), you may encounter the buzzword "service chain". Now, it's time to do some research on this feature. So what is the service chain? In short, it is to make traffic flow between two virtual networks through one or more "services". Let's give an example. There are two virtual networks: pippo and pluto. We want the two networks to communicate with each other. In Tungsten Fabric, you only need to configure the same RT (route target) on two virtual networks (the virtual network is vrfs, remember? ). Note: Route target is RT, which is used as a routing tag in Tungsten Fabric and is also a commonly used routing update tag in MPLS. Another option is that we can build a network policy that applies to both networks, which is to "allow any traffic between these virtual networks." Behind the scenes, Tungsten Fabric still relies on routing route target (hiding and automatically generating targets). So we can say that the two methods are the same. This seems to be true, but it is fundamentally wrong! Using network policies allows us to specify one or more service instances through which traffic must pass when moving between virtual networks. This cannot be done by the first method. And this is the service chain! Note: what the author wants to say here is that although the results are the same, the content of the implementation is different. The first type of same RT implementation is that different networks have the same routing attributes, which means that they can disclose and communicate with each other, while the second is not. As mentioned earlier, the service chain can include one or more services. This means that traffic from pippo to pluto can pass through the firewall, as well as (one by one) the firewall and DPI.

At first glance, some people will say, "OK, it's cool! but I can also do the same thing through routing." . Yes, but what really matters here is that it is easy to deploy. Tungsten Fabric is responsible for all transactions and automatically configures all required routes. All you have to do is tell Tungsten Fabric your intentions: "allow these networks to make calls and let traffic pass through these service instances." We are in an age of intention, aren't we? Of course, that's not the whole story. Tungsten Fabric introduces other features, such as health checks (health checks), into the table to provide high availability and scalability. In addition, the network policy itself can be used to deny / allow traffic based on L4 rules. So, the question now is: what does it take to create a service chain? Let's take a closer look at the elements! First, we need two virtual networks. There is no need to configure any route target on them. Next, we configure a network policy between them to allow all traffic to pass through:

At this point, the two networks can communicate with each other! It's time to turn to the service chain.

First, we create a virtual machine that will be part of our service instance. This is the virtual machine that the traffic between the two virtual networks (VNF) will traverse! For example, the virtual machine can be a firewall. The VM must be created in Openstack; just like any other VM created through Nova.

This is the only operation performed on Openstack.

Next, go back to Tungsten Fabric! We create an object called service template (service template):

As the name implies, a service template is a description of a service. The following five parameters must be configured:

Version (version), must be v2

Virtualization type (virtualization type), which must be a virtual machine unless you plan to use physical networking capabilities (PNF)

The type of service (service type), which can be a firewall or a parser, we use the first.

Service pattern (service mode), which can be transparent (bump in the wire), in-network (most common), in-network-nat (special use case when using nat)

Interface list, usually we define two interfaces: left and right

Because this is a template, it can be used multiple times for different VM configurations. For example, both Juniper firewall service instances and third-party vendor firewall service instances can be deployed using service templates. Importantly, in both cases, the virtual machine created in OpenStack has two interfaces that can be mapped to the interfaces defined in the service template (left and right). Next, we create a service instance. There are many things that can be configured in the service instance object. Here, we will focus on the minimum configuration that makes the chain work. The service instance references the service template. Once this reference is specified, the interfaces defined in the service template (left and right) can be mapped to the actual virtual network. For example, in this case, we map to fourcade to the left and to wierer to the right.

Now, let's introduce a key object: Port tuple (port tuple). It is a tuple that references a virtual machine interface. As mentioned earlier, the actual VM that acts as a firewall is not defined by Tungsten Fabric, but is created like any other VM in OpenStack. However, we need to "link" the virtual machine to our service instance. This is done through port tuples. Chaining is performed at the virtual machine interface (vmi) level. In this case, the port tuple will contain two elements, one for each interface defined in the service template (left and right). In addition, we map the service template interface to the virtual network (left to fourcade, right to wierer). Now, let's look at the virtual machine. It has three ports: eth0 connects to virtual networks that we don't care about, and eth2 connects to fourcade,eth3 and connects to wierer. What's the next step? It's obvious! The port tuple will include eth2 and eth3. This is how we tell Tungsten Fabric where traffic should go when traversing the service instance. Nothing can stop us from having multiple port tuples for a single service instance. What about ECMP? How does active/backup handle it? ... Do you have any ideas? We'll deal with it later. Now, let's focus on this use case first. Where are we now? Traffic from the VM in the fourcade network is destined for an IP address in the more wierer network. Traffic needs to go from fourcade to wierer. This communication is allowed in the network policy. Because the network policy tells that traffic from fourcade to wierer must pass through the service instance, the packet is sent to the VM eth2 port and will enter the wierer network from the eth3 port.

Because Tungsten Fabric is flow-based, symmetry and stickiness can be guaranteed! This is the theory of Mount Qomolangma. In the next article, we will see a real example. This will show us how easy it is to create a service chain and how Tungsten Fabric masks all the complexity!

Original link: https://iosonounrouter.wordpress.com/2020/06/09/whats-a-service-chain/

Series of articles on Tungsten Fabric Architecture Analysis

Part I: main features and use cases of TF

Article 2: how TF works

Part 3: detailed explanation of vRouter architecture

Part IV: service chain of TF

Part 5: deployment options for vRouter

Part 6: how does TF collect, analyze, and deploy?

Chapter 7: how to arrange TF

Part 8: TF support API list

Article 9: how TF connects to the physical network

Part 10: TF Application-based Security Policy

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.