Hey Bro, Do you even LISP?

So in the last article, we discussed a bit of why a solution like LISP ( Locator/Identifier Separation Protocol) is required. To summarize, there aren't enough IPv4 addresses to go around and there are too many IPv6 addresses to let them 'roam' using traditional routing methods. Available in IOS (15.1X+) and NX-OS with standards currently being developed within the IETF LISP Working Group, LISP provides a promising solution to mapping IP nodes to locations on the Internet.

If you read the last article, by now some of you are saying, "John, the devices that roam, such as mobile phones, can simply acquire new addresses on the most local network. Why do we need LISP?" It is true this is how we do it now, and it works reasonably well for most users and applications. While it would be nice to seamlessly stream as we move from one network to another, that is more of a luxury feature than a necessity.

The Case for LISP

Let's forget about mobile devices for just a moment and consider virtual machines and cloud computing. Virtual machines (VM) themselves are increasingly mobile. If I want to do maintenance on some bare metal, I can migrate that VM to another node but if my IP address is going to change, this adds a series of complications in updating services and applications such as DNS (Domain Name Service), to point at the correct address. These name to address mappings can be cached causing significant delays between a desired move and an actualized result when the cache finally expires.

With LISP, I don't need to do that. I can migrate my VM to another datacenter and its IP address does not have to change! One of the best small enterprise cases for this is a new feature in Microsoft Windows Server 2012 called "replica servers". (Great detail on the replica feature by Aidan Finn). Replicas allow you to replicate your virtual machines in real time (differentially) to another location for the majority of small or medium enterprise applications.

This is terrific because in a disaster (say a fire axe 'accidentally' falls on the server), you have a current copy of the VM at another location that you can activate immediately. "Great! I'm ready to go, but 'oh no', it's at another location and I need to change my IP addresses." Not with LISP!

In the LISP world, the endpoint (VM for example) and its location is mapped in a registration server that can be queried by the LISP capable routers. Conceptually, it's not unlike ARP requests to map a physical MAC address to an IP address, but a bit more like a DNS service that accepts registrations for mappings of host names to IP addresses.

What this means is that you can activate your IP address at another location and traffic can still find its way to thecorrect physical locationbecause the address and router location can be queried and identified!

The LISP Internet, How does it work?

So how is it done? Why, with acronyms of course! LISP routers change the view from IP address to 'routing locators' (RLOCs) and a mapping of endpoint identifiers (EIDs) that describe the session flow. These are registered with a Map Server or Map Resolver (MR/MS).

Rather than simply looking at the device as an IP address with a MAC hardware address, LISP maps the IP address and location as a combined identity and stores this in a database. That identity represents the address and current location of the address on the network.

An Endpoint Identifier (EID) is combined with a Route Locator ( RLOC ). The EID could move, but the RLOC is tied to the location and will always remain the same. If the EID moves, the mapping between the EID/RLOC changes and is registered with the appropriate server.

By allowing the IP address to be mapped with an identifier (EID) and locator (RLOC), other devices can still reach that device, each with their own EID/RLOC mapping. The connection between them is cached/mapped in the LISP server as an Endpoint ID (EID).

Ow! My Brain!

This mapping relationship is handled by means of a mapping server, not unlike a dynamic DNS registration but perhaps more similar to SIP registration and redirect services. Public Internet transport is achieved by combining this with Ingress and Egress Tunnel Routers (ITR/ETRs). If the tunnel router functions are combined, it is referred to as an xTR as in the diagram.

The Map Server (MS) is for the Egress Tunnel Router (ETR) and the Map Resolver (MR) is for Ingress Tunnel router (ITR).

The MR/MS maps (register/request/reply) queries and does no actual routing of packets, only learning and aggregating of prefixes between other Map Servers to be integrated with BGP allowing for great scale and efficiency of purpose. To think about it another way, compare it to how DNS scales by segmenting by TLD or domain. No single DNS server knows all DNS entries, only what it needs to know or is an authority on.

Before anyone asks, yes unicast reverse path forwarding currently would need to be handled by a proxy server known as the Proxy [Ingress/Egress] Tunnel Router (PITR/PETR or combined as PxTR). While LISP is multi-home capable, it is not clear if Unicast RPF loose mode is supported. (If you know this, let me know!)

Does this even scale?

At first it may seem a bit scary to think about tables that contain that many distinct routes, but remember, this scale already exists in systems like DNS and no server ever needs to know all mappings. Each router only needs to know about which routes they are actively routing and can look up any other mapping from the MR/MS as needed.

LISP requires viewing the Internet from a different perspective, but it's similar to systems we already use. While it feels complex at first glance, it ultimately should reduce network complexity by allowing for a more dynamic network, simplified multi-homing, and better persistence for mobile sessions. I do wish they would decide if the map resolver/map server is a mister or a miz (MR/MS) though (first LISP joke?).

Next Up: How do you get to Carnegie Hall? Location, Location, Location

More Reading:

Locator/ID Separation Protocol Architecture

LISP Technical Page