LISP – A base configuration to build on

Note: It occurred to me that I’ve been calling the Map Server / Map resolver router by both ‘maprouter’ as well as ‘mapserver’ throughout this post.  Any reference to either mapserver or maprouter refers to the central Map Server / Map Resolver router.  I’ve corrected this error in future posts and called it just ‘mapserver’.  Sorry!

So now that we’ve talked a little bit about the basics in the intro post, let’s do a little LISP configuration to get our feet wet.  One struggle I’ve had with learning LISP is that there really aren’t a ton of tutorials on it at the moment.  I find that I learn best through example, so in the next few posts I’d like to walk through some very simple configurations that should help you get your feet wet, but not be terribly over complicated.  That being said, let’s dig right in.

So let’s start with a base topology.  Something like this…

I’m going to start completely from scratch here and apply this base configuration to each device…

Router 1
hostname router1
int fa0/0
  ip address 10.0.1.1 255.255.255.252
  no shut
int fa0/1
  ip address 10.0.2.1 255.255.255.252
  no shut

Router 2
hostname router2
int fa0/0
  ip address 10.0.1.2 255.255.255.252
   no shut
int loop0
ip address 192.168.1.1 255.255.255.255
  no shut
ip route 0.0.0.0 0.0.0.0 10.0.1.1

Router 3
hostname router3
int fa0/0
  ip address 10.0.2.2 255.255.255.252
  no shut
int loop0
  ip address 192.168.2.1 255.255.255.255
  no shut
ip route 0.0.0.0 0.0.0.0 10.0.2.1

So at this point, we have some basic routing going on, but nothing fancy.  We can ping between the border networks, but router 2 doesn’t know about router 3’s loop 0 interface and vice versa.  In any other scenario, we’d configure some sort of IGP (or static routes) to get Loop 0 reachability between all of the routers.  Since this is a LISP lab, let’s give each router a LISP role…

So here’s what we’ve done.  We’ve renamed Router1 to ‘maprouter’.  Maprouter will serve as a LISP map server and map resolver.  In addition, maprouter is providing IP connectivity between the two other routers.  Router2 has been renamed ‘lisp1’ and is providing LISP xTR functionality for what I’ll refer to as ‘Site A’ throughout the rest of the example.  Router3 has been renamed ‘lisp2’ and is providing LISP xTR functionality to what I’ll refer to as ‘Site B’ throughout the rest of this example.

The green shaded area refers to what is considered the RLOC space and the orange shaded area refers to what is considered the EID space. 

If you need a refresher on the LISP terminology , refer to my first post here.

So now that we’ve changed things up a little bit, let’s put some LISP configuration on each device.  Let’s start with the mapserver router (formerly router 1).

mapserver configuration
Configuring LISP is much like configuring any other dynamic routing protocol.  Enter LISP configuration mode as follows…

mapserver#config t
Enter configuration commands, one per line.  End with CNTL/Z.
mapserver(config)#router lisp
mapserver(config-router-lisp)#

Now that we are in the LISP configuration mode, we can configure this router for it’s designated LISP role…

mapserver(config-router-lisp)#ipv4 map-server
mapserver(config-router-lisp)#ipv4 map-resolver

Since this router is acting as the map server, we need to define each of the LISP site’s that plan on connecting to this map server…

mapserver(config-router-lisp)# site sitea
mapserver(config-router-lisp-site)#  description Site A
mapserver(config-router-lisp-site)#  authentication-key sitea
mapserver(config-router-lisp-site)#  eid-prefix 192.168.1.0/24
mapserver(config-router-lisp-site)# exit

To build a site, we need to define the site name, the key it will use for authentication, and the EID prefix for which that site is authoritative for.  We’ll complete the same configuration for the other side, or Site B…

mapserver(config-router-lisp)# site siteb
mapserver(config-router-lisp-site)#  description Site B
mapserver(config-router-lisp-site)#  authentication-key siteb
mapserver(config-router-lisp-site)#  eid-prefix 192.168.2.0/24
mapserver(config-router-lisp-site)#  exit

That’s really all we need to do on the map server at this point.  Let’s run a couple of commands though to verify things…

As you can see, the mapserver router knows that sitea and siteb have been defined, but they are not yet ‘up’ at this point.  Let’s move onto the site router configuration…

lisp1 configuration
The configuration for the site’s is pretty easy as well.  Recall that since these router’s are performing LISP xTR functionality, they are performing both the LISP ITR and ETR roles.  Let’s walk through the lisp1 router configuration…

lisp1(config)#router lisp
lisp1(config-router-lisp)# database-mapping 192.168.1.0/24 10.0.1.2 priority 1 weight 100

The database-mapping command is used to describe the EID space for which this xTR is authoritative for.  Don’t worry about the priority and weight commands just yet, we’ll cover those in one of the coming posts.  Next we have to define the router roles…

lisp1(config-router-lisp)# ipv4 itr map-resolver 10.0.1.1
lisp1(config-router-lisp)# ipv4 itr

When configuring the ITR role, we need to tell the router what to use as a map resolver.  In our case, maprouter is performing both the map resolver and map server functionality so we specify it’s interface facing the lisp1 router.  Recall that the ITR is a device that takes traffic from EID space, encapsulates it, and sends it out into RLOC space as a LISP packet.  That being said, before it can do that it needs to ‘resolve’ the EID prefix it’s headed for.  Hence, it needs to query the LISP map-resolver.  Next, we configure the ETR function…

lisp1(config-router-lisp)# ipv4 etr map-server 10.0.1.1 key sitea
lisp1(config-router-lisp)# ipv4 etr
lisp1(config-router-lisp)# exit

When we configure the ETR function, we have to define the map-server.  The map-server is the LISP device that keeps track of all of the LISP mappings.  That being said, it would make sense that you’d want some type of authentication in place for this role.  After all, you want to make sure that the right device is registering the right EID prefixes.  Here we specify the map server as well as the key that we used to define the site on the mapserver router earlier. 

Before we move onto configuring the lisp2 router, let’s take a quick look at the mapserver router again…

As you can see, the mapserver router and the lisp1 router have already registered with each other.   Once we finished the configuration on lisp1 it immediately reached out to the mapserver router to register.  Let’s configure a quick debug on the mapserver router so we can see lisp2 register after it’s configured…

mapserver#debug lisp control-plane all
All LISP control debugging is on

lisp2 configuration
This configuration is almost identical to lisp1 so we won’t talk about it in such great detail…

lisp2(config)#router lisp
lisp2(config-router-lisp)# database-mapping 192.168.2.0/24 10.0.1.2 priority 1 weight 100
lisp2(config-router-lisp)# ipv4 itr map-resolver 10.0.2.1
lisp2(config-router-lisp)# ipv4 itr
lisp2(config-router-lisp)# ipv4 etr map-server 10.0.2.1 key siteb
lisp2(config-router-lisp)# ipv4 etr
lisp2(config-router-lisp)# exit

Immediately after configuring lisp2, we see these messages on the mapserver router…

*Nov  6 02:19:47.287: LISP: Processing received Map-Register message from 10.0.2.2 to 10.0.2.1
*Nov  6 02:19:47.287: LISP: Processing Map-Register no proxy, no map-notify, no merge, no security, no mobile-node, 1 record, nonce 0x9942D785-0xBA4E2890, key-id 1, auth-data-len 20
*Nov  6 02:19:47.287: LISP: Processing Map-Register mapping record for IID 0 192.168.2.0/24, ttl 1440, action none, authoritative, 1 locator
        10.0.2.2 pri/wei=1/100 LpR
*Nov  6 02:19:47.287: LISP-0: MS registration IID 0 prefix 192.168.2.0/24 10.0.2.2 site siteb, Created.
*Nov  6 02:19:47.291: LISP-0: MS registration IID 0 prefix 192.168.2.0/24 10.0.2.2 site siteb, Adding locator 10.0.2.2.
*Nov  6 02:19:47.291: LISP-0: MS EID IID 0 prefix 192.168.2.0/24 site siteb, Map-Notify, to registering ETRs due to changed registration.
*Nov  6 02:19:47.291: LISP-0: MS EID IID 0 prefix 192.168.2.0/24 site siteb, ALT route update/create.
*Nov  6 02:19:47.291: LISP-0: ALTroute IID 0 prefix 192.168.2.0/24 <-> created.
*Nov  6 02:19:47.291: LISP-0: ALTroute IID 0 prefix 192.168.2.0/24 <-> add source MS-EID.
*Nov  6 02:19:47.291: LISP-0: ALTroute IID 0 prefix 192.168.2.0/24 <MS-EID> RIBroute ignore create, no ALT RIB.

There’s a lot of detail here and some pieces of LISP that we haven’t yet explored but it’s fairly apparent from this debug that the registration of the LISP site ‘siteb’ was successful.  This can be confirmed by checking the lisp sites on the mapserver router again…

Testing LISP between sites
Now that we’ve configured LISP, it’s time to test it out.  Let’s try pinging from site A to site B to see what we get…

As you can see, it took the router a couple seconds, but eventually the pings went through.  The delay was due to the LISP lookup that occurred between lisp1 and mapserver.  If we take a look at both of the xTRs, we can see that they both have a valid map-cache entry for the the other router’s EID space…

I don’t want us to get caught up in the specifics (AKA, I’m not going to walk through the router debugs or packet captures in this post) but I do want to talk a little bit about the forwarding decision on LISP enabled routers before we wrap this post up. 

As we saw, the LISP enabled router populates it’s local map-cache with responses it receives from map resolvers and other ETRs.  However, those entries don’t appear when you look at the routing table the way most engineers do.  For instance, let’s look at the forwarding table on router lisp1…

As you’ve probably noticed, there isn’t a forwarding entry for the 192.168.2.0/24 network.  However, if we take a look at CEF…

We can see that CEF does actually know how to forward these packets and that forwarding action is to encapsulate the traffic.  Now, if we were to clear the map-cache entry and check again…

We see that CEF no longer has the specific prefix we are looking for, but it does know to check LSIP eligibility which I’m assuming means check the map-resolver before forwarding the packet natively.  That being said, it appears that the router will check with it’s defined map-resolver when attempting to route a packet to a destination for which the router doesn’t have a specific prefix in the forwarding table or a valid map-cache entry. 

So we’ve covered quite a bit in this post.  We built a very basic lab topology which we’ll continue to build upon as we scale the LISP infrastructure out in future posts.  Additionally, we scratched the surface of how the actual LISP protocol works.  In my next post, we’ll take a look at the LISP map-request and map-reply process in more depth and analyze the LISP process used to actually signal and build the connectivity we configured today.

Feedback and comments are more than welcome!