Updated: Jun 7, 2019
Understanding how a LISP site talks to a non-LISP site (and vice versa) is very crucial to LISP and the bigger picture that we're building towards - SDA.
The topology that we'll work with is a slightly modified version of what we had before - another router has been added that will facilitate conversation between LISP and non-LISP:
This new router, xTR6, connects to another router, R7 which in turn can reach the Internet, where 18.104.22.168 is. R7 is sending a default route to xTR6.
The focus of this post is to understand how R1s loopback, 22.214.171.124 (which is in the LISP space) can talk to 126.96.36.199 (which is in the non-LISP space).
To facilitate such a conversation, two additional functionalities were added into LISP - proxy iTR (PiTR) and proxy eTR (PeTR). When a device performs both functions, it is called as a PxTR. Thus, xTR6 in this topology, is a PxTR.
PiTR - this box is responsible for being a proxy for EIDs in the LISP space and advertising these EID spaces (via some form of aggregation) into the non-LISP space. The intention of this is to draw traffic for the LISP space towards itself.
PeTR - this box connects the LISP space to non LISP space. It receives encapsulated traffic, decapsulates it and forwards it natively towards non-LISP sites.
To understand how this works, we will look at each direction individually - LISP to non-LISP and non-LISP to LISP.
LISP to non-LISP:
Configuration for both of these functionalities (PiTR and PeTR) is fairly simple. Let's start off by having xTR6 be a normal xTR. It has the following configuration to begin with:
To enable PeTR functionality, simply use 'ipv4 proxy-etr'.
xTR6 is now configured to decapsulate LISP encapsulated packets and forward them natively. But how would it receive traffic in the first place, when our destination (188.8.131.52) is not even advertised in the LISP space (there are no database mappings configured for this)? This is where LISP starts to become really cool!
Let's go step by step - R1 sends an ICMP request to xTR2. It hits the 0.0.0.0/0 entry in CEF and subsequently leaks to the LISP process, where it hits the 0.0.0.0/0 entry again (which we should be very familiar with by now). This triggers LISP to generate a map request for 184.108.40.206.
When the MS/MR receives a map request, it looks at its site database to determine if this has been configured or not and if there are any active RLOCs for this EID.
If there is an EID miss (which is what happens in this case, as you can see above), it is required to send a negative map reply back with certain action bits set (remember, there are 3 action bits available). One of these action codes is natively-forward, which is what the MS/MR uses here.
The negative map reply looks like this:
Notice how the EID in the map reply is not 220.127.116.11/32. Per RFC (RFC 6833), the map resolver "should return the least-specific prefix that both matches the original query and does not match any EID-Prefix known to exist in the LISP-capable infrastructure" in order to minimize the number of negative cache entries needed.
When xTR2 processes this map reply, it installs this into the LISP map-cache. From here, it gets pushed into the CEF table as well.
Whoa - why does this entry say that it needs to be encapsulated to a 'proxy eTR'? I need to pull back the curtain a little bit now - prior to this, I had configured an additional command on xTR2 which wasn't show earlier:
This allows all negative cache entries with forward-native set to be sent to a particular IP address (as configured in the command). In our case, this IP address is 18.104.22.168, which connects to the non-LISP site. This IP address, in general, is typically set to point to your PeTR.
So, xTR2 can now encapsulate subsequent packets with a destination IP address of 22.214.171.124 (in the outer IP header) and forward it on.
xTR6 receives this, decapsulates it and does another CEF lookup on the inner IP header. This hits the 0.0.0.0/0 entry which leaks the packet to LISP, where it hits the 0.0.0.0/0 entry again, causing a map request to be sent to the MS/MR for the destination IP address, 126.96.36.199:
** note - I did have to enable PiTR functionality for this part to work. Without this, we run into other problems (such as routing loops) which I get to later in the post **
This can be visualized as below:
Again, the MS/MR responds back with a negative map reply and the native forward bit set, since it does not have any EIDs that match 188.8.131.52 in its site database:
xTR6 processes this map reply (remember that the MS/MR responds back with the least specific prefix, which in this case was 184.108.40.206/8) and gleans that this prefix needs to be natively forwarded. The next hop now gets picked up from the best match in RIB/FIB (which is the next hop for the default route received from R7).
The end result?
Subsequent packets for 220.127.116.11 now hit the above entry and get forwarded to R7:
This concludes our discussion on how packets get forwarded from a LISP site to a non-LISP site.
Non-LISP to LISP:
What about the reverse direction though (non-LISP to LISP)? This is where things get even more interesting and a very important rule of LISP is revealed.
So, in the reverse path, R7 forwards the ICMP reply from 18.104.22.168 to xTR6. Just like before, xTR6 does a CEF lookup for the destination (22.214.171.124). However, whenever a box is enabled for iTR functionality, it also does a lookup in the local LISP database to check whether the source is a locally known EID or not. If not, the LISP process is not invoked at all. Instead, traditional forwarding would happen without leaking any packets to the LISP process.
Currently, xTR6 is not configured to be a PiTR (remember, we had only configured the command for PeTR) - it behaves as an iTR as of now. So, technically, we can potentially create a routing loop here to prove what I just said. What is our setup like? xTR6 is getting a default route from R7 (just like a typical enterprise design):
Does xTR6 have the source in its LISP database as a local EID? No, it does not.
This means that even though we're hitting the 0.0.0.0/0 entry in CEF and it is associated to LISP0 (so that packets can leak to the LISP process), it will only consider the next-hop from RIB/FIB and not leak packets to LISP. This causes xTR6 to send the packet back to R7. R7 sends it back to xTR6 again and a routing loop ensues.
To bypass this check and have a device be a proxy for EIDs in the LISP space, you configure it as a PiTR. Additionally, you must remember that as a PiTR, there is no default 0.0.0.0/0 entry in the LISP map-cache (unlike a iTR where this is present by default).
This implies that you must create some manual map cache entries. This is done using the 'map-cache' commands.
Now, we should be able to reach 126.96.36.199 from R1s loopback, 188.8.131.52:
Let's quickly take a look at the entire end to end process in this direction of traffic flow (non-LISP to LISP).
R7 sends the ICMP reply from 184.108.40.206 to xTR6 (typically, the PiTR is configured to aggregate its EID spaces and send that to its peer so as to draw traffic towards itself for the LISP space. However, for the sake of simplicity, I have configured a static route on R7 for 220.127.116.11/24 that points to xTR6).
This reaches xTR6, which is now configured to be a PiTR. It bypasses the source EID lookup, does a CEF lookup, which leaks the packet to LISP, where it hits the 0.0.0.0/0 entry we had manually configured:
This triggers a map request for 18.104.22.168 that is sent to the MS/MR:
The MS/MR looks at its site database to see if this EID is configured and if any RLOC has registered this. It finds a hit with 22.214.171.124 as the RLOC:
It forwards this request to xTR2.
xTR2, in turn, sends a map reply back to xTR6 after processing it.
xTR6 processes this map reply and inserts the prefix in the LISP map-cache and pushes that to the CEF table as well:
xTR6 can now encapsulate subsequent packets and send them to xTR2.
xTR2 decapsulates them and sends them to R1.