SD-Access under the hood; Locator/ID Separation Protocol (LISP)

SD-Access under the hood; Locator/ID Separation Protocol (LISP)

When it comes to Cisco’s software-defined access (SD-Access), one of the key technologies working behind the scenes is Locator/ID Separation Protocol (LISP). At first glance, LISP might seem like just another routing protocol, but it plays a much bigger role. It fundamentally changes how network addressing works by decoupling identity from location. This separation is especially important in SD-Access environments, where flexibility, scalability, and mobility are critical.

In this article, I will break down the funadementals of LISP, the core components that make up its architecture, and how it fits into the SD-Access framework. Whether you’re managing campus networks or diving into next-gen network design, understanding LISP is essential to grasp how SD-Access delivers secure, automated, and policy-driven access.

LISP Fundamentals

Logical View;

Phyical view;

LISP, as defined in RFC6830, is a routing and addressing architecture for IP networks. It was built to address key challenges such as routing scalability, multihoming, traffic engineering across sites, and mobility.

  Creation of LISP was initially motivated by discussions during the
   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
   October 2006 (see [RFC4984]).  A key conclusion of the workshop was
   that the Internet routing and addressing system was not scaling well
   in the face of the explosive growth of new sites; one reason for this
   poor scaling is the increasing number of multihomed sites and other
   sites that cannot be addressed as part of topology-based or provider-
   based aggregated prefixes.  Additional work that more completely
   describes the problem statement may be found in [RADIR].
https://datatracker.ietf.org/doc/html/rfc6830

Given the depth of LISP, this post will focus on a high-level summary of its core components.

Today’s IP addressing system ties together two things: where a device is (its location in the network) and what it is (its identity). This is true whether it’s a 32-bit IPv4 or a 128-bit IPv6 address. LISP changes that. Its core idea is to separate identity from location.

With LISP, a device’s identity stays the same even if its location changes. In other words, “who you are” (your identifier) doesn’t change, even when “where you are” (your locator) does.

LISP achieves this by dividing addresses into two roles:

• Endpoint Identifiers (EIDs): These represent the identity of the device.
• Routing Locators (RLOCs): These describe the device’s position in the network topology.

To understand how LISP separates identity from location, it’s important to know the main components that make the architecture work. Each plays a specific role in how traffic is routed across LISP and non-LISP environments;

• Tunnel Routers
• Proxy Tunnel Routers
• Map Server
• Map Resolver

Tunnel Routers

Ingress Tunnel Router (ITR)

The ITR sits at the edge of a LISP site and handles outbound traffic. It takes packets from local devices, looks up where the destination EID lives, and encapsulates the traffic with the correct routing locator (RLOC). If the destination is a non-LISP site, it forwards the packets natively without encapsulation.

Egress Tunnel Router (ETR)

The ETR does the opposite. It receives incoming encapsulated packets from other LISP sites, strips the outer header, and forwards the original packet to the correct local endpoint.

Tunnel Routers Configuration

SITE01: 

router lisp
 site 01
  eid-prefix 10.0.1.0/24 accept-more-specifics
  exit
 !
 database-mapping 10.0.1.0/24 100.64.10.1 priority 1 weight 50
 ipv4 itr map-resolver 100.100.100.100
 ipv4 itr
 ipv4 etr map-server 100.100.100.100 key LISPPASSWORD
 ipv4 etr
 exit
 
Site01#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         100.64.10.1     YES manual up                    up
GigabitEthernet0/1         unassigned      YES unset  administratively down down
GigabitEthernet0/2         unassigned      YES unset  administratively down down
GigabitEthernet0/3         10.0.1.1        YES manual up                    up
LISP0                      10.0.1.1        YES unset  up                    up
Loopback0                  1.1.1.1         YES manual up                    up

SITE02: 

router lisp
 site 02
  eid-prefix 10.0.2.0/24 accept-more-specifics
  exit
 !
 database-mapping 10.0.2.0/24 100.64.20.1 priority 1 weight 50
 ipv4 itr map-resolver 100.100.100.100
 ipv4 itr
 ipv4 etr map-server 100.100.100.100 key LISPPASSWORD
 ipv4 etr
 exit

 
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down
GigabitEthernet0/1         100.64.20.1     YES manual up                    up
GigabitEthernet0/2         unassigned      YES unset  administratively down down
GigabitEthernet0/3         10.0.2.1        YES manual up                    up
LISP0                      10.0.2.1        YES unset  up                    up
Loopback0                  2.2.2.2         YES manual up                    up

LISP Inter-site communication

When I ping from LISP SITE01 to LISP SITE02, the IP packet is encapsulated using LISP tunneling. This encapsulation allows the original packet, with the source and destination EIDs, to be carried across the underlying IP network using RLOCs. The expected structure of the LISP-encapsulated packet includes an outer IP header with the source RLOC of SITE01 and the destination RLOC of SITE02, followed by a UDP header (typically using port 4341), the LISP header, and finally the original inner IP packet containing the source EID from SITE01 and the destination EID from SITE02.

LISP IPv4-in-IPv4 Header 

In the LISP IPv4-in-IPv4 encapsulation format, both the Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) use IPv4 addresses. The encapsulated packet includes an outer IPv4 header for RLOC-to-RLOC transport and an inner IPv4 header for EID-to-EID communication. The header structure for this type of encapsulation is defined in RFC 6830

LISP Packet Capture

In a packet capture of LISP-encapsulated traffic between two LISP sites, you can clearly see the layered structure of the encapsulated packet, including the LISP header, which plays a critical role in identifying and handling the tunneled traffic.

The packet begins with an outer IP header, where the source and destination IPs are the RLOCs (Routing Locators) of the ingress and egress LISP routers. This is followed by a UDP header, with source and destination ports typically set to 4341 (LISP data port). Directly after the UDP header is the LISP header, a small but crucial section that adds metadata for the LISP tunneling process.

The LISP header is 8 bytes long and contains several key fields:

• N bit (Nonce Present): Indicates if a nonce is included for loop detection.
• L bit (Locator-Status-Bits Present): Shows whether locator status bits are present.
• E bit (Echo-Nonce-Request) and V bit (Echo-Nonce-Reply): Used for control and diagnostics.
• Instance ID field (last 24 bits): Identifies the LISP instance (similar to VRF or VNID) the packet belongs to—this is important in SD-Access for enforcing segmentation.

Following the LISP header is the original inner IP packet, with the EID-to-EID communication between the endpoints. This structure allows routers to forward traffic based on RLOCs while preserving the endpoint identities inside the encapsulated payload.

In Wireshark or other packet analysis tools, the LISP header will appear as part of a UDP datagram and is typically decoded with these fields exposed, making it easy to verify correct encapsulation and routing behavior across the LISP fabric.

Proxy Tunnel Routers

Proxy Tunnel Routers make LISP interoperable with the rest of the network. They prevent the need for every site to be LISP-aware while still gaining the benefits of LISP (like scalable routing and mobility) within the LISP domain.

Proxy Ingress Tunnel Router (PITR)

The PITR is a bridge for non-LISP sites. It accepts packets from outside the LISP domain, encapsulates them, and sends them into the LISP network when needed—or forwards them natively when not.

Proxy Egress Tunnel Router (PETR)

A PETR handles traffic flowing out of the LISP domain to destinations that don’t support LISP. It decapsulates packets from LISP sites and forwards them to non-LISP sites.

LISP Mapping (EID-to-RLOC)

Map Server (MS)

The Map Server is where LISP sites register their EID-to-RLOC mappings. Egress Tunnel Routers (ETRs) register their EID-to-RLOC mappings with the MS. The MS stores this mapping information and ensures only authorized devices can register, enforcing policy and security.

Map Resolver (MR)

The Map Resolver is the lookup engine for Ingress Tunnel Routers (ITRs). When an ITR needs to send traffic to a destination EID, it queries the MR to find the associated RLOC. The MR forwards this request through the mapping system (like LISP-DDT or ALT) and returns the correct mapping.

LISP in SD-Access

At the heart of the SD-Access architecture lies LISP which functions as the control plane. It plays a foundational role in how SD-Access handles routing, mobility, and segmentation. Understanding how LISP fits into SD-Access means breaking down the protocol’s core components and seeing how each is used in the fabric infrastructure.

SD-Access uses LISP differently from generic deployments. The roles of LISP components are embedded within fabric nodes that each have a specific purpose. In this diagram I have placed the LISP components in an SD-Access topology;

Edge Node (ITR/ETR)

An edge node in SD-Access is the primary point where endpoints—such as user devices, printers, or IoT equipment—connect to the fabric. It plays a critical role in identifying and authenticating these endpoints, assigning them to the correct virtual network or segment, and enforcing policies defined by the network controller. The edge node tags the traffic with relevant information (such as SGTs and VNIs) and ensures that all communication within the fabric adheres to the defined security and segmentation rules.

In terms of LISP functionality, the edge node operates as both an Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR). As an ITR, it encapsulates packets from locally attached endpoints using their Endpoint Identifier (EID) and forwards them toward the appropriate Routing Locator (RLOC) destinations within or outside the fabric. As an ETR, it receives LISP-encapsulated traffic from other nodes, decapsulates it, and delivers it to the intended EID inside its local domain. The edge node is also the point where EIDs are registered into the LISP mapping system, effectively linking endpoint identity with location and enabling seamless mobility and policy enforcement across the SD-Access fabric. 

Border Node (PETR/PITR)

A border node in SD-Access is the connection point between the fabric and external networks such as the internet, data centers, or legacy infrastructure. Its primary role is to route traffic in and out of the fabric while preserving the segmentation and policy enforcement defined within the SD-Access domain. It also handles translation between fabric encapsulated traffic (VXLAN with LISP control plane) and traditional IP routing used outside the fabric, ensuring secure and policy-compliant communication between internal endpoints and external destinations.

In terms of LISP functionality, the border node acts as a Proxy Ingress Tunnel Router (PITR) and Proxy Egress Tunnel Router (PETR). As a PITR, it receives traffic from non-LISP-aware external sources and encapsulates it with LISP headers to forward it into the fabric, ensuring it reaches the correct Endpoint Identifier (EID). As a PETR, it receives LISP-encapsulated traffic from within the fabric and decapsulates it before routing it toward external, non-LISP destinations. This proxy functionality allows seamless interoperability between LISP-enabled fabric networks and traditional IP networks without requiring LISP support on external devices.

Control Plane Node (MS/MR)

A control plane node in SD-Access is responsible for maintaining the fabric’s centralized endpoint-to-location mapping database. It plays a critical role in enabling dynamic discovery and mobility by tracking where each endpoint (identified by its Endpoint Identifier, or EID) is connected within the fabric. Unlike traditional networks where forwarding and control are tightly coupled, SD-Access separates these functions, allowing the control plane node to manage intelligence and mapping while data plane nodes handle traffic forwarding.

The control plane node fulfills the function of the LISP Map Resolver (MR) and Map Server (MS). As a Map Server, it receives EID-to-RLOC registration updates from Egress Tunnel Routers (typically edge nodes) and stores them in its mapping database. As a Map Resolver, it responds to Ingress Tunnel Routers (ITRs) when they query for the RLOC associated with a given EID, allowing proper packet forwarding within the fabric. This LISP-based mapping system is essential for enabling fabric-wide endpoint mobility, policy consistency, and scalable traffic management.

LISP Troubleshooting

Site01#sh ip lisp
  Instance ID:                      0
  Router-lisp ID:                   0
  Locator table:                    default
  EID table:                        default
  Ingress Tunnel Router (ITR):      enabled
  Egress Tunnel Router (ETR):       enabled
  Proxy-ITR Router (PITR):          disabled
  Proxy-ETR Router (PETR):          disabled
  NAT-traversal Router (NAT-RTR):   disabled
  Mobility First-Hop Router:        disabled
  Map Server (MS):                  disabled
  Map Resolver (MR):                disabled
  Delegated Database Tree (DDT):    disabled
  Map-Request source:               derived from EID destination
  ITR Map-Resolver(s):              100.100.100.100
  ETR Map-Server(s):                100.100.100.100 (01:26:08)
  xTR-ID:                           0x6F626F0E-0x7DA69D74-0x836FC96B-0x5549B888
  site-ID:                          unspecified
  ITR local RLOC (last resort):     100.64.10.1
  ITR Solicit Map Request (SMR):    accept and process
    Max SMRs per map-cache entry:   8 more specifics
    Multiple SMR suppression time:  20 secs
  ETR accept mapping data:          disabled, verify disabled
  ETR map-cache TTL:                1d00h
  Locator Status Algorithms:
    RLOC-probe algorithm:           disabled
    RLOC-probe on route change:     N/A (periodic probing disabled)
    RLOC-probe on member change:    disabled
    LSB reports:                    process
    IPv4 RLOC minimum mask length:  /0
    IPv6 RLOC minimum mask length:  /0
  Static mappings configured:       0
  Map-cache size/limit:             3/1000
  Imported route count/limit:       0/1000
  Map-cache activity check period:  60 secs
  Map-cache FIB updates:            established
  Total database mapping size:      2
    static database size/limit:     1/5000
    dynamic database size/limit:    0/1000
    route-import database size:     0
    Inactive (deconfig/away) size:  1
  Persistent map-cache:             disabled
Site01#

================================================ 


Site01#sh ip lisp map-cache
LISP IPv4 Mapping Cache for EID-table default (IID 0), 3 entries

0.0.0.0/0, uptime: 01:45:24, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
10.0.1.0/24, uptime: 01:22:27, expires: 22:37:32, via map-reply, self, complete
  Locator      Uptime    State      Pri/Wgt
  100.64.10.1  01:22:27  up, self     1/50
10.0.2.0/24, uptime: 01:10:33, expires: 22:51:10, via map-reply, self, complete
  Locator      Uptime    State      Pri/Wgt
  100.64.20.1  01:08:49  up           1/50


================================================ 

Site01#show ip lisp database
LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x1
Entries total 2, no-route 0, inactive 1

10.0.1.0/24
  Locator      Pri/Wgt  Source     State
  100.64.10.1    1/50   cfg-addr   site-self, reachable
10.0.2.0/24, Inactive, expires: 22:31:39



================================================ 

MSMR#sh lisp site
LISP Site Registration Information
* = Some locators are down or unreachable
# = Some registrations are sourced by reliable transport

Site Name      Last      Up     Who Last             Inst     EID Prefix
               Register         Registered           ID
SITE01         01:28:39  yes#   100.64.10.1          0        10.0.1.0/24
SITE02         01:10:49  yes#   100.64.20.1          0        10.0.2.0/24