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,
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?
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!
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.
Senior Technical Marketing Engineer
Enterprise Networking Group
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:
Customer is running DNAC 126.96.36.199. According to the bugs, this might be fixed in 188.8.131.52 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.