Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

LISP Map Server and Map Resolver: The Silent Refusal

Software Defined Infrastructure ｜ Concept ｜ Advanced ｜ 19 min read

The Map Server and Map Resolver are usually discussed as one thing, because in a campus fabric they run on the same device and that device is called the control plane node. They do two different jobs. The Map Server owns the database: it decides which registrations to accept, from whom, for which prefixes, and it is the only place where a policy about what may be registered can be expressed. The Map Resolver owns the query path: it takes questions from edge nodes and gets them answered.

The distinction matters because the two fail differently and are diagnosed with different commands. A Map Server problem is a registration that was refused or a site definition that does not cover the prefix, and it manifests as endpoints that exist on a switch and nowhere else. A Map Resolver problem is a query that is not being answered, and it manifests as an edge node that cannot resolve anything while its own endpoints remain perfectly reachable from elsewhere.

This article covers what each half actually does, how site definitions and authentication decide what enters the database, how to design redundancy and placement for control plane nodes, what happens when the mapping system cannot satisfy a query, and the failures that are hardest to see — the ones where every device reports success and the database is quietly incomplete.

Blog ClaimThe Map Server is the only device in the fabric that can refuse a registration, and because a refused registration produces no error at the edge node that sent it, the mapping system is the one place where being silent about a failure is built into the protocol.
 
The Map Server decides what enters the database and refuses silently; the Map Resolver answers queries. Two control plane nodes hold independent copies rather than a synchronised pair.

What Is the Map Server Doing That the Map Resolver Is Not?

What is the division?

The Map Server is the authority: registrations arrive at it, it applies policy, and the resulting database is what the fabric knows. The Map Resolver is a query front end: it accepts requests from edge nodes and routes them to whatever holds the answer. In a campus fabric both functions sit on the same device and are configured together, which makes it easy to forget that the two failure modes are entirely distinct.

A Deeper Dive into the Two Functions

The Map Server as a policy point

Every registration is checked against a site definition before it is accepted. That check covers who is registering, whether their key matches, which prefixes they are permitted to register, and which instance IDs exist. It is the only place in the control plane where a policy about the endpoint namespace can be expressed, and it is why a fabric cannot be polluted by a switch registering arbitrary addresses — provided the site definitions are actually restrictive.

! What the mapping system holds, per site
CP1# show lisp site
LISP Site Registration Information
Site Name      Last      Up  Who Last              Inst  EID Prefix
               Register      Registered            ID
site_uci       00:00:31  yes 10.1.1.5              4099  10.10.10.55/32
site_uci       00:00:18  yes 10.1.1.9              4099  10.10.20.44/32
site_uci       never     no  --                    4099  10.10.30.0/24
! ^ The third line is a configured prefix nobody has registered.
!
! Totals, which are the fastest health check
CP1# show lisp site summary
Site name                  Configured  Registered  Incons
site_uci                          412         408       0

The Map Resolver as a query path

A resolver takes a request from an edge node and gets it answered, either by forwarding it towards the authoritative registrant or by answering directly where proxy replying is configured. It holds no authority of its own. Its failure mode is therefore about reachability rather than about content: an edge node that cannot reach any resolver cannot resolve anything, while everything registered by that same edge node remains perfectly reachable from the rest of the fabric.

! From the edge node's point of view
EDGE1# show lisp instance-id 4099 ipv4 map-resolver
    Map-resolver         Uptime     State
    10.1.100.1           4d02h      up
    10.1.100.2           00:00:00   down
! ^ One resolver down. Still functional, no redundancy.
!
! Confirm reachability at the underlay level
EDGE1# ping 10.1.100.2 source Loopback0
EDGE1# show lisp session | include 10.1.100.2
!
! And the query counters
EDGE1# show lisp instance-id 4099 ipv4 statistics | include Map-Request

Proxy replying, and what it changes

By default a request is forwarded to the registrant, which answers directly. With proxy replying enabled the Map Server answers on the registrant's behalf from its own database, which removes a round trip and makes the reply's source the control plane node. This is the usual configuration in a campus fabric and it has a diagnostic consequence: a reply arriving from the control plane node rather than from the far edge is correct rather than suspicious.

! Map Server answers on behalf of registrants
router lisp
 site site_uci
  authentication-key <key>
  eid-record instance-id 4099 10.10.0.0/16 accept-more-specifics
  exit-site
 !
 ipv4 map-server
 ipv4 map-resolver
 ipv4 proxy-reply
!
! The reply now comes from the CP node, not the far edge
EDGE1# show lisp instance-id 4099 ipv4 map-cache 10.10.20.44
10.10.20.44/32, uptime: 00:02:11, expires: 23:57:49, via map-reply
  Locator     Uptime    State  Pri/Wgt
  10.1.1.9    00:02:11  up     10/10
! ^ The LOCATOR is the far edge. The REPLY came from the CP node.

The two failure modes side by side

Observation Which function First command
One switch's endpoints unreachable from everywhere Map Server show lisp site on the CP node
One switch cannot reach anything, its own hosts are fine Map Resolver ... ipv4 map-resolver on that edge
Registrations rising, database not growing Map Server show lisp site summary
New conversations fail, existing ones fine Map Resolver reachability show lisp session
Two CP nodes disagree about a prefix Map Server Compare show lisp site on both
Compare the two control plane nodes routinelyThey build their databases independently from the registrations each receives, so they can legitimately differ — and a persistent difference is a finding. A scheduled comparison of show lisp site summary on both takes seconds and detects a class of problem that no single-device check will ever see.
Sub claimThe Map Server is the only device that can refuse a registration and the Map Resolver holds no authority at all, which is why their failures are distinguished by whether one switch's hosts are missing or one switch can find nothing.

How Do Site Definitions and Authentication Control What Gets Registered?

What is a site?

A site is a policy object on the Map Server containing an authentication key and a list of endpoint prefixes that devices presenting that key are permitted to register. A registration is accepted only if the key matches and the prefix falls within the permitted list for the correct instance ID. Everything else is discarded, and — this is the property that matters operationally — discarded without any message reaching the device that sent it.

A Deeper Dive into Site Policy

The prefix list and the more-specifics keyword

A site is configured with the subnet ranges that belong to it, and endpoints register as host routes inside those ranges. That only works because of a keyword permitting more specific registrations than the configured prefix — without it, a site configured for a /24 accepts a registration for exactly that /24 and rejects every /32 inside it. In an automated fabric the controller sets this correctly; in a hand-built or hand-edited configuration it is a plausible thing to omit.

! A site definition, with the keyword that makes it work
router lisp
 site site_uci
  authentication-key 0 <shared-key>
  eid-record instance-id 4099 10.10.0.0/16 accept-more-specifics
  ! ^ Without accept-more-specifics, every /32 is REJECTED
  eid-record instance-id 4100 10.20.0.0/16 accept-more-specifics
  eid-record instance-id 4101 10.30.0.0/16 accept-more-specifics
  exit-site
!
! Confirm the configured ranges
CP1# show lisp site detail | include Site name|Allowed|instance-id
Site name: site_uci
  Allowed configured locators: any
  Allowed EID-prefixes:
    EID-prefix: 10.10.0.0/16 instance-id 4099
      More specifics accepted

Reading a rejection

The rejection is invisible at the edge node and visible on the Map Server, which is why an investigation of "this switch's hosts are unreachable" belongs on the control plane node rather than on the switch. The site output distinguishes a prefix that was never registered from one that was registered and refused, and the counters record how many registrations were discarded and why.

! Registrations that arrived and were not accepted
CP1# show lisp site detail | include Registration errors|authentication
  Registration errors:
    Authentication failures:   1284
    Allowed locators mismatch: 0
! ^ A rising authentication failure count names the problem.
!
! Which device is sending them?
CP1# debug lisp control-plane map-server-registration
LISP: MS registration from 10.1.1.12 for IID 4099 10.10.10.55/32
LISP:   authentication failure, dropping
CP1# undebug all
!
! And the overall picture
CP1# show lisp site summary
CP1# show lisp instance-id 4099 ipv4 server summary

Rate limiting, which protects the database

A misbehaving edge node — one caught in a loop of learning and forgetting the same endpoints, for instance — can send registrations far faster than intended. The Map Server rate limits per site so that one switch cannot consume the control plane's capacity, and a site hitting that limit is a strong signal that something upstream is flapping rather than that the limit is too low.

! Is any site being rate limited?
CP1# show lisp site rate-limit
!
! A site at its limit means something is flapping. Find it.
CP1# show lisp site detail | include Last register|Who last
EDGE-C# show device-tracking database | count REACHABLE
EDGE-C# show logging | include SISF|DEVICE_TRACKING
! ^ A tracking database that churns produces registration churn.

The four rejection reasons, and how each looks

Rejection reason On the control plane node On the edge node Usual cause
No site matches the device Nothing appears in show lisp site Registers happily, no Notify Device provisioned outside the controller
Authentication key mismatch Authentication failure counter rises Registers happily, no Notify Partial re-provisioning, manual edit
EID outside the site prefix Prefix never appears as registered Registers happily, no Notify Subnet added outside the addressing plan
Instance ID not configured The whole VN is empty Registers happily, no Notify A VN added on the edge and not the CP node

The fourth column of that table is identical in every row, and that is the point. From the edge node's perspective all four rejections are indistinguishable from each other and from success, which is why the diagnosis has to start on the control plane node with the site output and the error counters rather than on the switch whose hosts are missing.

Extranet policy, for lookups across virtual networks

Instance IDs are separate namespaces, so a lookup in one does not find endpoints in another — which is the point of virtual networks. Where a shared service must be reachable from several VNs without a fusion device, an extranet policy on the Map Server permits lookups from subscriber instance IDs into a provider instance ID. It is a control-plane construct rather than a routing one, and it is the alternative to leaking prefixes outside the fabric.

! Provider VN reachable from subscriber VNs
router lisp
 service ipv4
  map-server
  extranet SHARED-SERVICES
   provider instance-id 4199 10.99.0.0/16
   subscriber instance-id 4099 10.10.0.0/16
   subscriber instance-id 4100 10.20.0.0/16
   exit-extranet
!
! Verify the policy is in effect
CP1# show lisp extranet
CP1# show lisp instance-id 4099 ipv4 server 10.99.1.10/32
! ^ A subscriber VN can now resolve a provider EID.
!   Subscribers still cannot resolve each other.
Pitfall: a site prefix that does not cover the subnet Symptom: one subnet's hosts are unreachable from the whole fabric while every other subnet on the same switch works normally. The switch shows the endpoints in its database and the control plane node has none of them. Cause: the site definition's permitted prefix list does not include that subnet, so every registration for it is rejected. This appears when a subnet is added outside the controller, or when a site was configured with a narrower range than the addressing plan later used. Confirm: show lisp site detail on the control plane node, comparing the allowed prefixes against the subnet in question. Fix: extend the site's prefix list, and prefer configuring one generously sized range with more-specifics accepted over enumerating individual subnets.
Sub claimA site definition is the only policy point in the endpoint namespace, and because every rejection it makes is invisible at the registering device, the control plane node is where "these hosts are unreachable" investigations belong.

How Do I Design Control Plane Node Redundancy and Placement?

What is the model?

Two control plane nodes, with every edge node registering to both and querying either. They do not synchronise with each other and are not an active-standby pair: each builds its database independently from the registrations it receives, and both should therefore end up holding the same content by construction rather than by replication. That is a robust model, and it means a difference between them is always caused by registrations reaching one and not the other.

A Deeper Dive into Design

Where to put them

Three options with different trade-offs. Collocated with the border nodes is the common choice for a single site and keeps the device count down. Dedicated devices give the control plane its own failure domain and its own maintenance window, which matters as a fabric grows. Distributed placement, with control plane nodes closer to groups of edge nodes, reduces the first-packet lookup latency in a physically large deployment.

Placement Suits Advantage Cost
Collocated with borders Single site, moderate size Fewest devices Border maintenance affects the control plane
Dedicated devices Larger fabrics Independent failure domain and change window Two more devices to buy and manage
Distributed by area Physically large campuses Shorter lookup round trip More nodes, more comparison surface
Transit control plane SD-Access transit between sites Preserves VN and SGT between fabrics An additional role to design and monitor

What a control plane node failure actually does

With two nodes and one failing, nothing breaks: edge nodes continue registering to and querying the survivor. With both failing, existing conversations continue because map-cache entries are long-lived, and new conversations fail — so the outage grows gradually as caches expire rather than arriving all at once. That gradual onset is the diagnostic signature and it is worth recognising, because a failure that spreads over hours points at the mapping system and almost nothing else does.

! Confirm every edge sees both control plane nodes
EDGE1# show lisp instance-id 4099 ipv4 map-resolver
EDGE1# show lisp instance-id 4099 ipv4 map-server
EDGE1# show lisp session
!
! A quick fleet-wide check is worth scripting
!   for each edge node:
!     show lisp session | include Up
!   expect 2 established sessions everywhere
!
! And confirm the two databases agree
CP1# show lisp site summary
CP2# show lisp site summary
! ^ Registered counts should match. A gap is a finding.

Scale, and what actually limits it

The limits are per platform and change with software release, so the number worth knowing is the one for the hardware in front of you rather than a general figure. What is worth understanding is which dimension binds: the number of registered endpoints, the registration rate, and the query rate are three separate limits, and a fabric with modest endpoint counts and a great deal of mobility can hit the rate limits long before the capacity ones.

! The three dimensions worth watching
!
! 1. Endpoint count
CP1# show lisp site summary
CP1# show lisp instance-id * ipv4 server summary
!
! 2. Registration rate - churn rather than size
CP1# show lisp site rate-limit
CP1# show lisp instance-id 4099 ipv4 statistics | include Map-Register
!
! 3. Query rate
CP1# show lisp instance-id 4099 ipv4 statistics | include Map-Request
!
! And the device itself
CP1# show processes cpu sorted | include LISP
CP1# show platform resources

Why the control plane node is not a bottleneck for traffic

A common concern on first encountering the design is that every conversation depends on a central device, which sounds like a scaling and availability problem. It is not, because the control plane node is consulted once per conversation rather than once per packet. After the lookup, traffic flows directly between edge nodes through a VXLAN tunnel that the control plane node has no part in — it is not in the data path at all.

That distinction is worth stating clearly because it changes what the device needs to be sized for. It handles registrations and queries, which are control-plane events measured in thousands per second at most, not user traffic measured in gigabits. A control plane node that is CPU-bound is experiencing registration churn or query churn, and the fix is upstream of it — a flapping edge node, a mobility event affecting many endpoints — rather than a bigger device.

Maintenance without an outage

Because the two nodes are independent rather than paired, taking one out of service is straightforward: confirm every edge node has an established session to the other, then work on it. The check is worth doing rather than assuming, because an edge node that has quietly lost its session to the survivor will lose all resolution capability the moment the second node goes down — and that is precisely the state a routine maintenance window discovers at the worst possible time.

Independent copies are a feature, not a gapThe absence of synchronisation between control plane nodes means there is no replication protocol to fail, no split-brain condition, and no convergence delay after a partition heals. Each node's database is a direct consequence of the registrations it received, which makes a discrepancy between them informative rather than alarming: it tells you exactly which registrations are not arriving somewhere.
Sub claimControl plane nodes hold independent copies rather than a synchronised pair, which means a difference between them is never a replication bug and always a registration that reached one and not the other.

How Does the Mapping System Answer a Query It Cannot Satisfy?

What is a negative reply?

A query for an endpoint the database does not hold returns a reply saying so, along with an instruction for what the requester should do instead — typically to forward the traffic natively, which in a fabric means towards the border node. Negative entries are cached briefly rather than for hours, so a destination that later registers is discovered within minutes. This is how a fabric handles internet traffic without every external prefix being registered anywhere.

A Deeper Dive into Negative Answers

Why the short lifetime matters

A positive answer is stable — the host is behind that switch until it moves, and a solicit will say so. A negative answer is inherently unstable, because the endpoint may register a second later. Caching it for hours would make a newly connected host unreachable from anyone who happened to try just before it arrived, so negative entries expire quickly and the cost is a few extra queries.

! A negative entry and its short expiry
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
! ^ Minutes, not hours. Compare with a positive entry:
!
EDGE1# show lisp instance-id 4099 ipv4 map-cache 10.10.20.71
10.10.20.71/32, uptime: 02:14:08, expires: 21:45:52, via map-reply, complete
  Locator     Uptime    State  Pri/Wgt
  10.1.1.9    02:14:08  up     10/10

The actions a negative reply can carry

The instruction accompanying a negative reply tells the requester what to do with the traffic: send it natively, drop it, or request again. In a campus fabric the practical outcome is that unknown destinations go to the border node and out, which is exactly what should happen for anything outside the fabric. An unexpected drop action, by contrast, means policy is deliberately discarding traffic for that range.

! What the edge does with an unknown destination
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 border it will actually use
EDGE1# show run | section router lisp
  ipv4 use-petr 10.1.1.1
  ipv4 use-petr 10.1.1.2
!
! Confirm the border is reachable in the underlay
EDGE1# ping 10.1.1.1 source Loopback0
EDGE1# show ip route 10.1.1.1

Distinguishing "not registered" from "not permitted"

Both produce a negative reply at the edge node and they have entirely different causes. Not registered means the destination's own edge node never published it — a host that was never learned, or a switch whose registrations are failing. Not permitted means the query came from an instance ID with no extranet policy allowing it to see the destination's namespace, which is correct behaviour for two virtual networks that are supposed to be separate.

! Ask the mapping system directly, in the DESTINATION's VN
CP1# show lisp instance-id 4100 ipv4 server 10.20.5.5/32
  Site name: site_uci
  Registered: yes
  Registered via: 10.1.1.9
! ^ Registered. So the negative reply in VN 4099 is a
!   POLICY outcome, not a registration failure.
!
! Versus a genuine registration failure
CP1# show lisp instance-id 4099 ipv4 server 10.10.30.7/32
% EID 10.10.30.7/32 not found
! ^ Nobody ever registered it. Go to the destination edge node.

Traffic to the border, and when that is wrong

Sending unknowns to the border is correct for external destinations and wrong for internal ones. A fabric endpoint that is being forwarded to the border rather than tunnelled directly is a registration failure whose symptom is a working but badly routed conversation — traffic reaches the destination via the border and back, which functions and adds latency and consumes border capacity. Spotting it requires looking at the path rather than at whether it works.

! A fabric-internal destination that should NOT be going to the border
EDGE1# show lisp instance-id 4099 ipv4 map-cache 10.10.20.44
  Negative cache entry, action: send-map-request
! ^ This is an internal host. It should have a locator.
!   Traffic is going out through the border and back.
!
! Confirm on the border that it is carrying internal traffic
BORDER1# show ip route vrf CAMPUS 10.10.20.44
BORDER1# show lisp instance-id 4099 ipv4 map-cache 10.10.20.44
!
! And go fix the registration at the source
EDGE2# show lisp instance-id 4099 ipv4 database 10.10.20.44/32
Alert on negative entries for internal rangesA negative map-cache entry for an address inside the fabric's own addressing plan is always wrong, and it is quiet — traffic still flows, via a longer path. A periodic check for negative entries whose prefix falls inside internal ranges catches registration failures that would otherwise be invisible until someone notices the latency.
Sub claimNegative entries are cached for minutes rather than hours because a missing endpoint may appear at any moment, which is the same property that makes a negative entry for an internal address a silent misrouting rather than an outage.

Which Mapping System Failures Are Hardest to See?

What are the failures worth memorising?

Four, and all of them share the property that every device involved reports success. A registration refused for a key or prefix mismatch. One control plane node holding a different database from the other. An edge node that has lost its session to one node and is one failure away from having none. And a negative entry for an internal destination, which routes traffic the long way round without breaking anything.

A Deeper Dive into the Quiet Failures

The one-sided registration

Pitfall: an edge node registered with only one control plane node Symptom: everything works normally until a routine maintenance window on the other control plane node, at which point one switch's endpoints become unreachable fabric-wide while every other switch is unaffected. Cause: that edge node's session or registration to the surviving node had already failed — a key mismatch introduced by a partial re-provisioning, or an underlay path problem to one node only. Nothing depended on it while both nodes were up. Confirm: compare show lisp site output on both control plane nodes for that switch's prefixes; show lisp session on the edge should show two established sessions and shows one. Fix: restore the failed registration, and make a two-session check part of the pre-maintenance routine rather than discovering it during the window.

The divergent database

Pitfall: two control plane nodes holding different databases Symptom: a destination is reachable from some edge nodes and not others, with the split following which control plane node each requester happened to query rather than any topological boundary. Cause: registrations are reaching one node and not the other, so one database is complete and the other is not. Because queries are load-shared, the result is intermittent and appears random. Confirm: show lisp site summary on both nodes shows different registered counts; show lisp instance-id <id> ipv4 server <prefix> succeeds on one and fails on the other. Fix: find which edge nodes are not registering to the incomplete node — usually a subset with a common underlay path or a common provisioning event.

The silent refusal

Pitfall: registrations refused with no indication at the sender Symptom: an edge node's database looks perfect, its endpoints are all present, and none of them is reachable from anywhere else in the fabric. Every command run on the switch reports success. Cause: the Map Server is refusing the registrations — wrong key, prefix outside the site's permitted list, or a missing instance ID — and the protocol provides no negative acknowledgement, so the switch cannot know. Confirm: the Map-Notify counter on the edge is not tracking its Map-Register counter, and the control plane node's registration error counters are rising. Fix: correct the site definition or key on the control plane node; in an automated fabric, re-provisioning the edge node from the controller resolves most instances.

A four-command health check

! Run on both control plane nodes and compare
show lisp site summary
! ^ registered counts should match between CP nodes
show lisp site detail | include Registration errors -A 3
! ^ any rising error counter is a finding
show lisp instance-id * ipv4 server summary
! ^ per-VN totals, to spot one VN that is not populating
show lisp session
! ^ one established session per edge node, on BOTH CP nodes

What to monitor continuously

Four items, none of which any fabric dashboard covers by default. Registered endpoint count per control plane node, alerting on divergence between the two rather than on an absolute value. Registration error counters, alerting on any increase. Session count per control plane node, alerting when it drops below the edge node count. And negative map-cache entries for internal prefixes, sampled across edge nodes. The first three are cheap; the fourth catches the failure that never announces itself.

Making the comparison automatic

Comparing two control plane nodes by hand is exactly the kind of check that is done during commissioning and never again. Automating it is straightforward: collect the registered count from each node on a schedule, subtract, and alert on any non-zero difference that persists across two consecutive samples. The transient differences during normal registration churn are small and short, so a two-sample confirmation removes the noise without hiding anything real.

The same pattern applies to the session count. Each control plane node should hold one established session per edge node, and that number is known — it is the fabric's device inventory. Alerting when the observed count falls below the expected one turns the one-sided registration failure from something discovered during a maintenance window into something discovered the day it happens.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers the LISP control plane within the software-defined infrastructure domain, and the mapping system usually appears as a role question: what a Map Server does that a Map Resolver does not, what happens when a control plane node fails, and which command shows whether an endpoint is registered. Being able to distinguish the two functions and name show lisp site covers most of it.

Every quiet failure here is found by comparisonNone of the four is visible from a single device or a single command — each requires comparing two things: two control plane nodes, two counters, a session count against a device count, or a prefix against an addressing plan. That is why routine comparison is worth more in this area than any amount of per-device monitoring.
Sub claimAll four of the hard-to-see mapping system failures report success on every device involved, which makes comparison between two things — not inspection of one — the only technique that finds them.

Conclusion

The Map Server and Map Resolver do different jobs and fail differently. The server owns the database and is the only place a policy about the endpoint namespace exists; when it fails, one switch's endpoints are missing from the whole fabric. The resolver owns the query path and holds no authority; when it fails, one switch can find nothing while its own hosts remain perfectly reachable. Knowing which symptom belongs to which function sends you to the right device immediately.

Site definitions are where registrations are accepted or refused, and the refusal is silent by design. An edge node whose key is wrong, or whose subnet falls outside the permitted prefix list, keeps registering forever and keeps believing it worked. That single property explains why "these hosts are unreachable" investigations belong on the control plane node rather than on the switch that appears to be the problem, and why the acknowledgement counter is the one worth watching.

Redundancy is two independent copies rather than a synchronised pair, which removes an entire class of replication failure and introduces a different discipline: the two databases should match, so comparing them is a real check rather than a formality. Together with registration error counters, session counts and a periodic look for negative entries pointing at internal addresses, that comparison finds the failures that every individual device is reporting as a success.

Reference Notes

  1. RFC 6833 defines the Map-Server interface, in which an ETR registers EID prefixes and the Map-Server authenticates and accepts or discards those registrations.
  2. RFC 6833 describes the Map-Resolver as accepting Map-Requests from ITRs and forwarding them into the mapping system, holding no authoritative mapping data of its own.
  3. RFC 9301 specifies the LISP control plane, including the Map-Register and Map-Notify exchange and the authentication applied to registrations.
  4. RFC 9301 describes negative Map-Replies, which are returned when no mapping exists and carry an action instructing the requester how to handle the traffic.
  5. RFC 9301 notes that negative mappings are cached for shorter periods than positive ones, so that a subsequently registered EID is discovered without a long delay.
  6. RFC 9301 describes the proxy Map-Reply behaviour, in which a Map-Server answers on behalf of registered ETRs rather than forwarding the request to them.
  7. RFC 9300 defines the Instance ID, which provides separate EID namespaces and corresponds to a virtual network in SD-Access.
  8. RFC 8111 defines the LISP Delegated Database Tree, a hierarchical mapping database referral mechanism for large deployments.
  9. Cisco documentation describes the LISP site construct, containing an authentication key and the EID prefixes a site is permitted to register.
  10. Cisco documentation describes the accept-more-specifics keyword, without which registrations more specific than the configured EID record are rejected.
  11. Cisco documentation describes extranet policy on the Map Server, which permits lookups from subscriber instance IDs into a provider instance ID.
  12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include LISP and SD-Access control plane operation within the software-defined infrastructure domain.