Overview of LISP Support for Disjointed RLOC Domains
Locator/ID Separation Protocol (LISP) implements a level of indirection that enables a new IP routing architecture. LISP separates IP addresses into two address spaces, Endpoint Identifiers (EIDs), which are assigned to end hosts, and Routing Locators (RLOCs), which are assigned to devices that make up the global routing system.
This feature enables communication between LISP sites that are connected to different RLOC spaces and have no connectivity to each other.
Prerequisites for LISP Support for Disjointed RLOC Domains
- You understand how LISP works, including infrastructure, workflow, roles and functions.
Information About LISP Support for Disjointed RLOC Domains
The fundamental principle of any network is that routing and reachability should exist between all devices that make up the total network system. There are many network systems, public and private, for which internetwork connectivity is not directly available.
-
A Multiprotocol Label Switching (MPLS) IPv4 VPN from service provider A and an MPLS IPv4 VPN from service provider B, with different scopes, 10.1.0.0/16 and 10.2.0.0/16.
-
An MPLS IPv4 VPN from service provider A and IPv4 internet.
When some sites within a network connect to one routing domain and other sites connect to another routing domain, a gateway function must be provided to facilitate connectivity between these disjointed routing domains. In traditional routing architectures, providing connectivity between disjointed routing domains can be quite complex. The inherent property of LISP, which separates IP addresses into two address spaces, gives it the ability to connect disjointed RLOC domains through simplified configuration mechanisms. The key components are new control plane configuration options on the LISP Map-Server, and the Re-encapsulating Tunnel Router (RTR) function, which provides data plane connectivity between disjointed locator spaces. The components and the workflow are explained.
LISP Map-Server
When a LISP site registers with the Map-Server, it provides RLOC information. Ensure that all relevant RLOCs are registered with the Map-Server. Map-Server configurations are required to enable connectivity across RLOC spaces.
Note |
A device with IOS XE software is used for the role of Map-Server. For more information, see IP Routing: LISP Configuration Guide, Cisco IOS XE Release 3S. |
LISP RTR
An RTR provides data plane communications support for LISP to LISP traffic between LISP sites that do not share common locator space. Functionally, an RTR takes in LISP encapsulated packets from an Ingress Tunnel Router (ITR) in one locator scope, decapsulates them, checks the map-cache, and then re-encapsulates them to an Egress Tunnel Router (ETR) in another locator scope. The following are important considerations for an RTR:
-
RTR should have RLOCs in all locator scopes that are being joined.
-
An RTR sends Map-Request messages to populate its map-cache. As a Map-Request message contains an ITR RLOC field that is populated with one or more entries corresponding to the locators of the device sending the Map-Request message, locator set configuration is required on the RTR to define its locators. This enables the Map-Server to correctly receive Map-Request messages from the RTR to assess locator scope connectivity.
-
Since an RTR performs functions similar to a Proxy Ingress Tunnel Router (PITR) and Proxy Egress Tunnel Router (PETR), the PITR and PETR features must be enabled on the RTR.
Note |
Cisco Nexus 7000 Series device is used for the PxTR (a device performing PITR and PETR functions) and RTR functions. |
Workflow of LISP Support for Disjointed RLOC Domains
For connecting disjointed RLOC domains in topology:
-
Specified prefixes form the EID space in site A and site B.
-
Ingress and Egress tunnel routers (referred as xTRs) represent the LISP site routers. xTR 1 and xTR 2 in site A have RLOC connectivity to one locator space, and the xTR in site B has RLOC connectivity to a different locator space.
-
The RTR (PxTR 1, PxTR 2) is the LISP data plane device that enables communication between end hosts in the two sites, across locator spaces.
-
Two virtual routing and forwarding (VRF) instances are created on the RTRs, one for the underlay (VRF core), and one for the overlay (VRF vrf5000).
Note |
Map-Servers and RTRs can be connected to eight locator scopes or address spaces. |
An end host connected to xTR 1 in site A sends traffic to an end host attached to the xTR in site B. Since the source and destination RLOCs are from different RLOC spaces, PxTR 1 performs the role of RTR to transport traffic across the RLOC spaces. The detailed workflow:
-
xTR 1 (acting as an ITR) receives traffic from an attached end host, and sends a Map-Request for the destination EID (198.51.100.10), to the Map-Server (denoted by the IP address 192.0.2.9/32).
-
The Map-Server responds with a proxy reply containing the configured RTR locators (with IP addresses 192.0.2.1 and 203.0.113.15). The Map-Server does because the ITR-RLOC in the Map-Request from xTR 1 contains the RLOC from site A.
-
xTR 1 populates its map-cache with locator information (that is, PxTR 1 and PxTR 2 RLOCs) for the RTRs.
-
xTR 1 encapsulates LISP traffic and forwards it to the RTR in the data plane.
-
The RTR decapsulates the ingress LISP traffic and sends a Map-Request to the Map-Server for the destination EID, for the first packet.
-
The ITR-RLOC of the Map-Request comprises the locators configured under the locator set. The locators are 192.0.2.10 and 192.0.2.21.
A Map-Request is sent because the static map-cache is configured with the map-request command.
-
The Map-Server forwards the Map-Request to the ETR. The Map-Server does because the ITR-RLOC in the Map-Request from the RTR contains RLOCs from site A and site B.
-
The ETR replies to the RTR with the ETR locator information.
-
The RTR populates its map-cache with the ETR locator information.
-
The RTR re-encapsulates LISP traffic forwards the ETR.
-
The ETR receives and sends traffic to the destination end host.
How to Configure LISP Support for Disjointed RLOC Domains
Note |
|
RTR configuration on PxTR 1 and the Map-Server:
PxTR 1 or RTR Configuration
Step 1 Configure LISP
(config)# feature lisp
Step 2 Create two VRF instances on the RTR, one for the underlay (VRF core), and one for the overlay (VRF vrf5000).
Configure LISP parameters for the core VRF
(config)# vrf context core
ip lisp itr-etr
ip lisp itr map-resolver 192.0.2.9/32
ip lisp etr map-server 192.0.2.9/32 key 3 a97b0defe7b8ff70
ip lisp multicast
lisp encapsulation vxlan
-
After configuring the LISP ITR and ETR functions on PxTR 1, the LISP Map-Resolver (used by the ITR to send Map-Requests) and Map-Server (used by the ETR to register EIDs) locator addresses are configured.
-
Also, LISP multicast transport and LISP Virtual Extensible LAN (VXLAN) encapsulation functions are enabled.
Configure LISP parameters for the vrf5000 VRF
(config)# vrf context vrf5000
ip lisp proxy-itr 192.0.2.1
ip lisp proxy-etr
lisp instance-id 5000
The following configuration chunk is specific to connecting disjointed RLOC spaces.
lisp locator-set set5000
192.0.2.10 priority 1 weight 10
192.0.2.21 priority 2 weight 20
exit
lisp map-request itr-rlocs set5000
ip lisp locator-vrf core
ip lisp map-cache 198.51.100.1/24 map-request
ip lisp map-cache 198.51.100.2/24 map-request
ip lisp multicast
lisp encapsulation vxlan
-
The lisp locator-set command specifies a locator set for RTR RLOCs. 192.0.2.10 and 192.0.2.21 are the RLOCs connecting the RTR to each IPv4 locator space.
-
The lisp map-request itr-rlocs command defines RTR RLOCs used in the Map-Request messages generated by the RTR. You can enable multiple locator sets, but only one of them can be active at a point in time, and that is determined by including the name in the lisp map-request itr-rlocs option.
-
Since Map-Resolver and Map-Server addresses are enabled in VRF core, VRF core is referenced within VRF vrf5000, in the locator-vrf core command.
Step 3 Configure an IP address for routing in the underlay
(config)# interface loopback0
vrf member core
ip address 192.0.2.1/32
isis circuit-type level-1-2
ip router isis 100
ip pim sparse-mode
The configured loopback interface IP address is used for IS-IS communication within the LISP site, and is added to VRF core.
Step 4 The configurations are relevant for RTR or PxTR 1. Similarly, configure the RTR or PxTR 2 device too.
PxTR 1 or RTR Configuration—RTR Locator-Set Inheritance
An RTR locator set can be defined in the underlay VRF and can then be referenced in an overlay VRF.
Step 1 Configure LISP
(config)# feature lisp
Step 2 Create two VRF instances on the RTR, one for the underlay (VRF core), and one for the overlay (VRF vrf5000).
Configure LISP parameters for the core VRF
(config)# vrf context core
ip lisp itr-etr
ip lisp itr map-resolver 192.0.2.9/32
ip lisp etr map-server 192.0.2.9/32 key 3 a97b0defe7b8ff70
lisp locator-set setCore
192.0.2.10 priority 1 weight 10
192.0.2.21 priority 2 weight 20
exit
ip lisp multicast
lisp encapsulation vxlan
Note |
The LISP locator set setCore is defined in the underlay VRF core and then associated using the lisp map-request itr-rlocs command in the overlay VRF vrf5000. |
Configure LISP parameters for the vrf5000 VRF
(config)# vrf context vrf5000
ip lisp proxy-itr 192.0.2.1
ip lisp proxy-etr
lisp instance-id 5000
lisp map-request itr-rlocs setCore
ip lisp locator-vrf core
ip lisp map-cache 198.51.100.1/24 map-request
ip lisp map-cache 198.51.100.2/24 map-request
ip lisp multicast
lisp encapsulation vxlan
Step 3 Configure an IP address for routing in the underlay
(config)# interface loopback0
vrf member core
ip address 192.0.2.1/32
isis circuit-type level-1-2
ip router isis 100
ip pim sparse-mode
The configured loopback interface IP address is used for IS-IS communication within the LISP site, and is added to VRF core.
Step 4 The configurations are relevant for RTR or PxTR 1. Similarly, configure the RTR or PxTR 2 device too.
Map-Server Configuration
Note |
|
Map-Server configuration on a device with IOS XE software (not Cisco Nexus 7000 Series device):
(config)# router lisp
locator-table vrf core
locator-set SITEAB
192.0.2.1 priority 1 weight 50
203.0.113.15 priority 1 weight 50
exit
locator-scope site-B
rtr-locator-set SITEAB
rloc-prefix 203.0.113.40/32
rloc-prefix 192.0.2.21/32
rloc-prefix 203.0.113.25/32
exit
locator-scope site-A
rtr-locator-set SITEAB
rloc-prefix 192.0.2.5/32
rloc-prefix 192.0.2.6/32
rloc-prefix 203.0.113.17/32
rloc-prefix 192.0.2.10/32
Verifying LISP Support for Disjointed RLOC Domains
Testing Reachability from xTR 1 in Site A to the xTR in Site B
In the following example, locator information for both sites (192.0.2.1 in site A and 203.0.113.15 in site B) are displayed. xTR 1 in site A is connected to the xTR in site B.
siteA-xTR1# lig 198.51.100.10 instance-id 5000
Mapping information for EID 198.51.100.10 from 192.0.2.9/32 with RTT 2 msecs
198.51.100.10/32, uptime: 00:07:06, expires: 00:14:59, via map-reply, complete
Locator Uptime State Pri/Wgt
192.0.2.1 00:07:06 up 1/50
203.0.113.15 00:07:06 up 1/50
Testing Reachability from PxTR 1 to the xTR in Site B
In the following example, Map-Request, Map-Reply, and map-cache information is displayed. Also, locator information for the xTR in site B is displayed. This signifies that PxTR 1 is connected to the xTR in site B.
PxTR1# lig 198.51.100.10 vrf vrf5000
Send map-request to 192.0.2.9 for [5000] 100.3.3.10 ...
Received map-reply from 203.0.113.40 with rtt 0.003248 secs
Map-cache entry for [5000] EID 198.51.100.10 is:
198.51.100.10/32, uptime: 05:05:47, expires: 23:59:58, via map-reply, auth
Locator Uptime State Priority/Data Control MTU Weight in/out in/out
203.0.113.40 05:05:47 up 10/10 0/0* 2/0 1500
EID Space Details in the Map-Server/Map-Resolver (MSMR)
In the following example, you can see that the client with the specified EID, attached to the xTR in site B, is registered with the MSMR. The specified EID, Instance ID and corresponding locator is displayed.
MSMR# show lisp site 198.51.100.10 instance-id 5000
LISP Site Registration Information
Site name: site-AAllowed configured locators: anyRequested
EID-prefix: EID-prefix: 198.51.100.10/32 instance-id 5000
First registered: 00:19:46
Last registered: 00:19:46
Routing table tag: 0
Origin: Dynamic, more specific of 203.0.0.0/16
Merge active: No
Proxy reply: No
TTL: 1d00h
State: complete
Registration errors:
Authentication failures: 0
Allowed locators mismatch: 0
ETR 203.0.113.40, last registered 00:19:46, no proxy-reply, map-notify
TTL 1d00h, no merge, hash-function sha1, nonce 0x4CC82237-0x6DCB0FC5
state complete, no security-capability
xTR-ID 0x90FA8033-0x867FE73F-0x5F32076D-0xE92E8945
site-ID unspecified
sourced by reliable transport
Locator Local State Pri/Wgt Scope
203.0.113.40 yes up 10/10 site-B
In the following example, corresponding LISP site information for the MSMR is displayed. The information includes, EID, IID, and locator information.
MSMR# show lisp site detail
EID-prefix: 198.51.100.10/32 instance-id 5000
First registered: 08:12:10
Last registered: 08:12:10
Routing table tag: 0
Origin: Dynamic, more specific of 203.0.0.0/16
Merge active: No
Proxy reply: No
TTL: 1d00h
State: complete
Registration errors:
Authentication failures: 0
Allowed locators mismatch: 0
ETR 203.0.113.40, last registered 08:12:10, no proxy-reply, map-notify
TTL 1d00h, no merge, hash-function sha1, nonce 0x4CC82237-0x6DCB0FC5
state complete, no security-capability
xTR-ID 0x90FA8033-0x867FE73F-0x5F32076D-0xE92E8945
site-ID unspecified
sourced by reliable transport
Locator Local State Pri/Wgt Scope
203.0.113.40 yes up 10/10 site-B
Verify LISP map-cache Details on PxTR 1
In the following example, map-cache details corresponding to PxTR 1 for the specified EID are displayed. The information includes locator information.
PxTR1# show ip lisp map-cache 198.51.100.1 vrf vrf5001
LISP IP Mapping Cache for VRF "vrf5001" (iid 5001), 16 entries
* = Locator data counters are cumulative across all EID-prefixes
198.51.100.1/32, uptime: 1d03h, expires: 20:01:07, via map-reply, auth
Last activity: 03:58:42
State: complete, last modified: 1d03h, map-source: 192.0.2.5
Pending hw update: FALSE
Locator Uptime State Priority/ Data Control MTU
Weight in/out in/out
192.0.2.5 1d03h up 10/10 0/0* 2/0 1500
Last up/down state change: 1d03h, state change count: 0
Last data packet in/out: never/1d03h
Last control packet in/out: 03:58:52/never
Last priority/weight change: never/never
Feature History for LISP Support for Disjointed RLOC Domains
This table lists the release history for this feature.
Feature Name |
Release |
Feature Information |
---|---|---|
Connecting LISP Disjointed RLOC Domains |
8.1(1) |
This feature was introduced. |