Cisco Locator ID Separation Protocol (LISP)

Hey Laz, are you saying that the reality is that ITR/ETRs are going to be WAN facing? I have read that edge routers are connected to end users. I am thinking of the typical 3 tier system with access/distribution/core with access switches being the edge device (layer 3 switch).
The router is often connected to the core. Would that end up being our ITR/ETR?

Would border routers be in our data center/network core and not located at one of our lisp sites?
Also, our Map server/map resolver would be located there along with all of our other services. Am I on the right track?

Hello Justin

As can be seen from the diagrams in the lesson, the ITR/ETR will be connected to the RLOC space. Because LISP sites are remote from each other, the RLOC space will typically include a WAN.

Now the actual topology and architecture within the LISP site can essentially be anything. Itā€™s just like any other LAN. Typically, you would have some sort of hierarchical structure like core/distribution/access or a collapsed core design with core-distribution/access.

Now would the core layer device also play the part of the ITR/ETR? It may. If the LISP site is extensively large, you may have the ITR/ETR role be played by a separate edge router rather than the core, but in smaller setups, you may have that role incorporated into the core device.

Border routers are always placed at the border of the local network, whether that network hosts your enterprise network or your datacenter. Your enterprise network and/or datacenter may also be a LISP site. There is no limitation as to what services you are hosting within a LISP site, so Iā€™m not sure I understand your specific question here. Can you clarify?

The MS/MR is found within the RLOC space. This can be at a physical location of where your LISP site is, but it is not within the LISP site itself. Strictly speaking, it is on ā€œthe other sideā€ of the ITR/ETR.

I hope this has been helpful!

Laz

Lazaros and Rene,
please, help me to clarify some of the confusion that arise when I went through your LISP explanation.

Pargraph 4.1.2 Map-Request and Map-Replay states the following

When the MR receives a Map-Request, and it has an entry in its local database, then the MR responds with a Map-Reply. When it doesnā€™t have an entry, then the MR forwards the Map-Request to an MS. The MS forwards the Map-Request to the ETR, which answers the Map-Request with a Map-Reply directly.

This above paragraph implies that both the MR and MS share a common database, and when an ETR comes online for the first time, or for any new EID added to a LISP site, it sends a MAP-Register to the MS and the MS save the EID-to-RLOC in its database for future reference.

And when an ITR sends a MAP-Request to MR, the MR lookup the database and respond back with an EID-to-RLOC MAP-Reply.

Now, the question is that why in all the given examples the MAP-Requests are forwarded to the MS and in turn the MS forward it to the ETR, of course because the P-flag bit is not set, and not having the MR to respond with EID-to-RLOC although the ETR has already registered its EID with the MS?

In another word, why the MR every time sends the MAP-Request to the MS, and this would contradict with the explanation of paragraph 4.1.2 ?

Hello Bassam

The operation of the MS and the MR can be a bit confusing. We must separate their roles clearly:

  • MS receives Map-Register messages from the ETRs and sends Map-Notify messages to the ETRs.
  • MR receives Map-Request messages for ITRs and either
    • responds with a Map-Reply if it has an entry
    • responds by forwarding the Map-Request to the MS which in turn sends it to the intended ETR

Note that the MS always receives a Map-Register from the ITRs. It will only receive a Map-Request from the MR to be relayed to the appropriate ETR if an EID-to-RLOC mapping is not found in the database.

The MS will not receive Map-Requests directly from the ITRs, but only via the MR.

As for the database, it is true that the MR and MS share a common database. Indeed, Cisco states the following:

The fundamental behavior of LISP is to separate the EID from the RLOC, which allows the host to retain its identity even with a change in location. But the seamless mobility is achieved using the EID-to-RLOC mapping, which is maintained in the distributed database. The map server (MS) learns EID-to-RLOC mapping entries from the ETRs and publishes these mappings to the distributed mapping database. To publish its EID prefixes, an ETR periodically sends its mapping entries to the MS. The MS also receives the map requests via the mapping system and forwards them to the registered ETRs.

The above is taken from the following Cisco documentation:

Note that the distributed database is indeed accessible by the MR, but is populated by the MS.

I hope this has been helpful!

Laz

Hi,

what does it mean exactly that MR/MS calculates the shortest prefix for non-LISP prefixes?

Hello Quirik

I did a bit of research and then conferred with @ReneMolenaar on this one. Again, in the lesson Rene states:

ā€œThe MS calculates the shortest prefix, which matches the requested destination, but which doesnā€™t match any LISP EIDs.ā€

What essentially is meant here is that an aggregate address is calculated by LISP. So when a non-LISP address is requested by the ITR, this request goes to the MS/MR. The MS replies with a negative map-reply that includes that calculated non-LISP aggregate address. So the big question is how is this address calculated?

There is some indication of how this is done found in related RFCs. For example RFC 6833 states:

  A Negative Map-Reply, with action code of "Natively-Forward", from
  a Map-Server that is authoritative for an EID-Prefix that matches
  the requested EID but that does not have an actively registered,
  more-specific ID-prefix.  In this case, the requested EID is said
  to match a "hole" in the authoritative EID-Prefix.  If the
  requested EID matches a more-specific EID-Prefix that has been
  delegated by the Map-Server but for which no ETRs are currently
  registered, a 1-minute TTL is returned.  If the requested EID
  matches a non-delegated part of the authoritative EID-Prefix, then
  it is not a LISP EID and a 15-minute TTL is returned.  See
  Section 4.2 for discussion of aggregate EID-Prefixes and details
  of Map-Server EID-Prefix matching.

I understand that this is not clear-cut, however, the only way to actually see what is sent by the MS is to lab this up and use the show ip lisp map-cache command to actually see what aggregate is created and sent back. @ReneMolenaar may lab this up later in the week and if so, Iā€™ll let you know the results.

I hope this has been helpful!

Laz

2 Likes

Thanks for the clarification Laz. I also stumbled on this as in the lessons it says ā€œThe ITR also programs its FIBā€ following receipt of the Map-Reply from the ETR/MS. And later ā€œwhen the ITR receives a a packet from H1 with EID 192.168.1.101 destined for H2 with EID 192.168.2.102, and ITR checks its FIB and finds a matching entryā€.

So are you saying there a differentiation between FIB entries created via normal IP routing and FIB entries created as a result of MS/MR process?

Also how does the ITR build the local map-cache for ā€˜LISP site locally connectedā€™ EIDs, such as 192.168.1.101? Is this statically configured? This in reference to when ITR receives the IP packet from H1 with destination 192.168.2.102 and it checks if the source IP a registered EID-prefix in the local map-cache.

Thanks

Hello Bhawandeep

Yes, there is a difference between FIB entries created via normal IP routing and FIB entries created as a result of the MS/MR process in the context of LISP.

In normal IP routing, FIB entries are created based on the routing table, which contains information about reachable networks and the best paths to reach them. These entries are used by routers to make forwarding decisions for IP packets.

In a LISP environment, the FIB serves a different purpose. It stores the mapping between EIDs and RLOCs for LISP encapsulation and forwarding. The ITR creates and maintains these FIB entries as a result of the MS/MR process, which involves receiving Map-Request and Map-Reply messages.

Using the example you shared, when the ITR receives a packet from H1 with EID 192.168.1.101 destined for H2 with EID 192.168.2.102, it checks its LISP-specific FIB for a matching entry. If a matching entry is found, the ITR encapsulates the packet with the RLOC of the destination ETR and forwards it accordingly.

So, there is a differentiation between FIB entries created via normal IP routing and FIB entries created as a result of the MS/MR process in a LISP environment. The former are used for traditional IP forwarding decisions, while the latter are used for LISP encapsulation and forwarding based on the EID-to-RLOC mappings.

The ITR builds the local map-cache in several ways. Yes, you can manually configure this, but this is not scalable nor is it recommended. Typically, it is with the use of dynamic registrations that the ITR populates its map-cache. When a host like H1 comes online and sends traffic, that EID is automatically registered with an ITR and this creates a local EID-to-RLOC mapping. This process is explained and described in detail in the lesson.

I hope this has been helpful!

Laz

1 Like

Very helpful. Thanks Laz.

1 Like

Thank you for the good lecture. But I have one question. Why does ETR answer ITRā€™s MAP-REQ directly? Isnā€™t it more efficient for MS to answer directly if itā€™s already saved on MS through MAP-REGISTER?

Hello Yuchan

According to the related RFC 9301, an ITR may receive a response directly from the MS/MR or it may receive a response from the ETR. There are different circumstances that dictate what will happen.

In the event that the MS/MR has a matching entry, it will return a LISP Map-Reply with the known mapping directly. If the MS/MR doesnā€™t have sufficient information to know if the requested EID exists, then it will forward the request to a device that has more information about the EID being requested. This may be another MS/MR or the actual ETR that has the EID information. The RFC clearly states that in such a situation:

The Map-Resolver does not send any response to the ITR; since the source RLOC is that of the ITR, the ETR or Map-Server that receives the Map-Request over the ALT and responds will do so directly to the ITR.

This makes sense because it is a direct response to the request. Otherwise, if you trace back the response via the MS/MR, you are adding hops to the response, and thus you are delaying it. Does that make sense?

Take a look at the Map-Resolver Processing section of RFC9301 that describes this process in detail.

I hope this has been helpful!

Laz

Hello @lagapidis , i hope you doing well

About Map-Request / Map-Replay Mechanism :slight_smile:

The ITR receives the IP packet from H1 with destination 192.168.2.102. It does a lookup in its FIB table and asks itself the following questions:

  • Is there an entry that matches 192.168.2.102? If so:
    • Use regular IP routing.
    • If not, we use LISP encapsulation if any of the following three checks is true:
      • We have a default route.
      • We donā€™t have a route
      • We have a route with Null0 as the next-hop.
  • Is the source IP a registered EID-prefix in the local map-cache?
    • If not, forward the packet with regular IP routing.
    • If so, the ITR:
      • Selects a UDP source port.
      • Sets the UDP destination port to 4342.
      • Sends an encapsulated Map-Request to the MR for 192.168.2.102.

Above in bold is what i understand are the conditions to forward the pckt throughout LISP Tunnel.

What i understood :

  1. No entry for the DST pckt (in this case 192.168.2.102) any of the following:
    • default route
    • no route
    • entry for 192.168.2.102 next-hop ā†’ Null0
  2. Src IP (in this case LISP Site1 Host1 IP 192.168.1.101) is a registered EID

Basically is an ā€œANDā€ operation between point 1 and 2 ?

Hello Juan

I fixed the formatting in your post, I think I got it the way you intended, if not please correct me.

Now as for your questions, yes, there must first be no entry that matches the destination IP. If that is the case, it goes to step 2 which checks the source IP to see if it is a registered EID-Prefix in the local map cache. If it is, only then will the packet be sent through the LISP tunnel.

I guess you could say it is an ā€œANDā€ operation, but I think itā€™s more appropriate to say that it is an ā€œif/thenā€ logic.

  1. If there is no entry in the FIB, then
  2. If we have a default route OR we donā€™t have a route, OR we have a route with Null0 then
  3. If the source IP is a registered EID-prefix in the local map cache, then

ā€¦the ITR will select the UDP source port, UDP destination port will be sent and an encapsulated map request to the MR will be sentā€¦ Does that make sense?

I hope this has been helpful!

Laz

1 Like

Hi,

regarding this ā€˜if-thenā€™ logic, what if there is a route in the RIB to destination IP, and the source IP is registered EID prefix? Will the LISP be used?

Hello Quirik

Thatā€™s a good question, and it shows how nuanced the use of LISP can be.

If a destination IP address is directly reachable according to the RIB (i.e., thereā€™s a specific, conventional IP route to that destination), and the destination does not require an EID-to-RLOC resolution (or is not part of a LISP-enabled site/network), the traffic can indeed be routed using normal IP routing mechanisms without involving LISPā€™s encapsulation or mapping services.

Now, In the scenario where the source IP is a registered EID (indicating itā€™s part of a LISP-enabled site/network) but the destination IP has a direct route in the RIB (suggesting it can be reached via conventional routing paths), then you must keep the following in mind:

  • The traffic from the source to the destination would typically use standard IP routing. LISP encapsulation or mapping is not needed because the destination is directly reachable through existing routes in the RIB, bypassing the need for EID-to-RLOC resolution for the destination.
  • However, LISP might still be involved in determining the sourceā€™s RLOC for packets leaving a LISP site, but if the destination is directly routable (and not a LISP participant requiring EID-to-RLOC mapping), the packet can be delivered without LISP encapsulation for the destination.

Keep in mind that LISP would be primarily involved when either the source or destination (or both) requires EID-to-RLOC translation to facilitate the routing across LISP and non-LISP networks. If both source and destination can be addressed through conventional IP routing mechanisms present in the RIB, and thereā€™s no need for EID-to-RLOC translation for the destination, the routing can proceed without involving LISPā€™s encapsulation/mapping features for that destination.

I hope this has been helpful!

Laz

Though not relevant to ENCOR, is there an already written page for L2 LISP, what is it, why is it needed and how to configure?

Hello Deepanshu

We donā€™t currently have a lesson on Layer 2 LISP, however, I have created a NetworkLessons note on the topic with a short summary describing Layer 2 LISP. You can find it here.

If you have any further questions, let us know!

I hope this has been helpful!

Laz