LISP (Locator/ID Separation Protocol) – Part II PxTR

In previous blog I described basics functional keys of the LISP and how it works for LISP-to-LISP site communication. In this part I am going to focus on how to interconnect LISP site to non LISP site. There is a challenge to provide communication between LISP and no LISP sites because they have completely separate database of connectivity information and use different control plane protocols. The whole idea behind the LISP is a separation of EID and RLOC so using any redistribution mechanism between LISP and non LISP site would contradict the entire purpose of LISP, which is locator and identifier separation.

To establish communication between LISP and non LISP sites an extra components must be use, a proxy ingress tunnel router (PITR), which allows non-LISP sits to send packet toward LISP sites. The PITR attracts traffic from non-LISP sites by advertising aggregate prefixes for the LISP EID into the non-LISP network. When PITR receives packets from non-LISP sites it encapsulate and forward these packets to LISP sites. The second element to establish communication between the LISP and non-LISP sites is called a proxy egress tunnel router (PETR). The PETR allows the communication from the LISP sites to the non-LISP sites. The PETR receives LISP encapsulated traffic from ITR. The PITR and PETR can be combine and deployed on the same node called (PxTR) to provide symmetric traffic when stateful inspection devices are deployed between LISP and non-LISP sites.

Figure below shows the network used in this example to explain the configuration steps in deploying PxTR device to provide communication between the two LISP sites and non-LISP site. In real case scenario where LISP site needs to communicate with non-LISP site on the Internet, EID prefix either must be public range or NAT-ed to make sure non-LISP site can reach it from the Internet.

The PxTR device is part of AS100 and is running eBGP between own AS and AS1000. The AS1000 advertised prefix 200.1.1.0/24 with standard community no-advertise to make sure this prefix is not advertised to any peer within AS100. Furthermore PxTR router has static route to Null for prefix 10.10.0.0/16 and advertises only that prefix to AS1000. In other words AS100 has no knowledge about the non-LISP prefix and only PxTR node is aware about AS1000 prefix 200.1.1.0/24.

Below is configuration for EDGE01 xTR device to use PxTR. The only difference to compare previous configuration for LISP-to-LISP communication is following command ipv4 use-petr 150.1.1.10. This command specify IP of the PETR device for traffic destined to non-LISP IPv4 destinations.

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 use-petr 150.1.1.10
  ipv4 itr map-resolver 150.1.1.2
  ipv4 itr
  ipv4 etr map-server 150.1.1.2 key cisco
  ipv4 etr
  exit
 !
 exit

The next cofig snip is for EDGE02 IOX-XE device.

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
   use-petr 150.1.1.10
   no proxy-etr
   exit-service-ipv4
  !
  service ipv6
   eid-table default
   exit-service-ipv6
  !
  exit-instance-id
 !
 exit-router-lisp

Finally last config snip below is for PxTR device which provides PETR and PITR role. As you can see here EID aggregate prefix 10.10.0.0/16 is configure, which covers all EID prefixes for all LISP sites.

router lisp
 locator-table default
 eid-table default instance-id 0
  map-cache 10.10.0.0/16 map-request
  exit
 !
 ipv4 map-request-source 150.1.1.10
 ipv4 proxy-etr
 ipv4 proxy-itr 150.1.1.10
 ipv4 itr map-resolver 150.1.1.2

In addition, below config shows BGP related configuration for PxTR node where static route 10.10.0.0/16 to Null is configured. This static route covers all EID prefixes for LISP sites and is advertised to AS1000 only.

router bgp 100
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 110.1.150.15 remote-as 1000
 neighbor 192.168.1.2 remote-as 100
 neighbor 192.168.1.2 update-source Loopback0
 !
 address-family ipv4
  network 150.1.1.10 mask 255.255.255.255
  network 192.168.1.10 mask 255.255.255.255
  redistribute static
  neighbor 110.1.150.15 activate
  neighbor 110.1.150.15 route-map AS1000-OUT out
  neighbor 192.168.1.2 activate
  neighbor 192.168.1.2 next-hop-self
  neighbor 192.168.1.2 route-map DENY_STATIC out
 exit-address-family
!
ip route 10.10.0.0 255.255.0.0 Null0
!
ip prefix-list NULL seq 5 permit 10.10.0.0/16
!
route-map DENY_STATIC deny 10
 match ip address prefix-list NULL
!
route-map DENY_STATIC permit 100
!
route-map AS1000-OUT permit 10
 match ip address prefix-list NULL

The MS/MR configuration is exactly the same as in previous blog so I am not going to show that config here.

Lets check first connectivity from EDGE01 and EDGE02 routers to PxTR node.

EDGE01#ping 150.1.1.10 source 150.1.1.19
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.10, 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 = 2/2/3 ms

EDGE02#ping 150.1.1.10 source 150.1.1.31
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.10, 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 = 2/2/5 ms
EDGE02#

Both of these nodes have basic connectivity to PxTR. The next step is to verify EDGE01 routing table. As depicted below that router has no knowledge about external no-LISP site prefix 200.1.1.0/024. As mentioned above this is because that prefix was filter out at the PxTR router and is not advertised into the AS100.

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, 03:38:25, 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, 4 subnets
B        150.1.1.2 [20/0] via 110.1.194.14, 03:36:45
B        150.1.1.10 [20/0] via 110.1.194.14, 03:13:53
C        150.1.1.19 is directly connected, Loopback100
B        150.1.1.31 [20/0] via 110.1.194.14, 03:32:44

The final step is to verify communication from LISP sites to non-LISP site using the PxTR router. Before running ICMP lets check how lisp map-cache looks like on the EDGE01 node. As depicted below there is none entries.

EDGE01#show ip lisp map-cache  
LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries

0.0.0.0/0, uptime: 00:00:22, expires: never, via static send map-request
  Negative cache entry, action: send-map-request

ICMP output for host communication from 10.10.1.1 to 200.1.1.1 shows that success rate is 60 percent because for the first time communication LISP lookup needs to be perform.

HOST#ping 200.1.1.1 source 10.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.1.1.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 = 4/4/4 ms

Now lest verify LISP map-catche entries on the EDGE01 node. One thing to noted is that entry 128.0.0.0/1 appeared in the map-cache and indicate is encapsulated to proxy ETR

EDGE01#show ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

0.0.0.0/0, uptime: 00:07:04, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
128.0.0.0/1, uptime: 00:00:42, expires: 00:14:18, via map-reply, forward-native
  Encapsulating to proxy ETR

Other useful command is show ip lisp forwarding eid remote detail which shows how specific prefixes are forwarded. Looking at prefix 128.0.0.0/1 you can see that NH is 150.1.1.10 which is PETR and is LISP encapsulated using LISP0 interface.

EDGE01#show ip lisp forwarding eid remote detail 
Prefix                 Fwd action  Locator status bits
0.0.0.0/0              signal      0x00000000
  packets/bytes       1/100
  path list E731BA7C, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn]
    ifnums:
      LISP0(12)
    1 path
      path E363B054, share 1/1, type attached prefix, for IPv4
        attached to LISP0, glean for LISP0
    1 output chain
      chain[0]: glean for LISP0
128.0.0.0/1            fwd native  0x00000000
  packets/bytes       4/400
  path list E731BB1C, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn]
    ifnums:
      LISP0(12): 150.1.1.10
    1 path
      path E363AEA4, share 1/1, type attached nexthop, for IPv4
        nexthop 150.1.1.10 LISP0, IP midchain out of LISP0, addr 150.1.1.10 E363C210
    1 output chain
      chain[0]: IP midchain out of LISP0, addr 150.1.1.10 E363C210
Prefix                 Fwd action  Locator status bits
                IP adj out of Ethernet0/0, addr 110.1.194.14 E58B9F48

It’s always nice to look at the packet capture to see what is going on behind the scene. Below is packet capture run on the EDGE01 node. First packet was sent as Map-Request for destination IP 200.1.1.1/32 to MS/MR 150.1.1.2

Next EDGE01 node received negative MAP-Replay packet from MS/MR containing the shortest prefix that contains the destination and does not cover any of the registered EID space. The ITR EGDE01 cache that prefix and map it to the PETR.

Then the ICMP packet is LISP encapsulated and sent to the PETR to reach non-LISP site.

For the return ICMP traffic PITR did not know anything about EID 10.10.1.0/24 so it sent Map-Request to MS/MR which is then forward it to EDGE01 node. Look at highlighted packet which indicates it is from P-ITR, then EDGE01 sent MAP-Replay to the PETR.

This is an output of map-cache from the PxTR device after map-replay packet was received from EDGE01 node. As you can see entry for EID 10.10.1.0/24 was created and it was done via map-reply. That entry also point to RLOC 150.1.1.19.

PxTR#sh ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

10.10.0.0/16, uptime: 00:00:52, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
10.10.1.0/24, uptime: 00:00:33, expires: 23:59:26, via map-reply, complete
  Locator     Uptime    State      Pri/Wgt
  150.1.1.19  00:00:33  up           1/100

After all above steps were completed and each component populated its own map-cache with correct information succeeding ICMP packet are successful.

I run another ICMP ping from second LISP site and per an output below you can see another map-cache entre was created for EDI 10.10.2.0/24

PxTR#sh ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries

10.10.0.0/16, uptime: 00:00:15, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
PxTR#sh ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 3 entries

10.10.0.0/16, uptime: 00:00:52, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
10.10.1.0/24, uptime: 00:00:21, expires: 23:59:38, via map-reply, complete
  Locator     Uptime    State      Pri/Wgt
  150.1.1.19  00:00:21  up           1/100
10.10.2.0/24, uptime: 00:00:10, expires: 23:59:49, via map-reply, complete
  Locator     Uptime    State      Pri/Wgt
  150.1.1.31  00:00:10  up           1/100

LISP is an overlay protocol that supports forwarding packets between LISP sites and non-LISP sites communicating with LISP sites, and for such communication LISP requires PITR/PETR device. A proxy ETR takes LISP packet sources from a LISP site, de-encapsulates it, and forwards it natively as IPv4 packets out to a non-LISP site. The proxy ITR does the opposite. It takes native IPv4 packet from non-LISP site, encapsulates it into LISP packet, and routes the packet to the ETR RLOC mapped to the destination address.

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