SDA transit control node

[iores]

Hi,

I have a question regarding traffic flow from fabrice site 1 to fabric site 2 with the help of transit control node.

I know that B/C node at each site registers local EID prefixes to transit control node which then redistributes them to MPBGP.

As a result, each B/C node at each site will have BGP route with next-hop to transit control node.

So when end-point at site 1 tries to communicate to end-point to site 2, how B/C at site 1 chooses to send LISP request to transit control node when more specific entry exists in the routing table? As I recall, LISP is used only if there is no specific route in the routing table.

[Torbjørn]

When using SDA Transit you will typically only have the infra VN/underlay routing information on your TCN and border nodes. This way your borders should be able to reach TCN and the loopbacks(RLOC) of other borders without learning routes for the destination within your VNs/VRFs. By doing this LISP will be used for routing of the traffic as expected.

The situation you describe will only arise if you configure a routing protocol for your VRFs between your TCN nodes and the rest of your network, in addition to having configured an IP transit for your VNs on your borders. I don't see any good reason to do this in a production setting, but it could be a fun lab excercise.

A more common scenario that causes a similar issue is if you have both SDA transit and IP transit configured on your borders(not unusual in a migration phase). In this situation you can quickly run into unexpected traffic patterns if you aren't careful about filtering routes in your non-SDA Transit.

[iores]

Hi,

But the transit CP learns LISP prefixes for all VRFs, and then redistributes them to BGP. It acts as some sort of route reflector. But I don't know what makes local BC nodes to send LISP queries to transit CP despite there is a BGP routes in RIB which points to transit CP.

[jedolphi]

Hi, I presume you're asking about LISP/BGP SDA Transit, not Pub/Sub SDA Transit. Just to be clear, moving forward Cisco recommends Pub/Sub Control Plane for Fabric Sites and SDA Transit, but of course some existing implementations use LISP/BGP. You could review the following Cisco Live presentation, "With BGP, LISP only knows the prefixes, not full EID-to-RLOC mappings, BGP populates map-cache with an incomplete entry, Map-cache is fully resolved through map-requests". https://www.ciscolive.com/on-demand/on-demand-library.html#/session/1686177770252001VXxo

[iores]

I thought that there were three types of SDA transit to interconnect multiple fabric sites in a single fabric domain: IP based, SDA transit, and SD WAN. 

[jedolphi]

That's correct, there is three types of Transits:
1. IP-Based Transit
2. SD-Access Transit
3. SD-WAN Transit

This discussion is about SD-Access Transit, and there are two Control Plane architectures possible in an SD-Access Transit:
A. LISP/BGP
B. LISP Pub/Sub

When you create SD-Access Transit you choose between A and B as per the below screenshot. Best regards, Jerome

[KevinR99]

Jerome

When I get to the screen above to create a SD Access Transit I have no options to select in the transit control plane node field even though I have 2 suitable devices, Catalyst 9300’s, provisioned in each fabric site.  The devices are added to network via LAN Automation and are each attached to a Border node in each fabric site.  I have tried defining the device as a control plane only node first or simply leaving it unassigned in thee hope it is designated as a TCN in the create SD Access transit process.  However, neither method then shows the node available in the transit control plane node field.

Could you advise the process to provision and deploy a TCN and any requirements for its location?

Thank you, Kev.

[Andrii Oliinyk]

so did u resolve it?Re: SD Access Transit control plane deployment - Cisco Community

[KevinR99]

Yes