LISP Tutorial

In the Internet nowadays, the IPv4 or IPv6 address of a device represents both its identity and location. When a host moves from one location to another location, it is assigned a different IPv4 or IPv6 address, which overloads the location/identity semantic. We can say routing in the Internet today is like putting direction signs about every city in the world at every crossing.

Locator ID Separation Protocol (LISP) solves this issue by separating the location and identity of a device through the Routing locator (RLOC) and Endpoint identifier (EID):

+ Endpoint identifiers (EIDs) – assigned to end hosts.
+ Routing locators (RLOCs) – assigned to devices (primarily routers) that make up the global routing system.

With LISP, the change in location of a device does not result in a change in its identity. In other words, when the device moves from one location to another, it still keeps its IPv4 or IPv6 address, which is the EID part. Only the RLOC (which represents the IP address of the connected router) changes. In order to do so, LISP provides the distributed architecture EID-to-RLOC mapping that maps EIDs to RLOCs.

Splitting ID and RLOC functions yields several advantages including improved routing system scalability, and improved multihoming efficiency and ingress traffic engineering.

LISP traffic flow example

Let’s see an example of how PC1 sends traffic to PC2 in a LISP-capable environment to understand more about LISP.

1. PC1 wants to send traffic to PC2. PC1 sends packets to its default gateway R1. Notice that PC1 does not know anything about LISP.
2. R1 has not had information about EID 5.5.5.5 in its Map cache so it queries R3, which is a LISP MS/MR (will be explained later).
3. R3 replies the RLOC of EID 5.5.5.5 to R1. R1 will store this mapping in its Map cache for later use.
4. R1 forwards packets to this RLOC, which is R2.
5. R2 removes RLOC information, and forwards packets to the destination. Notice that PC2 does not know anything about LISP.

In the example above, R1 works as an Ingress Tunnel Router (requesting LISP information) while R2 works as an Egress Tunnel Router (registering LISP information).

Ingress Tunnel Router (ITR) is the device (or function) that is responsible for finding EID-to-RLOC mappings for all traffic destined for LISP-capable sites. After the encapsulation, the original packet become a LISP packet.

Egress Tunnel Router (ETR) is the device (or function) that connects a site to the LISP-capable part of a core network (such as the Internet), publishes EID-to-RLOC mappings for the site, responds to Map-Request messages, and decapsulates and delivers LISP-encapsulated user data to end systems at the site. During operation, an ETR sends periodic Map-Register messages to all its configured map servers.

Do you remember in the above figure, R3 already learned EID 5.5.5.5 in RLOC 20.20.20.1. But how did it know? Well, when R2 was configured with the mapping, it sent a “Map Register” message to R3 to inform about it.

R3 worked as a Map Server (MS) and used this information to populate its EID to RLOC mapping table and replied back with a “Map Notify” message to confirm it received the registration.

And when R1 asks information to reach R2, R3 works as a Map-resolver (MR) to receive and process the EID-to-RLOC mapping lookup queries and provides the mappings to requester.

MS & MR functions are often included in a single device, which is referred to as an MR/MS device.

If MS and MR are two separate devices, MR is responsible to forward the Map-Request messages to the correct MS.

ITR and ETR are often included in a single device and it is called a xTR device. xTR is usually implemented in a LISP site’s customer premises equipment (CPE) router.

So now let’s see the topology above again with all the LISP devices:

 

So far we have established communication between LISP sites registered in the mapping system. But how can we interoperate between LISP regions and non-LISP regions as sites are not capable of running LISP in one day? This is where Proxy Ingress Tunnel Router and Proxy Egress Tunnel Router come into play.

Proxy Ingress Tunnel Router (PITR): A LISP device that receives packets from non-LISP sites and encapsulates the packets to LISP sites.

PITRs perform two primary functions:
+ Originating EID advertisements: PITRs advertise highly aggregated EID-prefix space on behalf of LISP sites to the non-LISP sites so that non-LISP sites can reach them.
+ Encapsulating legacy Internet traffic: PITRs encapsulate non-LISP Internet traffic into LISP packets and route them toward their destination RLOCs.

Proxy Egress Tunnel Router (PETR): A LISP device that de-encapsulates packets from LISP sites to deliver them to non-LISP sites.

PETRs are useful in the following cases:
+ Avoiding strict uRPF failures: Some providers’ access networks require the source of a packet to be within the address scope of the access networks. PETRs allow for LISP sites to send packets to non-LISP sites in cases where the access network does not allow for the LISP site to send packets with the source address of the site’s EIDs.
+ Traversing a different IP protocol: The transit path network between LISP sites and non-LISP sites may not be IPv4 or IPv6 enabled. LISP support for mixed protocol encapsulation allows PETRs to hop over such networks in order to route the traffic between the LISP and non-LISP sites.

Like ITR and ETR, PITR and PETR are usually included in one device, which is called PxTR.

Reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_lisp/configuration/15-mt/irl-15-mt-book/irl-overview.pdf

and https://www.ciscopress.com/articles/article.asp?p=2992605