Cisco Locator ID Separation Protocol (LISP)

Cisco Locator ID Separation Protocol (LISP) is a mapping and encapsulation protocol, originally developed to address the routing scalability issues on the Internet.

Internet routing tables have grown exponentially, putting a burden on BGP routers. Routing on the Internet is meant to be hierarchical, but because of disaggregation, a full Internet routing table nowadays contains over 800.000 prefixes.

Disaggregation is the opposite of aggregation (route summarization). We inject more specific routes when there is an aggregate (summary route). There are two main reasons why this happens:

• Multihoming: Customers connect to two different ISPs and advertise their provider-independent address space (PI) to both ISPs.
• Traffic engineering: A common practice for ingress traffic engineering is to advertise a more specific route. This works, but it increases the size of the Internet routing table.

You need powerful routers with enough RAM and TCAM to store all prefixes in the Internet routing table. Injecting more specific prefixes also increases the risk of route instability. We need routers with powerful CPUs to process changes in the routing table.

With traditional IP routing, an IP address has two functions:

• Identity: To identify the device.
• Location: The location of the device in the network; we use this for routing.

LISP separates these two functions of an IP address into two separate functions:

• Endpoint Identifier (EID): Assigned to hosts like computers, laptops, printers, etc.
• Routing Locators (RLOC): Assigned to routers. We use the RLOC address to reach EIDs.

Cisco created LISP, but it’s not a proprietary solution, it’s an open standard, defined in RFC 6830. Originally it was designed for the Internet, but nowadays, you also see LISP in other environments like data centers, IoT, WAN, and the campus (Cisco SD-Access).

In this lesson, you will learn about the different LISP components and how it operates.

LISP Overview

LISP is a map and encapsulation protocol. There are three essential environments in a LISP environment:

• LISP sites: This is the EID namespace, where EIDs are.
• non-LISP sites: This is the RLOC namespace where we find RLOCs. For example, the Internet.
• LISP mapping service: This is the infrastructure that takes care of EID-to-RLOC mappings.

Here is a high-level simplified overview of how LISP works:

Let me explain what you see above:

• We have two LISP sites, site 1 and site 2.
  • In each site, there is a host and a router configured to use LISP.
    • The hosts have an EID address:
      • H1 EID 192.168.1.101
      • H2 EID 192.168.2.102.
    • The routers have an RLOC address:
      • R1 RLOC 192.168.123.1
      • R2 RLOC 192.168.123.2
• The RLOC space is a non-LISP area. For example, the Internet.

When H1 wants to send an IP packet to H2, here’s what happens:

1. H1 doesn’t have anything to do with LISP and sends an IP packet to its default gateway (R1).
2. R1 receives the IP packet and asks the LISP mapping system where it can find EID 192.168.2.102.
3. The mapping system replies with an EID-to-RLOC mapping.
4. R1 now knows that it can reach EID 192.168.2.102 through RLOC 192.168.123.2. The router encapsulates the IP packet with LISP encapsulation and transmits the packet.
5. R2 receives the LISP encapsulated IP packet, de-encapsulates it, and forwards the original IP packet to H2.

A very simplified one-sentence explanation is that LISP is a tunneling protocol that uses a DNS-like system to figure out to which router they should send IP packets.

The LISP routers that encapsulate and de-encapsulate have a name:

• Ingress Tunnel Router (ITR): Router, which encapsulates IP packets.
• Egress Tunnel Router (ETR): Router, which de-encapsulates LISP encapsulated IP packets.
• Tunnel Router (xTR): Router which performs both the ITR and ETR functions.

I added the ITR and ETR functions in the picture below:

Keep in mind that the hosts (computers, laptops, printers)  don’t know anything about LISP.

• From the LISP router’s perspective: Every endpoint (host) has an EID.
• From the host’s perspective: It has a regular IP address. The host doesn’t even know what LISP is.

Now you know the basics of LISP, let’s add some more detail to this story.

LISP Control Plane

The LISP control plane is similar to how DNS works:

• DNS resolves a hostname to an IP address.
• LISP resolves an EID to an RLOC.

With traditional IP routing, we install prefixes in the routing table. LISP doesn’t install EID-prefixes in the routing table. Instead, LISP uses a distributed mapping system where we map EIDs to RLOCs. We store these mappings in a distributed EID-to-RLOC database. When an ITR needs to find an RLOC address, it sends a Map-Request query to the mapping system.

LISP Data Plane

Once an ITR has figured out which RLOC to use to reach an EID, it encapsulates the IP packet. Let’s take a closer look at how LISP encapsulates IP packets:

Let me walk you through the main headers. When the ITR receives the IP packet from a host, it adds the following headers:

• LISP Header: This header includes some LISP information needed to forward the packet. I won’t cover every bit and field here, but the instance ID is worth mentioning. The instance ID is a 24-bit value that has a similar function as the Route Distinguisher (RD) in MPLS VPN. The instance ID is a unique identifier, which keeps prefixes apart when you have overlapping (private) EID addresses in your LISP sites.
• Outer LISP UDP header: The source port is selected by the ITR to prevent traffic from one LISP site to another LISP site to take the same path if you have equal-cost multipath (ECMP) links to the destination. Different source ports prevent polarization. The destination port is 4341.
• Outer LISP IP header: Contains the source and destination RLOC IP addresses needed to route the packet from the ITR to ETR.

Although the instance ID makes prefixes unique, you need VRFs to implement virtualization. LISP supports this by binding the instance ID to VRFs and EID VRFs./box]

EIDs and RLOCs can be IPv4 or IPv6 addresses, so the LISP data-plane supports any of the following encapsulation combinations:

• IPv4 RLOCs with IPv4 EIDs.
• IPv4 RLOCs with IPv6 EIDs.
• IPv6 RLOCs with IPv6 EIDs.
• IPv6 RLOCs with IPv4 EIDs.

For a detailed explanation of all fields in the LISP header, check out RFC 6830.

LISP Operation

You now know what LISP RLOCs and EIDs are, what an ITR and ETR do, and that LISP uses a mapping system for the control plane and how LISP encapsulates IP packets on the data plane.

Let’s dive even deeper and look at the exact steps of how the LISP mapping system works.

Mapping System

Map-Register and Map-Notify

When you configure an ETR, the router registers the EID-prefixes with the device that is responsible for keeping track of EID-to-RLOC mappings; the Map-Server (MS).

Here is an illustration of the registration process:

The ETR sends a Map-Register message to the MS which contains:

• EID-prefix: 192.168.2.0/24.
• RLOC address: 192.168.123.2.
• UDP source port: Chosen by the ETR.
• UDP destination port: 4342.

The MS sends a reply called the Map-Notify to the ETR and confirms that it received and processed the Map-Register message. The Map-Notify message uses UDP source and destination port 4342.

Map-Request and Map-Reply

ITRs use Map-Request messages to request an EID-to-RLOC mapping. The Map-Reply provides the mapping.

Two functions provide a role here:

• MS
• MR (Map-Resolver)

We talked about the MS before. It’s the device where ETRs register their EID-prefixes and which stores EID-to-RLOC mappings.

When the ITR needs an EID-to-RLOC mapping, it sends a Map-Request to the MR.

When the MR receives a Map-Request, and it has an entry in its local database, then the MR responds with a Map-Reply. When it doesn’t have an entry, then the MR forwards the Map-Request to an MS. The MS forwards the Map-Request to the ETR, which answers the Map-Request with a Map-Reply directly.

In smaller environments, we combine the MR and MS functions into a single router. We call this an MR/MS. Here is an illustration of this process:

Let me walk you through this process:

Step 1

Within a LISP site, we use traditional routing. Let’s say H1 in LISP site 1 wants to communicate with H2 in LISP site 2. These hosts don’t know anything about LISP. If you had multiple routers in between H1 and the ITR, they would use regular IP routing to reach the ITR.

Step 2

The ITR receives the IP packet from H1 with destination 192.168.2.102. It does a lookup in its FIB table and asks itself the following questions:

• Is there an entry that matches 192.168.2.102? If so:
  • Use regular IP routing.
  • If not, we use LISP encapsulation if any of the following three checks is true:
    • We have a default route.
    • We don’t have a route
    • We have a route with Null0 as the next-hop.
• Is the source IP a registered EID-prefix in the local map-cache?
  • If not, forward the packet with regular IP routing.
  • If so, the ITR:
    • Selects a UDP source port.
    • Sets the UDP destination port to 4342.
    • Sends an encapsulated Map-Request to the MR for 192.168.2.102.

Step 3

The MR and MS functions are on the same device. When the MR/MS receives the Map-Request, it forwards it to the ETR, which registered the EID-prefix.

Step 4

When the ETR receives the Map-Request, it creates and transmits a Map-Reply which includes:

• EID-to-RLOC mapping:
  • EID: 192.168.2.0/24
  • RLOC: 192.168.123.2
• UDP source port 4342.
• UDP destination port is the one that the ITR selected as the UDP source port for the Map-Request.

The ETR sends the Map-Reply directly to the ITR. However, it’s also possible that the ETR requests the MS to answer the Map-Request on its behalf.

To do this, the ETR has to enable the “proxy Map-Reply” flag (P-bit) in the Map-Register message.

The ITR receives the Map-Reply from the ETR (or the MS if the ETR requested a proxy Map-Reply) and installs the EID-to-RLOC mapping in its local map-cache. The ITR also programs its FIB and is now ready to forward LISP encapsulated traffic.

LISP Data Path

Let’s see what it looks like when the ITR encapsulates the IP packet from H1 with LISP. Here is an overview:

Let me explain the steps: