cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3108
Views
40
Helpful
13
Replies

intermediate/edge node

Michal Rzepecki
Beginner
Beginner

Can a single node act as a SDA intermediate node and a SDA edge node simultanously? If it's possible, what is the best way to provision this kind of node?

1 Accepted Solution

Accepted Solutions

If I provision a node as a Edge node, can I make it seed and discover other devices that are connected to this edge node?
In this type of scenario another NAD connected to your provisioned edge node would be known as an extended node. This possibility allows you to daisy chain another switch and connect it via trunk by utilizing plug n play. However, there are only certain platform models that are supported; See here: https://www.cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access/compatibility-matrix.html
Also, for a deeper dive and understanding about edge nodes see this post: https://community.cisco.com/t5/software-defined-access-sd/sda-extended-node-tips/td-p/3994324
Not sure if you environment is wired and/or wireless, but other devices that you can find & discover, and attach to edge nodes would include access points. However, again there are restrictions here as well (see the compatibility matrix).
As far as overall SDA design I would suggest taking a look at CVDs and engaging with your Cisco reps for further assistance. Good luck & HTH!

View solution in original post

13 Replies 13

Mike.Cifelli
VIP Advisor VIP Advisor
VIP Advisor
AFAIK this is not possible. Reason being is that once you have discovered a NAD in DNAC, added to site, and provisioned to fabric you assign its type (ie - edge node). INs are not joined to the fabric since they are strictly used as a means of transport and dont need all the additional things such as Closed auth template configs. However, there is an approved solution called fabric-in-a-box that allows you to simultaneously configure a NAD to be an edge, border, and control plane node. HTH!

To add to Mike's comments, when we first set up SDA we added the INs to the Fabric. We later found out that this was not in accordance with the CVD. Though I don't remember exactly why, I do remember that there were good reasons not to add the INs to the Fabric and we removed all of them (still need to be in inventory, added to site and provisioned just not in Fabric).

 

With that said, when they were in the Fabric it was possible to use non-uplink and non-Network Module ports as user ports. Again this isn't recommended and it was something that worked ~2 years ago so I'm not sure if it would still work or not, however if you're in a pinch it may be something that you could try.

Hope this is helpful,

Chuck

I'm not able to try it because I don't have any equipment to do this. Someone asked to quote such a design but I'm not sure if it is going to work that way.

If I provision a node as a Edge node, can I make it seed and discover other devices that are connected  to this edge node?

If I provision a node as a Edge node, can I make it seed and discover other devices that are connected to this edge node?
In this type of scenario another NAD connected to your provisioned edge node would be known as an extended node. This possibility allows you to daisy chain another switch and connect it via trunk by utilizing plug n play. However, there are only certain platform models that are supported; See here: https://www.cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access/compatibility-matrix.html
Also, for a deeper dive and understanding about edge nodes see this post: https://community.cisco.com/t5/software-defined-access-sd/sda-extended-node-tips/td-p/3994324
Not sure if you environment is wired and/or wireless, but other devices that you can find & discover, and attach to edge nodes would include access points. However, again there are restrictions here as well (see the compatibility matrix).
As far as overall SDA design I would suggest taking a look at CVDs and engaging with your Cisco reps for further assistance. Good luck & HTH!

Hi guys,

Sorry to drag this one up again but I just stumbled on the post and wanted to clarify something.

We have a customer with a setup like in the diagram below. The switches labelled as Agg/EdgeXX are configured as fabric edge nodes but are providing aggregation functionality too: There are other edge nodes hanging off them...

 

sda.png

 

For this particular customer, we've been referring to these Agg/Edge switches as intermediaries but strictly speaking they are not because they are fabric edge nodes. Only they're not on the edge. They're aggregation switches with the ability for hosts to connect to the fabric.

This seems to be working fine. Do you see any issue with this?

Cheers!

Matt.

I think a concern you may run into is technically this is not a CVD relating to SDA AFAIK. So if you run into an issue with a NAD referenced as an App/Edge NAD you may encounter issues with TAC if you try to engage with them. True SDA intermediate nodes are supposed to only be a part of the L3 network (backbone/underlay) used as a means of transport between your border and edge nodes. Essentially the intermediate nodes are equivalent to older distro NADs when relating to a 3 tier campus. The intermediary nodes should not be added to fabric which would mean at that point they do not contain vxlan info, sgt awareness, etc.  I am interested in knowing how you have assigned and provisioned your ENs and APP/ENs.  We have tested a similar setup way back in the day and were advised to change it.  BTW daisy chaining an edge node to another edge node is actually referred to as an extended node (edge node->extended node) which are connected via a trunk.  Anyways, I would honestly engage with your Cisco reps on this concern to be sure as that will be your best bet.  HTH!

Interesting. Thanks Mike.

No problem. Should you hear something different or something that has changed from a CVD perspective please share later on for the rest of us. Thanks & good luck!

Matt,

What you have in that diagram is what we call daisy-chained Fabric Edge nodes, and this has been supported (although not documented in the CVD) since Day 1 of SDA with the only caveat being that they cannot be Cat 4500.

Remember that with SDA we are routing in the underlay between loopbacks based on a VXLAN header, and so if the destination loopback is not on the Intermediate Node / Fabric Edge, then it will just pass it on like any other routed packet.

Cheers,

Scott Hodgdon

Senior Technical Marketing Engineer

Enterprise Networking Group

That's great, thank you for confirming Scott 👍

Well that would have been nice to know a few years ago. :-)

Guess that's what I get for waiting till now to join the Community.

Thanks for that clarification.

Chuck McFadden

@Scott Hodgdon thank you for clarifying this for us and the rest of the community.  IMO adding this to a CVD would be extremely beneficial moving forward for any customer engaging with SDA.  Thanks again!

Hi @Scott Hodgdon,

Sorry to drag this back up. I've just hit a new issue with our customer's setup of daisy-chained fabric edge nodes.

LAN automation has always worked fine for our customer but recently we've configured the fabric for extended nodes. When this is enabled on the fabric, DNAC pushes out the configuration line "pnp startup-vlan XXX" to all edge nodes.

The result of this is that when we attempt to LAN automate a new edge switch that is connected to another edge switch (so the other edge switch is the seed), the new switch picks up the pnp startup-vlan configuration and therefore creates vlan XXX locally, and grabs an IP address from the extended node DHCP pool rather than Vlan1 on the seed. This causes the LAN automation process to fail.

There is a workaround where you remove the "pnp startup-vlan XXX" config from the seed but this isn't ideal.

I'm aware of the following bugs that are related:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt44900

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu30856

Customer is running DNAC 1.3.3.6. According to the bugs, this might be fixed in 2.1.2.3 but I'm not sure if that will be true for a network with daisy-chained edge nodes.

I just wanted to make you aware of this and anyone else that might be reading this thread with a similar setup.

Cheers,

Matt.

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:

Recognize Your Peers