Cisco Blogs

Why You’ll Want LISP Routing – Part 2

November 5, 2012 - 4 Comments

So, lets dig into LISP Routing a little more.  If you have not done so, I would recommend you read my first post, since I am not going to review the concepts here. In this post, I am going to break things down into three steps: 1) how packets are forwarded (i.e. the data plane operation), 2) how mapping information is propagated (i.e. control plane operation), and 3) how we internetwork with non-LISP locations.

For starters, lets head into the weeds and take a look at the LISP header format.  In the last post, I mentioned there is some flexibility in how handles IP addressing.  The two examples below show a couple of scenarios: pure IPv4 and a IPv4/IPv6 hybrid:


As you can see, the header is pretty straightforward—the outer (red) header identifies the source and destination routers, while the inner (blue) header identifies the source and destination hosts.  I am not going to dig into the LISP header for the purposes of this post—if you are interested, check out the IETF draft.

So, lets take a look at the day in a life of a LISP packet—As we look at packet forwarding, I am going to introduce you to two new terms:

  • Ingress Tunnel Router (ITR): receives packet from the host (EID) and encapsulate them for the remote LISP site or natively forwards them for non-LISP sites
  • Egress Tunnel Router (ETR): Receives the LISP packets, decapsulates them and delivers them to the proper EID

So, if you take a look at this, its pretty straightforward—nothing exotic going on, which is key to how LISP can be implemented in an incremental matter.  Its important to note that this is a unidirectional process.  The receiving host would go through the same process to determine the proper path going the other direction.  The is a process called “gleaning” where the ETR could determine the RLOC for the sending EID by looking at the LISP header, but there is some debate as to if this is a good thing to do–this gleaned info lacks any policy control amongst other things and opens up other security concerns.

Now, let’s look at how the mapping process works—there are a few more moving parts, so bear with me.  Let’s start with some more vocabulary (pay attention, there is a quiz later). As I noted, if you have an idea of how DNS works, this should seem somewhat familiar.

We have some new network elements:

Map Resolver (MR)

  • Receives Map Request messages (“where is a.b.c.d?”) from the ITR and forwards them to the ALT Toplology (more on this in a sec)
  • The MR also sends negative responses back to the ITR for Map Requests to non-LISP sites

Map Server (MS)

  • ETRs register the EID prefixes they serve with the MS
  • The MS injects routes for registered EIDs into BGP ALT topology
  • Receives Map-Requests via the ALT topology and forwards them to the appropriate ETR

Alternate Topology (ALT)

  • Overlay network of nodes (routers, Linux hosts, etc) running BGP and linked with GRE tunnels-
  • Aggregates and advertises EID prefixes across the topology
  • Forwards Map Requests across the topology back to the authoritative ETR

ALT is kinda interesting, so couple of notes on it.  First, the typical enterprise probably does not need an ALT, since there are a finite number of MR/MS to worry about—you need an ALT when you are talking about service provider level scale.  I also get the impression that the ALT mechanism is still play—at the end of the day, you need a mechanism for LISP messages to propagate back and forth, but other methods, beyond what I cover here, may emerge.

…we have some control messages:

  • Map-Request Message – sent by an ITR looking for a EID/RLOC mapping, to test RLOC reachability or to refresh an mapping before TTL expiration of the mapping
  • Map-Reply Message – sent by the ETR back to the ITR in response to the Map-Request with the appropriate EID/RLOC mapping.  The response also includes any site ingress policy for the EID (see note below).
  • Map Register Message – Sent by the ETR to the Map Server to register EID prefixes it serves.  The message also specifies the RLOC to be used by the Map Server when forwarding Map Requests to the ETR

Note: One of the cooler aspects of LISP is the ability to enforce policy (for example, the path inbound traffic takes) as part of the Map-Reply—the policy can even be modified based on who is sending the Map-Request—more on that in the third post.

…finally, we have a couple of types of data-stores:

  • LISP Map Cache – lives on the ITR and has EID/RLOC mappings populated by the Map-Replies received for ETRs and the ITR must respect any policy set forth by the ETR.  The cache is only populated with entries for active flows.
  • LISP Site Mapping-Database – lives on the ETR and maintains EID/RLOC mappings for ETRs in the local LISP site.  The ETR is considered “authoritative” for its EIDs and will respond to Map-Requests.

So, now that I have just thrown a bunch of terms at you, let’s start putting the pieces together.  Let’s start with the registration process:

An ETR sends a Map-Register message to the Map-Server with the EID prefixes is serves.  The Map Server then injects that info into the ALT topology where it propagates across the topology, including to the Map-Resolvers.  Where appropriate, the Map Server aggregates prefixes it gets from the various registrations it sees. Note, the mappings themselves so not propagate, only the prefixes, so you can find the Map Server that can tell you how to get to

 For the sake of simplicity, I have only shown a single ETR and a single MS, but probable deployment scenarios would employ multiple ETRs and Map Servers.  Multiple ETRs can register with the same MS for the same EID and the MS will feed them Map-Requests in a round-robin manner.  Similarly, an ETR can (and should) register with multiple Map Servers.  This provides redundancy without needing to add the complexity of a synchronization mechanism between the Map Servers.

Now, let’s go the other way and look at the Map-Reply Process:

Again, there is nothing really exotic going on here.  Once the ETR gets a request from a host, assuming it cannot find the address in the existing LISP cache, it will query the Map Resolver with a Map-Request.  The MR may send back a message that the address is not a LISP site and that info will get installed in the cache.  If it is, the information will move back through the ALT to the appropriate Map Server.  The MS will then pass the  Map-Request to the proper ETR which then sends a Map-Reply directly back to the ITR (i.e. through the regular routed network, not through the ALT).  The ITR will then take the info in the Map-Reply (EID prefix, RLOC, policy) and install it into its LISP cache.

I am guessing you may have questions over things like security, survivability, multicast or what happens if my VM moves I the middle of all this?  These are all good questions, but you are going to have to wait a post or two for answer, since this post is going to be long enough as it is. 🙂

OK, let’s tackle the final scenario—internetworking with non-LISP sites (because not everyone is as smart as you are).  Seriously, there are a couple of reasons why this is important—first there is the obvious flexibility for incremental implementation, but beyond that, there is the fact that you can get the traffic engineering benefits of LISP on day one, even if most of your hosts are still non-LISP. So, of course, I’ve got a couple more terms for you:

  • Proxy ITR (PITR) – Advertises aggregated EID prefixes, receives traffic from non-LISP sites, then encapsulates it and forwards it to LISP sites.
  • Proxy ETR (PETR) – Allows IPv6 hosts with IPv4 RLOCs to reach IPv6 hosts that have only IPv6 RLOCs (no dual stack).  It allows LISP sites reach non-LISP sites and get around uRPF restrictions that might arise from the asymmetric routing that may LISP internetworking can create.

Assume a host in a non-LISP network wants to chat with our favorite host at  The PITR will advertise a route to host, so the non-LISP host will forward traffic that way.  The PITR will encapsulate the traffic and forward it to the appropriate RLOC where is will be decapsulated and forwarded on the destination host.  The returning traffic however, takes a more direct route through the regular routed network as it is forwarded on by the ETR.  As noted earlier, this asymmetric routing may run afoul of uRPF restrictions, so the ETR can be configured to forward traffic via the PETR which should keep everyone happy.

So, that’s it for now.  If you have questions, please post them in the comments.  In the next post, I will move out of the theoretical and dig into some of the actual use cases.  After that, I will tackle some of the common questions I see are availability, security and other random topics.

NOTE: Part 3 of this series can be found here.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. You are correct–thanks for the catch.


  2. Is the addressing depicted in the drawing “LISP-2-4” correct? Shouldn’t the red SRC/DST pair be to illustrate that the original packet is being encapsulated by the Ingress Tunnel Router?

  3. Yes, the first set of packets are dropped until the map-cache entry is populated in the ITR. However, an ITR could encapsulate to an RTR (a Re-encapsulating Tunnel Router) where it has map-caches populated by many of sources so the chances for map-cache misses are minimized.

    Dino Farinacci

  4. Great explanation!

    What about an uncached scenario where the RLOC is not known before the first packet of a “flow” reaches the xTR. Those packets are dropped in my test environment until the xTR has enough information on how to forward LISP traffic (by doing a MAP request).

    Is this behaviour intentional?

    IMO it has a rather strong impact on user experience (page load delays with HTTP etc.)

    What do you think about it?