Importing BGP routes into LISP

[iores]

Hi,

What is the point of redistributing BGP routes into LISP in SD Access?

[jalejand]

There is no "direct" redistribution of BGP routes into LISP, but the functionality to create LISP database entries and map-cache entries using BGP exists, this is called route-import.

"Route-import database bgp" under a Layer 3 LISP instance, is commonly seen in Internal or Anywhere borders, mainly used for traffic manipulation, as BGP prefixes registered in the Control Plane will take preference over negative map-replies which points to External Borders, this results in "more specific" prefixes to go out a Border that registered this prefix, BGP prefixes used for this feature are the ones received by upstream Fusion Routers.

"Route-import map-cache BGP" is more commonly seen in standalone Borders (not Control Planes) to create a LISP map-cache to trigger a map-request for any north-south traffic. These BGP routes used are the ones received from a Control Plane, and is a core feature in the LISP-BGP control plane.

[iores]

@jalejand 

But for the fabric part to work, it is not necessary to import BGP to LISP? From my understanding, edge nodes will route to B/C (Proxy-xTR) for each destination (e.g. some service in DC) that is not part of LISP domain. B/C only needs to get that route from the fusion node.

[jalejand]

Correct, in the case of a single border or "mirrored" borders being the exit point of the fabric (External Borders), you do not really need any BGP-to-LISP route import, as you can simply send all traffic to the proxy-ETRS (External Borders) like a default gateway.

But if there is another fabric Border that has a direct link/path to a particular DC/Core prefix that should be preferred over the proxyETRs, then this border should import that prefix from BGP into LISP, so it takes preference over the NMR/Default gateway method used by proxyETRs. Consider this feature a way to do traffic manipulation using borders.

[andy!doesnt!like!uucp]

hi Jerom

could u pls bring more details on difference between route-import database bgp & route-import map-cache bgp?
thanks in advance

[iores]

I don't know if it is related but I think the database stores locally attached prefixes which are then being advertised to MR/MS, and map-cache stores what it is actively used to build data plane. 

But let's wait for Jerom.

[jalejand]

route-import database:

For the purpose of a Border registering a prefix into the control plane, it must be first added to its local LISP database. This command allows adding these prefixes into the LISP domain.

route-import map-cache:

Easier explained for non-collocated borders in SDA 1.0. A border needs to have a scope of what should trigger a map-request to resolve an EID, unlike Edge nodes, a static 0.0.0.0/0 map-cache is not configured in Borders, these require more specific map-caches, often in the form of a summary of each fabric pool to limit this map-request scope.

Control Planes would advertise a BGP VPNv4 summary route of fabric prefixes to borders, which include a community, this community matches a route-map in the route-import map-cache bgp command which allows the Border to install the map-cache with the send-map-request flag, in order to trigger resolution for destinations inside of the fabric.

[jedolphi]

Thanks Alejandro! For others reading that may not know, "SDA 1.0" = LISP/BGP Control Plane architecture. New SDA designs are recommended to use LISP Pub/Sub please, where we should no longer see the CLI "route-import map-cache"

[andy!doesnt!like!uucp]

sorry, but i still dont get "route-import map-cache" topic clearly.
as i understand above explanation in LISP1.0, dedicated site' CP forms list of site' available pools to announce it to BN via vpnv4 bgp for BN then to import pools to its lisp map-cache from bgp process?  why does site' BN need to have its local site' pools for the purpose different from announcing it via vpnv4 bgp to fusion node/wan-router?
thanks in advance  

[jalejand]

Exactly as you say:

Borders needs the BGP VPNv4 local sites to:

1) Announce them to upstream Fusion/WAN
2) Convert these entries to map-caches, so it can trigger resolution for North-South traffic.

Example.

Traffic from outside the fabric hits Border A to 10.10.10.10 which is a fabric client. To trigger a map-request to the control plane to resolve the RLOC to 10.10.10.10, it needs a map-cache with the send-map-request flag on it; as a side note, LISP XTRs do not trigger a map-request out of nothing for any unknown traffic, these either rely on the 0.0.0.0/0 map-cache like Edges, or in this case, a map-cache created directly from a BGP vpnv4 route from CP with a special community.

Naturally, Co-located Border CPs do not make use of this BGP-to-Map Cache conversion, as LISP registrations are directly translated to Map-Caches, but standalone Borders in 1.0 need to know the scope of what they should be "map-requesting" for.

[jalejand]

Another use for this command (again in SDA 1.0) is SDA Transit.

A remote border will register a remote fabric prefix to the Transit Control Plane, and then the TCP will take the registration, export it as LISP route, redistribute it into BGP and advertise the prefix to other Borders in other sites using BGP VPNv4.

Then, other borders will take the BGP route from TCPs and convert these into map-caches, so every time traffic hits a Border, which destination is an SDA transit-learned prefix, this map-cache can trigger resolution to the transit control plane .

[andy!doesnt!like!uucp]

Hi Alejandro
thanks for explanation but wouldnt it be more pragmatic for BN (at least in case with IP-transit) just to map-request site' local CP about destination EID instead of having site' prefixes imported into map-cache from vpnv4 bgp peering with CP? 
for SD-transit in LISP1.0 i might missed something. do we maintain vpnv4 bgp peering between BNs & TCPs on SD-transit concurrently to LISP? i cannot find materials to learn it deeper.

[andy!doesnt!like!uucp]

to make them part of prefix-to-RLOC mapping available to internal fabric's LISP routers maybe...