20 – Locator/ID Separation Protocol (LISP)

LISP VM-Mobility:  

Traditionally, an IP address uses a unique identifier assigned to a specific network entity such as physical system, virtual machine or firewall, etc. The routed WAN uses the identifier to also determine the network entity’s location in the IP subnet. When VMs migrate from one data center to another, the traditional IP address schema retains its original unique identifier and location, although the location has actually changed.

This is done because the Layer 2 VLAN between the physical and virtual machines supports the same IP subnet. The extended VLAN must share the same subnet so that the TCP/IP parameters of the VM remain the same from end to end, which is necessary to maintain active sessions for migrated applications.

To identify the location of a network device, LISP separates the identifier of the network device, server or application (known as the EndPoint Identifier) and its location (known as the Locator), once the separation is done, the LISP Mapping System will maintain an association between these two distinct address spaces (End-Point-Identifiers and Locators) The IP address of the identifier is preserved by having it encapsulated into a traditional IP frame for which the destination IP is the location (Locator) of the site where the server or application (EndPoint Identifier) has moved.

A traditional routed network provides reachability to the Locator while the IP address of the EndPoint Identifier can dynamically migrate to a new location without modification of the routing information pertinent to the locator space. Only the information in the LISP Mapping System is updated so the end-point identifier is now mapped to its new locator.

When a VM migrates from one data center to another, the movement is detected in real time and the association between the EndPoint Identifier and the Locator is immediately updated in the RLOC Mapping database. All traffic destined for the VM is dynamically, automatically, and transparently redirected to the new location.

For hybrid clouds, a service provider can move and house the data center of the enterprise without necessarily changing the full address space of network devices and servers.

LISP IP mobility:

With the introduction of LISP, IP based solutions allowing a subnet to be dispersed across any location become a reality. As we move forward, many of the workload mobility requirements may be addressed with a combination of LISP mobility and LAN extensions as outlined in this paper, but there may also be a number of deployments in which the LISP mobility functionality alone may be sufficient to address the workload mobility requirements, eliminating the need for Layer 2 extensions. This works well today for specific scenarios such as disaster recovery and live moves. Just to list few use cases where LISP can be very efficient and help remove the need to extend the Layer 2 between sites:

  • During process of migrating physical servers to a new data center some applications may be difficult to re-address at Layer 3, such as a Mainframe for example. Avoiding IP address renumbering may ease physical migration projects and reduces cost substantially.
  • With hybrid cloud, Enterprise Private/internal cloud resources are moved to a Public/external cloud location. Avoiding IP address renumbering not only ease the migration of the applications from the Enterprise premise equipment, but also reduces the risks and accelerates the deployment of those services. In addition LISP guarantees optimal routing to the active application, regardless of its location, removing the hairpin effect and therefore improving the response time to access the service.

As the technology evolves more and more scenarios will be addressed. In the future, the network architect will have the choice between an L2 and an L3 solution in order to satisfy the DCI requirements that traditionally were focused exclusively on L2 solutions.

Cisco LISP VM-Mobility provides an automated solution to IP mobility with the following characteristics:

  • Guaranteed optimal shortest path routing
  • Support for any combination of IPv4 and IPv6 addressing
  • Transparent to the EndPoints and to the IP core
  • Fine granularity per EndPoint
  • Autonomous system agnostic
This entry was posted in DCI, Path Optimization. Bookmark the permalink.

4 Responses to 20 – Locator/ID Separation Protocol (LISP)

  1. santsboy says:

    Hi,

    if you have 2 ACTIVE/ACTIVE DCs through dark fiber and your WAN is connected to an MPLS cloud where hundreds of offices are also attached, Where would you put the LISP MAP server?

    As far as I understood the LISP MAP server could be a router, so would you configure the LISP MAP Server at the WAN Edge routers of the HQ’s, or at the WAN Edge Routers of the 2 DCs in order to be closer of the VMs?

    Thanks a lot for the help.

    Regards,

    Santsboy

    • Yves says:

      Hi,

      Your understanding is correct and the MS can be configured on any node. I don’t know if there is currently any strong recommendations in term of MS/MR placement (remote branch office, wan edge layer or inside the DC (xTR)). You certainly want to build a redundant configuration on each DC. The trend is to enable the MS/MR function in the xTR located inside each DC to reduce the number of LISP device to manage. However for large-scale LISP deployments, it is certainly preferable to disperse multiple Map-Server and Map-Resolver functions (LISP mapping database) onto different physical nodes at different locations.

      yves

  2. santsboy says:

    Thank you very much for your explanation Yves, much appreciate it.

    Santsboy

  3. Pingback: PETER

Leave a Reply