Cisco SDA Part IV - LISP mobility - dynamic EIDs

Updated: Jun 21, 2019

One of the most important characteristics of LISP is the mobility it offers - the next few posts aim at helping understand how this functionality is achieved, starting with dynamic EIDs.


We will continue using the same topology as before, with some minor changes to the xTRs. xTR6 is now another xTR and not a PxTR.






The goal is this post is to understand how dynamic EIDs are configured and how does it really function behind the scenes. Our final test is to have complete connectivity between 1.1.1.1 and 5.5.5.5.


Our initial (and relevant LISP configuration) is pretty standard:





With dynamic EIDs, the first thing you realize is that you have to use locator sets. Think of locator sets as a parallel to peer groups in BGP - you can use one locator set, that uniquely identifies a RLOC and its attributes, and apply that to several instances of LISP.





Before we create the dynamic EID, take a quick look at the LISP map-cache:





As expected, there's just a single, default entry in the LISP cache. Let's configure a dynamic EID now:





You create a dynamic EID using the 'dynamic-eid' CLI and give it a name that can be referenced later. Within this dynamic EID, you need to create your database mappings - this dictates the prefix range that is assumed to be dynamic (or 'roaming') in nature.


This creates a new entry in the LISP map-cache:





But notice, as of now, the MS/MR has no registrations against this EID:





At this point, if I try to ping from R1 to xTR2 (sourcing an IP address of 1.1.1.1), nothing works and we get this error message:





So, what is missing? With dynamic EIDs, you need to configure the host facing L3 interfaces as LISP mobility interfaces as well for this to work:





This is where you call the dynamic EID that was defined at the beginning. And that's all there is to it! That is the complete configuration you need to enable dynamic EIDs in LISP on xTRs. There is a small catch though, which we'll get to in a bit.


Now that we understand how to configure dynamic EIDs, the big question remains - how are EIDs learnt dynamically? The answer is simple - via traffic. This can either be control-plane traffic (like ARP) or data-plane traffic (like an ICMP request).


When said traffic hits a xTR that is enabled for dynamic EIDs and it falls within that prefix range, the dynamic registration process starts. This includes sending a Map Register to the MS/MR as well as adding an exact match entry in the LISP database and RIB/FIB.






The Map Register process is the same as before - nothing special here. xTR2 generates a Map Register packet and sends that to the configured Map Server (MS/MR, in our case). The MS/MR looks at its site database and confirms that an EID exists in its database that matches the EID in the register and then sends a Map Notify back.



Interestingly enough though, we see no Map Notify coming back from the MS/MR right now:





Any guesses on why? Let's walk through the entire flow and understand why this happened. xTR2 gets a data packet (or an ARP) from R1 which has a source IP address of 1.1.1.1 and a destination IP address of 10.1.12.2. This triggers the LISP dynamic EID learn, which invokes an exact route installation in the LISP database and RIB/FIB.


We can confirm that both of these occurred correctly:




Additionally, a Map Register is sent to the MS/MR. Does the MS/MR have a match for this EID in its site database?



Yes, it does. However, pay close attention to the output - we are hitting the 1.1.1.0/24 entry and naturally, there are no registrations against this EID so it cannot send a Map Notify back.



This is one of the biggest gotchas with dynamic EIDs which leads me to one of the most important changes needed to make dynamic EIDs work - you must allow for more specific prefixes to be accepted on the MS/MR.

It is a very simple, but crucial change:





Now, when the Map Register is sent again, the MS/MR is willing to accept a more specific prefix under the range of 1.1.1.0/24 and it sends the corresponding Map Notify back:





The MS/MR also has this entry in its site database now:





As you can see, this is an entirely new entry that was dynamically added to the site database of the MS/MR because we allowed it to learn more specific prefixes within the scope of 1.1.1.0/24.


Let's complete our configuration for the 5.5.5.0/24 EID space as well. This requires three changes - first, on xTR4, configure this EID as a dynamic EID range. Second, on the MS/MR, allow for more specific prefixes to be learnt for this EID space. Lastly, on the interface facing the host, enable LISP mobility against the configured dynamic EID.





Let's trigger a dynamic EID learn for the 5.5.5.0/24 range and ensure that an entry gets added into the MS/MR site database.





A look at xTR4s LISP database and the MS/MRs site database to confirm the expected entries were added:




At this point, we should have complete reachability from 1.1.1.1 to 5.5.5.5, which we do. The data-plane process is the same as normal EIDs - nothing new there.





This completes our section of understanding dynamic EIDs. In the next post, we will look at host mobility and what happens when a host moves from one RLOC to another. See you in the next one!

For any queries, concerns or conversations, please email contact@theasciiconstruct.com