In this particular topology use of the Fusion router would lead to inefficient paths being taken and a single point of failure as we have two cores that would be acting as Border nodes but only one Fusion Router
Leaking routes on the border node is not going to fix the underlying issue here which is your topology.
It might move the route leaking responsibility to a pair of devices, but when you egress out of the fabric towards your shared services, you still have a single point of failure. It may seem like you are gaining added resilience, but you are not.
@trickyg wrote:
Hi
I am in the process of introducing SDA into our network and would prefer to route-leak between the VNs on the border router itself rather than handoff to the Fusion Router.
It is (allegedly, reportedly, though I have never tested it) technically feasible to leak routes on the border node itself. I tell you this because we are all engineers, and we figure out creative ways to do things based on the knowledge and experience and of course, information sharing. However, technically feasible ≠ supported. We support leaking routes on the an external entity. We do NOT support leaking routes on the border node itself. There are lots and lots and lots of reasons you don't want to do this beside the high degree of potentiality for interfering and breaking some Cisco DNA Center configured element.
In the SD-Access CVD, you can see me heavily promoting the use of service blocks (consider it a fusion router in your scenario).
Why?
"it isolates or separates specific functions into dedicated equipment allowing for cleaner operational processes and configuration management. It also provides a centralized location for applying network security services and policies such as NAC, IPS, or firewall. "
Please route leak externally, not on the fabric devices.
