cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5323
Views
7
Helpful
11
Replies

Intermediate node deployment

Sylvain_Che
Level 1
Level 1

Hi all,

 

I've got multiple questions about SDA Intermediate nodes deployment that I didn't find answers. I want to deploy 2*C9500-48Y4C as Intermediate nodes.

 

  1. How Intermediate nodes within the same site should be connected together? Should we physically connect a fiber between them?
  2. Should we configure a routing protocol between them? IS-IS or iBGP? And is it done automatically through the LAN Automation?
  3. Better to deploy them as Standalone nodes or in StackWise Virtual? I've read other threads saying that unless necessary, it is better to deploy them as Standalone.
  4. If the StackWise Virtual option is selected, can a pair of C9500-48Y4C be LAN Automated? We're currently running DNAC 1.3.3.9. The data sheets of the various existing DNAC versions are not always clear with this, especially when dealing with Intermediate nodes.

Any linked documentation would be appreciated.

Many thanks in advance for your help.

 

Sylvain.

2 Accepted Solutions

Accepted Solutions

jedolphi
Cisco Employee
Cisco Employee

Hi Sylvian,

Q1. Intermediate node simply routes IP between fabric nodes. There is no correct cabling connectivity between intermediate nodes. The right cabling depends on what failure and traffic forwarding scenarios you are designing for. In short: you can run a cable between intermediate nodes, or not run a cable, it's the network designer's choice.

Q2. Intermediate node within a fabric site usually runs same routing protocol as FE and border nodes. Usually this is IS-IS. If there is a cable between intermediate nodes then yes, route peer over the cable.

Q3. If there is no firm requirement to use StackWise Virtual then standalone is preferred as it's simpler.

Q4. There is no LAN Automation support for StackWise Virtual as PNP client. StackWise Virtual can be used as seed in later DNAC versions, this is explained in the LAN Auto deployment guide, https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/tech_notes/b_dnac_sda_lan_automation_deployment.html

Regards, Jerome

 

View solution in original post

 

Hi Sylvian,

Referring to the diagram, why only one B+CP? Does that make the CP a single point of failure?

Regarding “enable multicast”, it depends on what you’re trying to achieve. The first time you tick “enable multicast” the primary seed and secondary seed (if you have nominated one) will be setup as the underlay anycast RP; this is explained on the LAN Automation Deployment Guide, https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/tech_notes/b_dnac_sda_lan_automation_deployment.html

Yes, the procedure you shared should work.

Another way to accomplish same would be (assuming you want your borders to be hosting the underlay anycast RP) be:

  1. First time running LAN Automation, set B1 as primary seed, select B2 as secondary seed, “enable multicast”, start LAN Automation.
  2. Connect Intermediate1 and Intermediate2.
  3. Stop LAN automation.

Jerome

 

View solution in original post

11 Replies 11

jedolphi
Cisco Employee
Cisco Employee

Hi Sylvian,

Q1. Intermediate node simply routes IP between fabric nodes. There is no correct cabling connectivity between intermediate nodes. The right cabling depends on what failure and traffic forwarding scenarios you are designing for. In short: you can run a cable between intermediate nodes, or not run a cable, it's the network designer's choice.

Q2. Intermediate node within a fabric site usually runs same routing protocol as FE and border nodes. Usually this is IS-IS. If there is a cable between intermediate nodes then yes, route peer over the cable.

Q3. If there is no firm requirement to use StackWise Virtual then standalone is preferred as it's simpler.

Q4. There is no LAN Automation support for StackWise Virtual as PNP client. StackWise Virtual can be used as seed in later DNAC versions, this is explained in the LAN Auto deployment guide, https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/tech_notes/b_dnac_sda_lan_automation_deployment.html

Regards, Jerome

 

Thanks Jerome. The answers are clear.

We'll go for standalone deployment. It makes clearly more sens than using SVL.

 

For the routing between the 2 Intermediate nodes using the direct physical connection, I assume I can go with the following method (based on the attached topology):

  1. Perform the LAN Automation for Intermediate1 with the Seed defined as the Border/CP node.
  2. Physically connect the Intermediate2 to Border-only node and to the Intermediate1, and define the former as Primary Seed and the latter as 2ndary Seed. So the routing between Intermediate nodes is automated and use IS-IS.

 

In regards with @StevieC666's remark not to tick the 'Enable Multicast' checkbox and configuring the underlay multicast manually, is it correct and still needed to do this way?

 

Thanks,

Sylvain.

 

Hi Sylvian,

Referring to the diagram, why only one B+CP? Does that make the CP a single point of failure?

Regarding “enable multicast”, it depends on what you’re trying to achieve. The first time you tick “enable multicast” the primary seed and secondary seed (if you have nominated one) will be setup as the underlay anycast RP; this is explained on the LAN Automation Deployment Guide, https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/tech_notes/b_dnac_sda_lan_automation_deployment.html

Yes, the procedure you shared should work.

Another way to accomplish same would be (assuming you want your borders to be hosting the underlay anycast RP) be:

  1. First time running LAN Automation, set B1 as primary seed, select B2 as secondary seed, “enable multicast”, start LAN Automation.
  2. Connect Intermediate1 and Intermediate2.
  3. Stop LAN automation.

Jerome

 

Hi Jerome,

 

Got it. Thanks again for the feedback.

The topology shown is incomplete. We actually have a 2nd Control Plane node in a 2nd physical site (but belonging to the same Fabric Site). Based on current various constraints, the only connectivity option we have today is to connect 1 Intermediate node with a single uplink to B/CP, and to connect the 2nd Intermediate node with a single uplink to the 2nd Border.

StevieC666
Level 1
Level 1

We've got six C9400s out there in our campus setups with over 300 C93k & C36k switches hanging off them. Each campus site has two border nodes. 

 

We've not connected the FEs which also double as inters together, they only have uplink connections to the border nodes and down link to the FEs, in some cases we're 4 hops from the border nodes via the FE/inter approach.

 

Top tip, don't ever tick enable multicast when performing LAN Automation as the LA process expects devices to be connected to border nodes. Our clever partner chap worked with TAC who guided that we needed to configure multicast across the underlay manually.

 

Hope this helps 

leandrordc
Level 1
Level 1

To do LAN Automation of Stackwise Virtual switches, you can run the LAN Automation to provision the Master Switch then configure manually the stackwise on Master and Standby using a script like this:

===============

conf t
stackwise-virtual
domain 1
interface range TwentyFiveGigE1/0/47-48
stackwise-virtual link 1
interface TwentyFiveGigE1/0/46
stackwise-virtual dual-active-detection
end
switch 1 priority 15 <<<----- Just on Master switch (LAN automated)
wr
reload

=====================


@leandrordc wrote:

To do LAN Automation of Stackwise Virtual switches, you can run the LAN Automation to provision the Master Switch then configure manually the stackwise on Master and Standby using a script like this:

===============

conf t
stackwise-virtual
domain 1
interface range TwentyFiveGigE1/0/47-48
stackwise-virtual link 1
interface TwentyFiveGigE1/0/46
stackwise-virtual dual-active-detection
end
switch 1 priority 15 <<<----- Just on Master switch (LAN automated)
wr
reload

=====================


To have StackWise Virtual (SVL) in Cisco DNA Center, the SVL has to be built FIRST, then discovered.  We do not support discovering a single switch, converting it SVL, and then resyncing to try and have Inventory add the SVL. 

Please avoid any manual workarounds like this, as they are likely to encounter challenges later down the line because of them.

With regards to using SVL at all, may I ask the use case for SVL when using a Layer 3 routed access network which is what LAN Automation builds?  SVL, like VSS, was purpose-built to address Layer 2 link redundancy challenges and address full link utilization in these STP environments through MEC. I am hard-pressed to find a use case for SVL in a strict Layer 3 environment. 

Hey Jonathan


@Jonathan Cuthbert wrote:

@leandrordc wrote:

To do LAN Automation of Stackwise Virtual switches, you can run the LAN Automation to provision the Master Switch then configure manually the stackwise on Master and Standby using a script like this:

===============

conf t
stackwise-virtual
domain 1
interface range TwentyFiveGigE1/0/47-48
stackwise-virtual link 1
interface TwentyFiveGigE1/0/46
stackwise-virtual dual-active-detection
end
switch 1 priority 15 <<<----- Just on Master switch (LAN automated)
wr
reload

=====================


To have StackWise Virtual (SVL) in Cisco DNA Center, the SVL has to be built FIRST, then discovered.  We do not support discovering a single switch, converting it SVL, and then resyncing to try and have Inventory add the SVL. 

Please avoid any manual workarounds like this, as they are likely to encounter challenges later down the line because of them.

With regards to using SVL at all, may I ask the use case for SVL when using a Layer 3 routed access network which is what LAN Automation builds?  SVL, like VSS, was purpose-built to address Layer 2 link redundancy challenges and address full link utilization in these STP environments through MEC. I am hard-pressed to find a use case for SVL in a strict Layer 3 environment. 


L2 Border Handoff is one scenario where SVL is required to provide redundancy at Border level


Best regards
Ahsan Rana

 

Ahsan Rana

notice that topic is relevant to intermediate nodes which stacking in basically L3 env is senseless unless one needs to utilize them for some L2-stuff. & yeah, it can be L2 BN handoff among others. but here i'd suggest legacy l2-transit via intermediate VSL-pair :0)

guess you are reading a bit out of context here regardless 'title of the thread':

I responded to the statement "I am hard-pressed to find a use case for SVL in a strict Layer 3 environment"

HTH

Ahsan Rana

everyone is interpreting thread on it's own. But i wonder why in your case u ignore " in a strict Layer 3 environment" condition :0)

cheers

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: