SD-Access vstack from two borders

[waleedmatter]

If i configured vstack from two borders and connected the edge-switches dual homed , when i select the lan automation , it will detect the port-channel and configure it as a layer 3 and add the isis configuration or not ? dnac version 2.3.7 

[Enes Simnica]

gDay to u. And yes, LAN Automation in DNAC 2.3.7 will detect the dual-homed edge and build the port-channel automatically. And It’ll configure it as L3 and push the required IS-IS settings as part of the underlay bring-up, so u don’t need to do it manually.

hope it helps and PEACE

-Enes

[waleedmatter]

Good day , Thx for your answer but you sure that this will be a behaviour because i am afraid to make vstack and discover it and provision it and then when i will make lan automation , it will not create l3 port-channel and apply the ISIS config and i read the lan automation deployment for this version and they didnt mention this behaviour   Cisco Catalyst Center User Guide, Release 2.3.7.x - Provision a LAN Underlay [Cisco Catalyst Center] - Cisco  ,,,if you did in the lab or you have official doc. ?   thx

[Andrii Oliinyk]

can you bring more clarity on where do u want to do LAN-A when u need "create l3 port-channel and apply the ISIS config"?

[waleedmatter]

I need when i will make vstack between two borders so assumed when i will make lan automation (seed device logical border , peer the same border) and selected the physical interface which connected to the edge-switch ,,,i assumed the DNAC will bundle the physical interface to port-channel and push isis config. under it from two sides

Border-vstack

Tweng1/0/1        Teng2/0/1

|                             |

|                             |

teng1/0/1           teng1/0/2

Edge switch 

[Andrii Oliinyk]

sorry still not clear
is it where u want LAN-A?

[Torbjørn]

LAN Automation will always configure "regular" routed interfaces, it does not bundle them into an L3 portchannel as it usually not needed/wanted. If you wish to do this you will have to configure it manually.

To quote the LAN Automation portion of the SDA Design guide:

"""

Whether using LAN Automation or deploying the network manually, the underlay networks for the fabric have the following general design requirements:

●      Layer 3 routed access: The use of a Layer 3 routed access network for the fabric provides the highest level of availability without the need to use loop avoidance protocols such as Spanning Tree Protocol (STP), interface bundling techniques using link aggregation technologies such as EtherChannel, or Layer 2 redundancy technologies like StackWise Virtual (SVL).

"""

[waleedmatter]

So work-around ,,,can i make virtual stack between two borders and then make lan automation (seed device) and no peer and select the interface which connected to edge-switch then the isis will be pushed to this link and then provisiong the edge-switch ,,,,,from the fabric site , i will select this fabric edge switch and then add link and connect second link between this switch and vstack border and proivision it then the second link will have l3 isis routing so   at the end i have vstack border-------connected to two uplinks isis --------edge switch ,,,, i need to avoid the back to back between two borders and make VN's and underlay bgp between two borders as well as from fusion will have two session per vn so with this workaround no back to back bgp sessions and one session with fusion per vn correct ?

[Andrii Oliinyk]

"can i make virtual stack between two borders and then make lan automation"
If you mean converging 2 separate BNs in kind of cisco-stacking be discouraged from doing this as you'll lose hitless maintenance.
"connect second link between this switch and vstack border"
LAN-A allows you to create as many links to seeds as you need:
Cisco DNA Center User Guide, Release 2.3.5.x - Provision a LAN Underlay [Cisco Catalyst Center] - Cisco
no idea what bgp has to do with LAN-A

[waleedmatter]

so i am waiting your answer ,,, 

[Andrii Oliinyk]

as i thought. 
i & @Torbjørn already told that deployment as on your picture means population of site will lose connectivity during maintenance of the box on top. consider also worst case scenarios like unexpected entire stack crash. Always have your ENs connected to 2 different BN|CPs. do you want to build them as stacks? welcome, but still have that stacks different 2+ entities
& again, u add 2nd link with Add Link feature (see URL i dropped above)   

[waleedmatter]

It is new implementation and there is no any impact

[waleedmatter]

you didnt get my idea,,,,my target to make two border virtual stack to reduce the bgp neighbors if i will make the two broder separated then when i will make the two borders vstack and connected by two uplinks with the edge-switch and make lan automation,,,,, the configuration will be pushed on one interface ,,, so the problem now how i can make lan automation with the second link which connected to the edge-switch as well as it is not a peer and it is a seed so there is workaround to add fabric link after the edge switch provisioning 

[Andrii Oliinyk]

"if i will make the two broder separated then when i will make the two borders vstack" - what is it about?
try to form your idea with diagram maybe bc i personally constantly get confused reading it.
nevertheless having stacked BN as single BN in Fabric site is bad idea unless u dont care about hitless maintenance.
"how i can make lan automation with the second link" - Add Link feature is your friend
cannot get remaining...
 

[Torbjørn]

It will be easier to give you a correct answer if you could supply a diagram along with the explanation of the issue at hand. I think @Andrii Oliinyks last answer fits what you are asking in the last half of your latest last response.

You should however reconsider using stackwise virtual for your border nodes. Best practice is to keep the control & management plane separated. I recommend reading through the underlay network design portion of the SDA design guide: https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html#Underlaynetworkdesign