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 22.214.171.124/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 126.96.36.199/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 188.8.131.52. 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 184.108.40.206 priority 1 weight 100 ipv4 map-request-source 220.127.116.11 ipv4 use-petr 18.104.22.168 ipv4 itr map-resolver 22.214.171.124 ipv4 itr ipv4 etr map-server 126.96.36.199 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 188.8.131.52 priority 1 weight 100 itr map-resolver 184.108.40.206 itr etr map-server 220.127.116.11 key cisco etr map-request-source 18.104.22.168 use-petr 22.214.171.124 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 126.96.36.199 ipv4 proxy-etr ipv4 proxy-itr 188.8.131.52 ipv4 itr map-resolver 184.108.40.206
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 220.127.116.11 remote-as 1000 neighbor 192.168.1.2 remote-as 100 neighbor 192.168.1.2 update-source Loopback0 ! address-family ipv4 network 18.104.22.168 mask 255.255.255.255 network 192.168.1.10 mask 255.255.255.255 redistribute static neighbor 22.214.171.124 activate neighbor 126.96.36.199 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 188.8.131.52 source 184.108.40.206 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 220.127.116.11, timeout is 2 seconds: Packet sent with a source address of 18.104.22.168 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms EDGE02#ping 22.214.171.124 source 126.96.36.199 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 !!!!! 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 220.127.116.11/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 18.104.22.168/8 is variably subnetted, 2 subnets, 2 masks C 22.214.171.124/24 is directly connected, Ethernet0/0 L 126.96.36.199/32 is directly connected, Ethernet0/0 188.8.131.52/32 is subnetted, 4 subnets B 184.108.40.206 [20/0] via 220.127.116.11, 03:36:45 B 18.104.22.168 [20/0] via 22.214.171.124, 03:13:53 C 126.96.36.199 is directly connected, Loopback100 B 188.8.131.52 [20/0] via 184.108.40.206, 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 220.127.116.11 shows that success rate is 60 percent because for the first time communication LISP lookup needs to be perform.
HOST#ping 18.104.22.168 source 10.10.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 22.214.171.124, 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 126.96.36.199/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 188.8.131.52/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 184.108.40.206/1 you can see that NH is 220.127.116.11 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: glean for LISP0 18.104.22.168/1 fwd native 0x00000000 packets/bytes 4/400 path list E731BB1C, 3 locks, per-destination, flags 0x49 [shble, rif, hwcn] ifnums: LISP0(12): 22.214.171.124 1 path path E363AEA4, share 1/1, type attached nexthop, for IPv4 nexthop 126.96.36.199 LISP0, IP midchain out of LISP0, addr 188.8.131.52 E363C210 1 output chain chain: IP midchain out of LISP0, addr 184.108.40.206 E363C210 Prefix Fwd action Locator status bits IP adj out of Ethernet0/0, addr 220.127.116.11 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 18.104.22.168/32 to MS/MR 22.214.171.124
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 126.96.36.199.
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 188.8.131.52 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 184.108.40.206 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 220.127.116.11 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.