Note: It occurred to me that I’ve been calling the Map Server / Map resolver router by both ‘maprouter’ as well as ‘mapserver’ throughout this post. Any reference to either mapserver or maprouter refers to the central Map Server / Map Resolver router. I’ve corrected this error in future posts and called it just ‘mapserver’. Sorry!
In the last couple of posts we’ve looked at the map-register process as well as the map-request and map-reply process. Now comes the most important part, the actual LISP transport. We’ve already seen this happen multiple times, but we haven’t actually looked at the encapsulated traffic at this point. So let’s go back to our site A to site B connectivity test. The goal here being to have connectivity between the EID space at site A and the EID space at site B. So the LISP encapsulation path will look something like this…
So let’s assume that each router already has done their map-request and have valid map-cache entries for the other router’s EID space. A quick look at the ICMP packets from the packet capture should tell us quite a bit. The first packet is the initial (one the map-cache was formed on either side) ICMP packet from 192.168.1.1 to 192.168.2.1…
You can see that this is a UDP encapsulated packet and that the outer packet header has the router’s RLOC address space listed. The inner LISP encapsulated packet has the true source and destination information. The next packet is the reply, same information, just in reverse…
So from this we can tell that LISP uses UDP 4341 for it’s encapsulation method. I wanted to make sure I got this post in before we moved on since the LISP encapsulation is obviously the most important part of the whole protocol. Next up should be some PxTR configuration.