LISP map-cache site-registration

[iores]

Hi,

what exactly is the purpose of command from the subject?

I have noticed that without it I cannot ping from LISP to non-LISP site. I have one border/control node with L3 handoff, and LISP redistribution into BGP. However, when I omitt the command from border/control node, the ping stops working.

[M02@rt37]

Hello @iores,

LISP map-cache site-registration command controls whether your LISP router registers its EID prefixes into the map cache. Enabling this command is typically necessary for proper LISP operation, especially when dealing with communication between LISP and non-LISP sites. Disabling it could lead to communication issues and is generally not recommended unless you have a specific reason to do so.

This command enables or disables the registration of EID prefixes into the LISP map cache. When site registration is enabled (the default behavior), the LISP router will register EID prefixes into the map cache, allowing it to participate in the LISP mapping system.

If you omit this command or disable site registration, the LISP router won't register its EID prefixes, which can lead to communication issues, especially when trying to communicate between LISP and non-LISP sites. The map-cache is crucial for the LISP router to perform efficient routing and forwarding of traffic based on EID-to-RLOC mappings.

[iores]

M02@rt37 

If I understand correctly, the map-cache is some sort of LISP routing table.

When I configure the static default route pointing to fusion node at border node, and the same at fusion node but pointing back to border node, the ping works without the map-cache site-registration command.

Why?

But when I introduce BGP, it doesn't work anymore.

What is the different between these two scenarios?

When Proxy-xTR receives a ICMP packet for non-LISP site, first it performs a check with MR, and when it receives the negative MAP reply, the packet gets routed natively. 

Then, when Proxy-xTR receives a ICMP Echo packet from non-LISP for LISP site, it sends map request for destination IP, gets the reply, and then forwards the packet into LISP site.

At which step the process gets stucked without map-cache site-registration command because of which the ping doesn't work?

[M02@rt37]

@iores,

When you configure static default routes on both the border node and the fusion node, you essentially specify a default path for routing non-LISP traffic. This approach works without the need for "map-cache site-registration" because you're not relying on dynamic mapping lookups. The traffic is natively routed based on the static routes.

When you introduce BGP, you are likely relying on BGP route information to populate the EID-to-RLOC mappings in LISP. If there's an issue with BGP route propagation or the mapping process, it could lead to problems with LISP routing and require additional troubleshooting.

The "map-cache site-registration" command may be used to manually force certain mappings in scenarios where BGP or other mechanisms are not providing the desired results.

[iores]

M02@rt37 

Not sure I understand.

When I use BGP, at border node, I redistribute LISP into BGP so fusion router could get LISP prefixes. Fusion router sends its prefixes to border node.

What would be in border node map-cache without map-cache site-registration?

How MR can find a way to EID for intra-LISP ping, but not for LISP to non-LISP and vice-versa?

[jalejand]

Consider the following:

1) Forwarding to a LISP EID requires a LISP map cache, which requires asking the Map Resolver the location of the EID

Now the question is, how a Border node can determine whether a prefix should be attempted for resolution to the MR or simply forwarded using it's routing table? In other words, how does a Border node if a prefix is internal or external?

Edge nodes often have a command inside their LISP instance IDs which "map-request 0.0.0.0/0 map-cache", which instructs the Edge : for any ipv4 destination you don't know, try to use a Map Resolver to resolve it. But borders do not use this command, otherwise they must know the scope of what should be resolved and whatnot.

Resolution is achieved from map caches, a map cache can have different actions programmed on them, one being "send map request", for a particular prefix. Without a map cache, there cannot be a resolution. 

Their scope of resolution is often the following:

If it's collocated Border CP, it takes registrations into map caches

If it's non collocated, in sda1.0, it takes prefixes from BGP vpnv4 from the CP to create map caches.

If it's non collocated, in pubsub, it learns LISP publications from the CP to convert them into map caches. 

[M02@rt37]

@jalejand 

The key concept here is that internal LISP EID prefixes are typically resolved by consulting the local routing table (forwarded natively), while external prefixes require Map Resolver queries ?

[jalejand]

The other way around
External prefixes use the local RIB whiile internal EID prefixes use the map-cache. (With external prefixes being destinations outside the fabric and internal ones being endpoints or subnets inside of the fabric).

The important part is from where Borders get the map-cache to attempt resolution to the internal prefix, the source of the map-cache can be map-cache site-registration, route-import map-cache from BGP or LISP publications (PubSub), depending on the scenario (collocated/noncollocated and sda1.0/pubsub).

[andy!doesnt!like!uucp]

Hi Jay
getting back to @iores's case of disabled map-cache site-registration & lisp-bgp redistribution in place.
do i understand obstacle correctly that w/o subject command lisp just has nothing to redistribute into bgp?
thanks 
UPD. i also found this on FIABs:
router lisp
...
service ipv4
encapsulation vxlan
...
no map-cache site-registration

is there explanation to it?
UPD. Basically Jay gave it above: "either.... or Pub/Sub". our Fabics are PubSub

[iores]

@andy!doesnt!like!uucp 

I think that in order to redistribute LISP into any other routing protocol you have to enter route-export site-registrations. I had to do this in order for redistribution to work.

[andy!doesnt!like!uucp]

just curious, is it in conjunction with "no map-cache site-registration" or ...?

[jalejand]

That is correct

CPs get a registration of a host in a subnet
That /32 registration becomes an entry in the RIB for the VRF due to "route-export site-registrations"
That RIB entry is a "lisp" routing entry, which can be redistributed into BGP with "redistribute lisp metric 10" in bgp
With that /32 child route in BGP, the CP can create an aggregate for the entire fabric summary and advertise it to the borders in BGPvpnv4, so the Border advertises the BGP to the Fusion.

[andy!doesnt!like!uucp]

pardon for intrusion. why dont to replace lisp with mp-bgp?

[jedolphi]

Andy, please review the following presentation to explain why LISP is used, https://www.ciscolive.com/on-demand/on-demand-details.html?#/session/1686177770532001V0NT