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 post we talked about the process of an ETR sending it’s map-register packets to the map-server. Not super exciting to watch, but we did learn quite a bit about the process from watching the debugs and seeing the packet capture. The more interesting piece of the LISP process (to me at least) is the map-request and map-reply process. The map-resolver process is outlined very well in this section of a IETF draft document….
http://tools.ietf.org/html/draft-ietf-lisp-ms-16#section-3
Before we look at what a proper LISP map-request and map-reply looks like in our lab topology, I’d like to point out something else that I had brought up in the first lab post and have since tested.
I had suspected that a router with a defined map-resolver would query the map-resolver any time it couldn’t find a prefix match in either its forwarding table of the LISP map-cache. In my tests, I attempted to have lisp1 reach out to 4.2.2.2 with a simple ICMP ping. Let’s take a look at the CEF table for 4.2.2.2 before we try our ping…
The key piece of this output is ‘check lisp eligibility’. So now, let’s try pinging the destination and see what happens…
That looks like a pretty normal ICMP destination unreachable event. Why didn’t LISP kick in and try to find a EID mapping from the map-resolver? The answer is simple but very, very, very important. The ping did NOT come from EID space defined on the router. LISP has a very simple rule that says ‘If the source address of the packet is not in the defined EID prefix space for the site, forward natively (AKA without LISP)’. Let’s try that again but sourced from Loop0 which is within the EID space of this site…
That’s what we expected to see. Let’s first dig into the map-request packet…
As you can see the type is ‘map-request’ and the prefix we are looking for is in the ‘Record 1’ field of the LISP packet. The packet was sourced from the ITR and destined for the map-server. Now let’s take a look at the map-reply that came back from the map-resolver to the ITR…
As you can see the EID prefix that came back was 0.0.0.0/1 and it was noted that for this prefix, the router should ‘Natively-Forward’.
Now, let’s talk a little bit about that prefix that came back. 0.0.0.0/1 is not a prefix most of us are used to seeing in a routing table. If we take a look at the router lisp1, we can see that this prefix is now living in it’s map-cache and that the CEF entry for 4.2.2.2 now shows to forward natively…
As long as that map-cache entry is there, any attempts to access anything in that prefix won’t be looked up with a map-request. The 0.0.0.0/1 is an example of what I’m seeing referred to as a ‘Coarse prefix’. I believe, but am not certain, that these types of prefixes play a larger role when we start talking about things like the ALT namespace. Furthermore, in the same lab setup that we are working with, I believe that we won’t be able to fully answer the coarse prefix question until we get a little further along. Let’s table that piece of things for now and leave this section having a better understanding of how xTRs handle prefixes that they aren’t aware of. I’d like to now look at an example of how a EID to EID namespace map-request and map-reply work.
So let’s start right off by pinging between EID space between site A and site B…
The connectivity test worked as expected. Now let’s see what we get when we take a look at the packet capture…
The first set of packets we are interested in is packets 2 and 3. These are router lisp1’s attempts to find the EID space for the prefix 192.168.2.1/32. Let’s dig into the first packet…
Lot’s of interesting stuff in this one. First off, note that the outer IP header has a source of the router lisp1 and a destination of the router mapserver. The internal IP header has a source of the router lisp1 but a destination of the IP we were trying to ping. Also note that the LISP type for this packet is a map-request and that the prefix and ITR RLOC address are noted in the LISP packet. Taking a look at the second packet we see…
That the packet is almost identical save the fact that the outer IP header’s source is the router mapserver’s interface facing the router lisp2. You’ll also note that the Ethernet frame MAC addresses have changed indicating that this second packet is heading from the mapserver router to the lisp2 router.
If we look at the LISP spec documented here, under section 4.3 we can see what I believe to be the behavior that is occurring in these first two packets…
If any of the registered ETRs for the EID-prefix have requested proxy
reply service, then the Map Server answers the request instead of
forwarding it. It returns a Map-Reply with the EID-prefix, RLOCs,
and other information learned through the registration process.
If none of the ETRs have requested proxy reply service, then the Map
Server re-encapsulates and forwards the resulting Encapsulated Map-
Request to one of the registered ETRs. It does not otherwise alter
the Map-Request so any Map-Reply sent by the ETR is returned to the
RLOC in the Map-Request, not to the Map Server. Unless also acting
as a Map Resolver, a Map Server should never receive Map-Replies; any
such messages should be discarded without response, perhaps
accompanied by logging of a diagnostic message if the rate of Map-
Replies is suggestive of malicious traffic.
At this point, I have to admit I’m a little confused on the role of the map-server vs the map-resolver. The above section seems to be using the term map-server in place of what I thought would be map-resolver. Since these are still draft documents I won’t dwell too much on the definitions. That being said, it seems that the section above does describe what we’ve seen in the first two packets. The map-request gets sent to the map-resolver who then forwards it on to the ETR that is sourcing the EID prefix we are looking for. The resulting reply can be seen in packets 4 and 5 (there should only be one map-reply shown here, the duplicate is displayed due to the way I’m running my packet capture)…
As you can see, the router lisp2 has replied to lisp1 directly giving router lisp1 lisp2’s local RLOC ID of 10.0.2.2 to reach the prefix of 192.168.2.0/24.
Packets 8 and 9 show the inverse map-request that lisp2 is making to lisp1 to gain reachability information into 192.168.1.0/24. Packets 10 and 11 are lisp1’s reply to lisp2 with the RLOC information to reach that prefix. The whole thing looked a bit like this from a logical perspective…
So as you can see, things worked out a little different than I had expected. I had originally thought that an ITR would query the map-server which would directly return the RLOC required to reach the specified EID prefix. As it turns out, the map-server/resolver really just point the ITR to the correct ETR which in turn responds directly to the ITR with it’s RLOC information. I’d like to look a little more into the ‘proxy reply service’ mentioned in the draft section to get a better understanding of the how and why that is used. It seems to me that the map-server /resolver should be able to answer the ITR’s question directly but I’m sure there is a good reason it doesn’t by default.
The goal for the next post is to expand the topology of the lab to include a PxTR device. With any luck, my next post will talk about PxTR configuration and uses.
Thanks for reading, comments and questions are always welcome!