LISP Hybrid Cloud Implementation
In today’s rapidly evolving technological landscape, hybrid cloud solutions have emerged as a game-changer for businesses seeking flexibility, scalability, and cost-effectiveness. One of the most intriguing aspects of hybrid cloud architecture is its potential when combined with LISP (Locator/Identifier Separation Protocol). In this blog post, we will delve into the concept of LISP hybrid cloud and explore its advantages, use cases, and potential impact on the future of cloud computing.
LISP, short for Locator/Identifier Separation Protocol, is a network architecture that separates the routing identifier of an endpoint device from its location information. This separation enables efficient mobility, scalability, and flexibility in networks, making it an ideal fit for hybrid cloud environments. By decoupling the endpoint’s identity and location, LISP simplifies network management and enhances the overall performance and security of the hybrid cloud infrastructure.
Before you proceed, you may find the following posts helpful for pre-information:
LISP Hybrid Cloud Implementation
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 an added layer of 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. By utilizing LISP, organizations can easily distribute workloads across cloud providers, avoiding vendor lock-in and maximizing resource utilization.
Critical Points and Traffic Flows
- 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.
- 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.
- 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.
- 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.
- The PxTR-1 uses Proxy-ARP for both intra-subnet and inter-subnet communication.
- The PxTR-1 proxy replies on behalf of nonlocal servers ( VM-B in the Public Cloud ) by inserting its own MAC address for any EID.
- 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
- 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.
- 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.
- For returning traffic from the cloud to the enterprise, the xTR-1 acts as an iTR.
- 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
- Virtual Machine A in the enterprise space wants to communicate and opens a session with Virtual Machine B in the public cloud space.
- VM-A sends an ARP request for VM-B. This is used to find the MAC address of VM-B.
- 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.
- VM-A receives the MAC address via ARP from the PxTR-1 and forwards traffic to its default gateway.
- 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 ).
- 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.
- Finally, the LISP encapsulates traffic to the xTR-1 at the remote site.
Packet walk: Non-LISP site to public cloud
- An end host in a non-LISP site wants to open a connection with VM-B.
- Traffic is naturally attracted via traditional routing to the enterprise site domain and passed to the local default gateway.
- The local default gateway sends an ARP request to find the MAC address of VM-B.
- The PxTR-1 performs Proxy-ARP, responds to the ARP request, and inserts its own MAC address for the remote VM-B.
- Traffic is then LISP encapsulated and sent to the remote Public Cloud, where VM-B is located.