After some further tinkering with the LISP configuration in my last post, I realized that I really wasn’t using the LISP proxy ETR functionality despite having configured it. We were however, using the proxy ITR function to get traffic from non-LISP nodes back into EID space. So let’s change our configuration around a little to get the proxy ETR function working. We’ve already configured the proxy ETR function on the mapserver router, but we haven’t yet told routers lisp1 and lisp2 to use it. This is cone by configuring a global LISP command on each ISR router…
lisp1#config t
Enter configuration commands, one per line. End with CNTL/Z.
lisp1(config)#ip lisp use-petr 10.0.3.1
In addition (to prove this is working) let’s remove the default route from the router and just give the router a specific /32 route so it knows how to get to the proxy ETR node…
lisp1(config)#no ip route 0.0.0.0 0.0.0.0 10.0.1.1
lisp1(config)# ip route 10.0.3.1 255.255.255.255 10.0.1.1
You can perform the same changes on the lisp2 router.
Now, let’s test our EID to RLOC space connectivity to make sure it still works…
So you can see at this point I no longer have a default route, however I’m still able to reach out to the outside world. Let’s take a look at the packet capture to see what happened this time around…
Packet 1 – Map Request
So just like last time, 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 identical to last time. The map reply tells lisp1 to natively forward. Now, this is truly interesting. How is lisp1 to know where to send the packet since he doesn’t have a route? This is not what I had expected to see at this point but let’s keep going…
Packet 3 – lisp1 forwards an encapsulated packet to mapserver
Ok, so this is weird. Mapserver told lisp1 to forward the packet natively. In the past, this has meant that lisp1 should forward without LISP encapsulation. Let’s keep watching…
Packet 4 – mapserver forwards the packet onto outsideworld
The mapserver router strips the LISP encapsulation and forwards the packet on normally towards its final destination…
Packet 5 – outsideworld responds with an ICMP echo reply
Business as usual, the non-LISP router outsideworld is replying to the ICMP echo request…
Packet 6 – mapserver sends a map-request
Same as the last example here. LISP kicks in and issues a map-request looking for a way to get to the 192.168.1.1 address.
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.
Packet 8 – The path has been built, now a valid ICMP echo request/reply
As we saw before, we see the second attempt at a ICMP echo request. This time things should work out since the LISP path has been built.
Packet 9 – mapserver forwards the packet onto outsideworld
The mapserver router stripped the LISP encapsulation and forwarded the packet on normally towards its final destination…
Packet 10 – outsideworld responds with an ICMP echo reply
Business as usual, the non-LISP router outsideworld is replying to the ICMP echo request…
Packet 11 – mapserver LISP encapsulates the echo reply and forwards
The map server proxies the connection by LISP encapsulating the packet sending it on to its final destination. Much what I expected to see at this point. The rest of the packets show the ICMP echo request/reply wrapping up.
As you can see, the process was not all that different from what we examined in the last post. The only real difference was that lisp1 used it’s defined proxy ETR to forward packets. It was strange to me that the response from the map resolver told lisp1 to natively forward. But if you think about it, that sort of makes sense. The fact that lisp1 was defined to use a proxy ETR is totally separate from the map request/reply process. Let’s take a look at the FIB before and after the map request/reply process occurs…
Beforehand, all the router knows to do is to check with the map resolver…
After the LISP path has been setup we see something much different….
It knows that it was told to forward the packet natively, but it also knows that it has a PETR configured. Since it doesn’t have a native route for 4.2.2.2 it will have to use the PETR.
The entire process this time looked something like this….
Recall that the blue lines indicate LISP packets and the red lines indicate native IP forwarding. As you can see, step 3 in this process has changed to a LISP encapsulated packet. The initial ICMP echo request has to be LISP encapsulated to the PETR since lisp1 doesn’t have a route for it.
This cleared things up for me quite a bit and I hope it did for you as well. At this point, we have truly configured full PxTR functionality. In the next post, we’ll be talking about LISP real world use cases!
Hello Jon, great series of articles! Thank you so much for your effort and sharing!
Now I have a single question and will really appreciate if you can clarify it for me.
I cannot appreciate/understand the need of having PxTR. In this example, the only difference I’ve spotted was to remove the default GW and replace it by adding `use-petr` feature within the LISP config. OK, what’s the big deal anyway? Even if we don’t have that – it will still work (as per your previous example). Why do we need PxTRs if the remote routers know how to reach our EIDs? This traffic shall reach our RLOCs and they’ll simply perform xTR operations map-encap/decap.
Thanks in advance!
Hi! Lets clarify your question a little. We need a PITR role to get traffic between LISP and non-LISP space. You’re wondering why we would want to use a PETR role right? So the real definitions go like this…
PITR – Allows Non-LISP sites to talk to LISP sites
PETR – Allows LISP sites to talk to Non-LISP sites
Ok, thats a super basic definition but that’s the nuts and bolts of it. As you pointed out in my example, I was allowing the LISP sites to talk to non-LISP sites by normal IP routing. I think that last picture in both of those posts sums it up. With PETR the entire communication is done with LISP. Without the PETR, the response is done through normal IP routing since the LISP node just uses its default gateway.
I can see where you’d want to use a PETR and keep the traffic all LISP rather than letting some of it become normal IP traffic.
Does that make sense? Does that answer your question?
Hi Jon,
Your post helped me a lot! Thank you very much!
I tried to configure two petr address in lisp1 and one of them is wrong IP address.
I dont understand why lisp1 router can still use the right IP address to be the outer dst IP when sending out encapsulated ICMP packets.
Could you please kindly explain the symptom?
Thanks a lot!