Lab Objective
Configure a LISP map server/resolver representing the fabric control plane, configure two fabric edge nodes to register connected endpoints, and verify traffic between endpoints on different edge nodes is VXLAN-encapsulated based on location information learned via LISP rather than static configuration.
Lab Purpose
The static and BGP EVPN VXLAN labs covered earlier in this series used either manual peer lists or BGP to distribute MAC/IP reachability. SD-Access instead uses LISP (Locator/ID Separation Protocol) as its control plane, separating an endpoint's identity (its IP address) from its location (which fabric edge node it is attached to) — a distinction central to SD-Access's ability to support endpoint mobility across the fabric.
Lab Topology
MapServer (control plane node)
FabricEdge1 ---- HostA: 192.168.100.10
FabricEdge2 ---- HostB: 192.168.100.11
Both edge nodes registered with MapServerTask 1: Configure the Map Server/Resolver
Configure the control plane node as a LISP map server and map resolver for the fabric's endpoint prefix range.
Task 2: Configure FabricEdge1 to Register HostA
Configure FabricEdge1 as a LISP xTR, registering HostA's specific /32 address with the map server upon detecting it locally.
Task 3: Configure FabricEdge2 to Register HostB
Configure FabricEdge2 similarly for HostB.
Task 4: Verify Both Endpoints Are Registered
Confirm the map server shows both HostA and HostB's specific location (RLOC) mappings.
Task 5: Verify Traffic Uses LISP-Learned Location for Encapsulation
Generate traffic from HostA to HostB and confirm FabricEdge1 queries LISP for HostB's location and encapsulates traffic toward FabricEdge2's RLOC.
Solution and Verification
MapServer(config)# router lisp
MapServer(config-router-lisp)# site FABRIC-SITE
MapServer(config-router-lisp-site)# authentication-key LispKey2026
MapServer(config-router-lisp-site)# eid-prefix 192.168.100.0/24FabricEdge1(config)# router lisp
FabricEdge1(config-router-lisp)# database-mapping 192.168.100.10/32 [FabricEdge1-RLOC] priority 1 weight 100
FabricEdge1(config-router-lisp)# map-server [MapServer-address] key LispKey2026
FabricEdge1(config-router-lisp)# map-resolver [MapServer-address]
-- The database-mapping registers a
-- specific host, not the whole subnet --
-- this per-endpoint granularity is what
-- allows an individual host to move
-- between fabric edge nodes while keeping
-- its own IP addressFabricEdge2(config)# router lisp
FabricEdge2(config-router-lisp)# database-mapping 192.168.100.11/32 [FabricEdge2-RLOC] priority 1 weight 100
FabricEdge2(config-router-lisp)# map-server [MapServer-address] key LispKey2026
FabricEdge2(config-router-lisp)# map-resolver [MapServer-address]MapServer# show lisp site
Site Name Last Register EID Prefix
FABRIC-SITE 00:00:12 192.168.100.10/32
FABRIC-SITE 00:00:09 192.168.100.11/32
-- Both specific host addresses (not the
-- containing /24) are registered
-- independently, each with its own RLOCHostA> ping 192.168.100.11
-- FabricEdge1 has no local knowledge of
-- where 192.168.100.11 lives, so it queries
-- the map resolver:
FabricEdge1# show lisp dynamic-eid detail
192.168.100.11/32, via map-cache, RLOC:
FabricEdge2-address, priority 1, weight 100
-- The map-cache entry confirms FabricEdge1
-- learned HostB's location dynamically via
-- LISP, then used that RLOC as the VXLAN
-- encapsulation destination for the actual
-- data trafficKey Takeaway
LISP's core architectural principle — separating an endpoint's identity (EID, its IP address) from its location (RLOC, the fabric edge node it's attached to) — is what SD-Access relies on for endpoint mobility: if HostA physically moved to a different fabric edge node, only its database-mapping registration would need to update, and every other fabric device querying LISP would automatically learn the new location without any manual reconfiguration, a capability neither the static VXLAN nor BGP EVPN labs covered earlier in this series were designed to provide.