In our lab we were able to configure LISP and verify connectivity between our two hosts. One thing I noticed was the loss of the first two ICMP packets. Let’s walk through how LISP functions and examine what was happening behind the scene.
Upon receipt of the first packet, the SITE1 router (acting as an ITR) checked the LISP map cache to see if it already had an RLOC mapping for the destination EID (172.16.30.101):
SITE1#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries 0.0.0.0/0, uptime: 00:10:16, expires: never, via static send map-request Negative cache entry, action: send-map-request
This negative cache entry tells the router that it needs to send a map request to see if there’s an RLOC mapping available. The router will send a map request for EID 172.16.30.101/32 to the Map resolver at 192.168.255.3, and drop the initial data packet (ping #1) from our host:
The Map Resolver/Map Server checks the namespaces that have registered, and looks for the RLOC address of the ETR that is authoritative for the EID prefix:
MR_MS#sh lisp site name SITE2 Site name: SITE2 Allowed configured locators: any Allowed EID-prefixes: EID-prefix: 172.16.30.0/24 First registered: 00:31:21 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 192.168.100.2, last registered 00:00:50, no proxy-reply, map-notify TTL 1d00h, no merge, hash-function sha1, nonce 0x0524E21F-0x489614BB state complete, no security-capability xTR-ID 0xDC4A8044-0x87093251-0x602669CB-0x5B720F12 site-ID unspecified Locator Local State Pri/Wgt 192.168.100.2 yes up 10/50
Once the Map Server determines the RLOC for the authoritative ETR, it forwards the Map-Request message. The ETR receives the forwarded Map-Request, and responds with a Map-Reply:
Once the SITE1 router receives the reply, it updates the local cache:
SITE1#sh ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 3 entries 0.0.0.0/0, uptime: 00:10:35, expires: never, via static send map-request Negative cache entry, action: send-map-request 0.0.0.0/1, uptime: 00:09:25, expires: 00:05:34, via map-reply, forward-native Negative cache entry, action: forward-native 172.16.30.0/24, uptime: 00:09:22, expires: 23:50:38, via map-reply, complete Locator Uptime State Pri/Wgt 192.168.100.2 00:09:22 up 10/50
Now that the router has a complete LISP cache, it can encapsulate packets in LISP headers and send them on their way.
In this setup, it’s interesting to note that we lost the first two ICMP packets to the control-plane process. The first packet was dropped by the SITE1 router as it went through the Map Request/Map Reply process to build the local cache. The second packet actually made it through to the other host, but the response was dropped by the SITE2 router as it also had to build the local cache. You can see some of that below:
Once the caches have been built, subsequent attempts are 100% successful:
[root@SITE1 ~]# ping -c 5 172.16.30.101 PING 172.16.30.101 (172.16.30.101) 56(84) bytes of data. 64 bytes from 172.16.30.101: icmp_seq=1 ttl=255 time=1.62 ms 64 bytes from 172.16.30.101: icmp_seq=2 ttl=255 time=1.41 ms 64 bytes from 172.16.30.101: icmp_seq=3 ttl=255 time=1.36 ms 64 bytes from 172.16.30.101: icmp_seq=4 ttl=255 time=1.48 ms 64 bytes from 172.16.30.101: icmp_seq=5 ttl=255 time=1.33 ms --- 172.16.30.101 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 1.338/1.442/1.626/0.114 ms
I think there are a few important items to remember about the LISP forwarding process. These probably seem obvious, but I still want to point them out:
- The mapping system is really more of a ‘director’, in that it doesn’t actually know the answers to queries, but knows who to talk to find out.
- LISP control-plane always uses the same source and destination ports: UDP/4342
- LISP data-plane packets are always destined for UDP/4341, but the source port will change.
Cisco has a website dedicated to LISP and you can find a great deal of information there, including the devices and software versions that support LISP. I’d highly recommend checking it out: Cisco LISP