Fabric Border Redundancy in SDA

[techno.it]

Hello,

We have never deployed SDA, I am just wondering how the redundancy work between two Fabric Border nodes in SDA and they are physically distributed in different location within a building. Is it VSS or HSRP ? How the endpoints fail over to secondary, if primary fails

Any suggestions ?

[Scott Hodgdon · Accepted solution]

techno.it,

If you are using Catalyst 9500 for border, we do not yet support StackWise Virtual (SWV) as a border. If you have only L3 connections on the Border, then you won't need SWV as we will rely on ECMP routing for resilience.

The SD-Access Deployment Guide addresses Border resilience for Underlay and Overlay. This is also addressed in the Cisco Live session BRKCRS-2811, which you can download / watch for free in the On-Demand Library at ciscolive.com .

Cheers,

Scott Hodgdon

Senior Technical Marketing Engineer

Enterprise Networking Group

[techno.it]

Hi Scott,

We will proposing C9606R to an enterprise customer.

[iores]

@Scott Hodgdon How dual border actually works? I am not assuming stacking. Is one being the active one who gets all map registration/requests, and the other being passive?

[jedolphi]

By default the Border Nodes are active/active for outbound (South to North) traffic towards the Fusion device. For inbound traffic (North to South) the traffic follows whatever routing path is calculated on the Fusion device based on its routing protocol, which is usually BGP.

[iores]

@jedolphi 

If border node is control node, as well, how does the LISP map registration and map resolution work? To which b/c node edge node sends registration requests?

[jedolphi]

Hello, Endpoint details are registered to both Control Plane Nodes, regardless of whether they are standalone or co-located with Border Nodes. Regards, Jerome

[iores]

@jedolphi So in case of MAP request, the xTR would receive two MAP reply? Is there any case in which the two MAP reply would differ and which one would xTR choose as relevant?

[jedolphi]

Hello @iores Map-Request (as opposed to registration we discussed previously) is sent to one LISP Control Plane Node node, thus there is only one Map-Reply.

[Mike.Cifelli]

Definitely check out what @Scott Hodgdon shared.

Few things I would like to note from my experiences:

You have the ability to run two EBNs + two Fusions with each EBN having an uplink to each FR via an ebgp connection. Then the EBNs connect together via ibgp. In each bgp vrf address family set the max-paths eibgp to 2 so both routes get installed in bgp rib. By default DNAC will provision vrf-lite using 3xxx series vlan ids on your EBNs. In this implementation you could use 4xxx or 2xxx series vlan ids for the EBN <--> EBN ibgp config. The uplinks and connection between EBNs simply trunk the vrfs/ids respectively. Then for redundancy on the links you can run BFD. Something else we run in our SDA deployment is GLBP on the EBNs for an underlay fabric connection for DNAC/ISE. This accomplishes underlay connectivity regardless if an EBN goes down so that we can onboard hosts via ISE policies or manage NADs with DNAC. That buildout idea was so that we did not have to route underlay management functions (ISE/DNAC) out of the fabric through the FRs and into "legacy". Essentially it is a "backend" connection into the fabric.  Good luck & HTH!

[jendoubi Abdelbasset]

hello,

how can i select the 2 interfaces from each EBN to both FR with DNAC i can just select one interface

regards

[Scott Hodgdon]

jendoubi Abdelbasset,

You do 1 interface at a time. 

Cheers,
Scott Hodgdon

Senior Technical Marketing Engineer

Enterprise Networking and Cloud Group