02-21-2020 02:09 AM
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?
Solved! Go to Solution.
02-24-2020 04:52 AM
02-21-2020 06:01 AM
02-21-2020 06:26 AM
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
02-24-2020 12:37 AM
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?
02-24-2020 04:52 AM
05-01-2020 02:37 AM
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...
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.
05-01-2020 07:49 AM - edited 05-01-2020 07:51 AM
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!
05-01-2020 07:55 AM
Interesting. Thanks Mike.
05-01-2020 08:03 AM
05-01-2020 08:06 AM - edited 05-01-2020 08:09 AM
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
05-01-2020 08:13 AM
That's great, thank you for confirming Scott 👍
05-01-2020 08:27 AM
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
05-01-2020 08:32 AM
@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!
11-27-2020 01:16 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide