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
!
exitThe 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-lispFinally 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.2In 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 NULLThe 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-requestICMP 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 msNow 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 ETROther 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 E58B9F48It’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/100After 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/100LISP 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.
netmindblog 