Locator Identity Separation Protocol -VM Mobility
Locator Identity Separation Protocol ( LISP )
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 end points 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.
Basic LISP Traffic flow
A device ( S1 ) initiate 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 flows to the edge of the network on its way to D1, it is met by an Ingress Tunnel Routers ( ITR ). The ITR maps the destination EID to a destination RLOC and then encapsulates the original packet with an additional header that has 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. There is no routing convergence and any changes to the mapping systems is unknown to the source and destination hosts. Offering complete transparency.
LISP Name Spaces:
|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 end-points. The remote host obtains a destination the same way it obtains a normal destination addresses 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:
|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 site. 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 to local EIDs at the site. An ETR only accepts an IP packet where the destination address is the “outer” IP header is one of its own configured RLOCs. The ETR should be the last hop router directly connected to the destination.|
LISP Infrastructure Devices:
|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.|
Locator Identity Separation Protocol ( 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 “extended subnets”. Extended subnet mode requires a Layer 2 LAN extension. When the end hosts carries 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
If a VM wants to perform a “hot” migration between two dispersed sites, LISP does not remove the need for a LAN extensions. 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 it be back to back vPC and/or 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 used in conjunction with an LAN extension extends a single LISP site across two physical data center sites. The extended subnet functionality of LISP makes two DC sites a single LISP site. On the other hand, when LISP is deployed without an LAN extension, a single LISP site is not extended between two data centers and we end up having separate LISP sites.
LISP Extended subnet
To avoid asymmetric traffic handling the LAN extension technology must filter Hot Standby Router Protocol ( HSRP ) HELLO messages across the two data centers. This creates an active-active HSRP setup. HSRP localization optimizes egress traffic flows. Ingress traffic flows are optimized by LISP.
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 there is no need to re-ARP during mobility events.
The LAN extension technology must have multicast enabled to support the proper operation of LISP. Once a dynamic EID moved is detected the multicast group IP addresses is used to 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 subnet requires the mobile VM to have access to 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 to the HSRP group to be consistent across sites.
Proxy ARP must be configured under both local and remote SVIs to properly handle new ARP requests generated by the migrated workload.
With this deployment there is no need to deploy an 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.