LISP Components

In addition to separating device identity from location, the Location/ID Separation Protocol (LISP) architecture also reduces operational expenses (opex) by providing a Border Gateway Protocol (BGP)–free multihoming network. Multiple address families (AF) are supported, a highly scalable virtual private network (VPN) solution is provided, and host mobility is enabled in data centers. Understanding LISP’s architecture and how it works is essential to understand how all these benefits and functionalities are achieved.

LISP Architecture

In RFC 6830, LISP defines a routing and addressing architecture for the Internet Protocol. The LISP routing architecture addressed scalability, multi-homing, traffic engineering, and mobility problems. A single 32-bit (IPv4 address) or 128-bit (IPv6 address) number on the Internet today combines location and identity semantics. In LISP, the location is separated from the identity. As a result, the LISP’s network layer locator (the network layer identifier) can change, but the network layer locator (the network layer identifier) cannot.

As a result of LISP, the end user device identifiers are separate from the routing locators that others use to contact them. As a result of the LISP routing architecture design, devices are identified by their endpoint identifiers (EIDs), while their locations, called routing locators (RLOCs), are identified by their routing locators.

Before you proceed, you may find the following posts helpful for pre-information:

1. LISP Control Plane
2. LISP Hybrid Cloud Use Case
3. LISP Protocol
4. Merchant Silicon

Back to Basics: LISP Hybrid Cloud

Endpoint identifiers and routing locators

A device’s IPv4 or IPv6 address identifies it and indicates its location. Present-day Internet hosts are assigned a different IPv4 or IPv6 address whenever they move from one location to another, which overloads the location/identity semantic. Through the RLOC and EID, LISP separates location from identity. IP addresses of the egress tunnel router (ETR) and the host’s IP address are represented by the RLOC and EID, respectively.

A device’s identity does not change with a change in location with LISP. The device retains its IPv4 or IPv6 address when it moves from one location to another, but the site tunnel router (xTR) changes dynamically. A mapping system ensures that the identity of the host does not change with the change in location. As part of the distributed architecture, LISP provides an EID-to-RLOC mapping service that maps EIDs to RLOCs.

Advantages of LISP in Hybrid Cloud:

1. Improved Scalability: LISP’s ability to separate the identifier from the location allows for easier scaling of hybrid cloud environments. With LISP, organizations can effortlessly add or remove resources without disrupting the overall network architecture, ensuring seamless expansion as business needs evolve.

2. Enhanced Flexibility: LISP’s inherent flexibility enables organizations to distribute workloads across cloud environments, including public, private, and on-premises infrastructure. This flexibility empowers businesses to optimize resource utilization and leverage the benefits of different cloud providers, resulting in improved performance and cost-efficiency.

3. Efficient Mobility: Hybrid cloud environments often require seamless mobility, allowing applications and services to move between cloud providers or data centers. LISP’s mobility capabilities enable smooth migration of workloads, ensuring continuous availability and reducing downtime during transitions.

4. Enhanced Security: LISP’s built-in security features provide protection to hybrid cloud environments. With LISP, organizations can implement secure overlay networks, ensuring data integrity and confidentiality across diverse cloud infrastructures. LISP’s encapsulation techniques also prevent unauthorized access and mitigate potential security threats.

Use Cases of LISP in Hybrid Cloud:

1. Disaster Recovery: LISP’s mobility and scalability make it an excellent choice for implementing disaster recovery solutions in hybrid cloud environments. By leveraging LISP, organizations can seamlessly replicate critical workloads across multiple cloud providers or data centers, ensuring business continuity during a disaster.

2. Cloud Bursting: LISP’s flexibility enables organizations to leverage additional resources from public cloud providers during peak demand periods. With LISP, businesses can easily extend their on-premises infrastructure to the public cloud, ensuring optimal performance and cost optimization.

3. Multi-Cloud Deployments: LISP’s ability to abstract the underlying network infrastructure simplifies the management of multi-cloud deployments. Organizations can efficiently distribute workloads across cloud providers by utilizing LISP, avoiding vendor lock-in, and maximizing resource utilization.

Critical Points and Traffic Flows

1. The enterprise LISP-enabled router ( PxTR-1) can be either physical or virtual. The ASR 1000 and selected ISR models support Locator Identity Separation Protocol ( LISP ) functions for the physical world and the CSR1000V for the virtual world.
2. The CSR or ASR/ISR acts as a PxTR with both Ingress Tunnel Router ( ITR ) and Egress Tunnel Router ( ETR ) functions. The LISP-enabled router acts as PxTR so that non-LISP sites like the branch office can access the mobile servers once they have moved to the cloud. The “P” stands for proxy. The ITR and ETR functions relate to LISP encapsulation/decapsulation depending on traffic flow direction. The ITR encapsulates, and the ETR decapsulates.
3. The PxTR-1 ( Proxy Tunnel Router ) does not need to be in the regular forwarding path and does not have to be the default gateway for the servers that require mobility between sites. However, it does require an interface ( same subnet ) to be connected to the servers that require mobility. The interface can be either a physical or a sub-interface.
4. The PxTR-1 can detect server EID ( server IP address ) by listening to the Address Resolution Protocol ( ARP ) request that could be sent during server boot time or by specifically sending Internet Control Message Protocol ( ICMP ) requests to those servers.
5. The PxTR-1 uses Proxy-ARP for both intra-subnet and inter-subnet communication.
6. The PxTR-1 proxy replies on behalf of nonlocal servers ( VM-B in the Public Cloud ) by inserting its MAC address for any EID.
7. There is an IPsec tunnel, and routing is enabled to provide reachability for the RLOC address space. The IPSEC tunnel endpoints are the PxTR-1 and the xTR-1.

LISP hybrid cloud: The map-server and map-resolver

The map-server and map-resolver functions are enabled on the PxTR-1. They can, however, be enabled in the private cloud. For large deployments, redundancy should be designed for the LISP mapping system by having redundant map-server and map-resolver devices. You can implement these functions on separate devices, i.e., the map-server on one device and the map resolver on the other. Anycast addressing can be used on the map-resolver so LISP sites can choose the topologically closer resolver.

Public cloud deployment  

1. Unlike the PxTR-1 in the enterprise domain, the xTR-1 in the Public Cloud must be in the regular data forwarding path and acts as the default gateway.
2. At the cloud site, the xTR-1 acts as both the eTR and the iTR. With flows from the enterprise domain to the public cloud, the xTR-1 performs eTR functions.
3. For returning traffic from the cloud to the enterprise, the xTR-1 acts as an iTR.
4. The xTR-1 LISP encapsulates traffic and forwards it to the RLOC at the enterprise site for an unknown destination.

Packet walk: Enterprise to public cloud

1. Virtual Machine A in the enterprise space wants to communicate and opens a session with Virtual Machine B in the public cloud space.
2. VM-A sends an ARP request for VM-B. This is used to find the MAC address of VM-B.
3. The PxTR-1 with an interface connected to VM-A ( server mobility interface ) receives this request and replies with its MAC address. This is the Proxy ARP feature of the PxTR-1 and its users because VM-B is not directly connected.
4. VM-A receives the MAC address via ARP from the PxTR-1 and forwards traffic to its default gateway.
5. As this is a new connection, the PxTR-1 does not have a LISP mapping in its cache for the remote VM. This triggers the LISP control plane, and the PxTR-1 sends a map request to the LISP mapping system ( map-resolver and map-server ).
6. The LISP mapping system, which is local to the device, replies with the EID-to-RLOC mapping, which shows that VM-B is located in the public cloud site.
7. Finally, the LISP encapsulates traffic to the xTR-1 at the remote site.

 Packet walk: Non-LISP site to public cloud

1. An end host in a non-LISP site wants to open a connection with VM-B.
2. Traffic is naturally attracted via traditional routing to the enterprise site domain and passed to the local default gateway.
3. The local default gateway sends an ARP request to find the MAC address of VM-B.
4. The PxTR-1 performs proxy-ARP, responds to the ARP request, and inserts its MAC address for the remote VM-B.
5. Traffic is then LISP encapsulated and sent to the remote Public Cloud, where VM-B is located.