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.
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.
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
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 188.8.131.52/32
- CE2 has the loopback 0 configured with 184.108.40.206/32
- CE3 has the loopback0 configured with 220.127.116.11/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 18.104.22.168, 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 22.214.171.124 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 126.96.36.199, timeout is 2 seconds: Packet sent with a source address of 188.8.131.52 ..... 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 184.108.40.206/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 220.127.116.11/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 18.104.22.168/32 exit ! site CE2 authentication-key CISCO eid-prefix 22.214.171.124/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 126.96.36.199/32 CE2 00:00:19 yes 192.168.22.100 188.8.131.52/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 184.108.40.206 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 220.127.116.11, timeout is 2 seconds: Packet sent with a source address of 18.104.22.168 !!!!! 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 22.214.171.124 % 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 126.96.36.199 so lo0 num Type escape sequence to abort. Tracing the route to 188.8.131.52 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 184.108.40.206 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 220.127.116.11/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 18.104.22.168 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 22.214.171.124/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 126.96.36.199/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.
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.