What is LISP ?

LISP stands for Locator/ID Separation Protocol. This term “Separation Protocol” means that the identifier of the host and the location of a host is now decoupled (hence the separation) compared to the common behaviour where the identifier and the location are indistinguishable.

In a traditional routing paradigm, the IP address (whatever if we’re talking about IPv4 or IPv6) of a host expresses two things which are :

• The identity of the host
• The location of the host

When designing a network, the engineer must take care of the addressing and the topology because these two items are linked together. Each site should have its own addressing because each site is a separate location and as one site can have multiple topologies, one site may hosts multiple address spaces.

LISP is a routing architecture which changes a lot of thing compared to the traditional way :

• LISP uses a pull model instead of a push model.
  • With traditional routing protocols, routes are pushed from a router to another one. Routing Protocol are “publishing” the network the know.
  • With LISP a router has to get the information from a source and this is very similar to the DNS model.
• LISP is address-family agnostic.
  • LISP can do IPv4 to IPv4 but IPv6 to IPv6 can be done as well as IPv6/IPv4 or IPv4/IPv6, LISP doesn’t care of the address-family.
• LISP enables IP Portability.
  • A host can be moved across site and never change its IP address and this is a great feature of LISP because it enables transparent migration !

Last but not least, LISP is an open standard.

LISP Operations

Terminology

To accomplish this, LISP will have to make a distinction between two things :

• The EID (Endpoint ID) which is the address IP of the host.
• The RLOC (Routing Locator) which is the address of the LISP router of the host

LISP also defines some roles :

• MR – Map Resolver.
  • This is the system which will receive the Map-Request from the devices making requests and which will transfer these requests to the Map Server.
• MS – Map Server.
  • This is the system which will keep the configuration of which site hosts which addresses.
• ITR – Ingress Tunnel Router.
  • This logical role receives packets from sites and encapsulates to remote sites running LISP or natively to sites non running LISP.
• ETR – Egress Tunnel Router.
  • This logical role receives packets from the core and de-encapsulates packets to deliver to the destination EIDs.

Operations

From a pure operation point of view, this means that LISP will encapsulate the original IP frame to insert its own information in order to create tunnels :

As stated before, LISP is doing a separation between where the host is located (the RLOC) and the identity of the host (the EID). Now LISP has to make some kind of resolution to join the two information together and this is the EID to RLOC mapping.

So, at some point, a location where these mappings is stored must exists and this place is the Map Server (MS).

The device that will receive the LISP resolution request is the Map Resolver (MR). Its goals are to forward these requests to the MS and send negative answers when the request is about a non LISP site.

At this point, I think we’re ready for a little and very simple lab !

LISP – Basic Lab

Lab Diagram

The topology is build around a four device core and OSPF. OSPF is used with a flat area 0 just to publish the Core loopback and directly connected interfaces of the CE devices :

CE loopbacks are not advertised inside OSPF as it will be the task of LISP to maintain the connectivity.

• CE1 has the loopback 0 configured with 1.1.1.1/32
• CE2 has the loopback 0 configured with 2.2.2.2/32
• CE3 has the loopback0 configured with 3.3.3.3/32

The result is that Core routers are not able to join these loopbacks :

CORE2#ping 1.1.
*Jan 24 08:54:04.459: %SYS-5-CONFIG_I: Configured from console by console1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

CE devices are able to join the external interfaces of each other, like CE1 to CE3 for example :

CE1#ping 192.168.33.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.33.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/16/18 ms
CE1#

But CE Loopback ping to CE Loopback ping is not possible :

CE1#ping 3.3.3.3 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
.....
Success rate is 0 percent (0/5)
CE1#

LISP Configuration on CE

CE routers need to be configured with LISP as they need to publish there internal networks information at some point. First we need to enter the LISP process and create the database-mapping saying that the router own a specific subnet and how it need to be reached.

On CE1 for example, we specify that the subnet we own is 1.1.1.1/32 and we want it to be reached via the external interface of 192.168.11.100. A priority and a weight need to be configured, I’ll explain in another LISP lab how these work :

router lisp
database-mapping 1.1.1.1/32 192.168.11.100 priority 10 weight 10

Next, we need to tell the CE router about who will be responsible for registration and resolution (Map-Server and Map-Resolver). In our setup, these role are owned by the same device :

router lisp
ipv4 itr map-resolver 100.100.100.100
ipv4 etr map-server 100.100.100.100 key CISCO

The authentication key is mandatory here and of course it will need to match on the Map-Server.

Last, we have to enable two roles which are ITR and ETR. Here the CE routers hosts the two roles as they are able to send request for LISP resolution but they also connect to the end network :

router lisp
ipv4 itr
ipv4 etr

Repeat this configuration on the other customer routers with the correct database-mappings.

Configuration the MSMR

Now we need to configure the MSMR devices. In this very simple setup, both role are hosted on the same device.

This device will be responsible for LISP registration, which means it will know the subnet behind each CE router and it will also be responsible to reply to the various resolution requests.

LISP will rely on an organization based on sites. At the LISP level, we have to create to sites which will contain the authentication key and the allowed EID.

router lisp
site CE1 
  authentication-key CISCO
  eid-prefix 1.1.1.1/32
  exit
!
site CE2
  authentication-key CISCO
  eid-prefix 2.2.2.2/32
  exit

The site named CE1 represents the site behind CE1 while the site named CE2 represents the site behind CE2. In short, these are the prefixes that will be reachable via each CE routers.

As we have done on the customer routers, we need to activate the related roles on MSMR. These roles will be map-server and map-resolver for IPv4 :

router lisp
ipv4 map-server
ipv4 map-resolver
exit

Now we need to check if the customer sites are registered to the Map-Server :

MSMR#show lisp site 
LISP Site Registration Information

Site Name      Last      Up   Who Last             Inst     EID Prefix
               Register       Registered           ID       
CE1            00:00:03  yes  192.168.11.100                1.1.1.1/32
CE2            00:00:19  yes  192.168.22.100                2.2.2.2/32

So this mean that the CE routers have successfully registered their prefixes to the MSMR and, in theory, the MSMR will respond to them when they will ask for a resolution.

Let’s try this :

CE1#ping 2.2.2.2 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/9/19 ms
 

CE1 loopback can join CE2 loopback. The advantages here is that the CE devices or the Core are not polluted by these routing information :

CE1#sh ip route 2.2.2.2
% Network not in table
CE1#

From a forwarding point of view, the best path is used. Here is the traceroute from CE1 to CE3 when CE3 has registered the link with Core3 for prefix reachability :

CE1#traceroute 3.3.3.3 so lo0 num
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.11.1 2 msec 4 msec 8 msec
  2 10.13.13.3 12 msec 2 msec 10 msec
  3 3.3.3.3 19 msec *  19 msec

LISP – Behind the Scene

Initially and periodically, Map-Register packets are sent from the CE routers for the MSMR. These packets allows the CE site to register to the Map device and publish the prefixes that are reachable. On the Wireshark capture below, CE1 informs MSMR that 1.1.1.1/32 is reachable through its connected interface 192.168.11.100 along with the priority and weight.

In response to a Map-Register, a Map-Notification will be sent back.

When a communication is needed and the LISP mechanism hasn’t been used yet, the CE device will need to perform a request named an Encapsulated Map-Request.

This request is sent from the configured LISP interfaces to the Map-resolver, on the next packet capture, we can see the ping from 1.1.1.1 to 3.3.3. is encapsulated to be originated by the ETR interface on CE1 (192.168.11.100) to the Map-Resolver (100.100.100.100)

When the request is received on the resolver, it will be forwarded to the actual destination which is known by the resolver. The next capture shows the encapsulated ping which is being sent from MSMR to the final destination, which is the ETR of CE3 (192.168.33.100) :

This will allows the site to communicates directly with Map-Reply packets. These packets will be used to update the cache on each CE device.

The Map-Reply packet is shown below and is directed from CE3 ETR interface to CE1 ETR interface :

As a result, CE1 can update its LISP cache :

CE1#sh ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

0.0.0.0/0, uptime: 00:04:55, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
3.3.3.3/32, uptime: 00:00:44, expires: 23:59:15, via map-reply, complete
  Locator         Uptime    State      Pri/Wgt
  192.168.33.100  00:00:44  up          10/10

And so does CE3 :

CE3#sh ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

0.0.0.0/0, uptime: 01:45:23, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
1.1.1.1/32, uptime: 01:42:51, expires: 22:17:08, via map-reply, complete
  Locator         Uptime    State      Pri/Wgt
  192.168.11.100  01:42:51  up          10/10

Subsequent communication will now be sent directly from CE1 ETR to CE3 ETR without requests to the MSMR. Traffic will still be encapsulated by LISP to allow the traffic to be directed to the published ETR interfaces.

Conclusion

LISP allows to reduce the number of prefixes inside the Core network as the information will be hosted on the Map-Server who will be responsible for initial flow distribution. Encapsulated traffic will then flow directly between end sites.

In future labs, we’ll take a look at the scenarios where CE devices are not running LISP and must interact with LISP enabled devices. Load Sharing will also be tested to check how to equally distribute the traffic between multiple ETR interfaces.