Stacking Control Border catalyst9500

[SultanIE]

Hi all, 

I have Two Catalyst 9500 Switches, I Deployed SD-Access with one catalyst 9500 as Control and Border node and I'm having EBGP Sessions with physical stacked Fusion Routers

According to SD-A CVD Guide I understand I have to do the same with Second Control Border Node and IBGP between Control Border Nodes.

Instead doing that is it possible to stack them Physically both the Control Borders Nodes ? if it's supported please guide how to ?

Currently I'm using DNA Center Version 2.3.5.5 

Best Regards,

[Torbjørn]

Hi @SultanIE,

It is possible to stack your border nodes with StackWise virtual, but there is not much to gain in doing this. The common usecase for stacking border nodes is if you wish to create a L2 border handoff. If you wish to do this you will have to remove the switches from your inventory, configure the Stackwise Virtual manually, add them to your inventory and provision them with the desired roles.

Unless you have a very specific reason to do this I would keep them separate and configure it as a second L3 border handoff. This is both less complex and won't require a service disruption to implement. Note that your border+control nodes will establish iBGP peerings with eachother automatically.

[SultanIE]

Hi @Torbjørn thanks for your replay.

I was thinking to minimize the configs for L3 Handoff Redundancy by stacking both borders however, I totally agree second L3 border handoff is less complex and won't disrupt the service.

one more question you mentioned they will have IBGP peering automatically I thought I've to Configure them manually kindly, would you please guide how to push IBGP from DNAC ?

Best Regards,

[Torbjørn]

It will configure an iBGP peering automatically between all control-plane nodes in your fabric. You should be able to see it once you've added your second border/control-plane node to the fabric.

[SultanIE]

hi @Torbjørn thanks for your replay

as you mentioned DNAC already Pushed IBGP Peering using loopback as source between the borders.

[jedolphi · Accepted solution]

It was very common to manually configure per-VRF IBGP between External BNs in a LISP/BGP Fabric Site (although it was not strictly necessary, but I'll save opening that can of worms for now). In a LISP Pub/Sub Fabric Site the per-VRF IBGP should not be added manually and the underlying use case is no longer applicable. JFYI, all new Fabric Sites should use LISP Pub/Sub please, Pub/Sub is the focus of SD-Access innovation moving forward. Best regards, Jerome

[SultanIE]

Hi @jedolphi thanks for you replay.

yes as you mentioned most of the guides recommend manually configuring per-VRF IBGP which put me in some confuse

and I thought if Stacking the Borders are possible then I don't have to manually configure per-VRF IBGP however, it seems DNAC pushed IBGP Peering using loopback as source so I guess I don't have to manually configure per-VRF IBGP.

Currently my concerns are failover and load balancing as it seems the traffic goes to only border-1 since the static route in underlay pointing to border-1 so I added another static route pointing to Border-2 with AD of 2 for 1&2 floors and the opposite static route for 3&4 floor pointing to border2 with ad of 1 and to border2 with AD of 2 to have a Manuel load balance.

I'm not sure if this is best practice for SD-Access load balancing I couldn't find documents can describe that properly and how to verify that LISP load balancing is working 

[jedolphi]

This is likely to be a much longer discussion, but in short, static routes should not be needed, and if you do have static routes then load balancing will be more difficult to accomplish. In most SDA implementations static routes not used. Jerome

[SultanIE]

Hi @jedolphi thanks for your respond.

If SDA implementations doesn't require static routes in underlay (Global Routing Table) how the Edge Nodes can reach and Communicate with DNAC and ISE? do we need to redistribute BGP INFRA_VN at the Control Border to IGP(IS-IS, OSPF) to accomplish this ?

[jedolphi]

Hi @SultanIE , some people configure default route origination in the IGP on the External Border Nodes, so that's an option if it suits your requirements. Redistribution as you describe is also an option, please consider controlling what is redistributed to only the minimum necessary i.e. no point redistributing 1000s of routes into underlay IGP.

[SultanIE]

thank you for respond @jedolphi that's was helpful.