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?
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.
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 ?
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 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.
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.
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.
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?
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?
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.
If there is no entry in the FIB, then
If we have a default route OR we donāt have a route, OR we have a route with Null0 then
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?
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?
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.
