Static Route on a Border Node with Nexthop behind a Farbic Edge Node

[A.Swinnen]

Hi All,

It seems a common scenario to me where a router is connected to the campus LAN behind which  a few subnets are located (e.g. a staging environment). Would it in an SDA Fabric be possible (and supported) to connect this router on a fabric edge (port statically configured as trunk port) ?

I suppose I will have to implement the static route on the Fabric Edge and get it announced in LISP by the Fabric Edge (and redistributed into BGP by the Border Node). 

[Flavio Miranda]

Hello,

   Take a look on this tread.

https://community.cisco.com/t5/software-defined-access-sd-access/non-sda-switch-connected-to-the-fabric-edge/td-p/4297464

But I dont believe you can do the routing part as you are thinking.

[A.Swinnen]

Thanks, this looks as a potential solution: "(We CAN route between a router and SDA Edge + Border Node, but that is a much larger conversation, I assume it is not what you're looking for here).".

I also found this drawing, but I'm wondering how to configure the routing between a border node and a router behind an edge node.

 [source: https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKCRS-2811.pdf]

[andy!doesnt!like!uucp]

with regard to picture u've posted just imagine that u have configured legacy L1-L3 connectivity between BN & WAN|DC-edges (not very good idea actually :0). with that u can configure latter as extra-FNs in parallel to FN to External Network. But i dont think it's good idea to have L3-gateways to other legacy networks to be connected as endpoints to SDA-fabric & then have their EIDs to be used for whatever kind of legacy IP-peering with BN. Finally it's a matter of the SDA-supported designs & restrictions/limitations u meet in your real environment. 

i's suggest u to read this session from CscoLive:

DGTL-BRKENS-3822 (ciscolive.com)

notice slide 15 with recommendations about how to avoid problems with migration to SDA & its operation

[andy!doesnt!like!uucp]

i guess u want to have static routing between your Fusion Node & BN, right?

technically i's possible, but only protocol officially supported between BN & FN is BGP. i dont think it will change in the future.

for non-BGP LISP<>legacy-IP-routing interoperation u will need to configure it manually on both BN & FN now. & obviously it wont be supported solution.

[jalejand]

It is easier to just configure the FE as Internal Border + FE and setup BGP between it and the Router. This way these subnets can be imported into LISP.

[A.Swinnen]

A bit late: but indeed if the Fabric Edge Node could be combined with the Internal Border Node role, it would be ideal. However, that combination is (yet?) available in my current deployment. 

[jedolphi · Accepted solution]

The Fabric Edge Node (EN) + Internal Border (IB) Node combination is supported now, you need to provision both roles in the same provisioning action, you cannot add a role later e.g. cannot add IB to an existing EN. You'll need to delete the existing EN and then re-provision as EN+IB. Also you'll need to make sure that the EN hardware supports Border role; in other words C9200 won't cut it, you'll need at least an C9300, as per the SD-Access Compatibility Matrix.

If the Fabric Site in question is using LISP Pub/Sub architecture then please note that in Pub/Sub  all EIDs are continuously "published" from the Control Plane Node to all Border Nodes, and all Border Nodes program these publications into forwarding plane hardware immediately. This means you should be careful adding IB (Internal Border) role to a lower end platform (e.g. C9300) when the Fabric Site endpoint scale exceeds the IB platform's Border Node scale - check the DNA Center data sheet Border Node scale tables please. We may have a summarisation solution to this conundrum later, but not as of this writing.

Or, if the Fabric Site is using the LISP/BGP architecture then "publishing" all EIDs to the IB is not a thing that can happen, until the Fabric Site is upgraded to Pub/Sub, which is inevitable because Pub/Sub is our strategy model moving forward.

Regards, Jerome