Hi,
It all depends what kind of design you have and for and for what kind of events you would like to protect from (link failure / device failure / ...).
If your border devices are acting as an external gateway (acting as LISP PXTR) they will attract all the traffic irrespective of the uplink state. So what you need to assure is that there is point-of-exit from such border even when single link goes down (otherwise you would need to deploy extra EEM scripts to disable LISP PXTR functionality when single link is down to avoid traffic blackholing).
Therefore what I would suggest is to have at least two links with external connectivity.
In your setup: FB1, FB2, FR1, FR2 it all depends if you can afford to have links:
FB1 --- FR1
FB1 --- FR2
and
FB2 --- FR1
FB2 --- FR2
If so, then you can build BGP on each of these links to have link redundancy and device-redundancy.
If this is not feasible, then it would be good to have a link between FB1 and FB2 so that in case FB1---FR1 link goes down (and FB1 acts as default point of exit), there is still point of exit to external world through FB1---FB2 interlink and iBGP established between these two devices (note that this is already perceived as being outside of the fabric as leverages BGP, not LISP).
From DNA-Center automation perspective, you have a possibility to automate overlay (i.e. BGP in customer VRF) via Border automation flow (leveraging IP Transit fabric) on Fabric Borders (but not on Fusion Routers which are outside of fabric and are currently not automated). Underlay configuration (for Loopback0 reachability to cover link and device failures) must be done manually.
For more details, I would recommend to study:
1) SD-Access Deployment guide (look at Cisco SD-Access Site Reference Models section) : https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/SD-Access-Distributed-Campus-Deployment-Guide-2019JUL.pdf
2) Cisco Live session: Cisco SD-Access - Connecting the Fabric to External Networks - BRKCRS-2811
Best regards,
Mariusz
