LISP Fundamentals

The internet was built on a simple assumption: every device has one IP address, and that address describes both who it is and where it is located.

That assumption worked fine when networks were small and stable.

The Scalability Problem

Today, your enterprise hosts thousands of endpoints spread across branches, data centers, and cloud environments.
When a device moves from one site to another, its IP address changes.
Active sessions drop. Applications reconnect. Users notice.

At the routing level, the problem is just as serious.

Figure 1 — Global BGP Routing Table Overview

Internet routers carry over 900,000 prefixes in their BGP tables today.
Every new site and every mobile endpoint contributes to that growth.
This is not sustainable at scale.

The Root Cause

The root cause is that a single IP address carries two meanings at once:

• Identity — who the device is

• Location — where the device is attached in the network topology

When those two roles are fused into a single address, mobility becomes painful and routing tables become bloated.

Separating Identity from Location

In Figure 2, each LISP site has two clearly distinct elements.

• Your endpoint (PC1 or PC2) carries an Identity.

• Your edge router carries a Location.

The RLOC space in the center only knows about locations, not about individual endpoints.

Figure 2 — Identity Location Separation

LISP was designed to separate identity from location by introducing two distinct address spaces.

LISP (Locator/ID Separation Protocol), defined in RFC 9300, solves the problem by splitting the IP address space into two separate namespaces.

EID — Endpoint Identifier

The first namespace is the EID (Endpoint Identifier).

An EID is the address assigned to your endpoint: a host, a VM, or an entire subnet.
It represents identity. When your laptop moves from Paris to London, its EID does not change.

Figure 3 — Endpoint Identifier Concept

RLOC — Routing Locator

The second namespace is the RLOC (Routing Locator).

An RLOC is the routable IP address of the edge router at a site.
It represents location. When your laptop moves to London, it is now reachable through the London edge router's RLOC.

Figure 4 — Routing Locator Transport Network

Only RLOCs appear in the global routing table.

EIDs are kept entirely out of the routing table.
This is what reduces routing table size: instead of millions of endpoint routes, the network only needs to know the edge router locations.

The Four LISP Roles

You might be wondering how a router finds the RLOC for a given EID if that information is not in the routing table.
LISP answers this with a dedicated control plane built around four functional roles.

ITR and ETR

Figure 5 — LISP Architecture and Roles

• ITR (Ingress Tunnel Router) — the router at the source site. It intercepts traffic destined for an EID, resolves the corresponding RLOC, and encapsulates the packet for transport across the underlay.

• ETR (Egress Tunnel Router) — the router at the destination site. It receives the encapsulated packet, strips the LISP headers, and delivers the original packet to the local EID.

MS and MR

Figure 6 — Map Server Resolver Roles

• Map Server (MS) — the central mapping database. ETRs register their EID-to-RLOC bindings here. It is the authoritative source of truth for endpoint location.

• Map Resolver (MR) — the query handler. When an ITR does not know where an EID is located, it sends a Map-Request to the MR. The MR returns the correct RLOC.

In practice, the MS and MR roles are often hosted on the same device, referred to as the MS/MR.
A router that acts as both ITR and ETR is called an xTR. You will see this term frequently in SD-Access documentation.