Network overlay technologies: OTV, LISP and results. Part 3

In the previous parts ( first , second ) of this article, we reviewed the general classification of network overlay technologies for data centers, as well as discussed in more detail what TRILL, FabricPath and VXLAN are. It remains to OTV and LISP. Plus, you need to take stock.

Otv
')
OTV (Overlay Transport Virtualization) technology was invented by Cisco to provide connectivity to distributed L2 network segments over a regular IP network. With the help of OTV, we can “stretch” the broadcast domain between two or more data centers. We can say that this is one of the implementations of L2 VPN, running on top of an IP network.

OTV implements the concept of routing to MAS addresses. It looks like this. Devices running OTV technology (hereinafter referred to as OTV devices), using the IS-IS dynamic routing protocol, exchange data on the MAC addresses of the hosts behind them. This allows each OTV device to have a common MAC routing table. Then, having received a packet that has the MAC address of a host located somewhere far away (I mean in a remote L2 network segment), the OTV device determines from the table where to send this packet. A header is added to the packet, and it is sent first to the remote OTV device, and then to the recipient's host. When transmitting Ethernet packets between OTV devices, they are encapsulated into UDP datagrams.



I think many have already noted that, in general, OTV is very similar to the logic of VXLAN. But unlike VXLAN, OTV technology is designed primarily for communication of L2 networks between data centers. The second point - we are again talking about IS-IS. As in the TRILL / FabricPath for the control-plane (implementation of the operation logic), this dynamic routing protocol is used.

Let's look at how OTV devices find each other, to ensure further communication between them. For this, OTV supports two modes of operation.

In the first case, multicast traffic is used to connect OTV devices to each other. All OTV devices report to the network that they want to receive multicast traffic addressed to a specific group (via IGMP). Further, messages for establishing and maintaining communication between each other (Hello packets), as well as data on MAC addresses are transmitted via multicast messages. These messages are transmitted by the network to all OTV devices. This behavior is very similar to the normal dynamic routing protocol. Only OTV devices can be in different subnets. For all this to work, our network must support the transmission of multicast traffic, including its routing. As noted in the previous article, it is not always easy to ensure that this condition is met (for example, if the Internet is used between data centers). Therefore, there is a second mode of operation in which unicast traffic is used.

In the case of using unicast traffic for interaction between OTV devices, one of them is configured as an adjacency server (Adjacency Server). Further, on all other OTV devices, its address is indicated (this is done by “handles” during setup). All OTV devices establish a connection with it. Thus, the adjacency server collects data about all OTV devices (in particular, it recognizes their IP addresses) and distributes them to all devices. Having received this information, each OTV device can now communicate with others using unicast packets, as now there is data about their IP addresses. After establishing a connection between OTV devices, the exchange of MAC address tables begins. Of course, this mode of operation creates a greater load on OTV devices than in the case of using multicast traffic. Since in some cases (for example, for broadcast traffic), instead of one packet, it is necessary to send several (to each OTV device) at once.

To reduce the mutual influence of distributed L2-segments on each other and optimize the transmitted traffic between them, OTV provides their partial isolation:

• BPDU packets of STP protocols are not transmitted between OTV devices. Each segment builds its own independent STP topology.
• No unicast traffic is transmitted between OTV devices. This logic of operation is based on the assumption that any device will sooner or later transmit some data and we will know its MAC address.
• Optimized transmission of ARP messages. On OTV devices, all ARP responses from remote hosts are cached. Thus, the local OTV device can respond to an ARP request if someone has previously sent a similar one.

As noted earlier, OTV, unlike VXLAN, provides communication only between data centers. In fact, VXLAN is a more universal protocol. However, the requirements for the "hardware" in OTV are somewhat lower. OTV is quite often recommended by Cisco in designs between data centers where FabricPath is in turn used inside.
OTV is supported on the following Cisco hardware: Nexus 7K, ASR 1K, ISR 4451-X.

Lisp

LISP (Cisco Locator / ID Separation Protocol) has a different purpose than previously announced. Everyone knows the problem of correct traffic routing, if the virtual machine has moved, for example, from one data center to another. And it is good if the same address space is used in another data center. And if there are completely different subnets, how to inform the client equipment that now the traffic should be sent not to Data Center1, but to Data Center2, and it can also be to another address? One solution to this task was to divide the server identifier into two parts: the server address itself (Endpoint Identifier (EID) address) and the device address through which the server is accessible (Route Locator (RLOC) address). Thus, when moving a virtual machine to another data center, the EID address will always remain the same, and the RLOC address will change.



In general terms, the work of LISP can be described as follows. After “turning on” the network, the devices where the LISP is configured (in terms of LISP - xTR) inform the dedicated server (Map-Server) about the networks that they serve, i.e. for which they are the default gateway. Further, for example, the ROUTER2 device, receiving traffic from the client to the server (to the address EID = 1.1.1.2), makes a request for a dedicated device (Map-Resolver), which in turn refers to the Map-Server. Map-Server, having determined the RLOC1 address (ROUTER1 address) for the requested EID address in its database, asks ROUTER1 to respond directly to the client xTR (ROUTER2) ​​about its RLOC1 address. ROUTER2 then encapsulates all client packets and sends them to the RLOC1 address. Then ROUTER1, having received these packets, de-encapsulates them and sends them directly to the server (1.1.1.2).

But what happens if the virtual machine (VM) moves? In this case, after the migration to another host, the virtual switchboard (running on the host where the VM moved) will send a RARP or GARP message to the network (depending on the type of hypervisor). The objective of this message is to “tell” the network that the VM is now on the new host. Having intercepted such traffic (in fact, any traffic from a VM will do, but usually we see RARP / GARP first), the nearest xTR will send a message about this (that VM is now behind it) to the Map-Server. Map-Server, in turn, will update the database (for the address of the EID virtual machine, it will replace the RLOC address through which it is available). The Map-Server will also inform the old RLOC (in our case ROUTER1) that the virtual machine has left and now it is located behind the new RLOC address (for example, RLOC3, not shown in the figure). This is necessary in order to report a VM migration to all xTRs that previously addressed it and have in their local database an EID binding to the old RLOC1.

UDP is used to encapsulate the traffic, which ensures the transparent transmission of packets through a normal IP network.

LISP is supported sufficiently on a large list of Cisco equipment, for example: ISR G1 and G2, ASR, CRS, Nexus 7K, Catalyst 6K.

The overall result

Let's try to summarize all three parts of my article. The following table presents brief information on the technologies we touched on in this material.

	Overlay type	Where used	Transport
Fabricpath	Network-based	Inside the data center	FabricPath *
TRILL	Network-based	Inside the data center	TRILL *
VXLAN	Host-based or Network-based	Both inside the data center and between data centers	UDP
Otv	Network-based	Between data centers	UDP
Lisp	Network-based	Traffic transfers to VMs that are migrating.	UDP

* uses its own protocol at the data link layer.

In my opinion, a bunch of FabricPath (inside the data center) and OTV (between the data centers) technologies are widely spread on Cisco equipment. These technologies are well developed, easy to configure, and it is on them that most Cisco designs rely. There are examples of data centers where it is used. The truth is worth noting that their use requires not quite simple and cheap "iron". But what can you do.

What can you say about VXLAN? This is a fairly promising technology:

• constantly being finalized;
• supported and developed by many vendors;
• there is support for cheaper classes of devices;
• quite flexible: Host-based or Network-based, work both inside the data center and between;
• support of more than 16 million logical segments (VXLAN networks);
• used in SDN networks (in my opinion, a very powerful driver).

Of course, there are a number of issues that require further refinement. For example, if we are talking about Cisco, I would like to see support for MP-BGP EVPN for the unicast transfer mode on a simpler hardware, or the ability to work in unicast mode between several VSMs for the Cisco Nexus 1000V solution.

But technology is constantly evolving. Not so long ago to consider VXLAN for the implementation of communication between data centers was difficult. Now the ability to use MP-BGP EVPN for the implementation of the control-plane VXLAN made it possible. Thanks to MP-BGP EVPN, the issue of minimizing flooding and isolation of distributed segments when using VXLAN is solved. Although I would like, of course, that there was no flood and storms at all.

In general, it should be said that judging by Cisco documents, the vendor has high hopes for the implementation of the MP-BGP EVPN. Cisco is offering it as a standard for SDN architectures for implementing communication via VXLAN as opposed to the Open vSwitch Database Management Protocol (OVSDB). Well, this is not new for Cisco, let's see what happens.

It is worth noting that VXLAN does not participate in the transport network. Those. the transport network must be configured separately, plus if it is poorly configured, the transfer of VXLAN traffic will not be optimal. True, the "curvature" of the hands is dangerous for any technology.

LISP technology stands a bit apart, solving the problem of optimal traffic transfer to the server, and in some tasks to the client. Therefore, it is recommended to use LISP regardless of overlay technologies inside or between data centers. LISP is not the easiest (from the point of view of implementation) solution to the problem of non-optimal transmission of traffic and is not for all cases in life. For example, to completely resolve the issue of non-optimal traffic from client to server in the data center (ie, WAN-to-DC), LISP must be configured for each remote client (which is quite a challenge for the Internet network).

And finally, I would like to note a few more points:

1. The technologies described are overlayed. So add to the source package your title. Consequently, it is imperative to follow extremely closely such a parameter as the maximum frame size (MTU).
2. As I already wrote, there is no super technology that solves all problems. Any sounded technology has its pros and cons.
3. To simplify the perception of the material, I specifically missed a number of technical details. Therefore, if something causes questions, I will try to answer.