topic Re: SDA in Software-Defined Access (SD-Access)

SDA

perezjm — Sun, 18 Feb 2024 05:24:55 GMT

Hello, I have a few questions in regard to SDA Border node redundancy.

1. Is it recommended to run ISIS between two redundant border nodes ? I see some documentation that shows the nodes connected, but not much is mentioned in regard to what underlay routing protocol is being used.

2. I know iBGP can be used for each VN between border nodes, however should iBGP also be configured for the underlay/grt, if an IGP such as ISIS is already running between the border nodes what would be the benefit of also running iBGP in the underlay/grt?

3, If running lisp pub/sub, I understand that we no longer need iBGP for each of the VNs ,however DNAC does configure an iBGP peering in the underlay/grt with the redundant border. What is the reason for this ?

Re: SDA

perezjm — Sun, 18 Feb 2024 05:38:00 GMT

I was able to find a few posts that address questions 1 and 2, however I'm not finding anything on why DNAC configures an iBGP peering between the borders in the underlay/GRT only.

Re: SDA

jedolphi — Tue, 27 Feb 2024 03:25:10 GMT

Hi, assuming LISP Pub/Sub, which is the most recent and recommended control plane architecture:

1. Yes you can use ISIS (or your manual IGP) between BNs in underlay. Whether you need to or not is defined by how BN1 Lo0 can reach BN2 Lo0. Most people will enable ISIS/IGP between BNs, FYI.

2. Per-VRF IBGP between BNs not required.

3. The IBGP peering is from BN to both CPs, which presumably are co-located with BN in your design. It should have VPNv4 and VPNv6 AF enabled, this is for transporting L3VN BGP routes through a Fabric Site. This subject is covered very briefly in BRKENS-2816, slides 37-40, https://www.ciscolive.com/on-demand/on-demand-library.html?#/session/1707505512189001p6lp

Best regards, Jerome

Re: SDA

Andrii Oliinyk — Wed, 24 Jul 2024 10:54:09 GMT

Hi Jerom
would appreciate u to touch topic#3 one more time.
as i can see on number of BN|CP pairs peering between themselves there is VPNV4 AF section

address-family vpnv4
bgp aggregate-timer 0
neighbor <mate-BN-IP> activate
neighbor <mate-BN-IP> send-community both
neighbor <mate-BN-IP> route-map <some-RM> out
exit-address-family

within this peering BN|CPs are advertising each to other (after filtering by defined RM) their directly connected subnets they use for peering with FNs in each arbitrary VN. Interesting is that received subnet prefixes are actually visible on the BN|CPs as LISP-learned routes actually:

BC0001#sho lisp eid-table vrf EXAMPLE_VN ipv4 map-cache X.Y.Z.Y/31
LISP IPv4 Mapping Cache for LISP 0 EID-table vrf EXAMPLE_VN (IID 4099), 1 entries

X.Y.Z.Y/31, uptime: 10w6d, expires: never, via pub-sub, complete, local-to-site
Sources: pub-sub
State: complete, last modified: 10w6d, map-source: MATE_BN|CP_IP
Exempt, Packets out: 2(1152 bytes), counters are not accurate (~ 10w6d ago)
Configured as EID address space
Locator Uptime State Pri/Wgt Encap-IID
MATE_BN|CP_IP 10w6d up 10/10 -
Last up-down state change: 10w6d, state change count: 1
Last route reachability change: 10w6d, state change count: 3
Last priority / weight change: never/never
RLOC-probing loc-status algorithm:
Last RLOC-probe sent: never

having above i totally lost the idea behind this automated iBGP peering between arbitrary Site's BN|CPs...

Re: SDA

jedolphi — Thu, 01 Aug 2024 03:03:57 GMT

Hi Andy, sorry I am not following, what is your question?

Re: SDA

Andrii Oliinyk — Thu, 01 Aug 2024 07:59:35 GMT

Ok. Looks like i was exploring LISP&BGP stuff on one of 2 BN|CPs...
Here RIB from both:

bc on other BN|CP (#1) it looks differently & more reasonable (routes have their best roles expectedly). While on the BN|CP#2 subnets local to BN|CP#1 (specifically those between BN|CP#1 & FNs#[12]) are:
Routing entry for <MATE_BN|CP_2_FN[12]>/31
Known via "lisp", distance 250, metric 1, type unknown
Redistributing via bgp <LOCAL_AS>
Advertised by bgp <LOCAL_AS> metric 10 route-map LISP_TO_BGP
Routing Descriptor Blocks:
* directly connected, via Null0