This is first blog about the LISP (Locator/ID Separation Protocol) defined in RFC 6830 https://tools.ietf.org/html/rfc6830, which is a future reach routing architecture. First I am going to provide some information about the LISP and then focus on some practical examples for LISP-to-LISP site communication. The LISP separates the location from the identity, in other word it separates the end user device identifiers (EID) from the routing locators (RLOC). Let’s look at some main components of the LISP. The following are some of the key components that build the LISP architecture:
- ITR (Ingress tunnel router) – receives the packet from local site and encapsulates them to the remote LISP site or natively forwards the packet to a non LISP sites.
- ETR (Egress tunnel router) – receives packet from the core network and de-encapsulates the packet and sends it to site.
- PITR (Proxy ingress tunnel router) – receives packet from non LISP sites and encapsulates the packet to LISP sites or forward them natively.
- PETR (Proxy egress tunnel router) – de-encapsulates packets from LISP sites to deliver them to non LISP sites
- MS (Map server) – is a mapping database which is accepting registration requests from its client egress tunnel routers (ETRs)
- MR (Map resolver) – The function of the LISP MR is to accept encapsulated Map-Request messages from ingress tunnel routers (ITRs), decapsulate those messages, and then forward the messages to the MS responsible for the egress tunnel routers (ETRs) that are authoritative for the requested EIDs.
The topology below illustrates high level overview how LISP works.
In this topology, when host with IP address 10.10.1.1 tries to reach host with IP address 10.10.2.1, it sends the packet to the local ITR (EDGE01) at the site. Then, if the ITR does not have an entry in its map cache table, the ITR creates a map request looking for the host 10.1.2.2 and sends it to the MR. The map request is also LISP encapsulated where the outer header has the source IP address of 150.1.1.19 and destination IP address of 150.1.1.2 (MS/MR). The MS redirects the packet to the ETR (EDGE02), which has the information about the host prefix/subnet. One think to notice is that MS and MR role can be combine and provide by the same node. Furthermore, another important thing to notice is that the map request comes toward the mapping system, but the mapping system does not send the reply. The ETR sends the map reply directly to the ITR that raised the map request. The map reply contain the mapping entries of the ETRs with destination EIDs.
The diagram below is a simple network which I am going to use to demonstrate how to configure and verify basic LISP functionality. In the first scenario I am going to focus on communication between LISP sites only. Implementing LISP in this scenario requires configuration of two LISP components and is very straightforward: ITR an ETR on each router and the MS/MR node. ITR and ETR on the same nodes is called xTR.
At each LISP site there is OSPF running between xTR node and inside switch. In addition, there is BGP between xTR and ISP. One thing to notice is that internal EID prefixes are not advertises toward ISP’s. I am going to show only LISP related configuration as BGP and OSPF configuration is very basic in this example and only provides underlay transport for RLOC’s and MS/MR
Below is EDGE01 node LISP related configuration:
EDGE01#sh run | sec lisp
router lisp
eid-table default instance-id 0
database-mapping 10.10.1.0/24 150.1.1.19 priority 1 weight 100
ipv4 map-request-source 150.1.1.19
ipv4 itr map-resolver 150.1.1.2
ipv4 itr
ipv4 etr map-server 150.1.1.2 key cisco
ipv4 etr
exit
!
exitEDGE02 node is IOS-XE and recently Cisco has change syntax on that platform so is different from regular IOS. Please refer to the Cisco documentation for more details.
EDGE02#sh run | sec lisp
router lisp
service ipv4
exit-service-ipv4
!
instance-id 0
service ipv4
eid-table default
database-mapping 10.10.2.0/24 150.1.1.31 priority 1 weight 100
itr map-resolver 150.1.1.2
itr
etr map-server 150.1.1.2 key cisco
etr
map-request-source 150.1.1.31
exit-service-ipv4
!
service ipv6
eid-table default
exit-service-ipv6
!
exit-instance-id
!
exit-router-lispFinally MS/MR node LISP related configuration
MS-MR#sh run | sec lisp
router lisp
locator-table default
site AS-200
authentication-key cisco
eid-prefix 10.10.2.0/24
exit
!
site AS-300
authentication-key cisco
eid-prefix 10.10.1.0/24
exit
!
ipv4 map-server
ipv4 map-resolver
exitAs you see LISP configuration is very straightforward to provide communication between LISP site. In the ASA 100 which simulate Internet LISP functionality is deployed only on the MS/MR node. Other nodes in the AS 100 does not have LISP functionality enable.
The LISP network is divided into two routing domains, the RLOC and EID where each of these domain has own routing address space. The EID routing domain is running OSPF, while RLOC is running BGP only as shown on the above network diagram. The xTR router rely on MS/MR router to resolver the EID to RLOC mapping so underlay network must be working and must provide basic connectivity between RLOC and MS/MR node.
Furthermore, as shown below local EID prefixes 10.10.1.0/24 is not advertised into ISP network from EDGE01. The same is true for EDI 10.10.2.0/24 which is not advertises from EDGE02 node to the ISP. These prefixes will use LISP encapsulation to provide connectivity between LISP sites.
EDGE01#sh ip bgp neighbors 110.1.194.14 advertised-routes
BGP table version is 16, local router ID is 192.168.1.19
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 110.1.194.0/24 0.0.0.0 0 32768 i
*> 150.1.1.19/32 0.0.0.0 0 32768 i
EDGE02#sh ip bgp neighbors 110.1.133.13 advertised-routes
BGP table version is 53, local router ID is 192.168.1.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 150.1.1.31/32 0.0.0.0 0 32768 i
*> 192.168.1.13/32 110.1.133.13 0 0 100 i
Note that EDGE01 has only its own LISP site prefix 10.10.1.0/24 in the routing table and does not have knowledge about the prefix 10.10.2.0/24 from remote LISP site.
EDGE01#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.10.1.0/24 [110/11] via 10.19.21.21, 00:36:21, Ethernet0/2
C 10.19.21.0/24 is directly connected, Ethernet0/2
L 10.19.21.19/32 is directly connected, Ethernet0/2
110.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 110.1.194.0/24 is directly connected, Ethernet0/0
L 110.1.194.19/32 is directly connected, Ethernet0/0
150.1.0.0/32 is subnetted, 3 subnets
B 150.1.1.2 [20/0] via 110.1.194.14, 00:36:04
C 150.1.1.19 is directly connected, Loopback100
B 150.1.1.31 [20/0] via 110.1.194.14, 00:36:04
192.168.1.0/32 is subnetted, 9 subnets
B 192.168.1.2 [20/0] via 110.1.194.14, 00:36:04
C 192.168.1.19 is directly connected, Loopback0
O 192.168.1.21 [110/11] via 10.19.21.21, 00:36:21, Ethernet0/2Output below shows basic ICMP test connectivity from both RLOC nodes to MS/MR node.
EDGE01#ping 150.1.1.2 source 150.1.1.19
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.1.19
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
EDGE01#
EDGE02#ping 150.1.1.2 source 150.1.1.31
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.1.31
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
EDGE02#Now when basic underlay connectivity is in place, lets look at LISP control plane and try to understand how it works. First Lest check if LISP is enable and what specific functions are enable per node.
As you see LISP functionality is enable on the EDGE01 node. This command show ip lisp gives you a lot of information like what specific LISP component is enabled. In this Example only ITR and ETR is. In addition, you can see what is default map-cache TTL, local RLOC IP address and what is IP of MS/MR.
EDGE01#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: 150.1.1.19
ITR Map-Resolver(s): 150.1.1.2
ETR Map-Server(s): 150.1.1.2 (00:44:40)
xTR-ID: 0x5ADBBC84-0x900F8939-0xC7BF4C56-0xC96D6C79
site-ID: unspecified
ITR local RLOC (last resort): 150.1.1.19
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: 1/1000
Imported route count/limit: 0/1000
Map-cache activity check period: 60 secs
Map-cache FIB updates: established
Total database mapping size: 1
static database size/limit: 1/5000
dynamic database size/limit: 0/1000
route-import database size: 0
Inactive (deconfig/away) size: 0
Persistent map-cache: disabledThe second RLOC has exactly the same information so not going to show the output from that node. Now lets look at MS/MR output. The output is exactly the sam as for RLOC, however as you can see different functional services are enabled, which in this case is MS and MR.
MS-MR#sh ip lisp
Instance ID: 0
Router-lisp ID: 0
Locator table: default
EID table: N/A
Ingress Tunnel Router (ITR): disabled
Egress Tunnel Router (ETR): disabled
Proxy-ITR Router (PITR): disabled
Proxy-ETR Router (PETR): disabled
NAT-traversal Router (NAT-RTR): disabled
Mobility First-Hop Router: disabled
Map Server (MS): enabled
Map Resolver (MR): enabled
Delegated Database Tree (DDT): disabled
Map-Request source: derived from EID destination
ITR local RLOC (last resort): *** NOT FOUND ***
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: 0/1000
Imported route count/limit: 0/1000
Map-cache activity check period: 60 secs
Map-cache FIB updates: pre-init
Total database mapping size: 0
static database size/limit: 0/5000
dynamic database size/limit: 0/0
route-import database size: 0
Inactive (deconfig/away) size: 0
Persistent map-cache: disabledOther useful command we can run on MS/MR node to verify control-plane is show lisp site details. That command gives you an information what specific xTR node is registered with the map server.
The output confirms that both RLOC node are registered with MS/MR node and what EID-prefix is behind specific RLOC device. As you see for example AS-200 sites registered prefix 10.10.2.0/24 with the locator IP 150.1.1.31.
MS-MR#sh lisp site detail
LISP Site Registration Information
Site name: AS-200
Allowed configured locators: any
Allowed EID-prefixes:
EID-prefix: 10.10.2.0/24
First registered: 00:57:37
Last registered: 00:00:09
Routing table tag: 0
Origin: Configuration
Merge active: No
Proxy reply: No
TTL: 1d00h
State: complete
Registration errors:
Authentication failures: 0
Allowed locators mismatch: 0
ETR 110.1.133.1, last registered 00:00:09, no proxy-reply, map-notify
TTL 1d00h, no merge, hash-function sha1, nonce 0x7E3B12B7-0x0E9899B1
state complete, no security-capability
xTR-ID 0x3DDFAB35-0xFAF31FC8-0xA78CA361-0x6AE9B407
site-ID unspecified
Locator Local State Pri/Wgt Scope
150.1.1.31 yes up 1/100 IPv4 none
Site name: AS-300
Allowed configured locators: any
Allowed EID-prefixes:
EID-prefix: 10.10.1.0/24
First registered: 00:57:18
Last registered: 00:56:14
Routing table tag: 0
Origin: Configuration
Merge active: No
Proxy reply: No
TTL: 1d00h
State: complete
Registration errors:
Authentication failures: 0
Allowed locators mismatch: 0
ETR 150.1.1.19, last registered 00:56:14, no proxy-reply, map-notify
TTL 1d00h, no merge, hash-function sha1, nonce 0x56073406-0xB625087B
state complete, no security-capability
xTR-ID 0x5ADBBC84-0x900F8939-0xC7BF4C56-0xC96D6C79
site-ID unspecified
sourced by reliable transport
Locator Local State Pri/Wgt Scope
150.1.1.19 yes up 1/100 IPv4 noneOther useful command is show lisp session which gives information about peer and its status.
MS-MR# show lisp session
Sessions for VRF default, total: 2, established: 2
Peer State Up/Down In/Out Users
150.1.1.19 Up 01:00:58 1/3 1
150.1.1.31 Up 01:01:16 1/2 0Now we can look at data plane and try to understand how LISP forwards packets in the network. In this example IP address 10.10.1.1 in site AS-300 is communicating with IP address 10.10.2.1 in AS-200 for the first time
The routing table on the LAN switch site AS-300 has only default route towards EDGE01 node which has no information about 10.10.2.0/24 prefix.
SW1#sh ip route
Gateway of last resort is 10.19.21.19 to network 0.0.0.0
O*E2 0.0.0.0/0 [110/1] via 10.19.21.19, 01:20:01, Ethernet0/0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.1.0/24 is directly connected, Loopback100
L 10.10.1.1/32 is directly connected, Loopback100
C 10.19.21.0/24 is directly connected, Ethernet0/0
L 10.19.21.21/32 is directly connected, Ethernet0/0
192.168.1.0/32 is subnetted, 1 subnets
C 192.168.1.21 is directly connected, Loopback0EDGE01#sh ip route
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.10.1.0/24 [110/11] via 10.19.21.21, 01:20:35, Ethernet0/2
C 10.19.21.0/24 is directly connected, Ethernet0/2
L 10.19.21.19/32 is directly connected, Ethernet0/2
110.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 110.1.194.0/24 is directly connected, Ethernet0/0
L 110.1.194.19/32 is directly connected, Ethernet0/0
150.1.0.0/32 is subnetted, 3 subnets
B 150.1.1.2 [20/0] via 110.1.194.14, 01:20:18
C 150.1.1.19 is directly connected, Loopback100
B 150.1.1.31 [20/0] via 110.1.194.14, 01:20:18
192.168.1.0/32 is subnetted, 9 subnets
C 192.168.1.19 is directly connected, Loopback0
In addition EDGE01 node LISP map-cahce has no information about remote EID-prefixes and is empty
EDGE01#show ip lisp map-cache
LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries
0.0.0.0/0, uptime: 01:22:19, expires: never, via static send map-request
Negative cache entry, action: send-map-requestLets run a ping from AS-300 IP 10.10.1.1 to remote IP 10.10.2.1 at remote site AS-200. As illustrated below first two pings failed and this is expected behavior for the first time because xTR device EDGE01 had to resolver the RLOC address for the destination EID IP 10.10.2.1
SW1# ping 10.10.2.1 source 10.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.1
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 3/19/53 msNow lets look at the packet capture taken at EDGE01 device to see what exactly happens in the date plane for that communication. This is the first LISP packet sent from RLOC EDGE01. As shown the scr IP of the packet is 150.1.1.19 and dst is 150.1.1.2 MS/MR. That LISP packet is MAP-Request which contains source EID 10.10.1.1 and MAP-Request record for 10.10.2.1/32.
The second LISP packet is Map-Replay which contains remote EID prefix 10.10.2.0 and remote RLOC 150.1.1.31 but it’s worth to note that this replay is directly from remote RLOC which has EID 10.10.2.0/24.
The third LISP packet at EDGE01 device is actually map-request from MS/MR node for EDGE02 device as remote RLOC had to perform exactly the same lookup because for the first time communication had no knowledge about the prefix 10.10.1.0/24
The last LISP packet is direct replay from EDGE01 to EDGE02 with its local EID prefix and IP address of RLOC.
At this stage mapping was completed and ping was successful. Belo is ICMP packet capture which shows that firs ICMP was unsuccessful because the lookup was still in progress.
Now let’s look at EDGE01 RLOC device to verify map-cache entry. As presented below there is specific entry now for remote EID-prefix 10.10.2.0/24 with the remote locator IP 150.1.1.31. Furthermore you can see what is priority, weight and TTL for the remote RLOC.
EDGE01#show ip lisp map-cache
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries
0.0.0.0/0, uptime: 01:28:36, expires: never, via static send map-request
Negative cache entry, action: send-map-request
10.10.2.0/24, uptime: 00:04:20, expires: 23:55:39, via map-reply, complete
Locator Uptime State Pri/Wgt
150.1.1.31 00:04:20 up 1/100In the next part I will look into LISP to Non-LISP site communication and what function provides PITR and PETR.
netmindblog 