LISP Protocol and VM Mobility
Locator Identity Separation Protocol ( LISP ) provides a set of functions that allow Endpoint identifiers ( EID ) to be mapped to an RLOC address space. The mapping between these two endpoints offers the separation of IP addresses into two numbering schemes ( similar to the “who” and the “where” analogy ), offering many traffic engineering and IP mobility benefits for the geographic dispersion of data centers beneficial for VM mobility.
Before you proceed, you may find the following posts helpful:
- LISP Hybrid Cloud
- LISP Control Plane
- Triangular Routing
- Active Active Data Center Design
- Application Aware Networking
VM Mobility |
|
- A key point: Video on LISP configuration.
In this video, we will have a look at LISP configuration. This can be considered the first step before you get into the more advanced features of LISP and VM mobility. The LISP protocol, from its inception, has been an open standard protocol that interoperates across various platforms and is incrementally deployable on top of any transport. LISP’s flexibility has led to its application in every part of today’s modern network, from the data center to the enterprise WAN to the enterprise campus to the service provider edge and the core. The following will help you understand a LISP hybrid cloud implementation.
- A key point: Back to basics with the Virtual Machine (VM).
The idea of virtualization can be applied not solely to subsystems such as disks but to a whole machine. A virtual machine (VM) is implemented by adding a software layer to an actual device to sustain the desired virtual machine’s architecture. In general, a virtual machine can circumvent real compatibility and hardware resource limitations to enable a more elevated degree of software portability and flexibility.
Basic LISP Traffic flow
A device ( S1 ) initiates a connection and wants to communicate with another external device ( D1 ). D1 is located in a remote network. S1 will create a packet with the EID of S1 as the source IP address and the EID of D1 as the destination IP address. As the packets flow to the network’s edge on their way to D1, it is met by an Ingress Tunnel Router ( ITR ). The ITR maps the destination EID to a destination RLOC and then encapsulates the original packet with an additional header with the source IP address of the ITR RLOC and the destination IP address of the RLOC of an Egress Tunnel Router ( ETR ). The ETR is located on the remote site next to the destination device D1.
The magic is how these mappings are defined, especially regarding VM mobility. There is no routing convergence, and any changes to the mapping systems are unknown to the source and destination hosts. We are offering complete transparency.
LISP Terminology
LISP namespaces:
LSP Name Component | LISP Protocol Description |
End-point Identifiers ( EID ) Addresses | The EID is allocated to an end host from an EID-prefix block. The EID associates where a host is located and identifies endpoints. The remote host obtains a destination the same way it obtains a normal destination address today, for example through DNS or SIP. The procedure a host uses to send IP packets does not change. EIDs are not routable. |
Route Locator ( RLOC ) Addresses | The RLOC is an address or group of prefixes that map to an Egress Tunnel Router ( ETR ). Reachability within the RLOC space is achieved by traditional routing methods. The RLOC address must be routable. |
LISP site devices:
LISP Component | LISP Protocol Description |
Ingress Tunnel Router ( ITR ) | An ITR is a LISP Site device that sits in a LISP site and receives packets from internal hosts. It in turn encapsulates them to remote LISP sites. To determine where to send the packet the ITR performs an EID-to-RLOC mapping lookup. The ITR should be the first-hop or default router within a site for the source hosts. |
Egress Tunnel Router ( ETR ) | An ETR is a LISP Site device that receives LISP-encapsulated IP packets from the Internet, decapsulates them, and forwards them to local EIDs at the site. An ETR only accepts an IP packet where the destination address is the “outer” IP header and is one of its own configured RLOCs. The ETR should be the last hop router directly connected to the destination. |
LISP infrastructure devices:
LISP Component Name | LISP Protocol Description |
Map-Server ( MS ) | The map server contains the EID-to-RLOC mappings and the ETRs register their EIDs to the map server. The map-server advertises these, usually as an aggregate into the LISP mapping system. |
Map-Resolver ( MR ) | When resolving EID-to-RLOC mappings the ITRs send LISP Map-Requests to Map-Resolvers. The Map-Resolver is typically an Anycast address. This improves the mapping lookup performance by choosing the map-resolver that is topologically closest to the requesting ITR. |
Proxy ITR ( PITR ) | Provides connectivity to non-LISP sites. It acts like an ITR but does so on behalf of non-LISP sites. |
Proxy ETR ( PETR ) | Acts like an ETR but does so on behalf of LISP sites that want to communicate to destinations at non-LISP sites. |
VM Mobility
LISP Host Mobility
LISP VM Mobility ( LISP Host Mobility ) functionality allows any IP address ( End host ) to move from its subnet to either a) a completely different subnet, known as “across subnet,” or b) to an extension of its subnet in a different location, known as “extended subnet” – while keeping its original IP address.
When the end host carries its own Layer 3 address to the remote site, and the prefix is the same as the remote site, it is known as an “extended subnet.” Extended subnet mode requires a Layer 2 LAN extension. On the other hand, when the end hosts carry a different network prefix to the remote site, it is known as “across subnets.” When this is the case, a Layer 2 extension is not needed between sites.
LAN extension considerations
LISP does not remove the need for a LAN extension if a VM wants to perform a “hot” migration between two dispersed sites. The LAN extension is deployed to stretch a VLAN/IP subnet between separate locations. LISP complements LAN extensions with efficient move detection methods and ingress traffic engineering.
LISP works with all LAN extensions – whether back-to-back vPC and VSS over dark fiber, VPLS, Overlay Transport Virtualization ( OTV ), or Ethernet over MPLS/IP. LAN extension best practices should still be applied to the data center edges. These include but are not limited to – End-to-end Loop Prevention and STP isolation.
A LISP site with a LAN extension extends a single LISP site across two physical data center sites. This is because the extended subnet functionality of LISP makes two DC sites a single LISP site. On the other hand, when LISP is deployed without a LAN extension, a single LISP site is not extended between two data centers, and we end up having separate LISP sites.
LISP extended subnet
The LAN extension technology must filter Hot Standby Router Protocol ( HSRP ) HELLO messages across the two data centers to avoid asymmetric traffic handling. This creates an active-active HSRP setup. HSRP localization optimizes egress traffic flows. LISP optimizes ingress traffic flows.
The default gateway and virtual MAC address must remain consistent in both data centers. This is because the moved VM will continue to send to the same gateway MAC address. This is accomplished by configuring the same HSRP gateway IP address and group in both data centers. When an active-active HSRP domain is used, re-ARP is not needed during mobility events.
The LAN extension technology must have multicast enabled to support the proper operation of LISP. Once a dynamic EID is detected, the multicast group IP addresses send a map-notify message by the xTR to all other xTRs. The multicast messages are delivered leveraging the LAN extension.
LISP across subnet
LISP across subnets requires the mobile VM to access the same gateway IP address, even if they move across subnets. This will prevent egress traffic triangulation back to the original data center. This can be achieved by manually setting the vMAC address associated with the HSRP group to be consistent across sites.
Proxy ARP must be configured under local and remote SVIs to correctly handle new ARP requests generated by the migrated workload.
With this deployment, there is no need to deploy a LAN extension to stretch VLAN/IP between sites. This is why it is considered to address “cold” migration scenarios, such as Disaster Recovery ( DR ) or cloud bursting and workload mobility according to demands.
- DMVPN - May 20, 2023
- Computer Networking - April 7, 2023
- eBOOK – SASE Capabilities - April 6, 2023