The LISP Control Plane: Where the Host Is, and Who Knows It
LISP starts from one observation: an IP address is being asked to do two incompatible jobs. It identifies a host, which should be stable, and it describes where that host is in the topology, which should change when the host moves. Every awkward property of traditional campus design — VLANs stretched to allow roaming, subnets that mean a physical location, renumbering when something moves — comes from those two jobs sharing one field.
Separating them produces two namespaces. The endpoint identifier is the host's address and stays with it. The routing locator is the fabric node the host is currently behind and changes when it moves. A mapping database holds the relationship, edge nodes register what they see and query for what they need, and the whole thing is a distributed lookup rather than a routing protocol — which is why LISP scales differently from an IGP and why its failures look nothing like routing failures.
This article covers the edge node's half of the control plane: how a host is learned and registered, how the query and reply exchange works, how the map-cache lives and expires, what actually happens when a host moves between switches, and the failure catalogue — the control-plane problems that present as data-plane problems and get investigated with the wrong commands.
What Problem Does Separating EID From RLOC Solve?
What is the separation buying?
Three things that campus networks have historically paid for in other ways. A host keeps its address when it moves, so roaming needs no stretched VLAN. A subnet stops implying a location, so addressing can follow policy rather than topology. And the routing table stops growing with the number of endpoints, because endpoints live in a mapping database that is queried on demand rather than in a table that every router carries. The last one is what makes the design scale.
A Deeper Dive into the Separation
Pull, not push
An IGP pushes every prefix to every router whether or not anyone needs it. LISP pulls: an edge node knows only the endpoints it is currently talking to, and asks about the rest when it needs them. That inverts the scaling relationship — a fabric with fifty thousand endpoints does not put fifty thousand entries on every switch, it puts a few hundred on each one reflecting actual conversations. The cost is a lookup delay on the first packet to an unknown destination, which is paid once per conversation.
! What an edge node actually holds - only what it is using
EDGE1# show lisp instance-id 4099 ipv4 map-cache
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf CAMPUS, 6 entries
!
0.0.0.0/0, uptime: 4d02h, expires: never, via static-send-map-request
Negative cache entry, action: send-map-request
!
10.10.20.44/32, uptime: 00:12:41, expires: 23:47:19, via map-reply, complete
Locator Uptime State Pri/Wgt Encap-IID
10.1.1.9 00:12:41 up 10/10 -
! ^ Six entries on a fabric that may hold thousands of hosts.
The roles, which are functions on the same box
An ITR encapsulates traffic towards a remote RLOC and is the role an edge node plays for outbound traffic. An ETR de-encapsulates and registers local endpoints, which is the same edge node for inbound traffic. A device doing both is an xTR, which every SD-Access edge node is. Proxy variants — PITR and PETR — connect the LISP world to the non-LISP world, and in SD-Access that job belongs to the border node.
| Role | Does | In SD-Access, that is |
|---|---|---|
| ITR | Encapsulates towards a remote RLOC | The edge node, for outbound traffic |
| ETR | De-encapsulates; registers local EIDs | The edge node, for inbound traffic |
| xTR | Both of the above | Every fabric edge node |
| MS | Accepts registrations, holds the database | The control plane node |
| MR | Answers queries from ITRs | The control plane node |
| PITR / PETR | Bridges LISP and non-LISP | The border node |
Instance IDs, which carry the virtual network
Every LISP operation in a fabric is scoped to an instance ID, and that instance ID is the virtual network. Two hosts with the same address in different VNs are different EIDs because their instance IDs differ, which is what makes overlapping address space work. It also means every diagnostic command needs the instance ID, and running one without it — or with the wrong one — returns a truthful answer about a different virtual network.
! Every command is scoped to an instance ID = a VN
EDGE1# show lisp instance-id 4099 ipv4 map-cache ! CAMPUS
EDGE1# show lisp instance-id 4100 ipv4 map-cache ! GUEST
!
! Which instance ID belongs to which VRF?
EDGE1# show lisp instance-id 4099 ipv4 | include EID-table
EID-table: vrf CAMPUS
!
! Or list them all at once
EDGE1# show lisp eid-table summary
EDGE1# show lisp instance-id * ipv4 map-cache | include EID-table|entries
The cost of the first packet
A pull model means the first packet to an unknown destination arrives before the answer does. Implementations handle that by holding a small number of packets while the query completes and forwarding them once the reply arrives, so the practical effect is a few milliseconds of additional latency on the first packet of a conversation and nothing thereafter. It is worth understanding because it occasionally shows up in application testing as a first-connection delay that does not reproduce on the second attempt.
Where that delay matters — a latency-sensitive application, a synthetic test measuring first-byte time — the mitigation is not to tune LISP but to accept that the first packet of a new conversation between two parts of a large fabric costs one round trip to the control plane node. Placing control plane nodes so that round trip is short is a design decision with a measurable effect, and it is one of the few places where control plane node placement matters operationally rather than just for availability.
What the border node contributes
Everything outside the fabric has no EID and is not in the mapping database. A query for such a destination returns a negative reply, and the edge node then sends the traffic to the border node, which forwards it using ordinary routing. That is why a fabric works for internet traffic without every internet prefix being registered anywhere, and it is why a border node failure presents as "everything outside the fabric is unreachable while internal traffic is fine".
! The default entry that sends unknowns to the border
EDGE1# show lisp instance-id 4099 ipv4 map-cache 0.0.0.0/0
0.0.0.0/0, uptime: 4d02h, expires: never, via static-send-map-request
Negative cache entry, action: send-map-request
!
! And the configured use-petr pointing at the border
EDGE1# show run | include use-petr
ipv4 use-petr 10.1.1.1
ipv4 use-petr 10.1.1.2
! ^ Two borders. Traffic for unknown destinations goes here.
What Are the Message Types and When Is Each Sent?
What is the exchange?
Five messages cover everything. Map-Register is an edge node telling the mapping system what it has. Map-Notify is the acknowledgement. Map-Request is an edge node asking where something is. Map-Reply is the answer. And the Solicit-Map-Request is the mechanism for telling a node that its cached answer is now wrong. All of it runs over UDP port 4342, which is a different port from the VXLAN data plane and therefore a separately filterable and separately breakable thing.
A Deeper Dive into the Messages
Map-Register, which repeats forever
An edge node registers every endpoint it has learned, and re-registers periodically rather than once, so that the mapping system's view expires if the edge node goes away. The registration is authenticated with a per-site key, which means a key mismatch produces registrations that are sent, received, and silently discarded — the edge node believes it has registered and the mapping system has no record.
! What the edge node believes it has registered
EDGE1# show lisp instance-id 4099 ipv4 database
LISP ETR IPv4 Mapping Database for EID-table vrf CAMPUS, LSBs: 0x1
Entries total 3, no-route 0, inactive 0
!
10.10.10.55/32, dynamic-eid 10_10_10_0-CAMPUS-IPV4, inherited from default
Uptime: 00:41:12, Last-change: 00:41:12
Domain-ID: local
Locator Pri/Wgt Source State
10.1.1.5 10/10 cfg-intf site-self, reachable
!
! And whether the registration is being accepted
EDGE1# show lisp instance-id 4099 ipv4 statistics | include Map-Register|Map-Notify
Map-Registers in/out: 0/842
Map-Notifys in/out: 842/0
! ^ Notifys received should track Registers sent. Zero in
! with a rising out count means the key is wrong.
Map-Request and Map-Reply
An edge node with traffic for an unknown destination sends a Map-Request to a Map Resolver. The resolver forwards it through the mapping system to the authoritative node, which replies directly to the requester — the reply does not retrace the request's path. In SD-Access the control plane node is typically configured to reply on behalf of the edge nodes, which removes a round trip and means the reply's source is the control plane node rather than the far edge.
! Watch the exchange for one destination
EDGE1# debug lisp control-plane map-request
EDGE1# debug lisp control-plane map-reply
!
LISP: Send map request for EID prefix IID 4099 10.10.20.44/32
LISP: Processing received Map-Reply message
LISP: Record 1: EID 10.10.20.44/32, ttl 1440, action none, authoritative
LISP: Locator 10.1.1.9, priority 10, weight 10, state up
LISP: Created map cache entry for IID 4099 10.10.20.44/32
!
! Always undebug - these are chatty on a busy fabric
EDGE1# undebug all
!
! The counters, which are safer than debug
EDGE1# show lisp instance-id 4099 ipv4 statistics | include Map-Request|Map-Reply
Negative replies, and what they mean
A query for something the mapping system does not know returns a negative Map-Reply with an action telling the requester what to do — typically to send the traffic natively, which in a fabric means towards the border. Negative entries have short lifetimes so that a destination which later appears is discovered quickly. An unexpected negative entry for something that should be in the fabric is a registration problem at the other end, not a query problem at this one.
! A negative entry for something that SHOULD be registered
EDGE1# show lisp instance-id 4099 ipv4 map-cache 10.10.20.44
10.10.20.44/32, uptime: 00:00:41, expires: 00:14:19, via map-reply
Negative cache entry, action: send-map-request
! ^ The mapping system does not know this host.
! Go and look at the OTHER edge node's database.
!
! On the far edge node - is it registered at all?
EDGE2# show lisp instance-id 4099 ipv4 database 10.10.20.44/32
EDGE2# show device-tracking database address 10.10.20.44
! ^ Not in device tracking = the switch never learned the host.
The message summary
| Message | Triggered by | Failure symptom | Check |
|---|---|---|---|
| Map-Register | A host learned, then periodically | Host unreachable from everywhere | ... ipv4 database on the local edge |
| Map-Notify | A registration accepted | Registers sent, none acknowledged | ... statistics — key mismatch |
| Map-Request | Traffic to an unknown EID | First packet delayed or dropped | ... map-resolver reachability |
| Map-Reply | A Map-Request received | Map-cache stays empty | CP node's server database |
| SMR | A mapping changed | Traffic follows a moved host slowly | Map-cache uptime after a move |
show lisp instance-id <id> ipv4 statistics on the edge shows Map-Registers going out and no Map-Notifys coming back; the control plane node's site registration list is missing the prefixes. Fix: correct the key on both sides — in an automated fabric, re-provisioning the node from the controller is usually faster than editing it.How Does an Edge Node Learn, Register and Cache?
How does a host get into the database at all?
The edge node has to notice the host first, and it does that through the switch's endpoint tracking — ARP, IPv6 neighbour discovery, DHCP, or seeing data-plane traffic from an address it has not seen before. Once tracked, the address is matched against a configured dynamic EID range, a /32 mapping is created, and that is registered. Every step in that chain has to work, and a host that never speaks — a silent device waiting to be polled — is never learned and therefore never registered.
A Deeper Dive into Learning and Caching
Device tracking, which feeds everything
The switch's endpoint tracking database is the source of truth for what LISP registers. If a host is not in it, nothing downstream can work, and the reasons a host is absent are ordinary switching reasons: the port is down, the VLAN is wrong, the device is silent, or a tracking policy is not applied to the port. Checking tracking before checking LISP saves investigating a control plane that is behaving correctly.
! Start here - did the switch even see the host?
EDGE1# show device-tracking database vlanid 1021
Network Layer Address Link Layer Address Interface vlan prlvl state
ARP 10.10.10.55 a0b4.0101.5555 Gi1/0/12 1021 0025 REACHABLE
ND 2001:DB8:10::55 a0b4.0101.5555 Gi1/0/12 1021 0024 REACHABLE
!
! Then confirm it became a dynamic EID
EDGE1# show lisp instance-id 4099 ipv4 database 10.10.10.55/32
!
! And the dynamic EID configuration that made that happen
EDGE1# show run interface Vlan1021 | include lisp mobility
lisp mobility 10_10_10_0-CAMPUS-IPV4
Map-cache lifetime
A map-cache entry carries a lifetime from the reply, commonly twenty-four hours, and is not re-validated on every packet. That is deliberate — it keeps the control plane quiet — and it means the cache is only correct because something actively invalidates it when a mapping changes. Understanding that the cache is long-lived and event-driven rather than short-lived and polled explains both why the control plane is so quiet in steady state and why the invalidation mechanism matters so much.
! An entry with hours left on it
EDGE1# show lisp instance-id 4099 ipv4 map-cache 10.10.20.44
10.10.20.44/32, uptime: 00:41:02, expires: 23:18:58, via map-reply, complete
Locator Uptime State Pri/Wgt
10.1.1.9 00:41:02 up 10/10
!
! Clearing one entry, to force a fresh lookup
EDGE1# clear lisp instance-id 4099 ipv4 map-cache 10.10.20.44
!
! Clearing the whole cache - disruptive, use deliberately
EDGE1# clear lisp instance-id 4099 ipv4 map-cache
! ^ Every active conversation takes a lookup hit.
Subscription instead of polling
Newer implementations replace periodic re-requesting with a subscription model: the edge node registers an interest in a prefix over a reliable session, and the control plane node pushes an update whenever the mapping changes. This makes invalidation immediate rather than dependent on the SMR mechanism reaching every cached requester, and it makes the session state itself something to check — a session that is down means updates are not arriving even though the cache still looks populated.
! The reliable session to the control plane node
EDGE1# show lisp session
Sessions for VRF default, total: 2, established: 2
Peer State Up/Down In/Out Users
10.1.100.1 Up 4d02h 412/389 3
10.1.100.2 Up 4d02h 408/389 3
!
! What this node has subscribed to
EDGE1# show lisp instance-id 4099 ipv4 map-cache | include subscribe
EDGE1# show lisp instance-id 4099 ipv4 publication
EDGE1# show lisp instance-id 4099 ipv4 subscription
What a duplicate registration means
Two edge nodes registering the same endpoint at the same time is not necessarily an error — it is the normal transient state during a move, and it is also what a dual-homed host produces. It becomes a problem when it persists, because the mapping system then has two locators for one endpoint and traffic goes to whichever it selects, which may be the switch the host is no longer behind.
The usual cause of a persistent duplicate is a host whose MAC appears on two switches through a Layer 2 path that should not exist — a mis-cabled link, an unmanaged switch bridging two access ports, or a virtual machine whose traffic egresses through two uplinks. The diagnosis is a switching one: find where the address is being seen twice, and the LISP symptom resolves on its own.
! Two locators for one endpoint - transient is fine, persistent is not
CP1# show lisp instance-id 4099 ipv4 server 10.10.10.55/32
Site name: site_uci
Registered: yes
Registered via: 10.1.1.9, 10.1.1.12
Last registered: 00:00:04
! ^ Check again in a minute. Still two? Investigate Layer 2.
!
! Find where the address is being seen
EDGE-B# show device-tracking database address 10.10.10.55
EDGE-C# show device-tracking database address 10.10.10.55
EDGE-B# show mac address-table address a0b4.0101.5555
Silent hosts
A device that never sends anything until spoken to is never learned, never registered, and therefore unreachable in a fabric that does not flood. This affects a predictable set of equipment — building management systems, older industrial devices, some appliances — and the answer is either static registration for the specific addresses or Layer 2 flooding for the subnet containing them. Identifying these devices during discovery is considerably cheaper than diagnosing them after cutover.
! A static entry for a device that will never announce itself
router lisp
instance-id 4099
service ipv4
eid-table vrf CAMPUS
database-mapping 10.10.40.50/32 10.1.1.5 priority 10 weight 10
exit-service-ipv4
!
! Confirm it registered despite the host being silent
EDGE1# show lisp instance-id 4099 ipv4 database 10.10.40.50/32
CP1# show lisp instance-id 4099 ipv4 server | include 10.10.40.50
show device-tracking database answers that in one command and rules out the whole control plane when the entry is absent.What Happens When a Host Moves?
What is the sequence?
The new edge node learns the host and registers it. The mapping system updates so the endpoint identifier now points at the new routing locator. The old edge node, which had been advertising that host, is informed and sends a solicit message to every node holding a stale cached entry. Those nodes re-request, receive the new locator, and rebuild their tunnels. Throughout, the host's address is unchanged and the host itself observes nothing — no new DHCP lease, no gratuitous ARP for a new gateway, no session reset.
A Deeper Dive into Mobility
Why the host notices nothing
Its address did not change, because the address was never describing where it was. Its default gateway did not change, because the anycast gateway is identical on every edge node — same address, same MAC. And its ARP entry for that gateway remains valid, because the MAC it points at is present on the new switch too. The move is entirely a control-plane event between infrastructure devices.
! Before the move - registered on EDGE-B
CP1# show lisp instance-id 4099 ipv4 server 10.10.10.55/32
Site name: site_uci
Registered: yes
Registered via: 10.1.1.9
!
! After the move - registered on EDGE-C, same EID
CP1# show lisp instance-id 4099 ipv4 server 10.10.10.55/32
Site name: site_uci
Registered: yes
Registered via: 10.1.1.12
Last registered: 00:00:06
! ^ Same host address. Different locator. That is the move.
The solicit mechanism
Every node that queried for a host holds a cached answer that is now wrong, and there may be many of them. The old edge node keeps a list of who asked and sends each of them a solicit message, which is a request carrying a bit meaning "your entry is stale, ask again". They do, get the new answer, and converge. The mechanism depends on that list being accurate, which is why a node that learned the mapping some other way — a stale static entry, for example — is not solicited and does not update.
! Watch a move converge on a third-party edge node
EDGE1# show lisp instance-id 4099 ipv4 map-cache 10.10.10.55
10.10.10.55/32, uptime: 02:41:19, expires: 21:18:41, via map-reply
Locator Uptime State Pri/Wgt
10.1.1.9 02:41:19 up 10/10
!
! ... host moves, SMR arrives, entry is refreshed ...
!
EDGE1# show lisp instance-id 4099 ipv4 map-cache 10.10.10.55
10.10.10.55/32, uptime: 00:00:04, expires: 23:59:56, via map-reply
Locator Uptime State Pri/Wgt
10.1.1.12 00:00:04 up 10/10
! ^ Uptime reset to seconds. The entry was rebuilt, not aged out.
Wireless roaming, which is the same process
A client roaming between access points attached to different edge nodes goes through exactly this sequence. The wireless controller signals the move, the new edge node registers the client, and the mapping updates. That is why fabric wireless does not need the client's traffic tunnelled back to a controller for mobility — the mobility is handled by the same mechanism that handles a wired host being unplugged and moved, and the client keeps its address either way.
Verifying a move end to end
! Four checks, in order, after a host has moved
!
! 1. New edge node learned it
EDGE-C# show device-tracking database address 10.10.10.55
!
! 2. New edge node registered it
EDGE-C# show lisp instance-id 4099 ipv4 database 10.10.10.55/32
!
! 3. Mapping system reflects the new locator
CP1# show lisp instance-id 4099 ipv4 server 10.10.10.55/32
!
! 4. A third-party edge node has the updated entry
EDGE-A# show lisp instance-id 4099 ipv4 map-cache 10.10.10.55
! ^ Locator should be EDGE-C, uptime should be short.
When a move does not converge
| Where it stopped | Symptom | Likely cause |
|---|---|---|
| New edge never learned the host | Host unreachable from everywhere | Silent host, wrong VLAN, or tracking policy absent |
| Learned but not registered | Same | Dynamic EID range does not cover the address |
| Registered, mapping still shows the old locator | Traffic goes to the old switch | Registration rejected — key or site policy |
| Mapping updated, remote caches stale | Some sources work, others do not | Solicit not delivered, or a stale static entry |
| Everything updated, traffic still fails | Not a control plane problem | Underlay, MTU, or policy at the new edge |
Which LISP Failures Look Like Data Plane Failures?
What are the failures worth memorising?
Five. The host that was never learned, which is a switching problem. The registration that is discarded for a key mismatch, which leaves the edge node convinced it succeeded. The stale map-cache entry after a move that did not fully converge. The control plane node that is unreachable, which breaks new conversations while existing ones continue. And the instance ID mismatch, where everything is correct in a different virtual network.
A Deeper Dive into the Failure Catalogue
The unreachable control plane node
show lisp instance-id <id> ipv4 map-resolver shows the resolvers down; show lisp session shows sessions not established. Fix: restore reachability, and treat the gradual spread as the diagnostic signature — a failure that grows as caches expire is almost always the mapping system rather than the data path.The instance ID mismatch
show lisp instance-id <id> ipv4 \| include EID-table names the VRF — check it is the one the host belongs to. Fix: establish the instance ID from the host's VN before running any LISP command, and include the VRF name in any notes so a colleague picking up the case does not repeat it.Control plane versus data plane, decided in one command
show lisp instance-id <id> ipv4 map-cache <destination> — empty or negative means stop and go to the control plane. Fix: make this the first command in every fabric reachability investigation, before any underlay or MTU check.A diagnostic order that works
! Source edge first, then mapping system, then destination edge
!
! 1. Does the source know where the destination is?
EDGE-A# show lisp instance-id 4099 ipv4 map-cache 10.10.20.44
! ^ negative or absent = control plane. Continue below.
! ^ populated = data plane. Go to underlay and MTU instead.
!
! 2. Does the mapping system know?
CP1# show lisp instance-id 4099 ipv4 server 10.10.20.44/32
! ^ absent = the destination edge never registered it.
!
! 3. Did the destination edge learn and register it?
EDGE-B# show device-tracking database address 10.10.20.44
EDGE-B# show lisp instance-id 4099 ipv4 database 10.10.20.44/32
!
! 4. Are its registrations being accepted?
EDGE-B# show lisp instance-id 4099 ipv4 statistics | include Map-Notify
Debugging without damage
The LISP debugs are informative and chatty, and on a busy edge node they will affect the control plane they are meant to be observing. Scoping to one instance ID and one prefix keeps that manageable, and the statistics counters answer most questions without any debug at all — a Map-Notify count that is not tracking the Map-Register count says everything a registration debug would say, without the risk.
! Prefer counters to debug wherever possible
EDGE1# show lisp instance-id 4099 ipv4 statistics
!
! If debug is necessary, scope it tightly
EDGE1# debug lisp control-plane map-request
EDGE1# debug lisp control-plane map-server-registration
!
! And bound the exposure
EDGE1# show logging | include LISP
EDGE1# undebug all
What to capture before escalating
A LISP case that has to go to someone else is far more useful with four outputs attached than with a description. The source edge node's map-cache entry for the destination, the mapping system's server entry for the same, the destination edge node's database entry, and the destination edge node's registration statistics. Together those four say exactly where the chain broke, and they take under a minute to collect.
Adding the instance ID and the VRF name to that bundle matters more than it sounds, because whoever picks the case up will otherwise run the same commands against the wrong virtual network and reach a different conclusion. Stating the instance ID once at the top of the case notes prevents a repeat of the most common wasted investigation in this area.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint places LISP within the software-defined infrastructure domain, and the questions concentrate on the concepts rather than the syntax: what an EID and an RLOC are, which node plays which role, what happens when a host moves, and which show command answers which question. Being able to name the five messages and describe the mobility sequence covers most of it.
Conclusion
LISP separates what a host is from where it is, and every property of the fabric that seems surprising follows directly from that. A host keeps its address when it moves because the address was never describing its location. Edge nodes hold a few hundred mappings rather than the full endpoint table because mappings are pulled on demand rather than pushed everywhere. And the control plane is quiet in steady state because cached entries are long-lived and invalidated by events rather than by polling.
The message set is small and each message has one job. Registration publishes what an edge node has, and its acknowledgement is the counter worth watching, because a registration discarded for a key mismatch leaves the edge node convinced it succeeded. The query and reply exchange resolves unknowns, with the reply arriving directly rather than retracing the request. And the solicit mechanism is what makes a long-lived cache safe, by telling holders of a stale entry to ask again.
For troubleshooting, one command decides everything else. An empty or negative map-cache entry for the destination means the control plane has failed and no tunnel is being attempted, so every underlay and MTU check will pass and prove nothing. A populated entry means the control plane did its job and the problem is below it. Running that command first, with the correct instance ID, is the difference between a ten-minute investigation and a full day in the wrong plane.
External Links
- RFC 9300 — The Locator/ID Separation Protocol (LISP)
- RFC 9301 — Locator/ID Separation Protocol (LISP) Control Plane
- RFC 6830 — The Locator/ID Separation Protocol (LISP), experimental
- RFC 6833 — Locator/ID Separation Protocol (LISP) Map-Server Interface
- RFC 7348 — Virtual eXtensible Local Area Network (VXLAN)
- Cisco — Software-Defined Access Configuration Guide, Catalyst 9300
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 9300 specifies LISP and the separation of the Endpoint Identifier namespace from the Routing Locator namespace.
- RFC 9301 specifies the LISP control plane, including the Map-Request, Map-Reply, Map-Register and Map-Notify messages.
- RFC 9301 assigns UDP port 4342 to LISP control plane messages, distinct from the data plane encapsulation port.
- RFC 9301 describes the Solicit-Map-Request, a Map-Request with the SMR bit set, used to inform a requester that its cached mapping should be refreshed.
- RFC 6833 defines the Map-Server interface, including the authenticated registration of EID prefixes by an ETR and the Map-Notify acknowledgement.
- RFC 9301 describes negative Map-Replies, which indicate that no mapping exists for the requested EID and carry an action for the requester to apply.
- RFC 9300 defines the ITR, ETR and xTR roles, and the proxy variants PITR and PETR that interconnect LISP and non-LISP sites.
- RFC 9300 describes the Instance ID, which provides a separate EID namespace and is used in SD-Access to represent a virtual network.
- RFC 7348 defines VXLAN and UDP port 4789, which SD-Access uses for the data plane, separate from the LISP control plane port.
- Cisco documentation describes dynamic EID detection, in which an edge node learns an endpoint through endpoint tracking and registers a host route for it.
- Cisco documentation describes
lisp mobilityon a fabric SVI, which associates the interface with a dynamic EID range for registration purposes. - The CCIE Enterprise Infrastructure v1.1 unified exam topics include LISP within the software-defined infrastructure domain.