Distributed CP and Border node

[mhaleem1985]

when we have separated control plane node and border node so there will be IBGP session between CP and Border node and CP will advertise all the lisp database via summarization to the Border node so what will be the next hop at Border for this routes that learned from CP node ? as it shouldn't be the CP node as it will not be at the path of traffic.

[jalejand · Accepted solution]

iBGP VPNV4 session exists between CP and Borders for the following reason:

1) Edge node registers an endpoint to the CP, creating a LISP Site/Server entry on CP(MS/MR)
2) CP takes this registration and exports it as a RIB route for the appropriate VRF with this command:

              route-export site-registrations, so a LISP route with AD of 250 is created on the CP

3) CP redistributes LISP routes (AD 250 routes) into BGP with a metric of 10, thanks to this child route, a summary can be created to non CP borders:

             aggregate-address 172.19.10.0 255.255.255.0 summary-only
             redistribute lisp metric 10

4) This aggregate is 172.19.10.0/24 is advertised to Borders, then here is when the magic happens. This route is no data-path route, is only used for control plane so Borders know what is the scope for their Map Requests. In other words, a Border should not do a map-request to anything he doesn't know, that would be a waste of control plane processing. External Borders specially, should only do a map-request to CP for prefixes that exist inside SDA Fabric, as they are the proxy-etr for any unknown destination, they must "know" what they can do a map-request or not beforehand.

This is achieved by importing the summary BGP route from the CP to their map-cache table as entries which action is "send-map-request", meaning, any destination in this scope can trigger a map-request:

Border1# show lisp ins 4099 ipv4 map-cache 172.19.10.0
LISP IPv4 Mapping Cache for EID-table vrf Campus (IID 4099), 24 entries

172.19.0.0/16, uptime: 00:21:21, expires: never, via route-import, self, send-map-request

route-import entries are originally imported from BGP routes

Map-cache entries with the send-map-request flag will create a "glean" entry in CEF, that will instruct the device to resolve the adjacency needed to forward the  packet. Once it is resolved, a specific map-cache (/32) for the user will be created in LISP, and as we know, in SDA, LISP map-caches take precedence than RIB routes.

Meaning that, BGP summary from CP will be seen in RIB, this route was used to limit the scope of map-requests

But in CEF, a LISP RLOC is the preferred forwarding method, this is after resolving the LISP RLOC for the endpoint.

Regards