This is part of a series of posts – The Lisp Papers.
The previous blog posts on LISP have considered the forwarding plane. A brief summary of the forwarding plane is as follows:
- The traffic originates at the EID space of the source where
- it is routed to the ITR at the edge of the Service Provider network,
- encapsulated in the LISP tunnel,
- the encapsulated packet traverses the RLOC space towards the ETR,
- where it is decapsulated and
- routed in the destination EID space towards the destination.
The control plane is concerned with how the ITR maps a destination to an ETR. In order for this to happen, two primary activities need to be completed.
- The first is an ETR needs to inform the network that it should be used as the ETR for a particular EID space.
- The second is that an ITR needs to look up the required ETR for a destination EID.
These functions are known as mapping functions. LISP considered a number of different mechanisms (CONS, NERD and EMACS) to deliver this, but the LISP + ALT (Alternative Logical Topology) mechanism is the version Cisco has made available on its released IOS (LISP + ALT is documented in draft-ietf-lisp-alt) and seems to be the way forward.
These two functions are delivered by two separate services. The registration service is delivered via a Mapping Server (MS), while the lookup via the Mapping Resolver (MR). This is in a general deployment. The draft discusses various potential configurations where the ETR or ITR may be directly connected to the ALT network, but this is for sites that require additional controls and wouldn’t be the general practice.
So broadly speaking, the ETR registers its EIDs with the MS. This is communicated to the MS as a push, which in turn is pushed out over the ALT network. This is similar to how BGP routes in the Internet today, in that user networks advertise their reachability out to the wider BGP-connected network.
The ITR sends a mapping request for the destination EID address to the MR, which then forwards the request to the corresponding ETR over the ALT network. The ETR responds with a mapping reply. This mapping reply contains the RLOC addresses (the ETRs) that should be used for the required EIDs, which is stored in the mapping database. This operates as a pull, in a similar fashion to DNS. Together, this is known as a hybrid push pull system.
The asymmetry between the push from the ETR and the pull from the ITR is the key to keeping the forwarding state small on the ITR and allowing the forwarding plane on these systems to scale. It is what keeps Elbonian prefixes off of your router unless you really need it.
These services are configured as follows:
Mapping Server
vrf definition LISP rd 1:1 !enable the Mapping Server service ip lisp map-server !configure LISP site lisp site CustomerA authentication-key cisco eid-prefix 10.1.1.0/24 accept-more-specifics lisp site CustomerB authentication-key cisco eid-prefix 10.1.2.0/24 accept-more-specifics !enable ALT on the vrf LISP ip lisp alt-vrf LISP
Mapping Resolver
vrf definition LISP rd 1:1 !enable the Map Resolver system ip lisp map-resolver ip lisp alt-vrf LISP
Combined
vrf definition LISP rd 1:1 ip lisp map-server ip lisp map-resolver lisp site CustomerA authentication-key cisco eid-prefix 10.1.1.0/24 accept-more-specifics lisp site CustomerB authentication-key cisco eid-prefix 10.1.2.0/24 accept-more-specifics ip lisp alt-vrf LISP
Note that the VRF definition is required, even if the Map Server and Map Resolver are located on the same system. My initial configurations assumed that this would not be required, but this makes sense when you consider that the MS and MR are actually two separate processes and in most cases they will need to communicate over the ALT network (more on this in the next post). Even if they are located on the same system, the MR requires an ALT network to forward the mapping request to the MS, and then on to the ETR.
Adding the above configuration to the forwarding topology discussed in the previous LISP post, we would have the following:
xTR1 and xTR2 would register with the MS element of the MSMR system. They would have the same address configured as the MR, so that the configuration for xTR1 would look as follows:
!create a database mapping for the EIDs owned by this site. This is used by the ETR function to register with the Mapping Server ip lisp database-mapping 10.1.1.0/24 10.255.255.1 priority 2 weight 50 !configure the Map Resolver address that is to be used by this system ip lisp itr map-resolver 10.255.255.4 !enable the itr function ip lisp itr !configure the Map Server address that is to be used by this system ip lisp etr map-server 10.255.255.4 key cisco !enable the etr function ip lisp etr
The full configurations and topology of the Basic LISP testbed is documented here. Obviously, the MS and MR systems are very rarely going to be self-contained. In the next post, I’ll consider the ALT environment and how it joins up the MS and MR environments in greater detail.
Hi Terry,
Thanks for taking the time to write these articles! I’ve tried a couple of times to understand what LISP is about, but it’s only after reading The Lisp Papers that it’s started to make any sense!
Hi,
Thank you for your useful post. It is easy to understand what is LISP, and how it works from you post. Hope that you will work well in this topic ^^