So we’ve sort of beaten the proverbial horse out of what I’ll call ‘basic’ LISP connectivity. If you haven’t read any of the earlier posts, it might be worth your time to catch up now before moving on…
LISP Intro
LISP Base configuration
LISP Map-register
LISP Map Request / Reply
LISP Map and Encap
In the next couple of posts, I’d like to cover some more LISP roles that a router can play in a LISP environment. After that I’d like to move onto some case studies on how one might use LISP in the real world (I’m getting excited about these coming posts already!). That being said, let’s dig right into the next role I’d like to talk about, the PxTR.
The proxy xTR (PxTR) role serves a very important role in the LISP environment. It allows EID space to talk to the outside world (RLOC space), and the outside world to talk to EID space. You might be asking yourself why this wasn’t possible before. After all, couldn’t the xTR router just forward the packet from EID space out into the world (native forward) without the LISP encapsulation? The answer is yes, you certainly could, however, getting a response back would be difficult. Recall that the mapserver router in our example facilitates connectivity between routers lisp1 and lisp2. However, it only knew about the 10.0.1.0/20 and the 10.0.2.0/30 networks. Once it sent the packet where it needed to go, no one would know how to get the packet back to the EID space that it came from. That being said, we need a mechanism to allow networking elements not actively participating in LISP to talk to EID space. That role should also allow EID space to talk to RLOC space.
So let’s modify out lab setup a little bit so it looks like this…
Recall that the green space is RLOC space (publically routable) and the orange space is EID space (LISP EID namespaces). As you can see, we’ve added a 4th router (outsideworld) to the lab setup and put that router entirely in RLOC space. In addition, we’ve added the PxTR role to the router mapserver. The goal of this lab is to get the EID space to talk to the loopback 0 interface on outsideworld. Conversely, that same loopback should be able to talk to the EID space hung off of routers lisp1 and lisp2. Let’s jump right into the LIPS configuration…
Note: Im assuming that you’ll complete the following tasks on your own…
-Add the 4th router and configure it’s Ethernet interface connecting to mapserver as well as it’s loop0 interface
-Put a 0’s route on mapserver pointing to outsideworld
-Put a 0’s route on outsideworld pointing to mapserver
-Configure the loop0 interface on mapserver
The only real configuration that needs to be done to make this work (save the basics I outlined above) is the PxTR configuration. Since we’re going to be configuring mapserver as the PxTR, let’s start there…
Enter config mode and get yourself in LISP configuration mode…
mapserver#config t
Enter configuration commands, one per line. End with CNTL/Z.
mapserver(config)#router lisp
Recall that xTR means both ITR and ETR functions in the same router. Configuring PETR functionality is rather straight forward…
mapserver(config-router-lisp)#ipv4 proxy-etr
Configuring the PITR functionality is almost as easy, you just need to tell it what interface to use for the function. In this case, we created a separate loopback (10.0.3.1) to use just for this. We’ll see where this comes in later in the article…
mapserver(config-router-lisp)#ipv4 proxy-itr 10.0.3.1
Next we have to tell the PxTR where the map-resolver is so it can perform lookups. As it were, mapserver is the map-resolver so we can just specify the same loopback interface in this command…
mapserver(config-router-lisp)#ipv4 itr map-resolver 10.0.3.1
Now, proxy versions of the ITR and ETR roles act a little bit different than the normal ITR and ETR versions. Namely, the proxy version doesn’t assume it should do a LISP lookup. That is, if there isn’t an entry in CEF, it won’t try to contact the map-resolver. We need to tell the PxTR specifically what prefixes it should perform lookups on. This is done by manually creating a map-cache entry telling the router to perform a map-request when it sees that prefix…
mapserver(config-router-lisp)#map-cache 192.168.1.0/24 map-request
mapserver(config-router-lisp)#map-cache 192.168.2.0/24 map-request
mapserver(config-router-lisp)#end
mapserver#
So that’s it. Pretty easy wasn’t it? Let’s give it a try and see what happens….
As you can see, the EID space at site 1 can now talk to 4.2.2.2 which is an end host in RLOC space off of a router that doesn’t even know what LISP is. You’ll also note that the router picked up a map-cache entry for one of those coarse prefixes we saw earlier (0.0.0.0/1). Let’s dig right into packet captures to try and discern how this is working…
So here’s what the entire capture looked like…
As you can see, there are some familiar components to this function. We see the map-request and map-reply actions taking place just as we did with the EID to EID communication. Besides that, things look rather normal. Let’s dig into the packets to see what happened.
Packet 1 – Map Request
Looks like what I’d expect to see. A standard map-request from lisp1 asking the map-resolver if he’s aware of 4.2.2.2/32.
Packet 2 – Map Reply
The map reply also looks pretty standard, however note that the reply tells the router to natively forward the packet. That is, forward it on without LISP encapsulation.
Packet 3 – lisp1 forwards the packet natively
Doing as it’s told, lisp1 forward the packet natively following the instructions programmed in it’s forwarding table. It takes the next hop following it’s 0’s route out towards the mapserver router.
Packet 4 – mapserver forwards the packet to outsideworld
As you can see, this looks to be very normal IP forwarding. Packet 4 shows the mapserver router decrementing the TTL and forwarding the ICMP request onto outsideworld following it’s 0’s route.
Packet 5 – 4.2.2.2 replies to the ICMP request
Still looks like normal IP forwarding. The reply from 4.2.2.2 is heading back towards 192.168.1.1
Packet 6 – mapserver sends a map-request
At this point, LISP needs to kick in. More specifically, the PxTR needs to find a way to get the reply from 4.2.2.2 back to 192.168.1.1 that lives in EID namespace. Since mapserver itself is the map resolver, we don’t see the initial map request to the map resolver. However, we do see the tail end of the map request as mapserver router queries the ETR directly. As you can see, the mapserver is asking the ETR lisp1 if it knows about the prefix 192.168.1.1/32. What’s interesting is that the map request lists 4.2.2.2 as the source EID.
Packet 7 – lisp1 replies to mapserver with it’s address
The map reply to mapserver from lisp1 states that it’s authoritative for the EID space mapserver is looking for. lisp1 gives mapserver it’s local RLOC address as the destination to encapsulate LISP packets to.
Packets 8 and 9 – The ICMP echo request to 4.2.2.2
This packet is natively forwarded, it shows up as two packets since I’m capturing on the link between lisp1 and mapserver as well as the link between mapserver and outsideworld. Note that the first ICMP echo request failed since LISP was busy setting up the path. Packets 8 and 9 show lisp1’s second attempt.
Packet 10 – The ICMP echo reply
Packet 10 shows the ICMP echo reply on the link between outsideworld and mapserver. As you can see, this is also a native IP packet as it traverses this link.
Packet 11 – The LISP Encapsulated ICMP echo reply
At this point the ICMP echo reply is being LISP encapsulated as it traverses the link between mapserver and lisp1. You can see the inner encapsulated packet has the original source and destination while the out IP header has IP address info for the RLOC space between mapserver and lisp1.
The rest of the ICMP echo request and echo reply packets follow the same path. If we were to put the flow on the diagram, it might look something like this….
Note that I didn’t include the first failed attempt of the initial echo request in the diagram (not enough room).
I’ve highlighted all of the actions that LISP was a part of in blue, the remaining actions were standard IP forwarding and are in red. The diagram gives you a pretty clear idea how the PxTR fits into a LISP design.
Alright, I think that’s it for now, in the next posts I’d like to start talking about some use cases for LISP and real world applications.
Comments and feedback always welcome!
Again great job! Very deep explanation for me and i believe for all another people.
Thanks!
Thanks for the great article.
If the source ip of the packet initiated by lisp1 is unmodified does it mean
1) EID address space doesn’t clash with the RLOC (native) address space
2) The packet some how returns to proxy xTR (Does it advertise the EID space in a routing protocl/….)?
Jon,
What if 4.2.2.2 was somewhere else in the cloud…How would it know that the packet would need to be sent to PxTR. Does PxTR advertise the 192.168.1.1 address??