/
Sign up to Ping Labz!
Already have an account? Sign in
Overlay Networking

LISP Explained: Locator/ID Separation and Why Fabrics Use It

J
7 min read
LISP on Cisco IOS XE: cold-cache ping dropping then resolving via map-reply from the remote RLOC
In: Overlay Networking, Labs

An IP address is doing two jobs at once, and that overload is the root of a surprising number of networking problems. It is an identity ("this is my server") and a location ("here is where it sits in the topology"). When a machine moves (a VM migrates, a site multihomes, a device roams), those two meanings conflict: the identity should stay the same, but the location must change, and IP forwarding cannot tell them apart. LISP fixes this by splitting the two into separate namespaces.

This article explains the Locator/ID Separation Protocol and proves it on a real IOS XE lab, watching the first packets get dropped while the mapping resolves and then flow cleanly. It is the opening piece of the Network Virtualization and Overlays cluster guide.

Two Namespaces: EID and RLOC

LISP defines two separate address spaces where IP has one:

EID (Endpoint Identifier)
The address of an endpoint - a host, a server, a VM. It identifies who, and it does not change when the endpoint moves. Endpoints only ever see EIDs.
RLOC (Routing Locator)
The address of a router that can reach the endpoint. It identifies where, and it is what the core network actually routes on. The core only ever sees RLOCs.

The core network routes on RLOCs and has no idea EIDs exist. The endpoints use EIDs and have no idea RLOCs exist. In between sits a mapping system that answers the question "for this EID, which RLOC do I send to?" That indirection is the whole of LISP, and everything else is machinery to make the mapping fast and reliable.

The analogy that sticks: an EID is like a person's name and an RLOC is like their current street address. You know your friend by name (identity), but to send them mail you need their address (location), and a directory maps one to the other. When they move house, the name is unchanged and only the directory entry updates.

The Router Roles

LISP routers sit at the edge, between the EID world (the sites) and the RLOC world (the core), and they wear a few hats:

ITR (Ingress Tunnel Router)Receives a packet from a local EID, looks up the destination EID's RLOC, and encapsulates the packet toward it.
ETR (Egress Tunnel Router)Receives the encapsulated packet, decapsulates it, and delivers to the local EID. Also registers its EIDs with the mapping system.
xTRA router that is both an ITR and an ETR, which is the normal case. Every site edge is an xTR.
Map-Server (MS)Accepts EID-to-RLOC registrations from ETRs. Holds the mapping database.
Map-Resolver (MR)Answers map-requests from ITRs, returning the RLOC for a queried EID.

The Lab

Three IOS XE routers, and yes, LISP runs fully on this platform (the router lisp configuration mode is complete):

  xTR1 ---- MSMR ---- xTR2
  RLOC      MS+MR     RLOC
  1.1.1.1   2.2.2.2   3.3.3.3
  EID       (mapping  EID
  10.1.1/24  system)  10.3.3/24

xTR1 and xTR2 are site edges, each with a customer EID subnet on a loopback. MSMR is the mapping system (map-server and map-resolver combined, which is common in smaller deployments). OSPF runs in the core purely to give the RLOCs (the loopbacks) reachability to each other; the EID subnets are not in the IGP, which is the point.

The mapping system

MSMR(config)# router lisp
MSMR(config-router-lisp)#  site SITE-1
MSMR(config-router-lisp-site)#   authentication-key PINGLABZ
MSMR(config-router-lisp-site)#   eid-prefix 10.1.1.0/24
MSMR(config-router-lisp)#  site SITE-2
MSMR(config-router-lisp-site)#   authentication-key PINGLABZ
MSMR(config-router-lisp-site)#   eid-prefix 10.3.3.0/24
MSMR(config-router-lisp)#  ipv4 map-server
MSMR(config-router-lisp)#  ipv4 map-resolver

The xTRs

xTR1(config)# router lisp
xTR1(config-router-lisp)#  locator-set MYLOC
xTR1(config-router-lisp-locator-set)#   IPv4-interface Loopback0 priority 1 weight 100
xTR1(config-router-lisp)#  eid-table default instance-id 0
xTR1(config-router-lisp-eid-table)#   database-mapping 10.1.1.0/24 locator-set MYLOC
xTR1(config-router-lisp)#  ipv4 itr map-resolver 2.2.2.2
xTR1(config-router-lisp)#  ipv4 etr map-server 2.2.2.2 key PINGLABZ
xTR1(config-router-lisp)#  ipv4 itr
xTR1(config-router-lisp)#  ipv4 etr

Reading that: the locator-set names this router's RLOC (its Loopback0). The database-mapping declares "I am the ETR for the 10.1.1.0/24 EID subnet, reachable via my RLOC." The map-resolver and map-server lines point at MSMR. The final itr/etr lines turn on both roles. xTR2 is identical with its own EID subnet.

Registration: The ETRs Announce Themselves

As soon as the xTRs come up, each registers its EID prefix with the map-server. The map-server's view:

MSMR#show lisp site
Site Name      Last      Up     Who Last              Inst     EID Prefix
               Register         Registered            ID
SITE-1         00:00:45  yes#   1.1.1.1:54379         0        10.1.1.0/24
SITE-2         00:00:16  yes#   3.3.3.3:24326         0        10.3.3.0/24

Both sites are registered and up. The mapping database now knows that 10.1.1.0/24 lives behind RLOC 1.1.1.1 and 10.3.3.0/24 lives behind RLOC 3.3.3.3. The # flag means the registration used reliable transport (TCP-based), a modern refinement.

This registration is the "moving house updates the directory" step. If a site's EIDs move to a new RLOC, the ETR re-registers and the database updates, with no change to the EIDs themselves and no reconvergence in the core.

The Money Capture: First-Packet Behavior

Here is the single most instructive thing about LISP, and it surprises people the first time. Ping from xTR1's EID to xTR2's EID with a cold map-cache:

xTR1#ping 10.3.3.1 source 10.1.1.1
Sending 5, 100-byte ICMP Echos to 10.3.3.1, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5)

The first two packets are dropped. That is not a fault; it is LISP working. When the ITR receives the first packet for an unknown EID, it has no RLOC to send to, so it drops the packet and fires off a map-request to the map-resolver. While it waits for the reply, subsequent packets are also dropped, until the mapping arrives and gets cached. Then packets three, four, and five sail through.

The map-cache after that first ping tells the story:

xTR1#show lisp instance-id 0 ipv4 map-cache
LISP IPv4 Mapping Cache for LISP 0 EID-table default (IID 0), 2 entries

0.0.0.0/0, uptime: 00:00:50, via static-send-map-request
  Negative cache entry, action: send-map-request
10.3.3.0/24, uptime: 00:00:04, via transient-publication, complete
  Locator   Uptime    State  Pri/Wgt
  3.3.3.3   00:00:04  up       1/100

The 10.3.3.0/24 entry is now cached, pointing at RLOC 3.3.3.3. The 0.0.0.0/0 negative entry is the "anything I do not have a mapping for, send a map-request" default. You can trigger the lookup manually with the LISP Internet Groper, which is the LISP equivalent of a ping-for-mappings:

xTR1#lig 10.3.3.1
Mapping information for EID 10.3.3.1 from 3.3.3.3 with RTT 4 msecs
10.3.3.0/24, uptime: 00:00:00, via map-reply, complete
  Locator   Uptime    State  Pri/Wgt
  3.3.3.3   00:00:00  up       1/100

via map-reply confirms the mapping came from a map-reply, sourced from RLOC 3.3.3.3. And now that the cache is warm, the ping is perfect:

xTR1#ping 10.3.3.1 source 10.1.1.1
!!!!!
Success rate is 100 percent (5/5)

Cold cache, first packets dropped, map resolved, warm cache, clean flow. That cycle is the entire LISP data plane in three commands.

Why This Architecture Matters

The EID/RLOC split buys capabilities that flat IP routing struggles with:

Mobility
An endpoint keeps its EID when it moves. Only the mapping updates. No renumbering, no core reconvergence.
Scalable multihoming
A site registers multiple RLOCs with priorities and weights. Ingress traffic engineering without polluting the global BGP table.
Smaller core tables
The core routes only on RLOCs (a small set), not on every EID prefix. EIDs live in the mapping system, resolved on demand.
The fabric control plane
LISP is the control plane of Cisco SD-Access: it maps endpoints to fabric edge nodes exactly as it maps EIDs to RLOCs here.

That last point is why LISP matters for the CCNP. It is not a niche protocol; it is the mapping system underneath Cisco SD-Access. The fabric edge nodes are xTRs, the control-plane nodes are map-servers/resolvers, and endpoint mobility across the campus is exactly the EID-stays-put, RLOC-changes behaviour demonstrated above, at scale. Understanding LISP here means understanding the fabric later.

FAQ

Why were my first LISP pings dropped?

Expected behaviour. The ITR drops the first packet(s) to an unresolved EID while it sends a map-request and waits for the reply. Once the mapping is cached, traffic flows. Warm the cache with lig if you want the first real packet to succeed.

Does the core need to know about EIDs?

No, and that is the point. The core routes only on RLOCs. EID prefixes are deliberately kept out of the core IGP and live in the mapping system.

Can a site have more than one RLOC?

Yes. A site registers multiple locators with priorities and weights, giving you multihoming and ingress traffic engineering without injecting the site prefix into global BGP.

Is LISP just for SD-Access?

No, but that is its highest-profile use. LISP is a general architecture (RFC 9300/9301) used for mobility, multihoming, and IPv6 transition, as well as being the SD-Access control plane.

What replaces the map when an endpoint moves?

The new ETR registers the EID with the map-server, updating the database. ITRs with a stale cached mapping are corrected via solicit-map-request, so traffic follows the endpoint to its new location.

Key Takeaways

  • An IP address conflates identity and location. LISP splits them into EIDs (endpoints, who) and RLOCs (routers, where).
  • The core routes only on RLOCs; a mapping system (map-server + map-resolver) answers "which RLOC for this EID?" on demand.
  • Roles: ITR encapsulates, ETR decapsulates and registers, xTR is both. LISP runs fully on IOS XE.
  • The lab captured the signature behaviour: first pings dropped (60%) while the map-request resolved, then 100% once cached. lig showed the mapping arriving via map-reply from RLOC 3.3.3.3.
  • The split enables mobility (EID stays, RLOC changes), scalable multihoming, and smaller core tables.
  • LISP is the control plane of Cisco SD-Access. Understanding it here is understanding the fabric later.

Next: VXLAN deep dive (the data-plane encapsulation fabrics pair with LISP or EVPN), or the Network Virtualization cluster guide.

Written by

J

View all posts
More from Ping Labz
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.