6.1 LISP Architecture & EID-to-RLOC Mapping Mechanics

6.1 LISP Architecture & EID-to-RLOC Mapping Mechanics

Traditional IP networking overloads the semantics of the IP address. A single IP address simultaneously represents who a host is (its identity) and where it is attached to the network (its topological location). When an endpoint moves between physical subnets, its IP address must change, breaking active TCP sessions. Furthermore, multi-homed enterprise networks inject specific provider-independent (PI) route prefixes into the global Internet routing table, driving exponential growth and high route churn in the Default-Free Zone (DFZ).

The Locator/ID Separation Protocol (LISP) (defined in RFC 6830, RFC 9300, and RFC 9301) resolves these fundamental scalability and mobility constraints by creating two separate, distinct namespaces.

+-----------------------------------------------------------------------------------+
|                    TRADITIONAL IP OVERLOAD VS. LISP SEPARATION                    |
+-----------------------------------------------------------------------------------+
|  TRADITIONAL IP:                                                                  |
|  [ IP Address ] = Identity (Host ID) + Topological Location (Routing Prefix)      |
|  - Moving the host requires changing the IP address, breaking active sessions.    |
|  - Scaling multi-homing injects specific host prefixes into the Internet core.    |
|                                                                                   |
|  LISP ARCHITECTURE:                                                               |
|  [ Endpoint Identifier (EID) ]  = Pure Host Identity (Unchanged during roaming)   |
|  [ Routing Locator (RLOC) ]     = Topological Location (Underlay Core Next-Hop)   |
|  - Hosts keep their EID globally; edge switches update EID-to-RLOC mappings.      |
+-----------------------------------------------------------------------------------+

1. Core LISP Namespaces & Architectural Principles

LISP establishes a clear boundary between edge networks where endpoints reside and the high-speed transit core across which packets are routed.

1. Endpoint Identifiers (EID)

• Definition: An IP address (IPv4 /32 host or /24 subnet, or IPv6 /128 host or /64 prefix) assigned to an end-system device (workstation, server, printer, virtual machine).
• Scope: EIDs operate inside the local site network. They are preserved even when the host roams to a different access switch or data center.
• Routability: EIDs are non-routable across the intermediate underlay transit core. Core routers have zero knowledge of individual EID subnets.

2. Routing Locators (RLOC)

• Definition: An IPv4 or IPv6 address assigned to the core-facing interface of an edge routing device (such as an Ingress/Egress Tunnel Router).
• Scope: RLOCs belong to the topological underlay transport infrastructure (enterprise core, SP MPLS backbone, or the public Internet).
• Routability: RLOCs are globally routable in the underlay network. Core routers switch and route packets based solely on destination RLOC addresses.

Architectural Comparison: EID vs. RLOC

2. LISP Functional Roles & Network Devices

LISP defines specific functional roles that devices assume at the edge of the network and within the mapping system infrastructure.

+-----------------------------------------------------------------------------------+
|                         LISP FABRIC TOPOLOGY & ROLES                              |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|     +------------------+                    +------------------+                  |
|     |  Map-Resolver    |                    |   Map-Server     |  MAPPING         |
|     |      (MR)        |<==================>|      (MS)        |  SYSTEM          |
|     +------------------+                    +------------------+                  |
|              ^                                       ^                            |
|      Map-    |                                       | Map-                       |
|     Request  |                                       | Register                   |
|              v                                       v                            |
|       +------------+     [ Routed Underlay Core ]     +------------+              |
|       |  ITR / xTR |=================================>|  ETR / xTR |              |
|       |  (Site A)  |    (LISP Encapsulated UDP 4341)  |  (Site B)  |              |
|       +------------+                                  +------------+              |
|             |                                                |                    |
|       [ EID: Host A ]                                  [ EID: Host B ]            |
|        (10.1.1.50)                                      (10.2.2.80)               |
+-----------------------------------------------------------------------------------+

LISP Device Roles

1. Ingress Tunnel Router (ITR):

   • Receives native IP packets from local EIDs destined for an external EID.
   • Queries the LISP mapping database (Map-Resolver) to determine the destination EID's current RLOC.
   • Encapsulates the native IP packet inside a LISP outer IP/UDP header (Source IP = local ITR RLOC, Destination IP = remote ETR RLOC) and forwards it across the underlay.

2. Egress Tunnel Router (ETR):

   • Receives LISP-encapsulated packets from the core underlay network.
   • Strips the outer LISP IP/UDP headers to recover the original native IP packet.
   • Forwards the un-encapsulated native packet to the local destination EID.
   • Authoritatively registers its local EID subnets and associated RLOCs with the Map-Server (MS).

3. xTR (Combined ITR + ETR):

   • A single router or multilayer switch executing both ITR and ETR functions simultaneously.
   • This is the standard deployment model on edge switches in enterprise campus fabrics (such as Cisco SD-Access Fabric Edge nodes) and data centers.

4. Map-Server (MS):

   • A network service device (or co-located control plane router) that maintains the authoritative database of EID-to-RLOC mappings.
   • Authenticates and accepts Map-Register messages from authoritative ETRs.
   • When a Map-Request arrives, the MS routes the request toward the authoritative ETR responsible for that EID (or responds directly if configured with proxy-reply).

5. Map-Resolver (MR):

   • Receives Map-Request messages over UDP port 4342 from ITRs seeking destination EID mappings.
   • Consults the mapping infrastructure (such as a local database, LISP-ALT, or LISP-DDT hierarchy) to find the authoritative Map-Server for that target EID and forwards the request.
   • In most enterprise deployments (including Cisco Catalyst Center / SD-Access), the MS and MR are co-located on the same control plane device (MS/MR).

6. Proxy Ingress Tunnel Router (PITR):

   • Acts as a gateway for traffic originating in non-LISP sites (e.g., the public Internet or legacy enterprise core) destined for a LISP site.
   • Advertises coarse aggregate EID prefixes into non-LISP routing protocols (such as BGP).
   • Receives non-LISP packets, performs an EID-to-RLOC lookup via an MR, encapsulates the packets, and transmits them to the destination ETR.

7. Proxy Egress Tunnel Router (PETR):

   • Allows LISP-enabled EIDs to send traffic to non-LISP destinations (such as public web servers).
   • An ITR encapsulates traffic destined for non-LISP addresses toward the PETR's RLOC.
   • The PETR decapsulates the LISP packet and routes native IP packets onto the non-LISP transit network.
   • PxTR: A device combining both PITR and PETR roles for bidirectional non-LISP interworking.

3. LISP Control Plane Messaging & Resolution Workflow

LISP decouples route discovery from packet forwarding. Instead of broadcasting routing updates globally, LISP operates as an on-demand pull model (similar to DNS).

+-----------------------------------------------------------------------------------+
|                         LISP MESSAGE FLOW & REGISTRATION                          |
+-----------------------------------------------------------------------------------+
|                                                                                   |
| 1. REGISTRATION PHASE:                                                            |
|    [ETR-B]  ---( Map-Register [EID 10.2.2.0/24 -> RLOC 192.168.100.2] )---> [MS]   |
|    [MS]     ---( Map-Notify [Authentication & Ack] )----------------------> [ETR-B]|
|                                                                                   |
| 2. RESOLUTION & FORWARDING PHASE:                                                 |
|    [Host-A] ---( Sends Native IP Packet to 10.2.2.80 )--------------------> [ITR-A]|
|    [ITR-A]  ---( Map-Request for 10.2.2.80 )------------------------------> [MR]   |
|    [MR/MS]  ---( Forwards Map-Request )-----------------------------------> [ETR-B]|
|    [ETR-B]  ---( Map-Reply [10.2.2.0/24 at RLOC 192.168.100.2] )----------> [ITR-A]|
|    [ITR-A]  [ Caches mapping in local Map-Cache ]                                 |
|    [ITR-A]  ---( LISP Data UDP 4341 Encapsulated Packet )-----------------> [ETR-B]|
|    [ETR-B]  [ Strips LISP Header ] ---> [ Native IP Packet ] -------------> [Host-B]|
+-----------------------------------------------------------------------------------+

Step-by-Step Resolution Mechanics

1. ETR Registration (Map-Register / Map-Notify):

   • The ETR (Site B) boots and reads its local EID database.
   • It sends a Map-Register packet to the configured Map-Server over UDP port 4342. This message is authenticated using a shared-secret key (HMAC-SHA-1 or HMAC-SHA-256).
   • If the want-map-notify flag is set, the Map-Server responds with a Map-Notify message confirming the registration.

2. Packet Arrival at Ingress Router:

   • Host A (EID 10.1.1.50) generates a packet destined for Host B (EID 10.2.2.80).
   • The packet reaches ITR-A. ITR-A inspects its local Map-Cache (FIB).
   • Because this is the first packet for 10.2.2.80, a cache miss occurs.

3. Map-Request Transmission:

   • ITR-A generates a Map-Request query (UDP port 4342) and sends it to its configured Map-Resolver (MR).
   • The Map-Resolver consults its mapping tables and forwards the Map-Request to the authoritative Map-Server (MS).
   • The MS forwards the Map-Request directly to the authoritative ETR (ETR-B).
   • (Optimization: If the MS is configured with proxy-reply, the MS itself answers the request authoritatively without forwarding it to the ETR).

4. Authoritative Map-Reply:

   • ETR-B generates a Map-Reply message containing the authoritative mapping: EID 10.2.2.0/24 $\to$ RLOC 192.168.100.2.
   • Crucially, ETR-B sends this Map-Reply directly back to ITR-A's RLOC via unicast over UDP port 4342.

5. Map-Cache Installation & Data Plane Forwarding:

   • ITR-A installs the mapping entry into its hardware Map-Cache with the returned Time-to-Live (TTL, default: 1440 minutes / 24 hours).
   • ITR-A encapsulates buffered and subsequent data packets inside outer LISP/UDP headers (Dest IP: 192.168.100.2, Dest UDP: 4341) and transmits them across the core at line rate.

Map-Reply Policy Attributes: Priority and Weight

When an ETR registers multiple RLOCs for redundancy and multihoming, it assigns Priority and Weight values in the Map-Reply:

• Priority (0 to 255): Determines active/standby path selection. The RLOC with the lowest priority integer is preferred (Priority 1 is preferred over Priority 20).
• Weight (0 to 100): Determines traffic load balancing across multiple active RLOCs that share the same priority value. The weight represents the relative percentage of traffic directed to that locator.

! Example Map-Reply Record with Multi-RLOC Redundancy:
EID Prefix: 10.2.2.0/24, TTL: 1440 min
  -> Locator: 192.168.100.2, Priority: 10, Weight: 70  (Active Link 1 - 70% traffic)
  -> Locator: 192.168.200.2, Priority: 10, Weight: 30  (Active Link 2 - 30% traffic)
  -> Locator: 192.168.300.2, Priority: 20, Weight: 0   (Standby Backup Link)

4. LISP Data Plane Packet Encapsulation & Header Format

Once control-plane resolution completes, user payload traffic is encapsulated using LISP Data Encapsulation.

+-----------------------------------------------------------------------------------+
|                         LISP DATA PACKET ENCAPSULATION                            |
+-----------------------------------------------------------------------------------+
| Outer IP Header:   Source IP = Ingress RLOC (ITR)                                 |
|                    Destination IP = Egress RLOC (ETR)                             |
|                    Protocol = 17 (UDP)                                            |
+-----------------------------------------------------------------------------------+
| Outer UDP Header:  Source Port = Dynamic 5-Tuple Hash (for Underlay ECMP)         |
|                    Destination Port = 4341 (LISP Data Channel)                    |
+-----------------------------------------------------------------------------------+
| LISP Header (8B):  [N|L|E|V|I|flags] [ 24-bit Nonce / Map-Version ]               |
|                    [ 24-bit Instance ID (VNID/VRF) ] [ 8-bit Reserved ]           |
+-----------------------------------------------------------------------------------+
| Inner IP Packet:   Source IP = Source EID (Host A: 10.1.1.50)                     |
|                    Destination IP = Destination EID (Host B: 10.2.2.80)           |
|                    Payload = TCP / UDP / ICMP User Data                           |
+-----------------------------------------------------------------------------------+

Detailed LISP Header Field Breakdown (8 Bytes)

1. N-bit (Nonce Present): Set to 1 when a 24-bit random security nonce is included in the header to protect against blind spoofing attacks.
2. L-bit (Locator-Reachability Bits Enabled): Set to 1 when the 8-bit locator status bits are active, allowing routers to signal RLOC up/down reachability directly in data packets.
3. E-bit (Echo-Nonce Request): Used by an ITR to request that the remote ETR echo back the transmitted nonce, verifying bidirectional data-path reachability.
4. V-bit (Map-Version Present): Set to 1 when mapping versioning is enabled to signal that map-cache synchronization is active.
5. I-bit (Instance ID Present): Set to 1 when a 24-bit Instance ID is included in the header.
6. Instance ID (24 bits): Extends LISP to support network virtualization, multi-tenancy, and VRF segmentation. It conveys the virtual network identifier (equivalent to a VRF or VNID) across the shared underlay.

Port Differentiation Summary

5. Host Mobility & Solicit-Map-Request (SMR)

In modern software-defined enterprise fabrics (such as Cisco SD-Access), wireless access points and wired endpoints roam across physical switches while preserving their original /32 IP address (EID). LISP provides seamless Host Mobility without requiring hairpinned routing.

+-----------------------------------------------------------------------------------+
|                         LISP HOST MOBILITY & SMR WORKFLOW                         |
+-----------------------------------------------------------------------------------+
|                                                                                   |
| 1. Endpoint (EID 10.1.1.50) roams from Switch-1 (RLOC-1) to Switch-2 (RLOC-2).   |
| 2. Switch-2 detects host (via ARP / 802.1X / DHCP) and creates dynamic EID entry. |
| 3. Switch-2 sends Map-Register for EID 10.1.1.50/32 -> RLOC-2 to Map-Server.      |
| 4. Map-Server updates mapping database and notifies Switch-1.                     |
| 5. Switch-1 sends Solicit-Map-Request (SMR) to active remote ITRs (ITR-X).        |
| 6. ITR-X invalidates local Map-Cache for 10.1.1.50.                               |
| 7. ITR-X sends new Map-Request to MR -> receives Map-Reply with RLOC-2.           |
| 8. Traffic flows directly to Switch-2 without hairpins or dropped TCP sessions.   |
+-----------------------------------------------------------------------------------+

Solicit-Map-Request (SMR) Mechanics

• When an endpoint moves, remote ITRs that are actively communicating with that endpoint still hold stale map-cache entries pointing to the old RLOC.
• The old xTR (or the new xTR) issues a Solicit-Map-Request (SMR) control packet (UDP 4342) directly to all ITRs that recently sent traffic to that EID.
• Upon receiving an SMR, the ITR immediately invalidates its cached mapping, drops back to the control plane, issues a fresh Map-Request, and receives the updated RLOC from the Map-Server. Data plane traffic shifts to the new topological location within milliseconds.

6. Cisco IOS-XE LISP Configuration & Verification

1. Map-Server / Map-Resolver (MS/MR) Configuration

! Configure the Control Plane Map-Server / Map-Resolver
Router-MSMR(config)# router lisp
Router-MSMR(config-router-lisp)# ipv4 map-server
Router-MSMR(config-router-lisp)# ipv4 map-resolver

! Define authorized enterprise site and authentication key
Router-MSMR(config-router-lisp)# site CAMPUS-BRANCH-A
Router-MSMR(config-router-lisp-site)# authentication-key CiscoEnc0rKey#1
Router-MSMR(config-router-lisp-site)# eid-prefix 10.1.1.0/24 accept-more-specifics
Router-MSMR(config-router-lisp-site)# exit

Router-MSMR(config-router-lisp)# site CAMPUS-BRANCH-B
Router-MSMR(config-router-lisp-site)# authentication-key CiscoEnc0rKey#2
Router-MSMR(config-router-lisp-site)# eid-prefix 10.2.2.0/24 accept-more-specifics
Router-MSMR(config-router-lisp-site)# exit

2. Edge Device (xTR) Configuration

! Configure the Edge Device (xTR) at Site A
xTR-SiteA(config)# router lisp
! Define EID-to-RLOC database mapping for local subnet
xTR-SiteA(config-router-lisp)# database-mapping 10.1.1.0/24 192.168.100.1 priority 1 weight 100

! Specify Map-Server and Map-Resolver destinations
xTR-SiteA(config-router-lisp)# ipv4 map-resolver 192.168.100.250
xTR-SiteA(config-router-lisp)# ipv4 map-server 192.168.100.250 key CiscoEnc0rKey#1

! Configure source interface for LISP control plane packets
xTR-SiteA(config-router-lisp)# ipv4 map-request-source Loopback0
xTR-SiteA(config-router-lisp)# exit

3. Verification & Troubleshooting Commands

! Verify the local EID database on the xTR
xTR-SiteA# show ip lisp database
LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x1
Entries total 1, no-route 0, inactive 0, do-not-register 0

EID-prefix: 10.1.1.0/24
  Locator: 192.168.100.1, priority: 1, weight: 100, state: up, status: registered

! Inspect the resolved Map-Cache on the ITR
xTR-SiteA# show ip lisp map-cache
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

0.0.0.0/0, uptime: 2d14h, expires: never, via default-send-map-request
  Negative cache entry, action: send-map-request
10.2.2.0/24, uptime: 00:14:32, expires: 23:45:28, via map-reply, complete
  Locator: 192.168.100.2, priority: 1, weight: 100, state: up

! Verify site registration status on the Map-Server
Router-MSMR# show ip lisp site
LISP Site Registration Information
* = configured site
Site Name      Last Register       Up   Who Last Registered      EID Inst ID   EID Prefix
*CAMPUS-A      00:00:14            yes  192.168.100.1:4342                     10.1.1.0/24
*CAMPUS-B      00:00:22            yes  192.168.100.2:4342                     10.2.2.0/24