LISP (Locator/ID Separation Protocol) – Part I

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
 !
 exit

EDGE02 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-lisp

Finally 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
 exit

As 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/2

Output 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:             disabled

The 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:             disabled

Other 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 none

Other 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      0

Now 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, Loopback0
EDGE01#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-request

Lets 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 ms

Now 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/100

In the next part I will look into LISP to Non-LISP site communication and what function provides PITR and PETR.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s