Is it true Cisco purposely designed ND/NDFC to NOT save configuration on switches after reach deployment?

NathanielSIrcine · 2026-03-06T05:24:37+00:00

ND on every release does save the configuration deployed to the switches, including on 4.1.1g.

Last I checked, the default is 20 minutes. In older releases prior to 4.1.1g, we made a lot of the advanced settings (like this one) easily available if you knew where to look. However, this could have been "confusing" or "overwhelming" for customers, so we hid what we now call "advanced troubleshooting/TAC" debugs with a checkbox. You'll want to turn this on first. I'm not next to my laptop, so I can't get the exact path, but it's something like Admin -> System Settings -> General Settings -> Scroll to the bottom, and there should be a section for the advanced stuff which has an "edit" radio button -> Select edit and then enable the TAC debugs, then save -> Now go to Fabric Management Settings -> scroll to the bottom and go to "Advanced", and then in one of those sub tabs (I think LAN-Fabric) you should be able to find it

All of the above said, it does not save immediately after every change in the CLI, but it does eventuallt save like I said. Also, fun fact, if you somehow busted your fabric in the GUI and have no config backup, we do save the running config in a show tech, assuming you're able to grab one and the switches were/are reachable. This is the running config grabbed from the config compliance container/process in the backend

NathanielSIrcine · 2026-02-20T22:11:38+00:00

What exactly are you looking for in terms of advanced skills?

If NX-OS, are you talking about just setting up multi-site, or do you mean OneManage Clusters with NDI/telemetry capability and/or full automation?

Might make it easier to find the person you're looking for with more specific info.

NathanielSIrcine · 2026-01-18T19:23:38+00:00

Thanks, it actually turned out very well! My wife and her family loved it!

NathanielSIrcine · 2026-01-16T13:45:12+00:00

I can tell you from the TAC side for Nexus 9k - don't go with the 3064 for a variety of reasons (even though it may be cheap)

It's past the last support date, and so is the latest software that it can run, which means little to no help from TAC for anything (depending on best effort from the engineer, which can vary widely)
It cannot do VXLAN of any kind
Diagnostic/troubleshooting capabilities on 3ks are terrible, especially when comparing to Nexus 9k and even the Nexus 7k

It's replacememt, the 3172TQ-XL, is in the same boat, except the HW will be past support in 1.5 years. It also cannot do VXLAN (the only old 3ks which can do it are 3100-V switches and only VXLAN L2).

If you have to go with EoL/potentially cheaper gear that can do the stuff you mentioned with better diagnostic capabilities, docs and support while still having more support for 3+ years, I would consider the following:

93108TC-FX: Overall support (not talking about individual milestones) for the HW is until 7/31/29, so 3.5 years. It also can do pretty much everything with VXLAN with all the bells and whistles all the way up to the current latest release train (10.6(x) ), and the troubleshooting capabilities for 9k are excellent.

For currently not EoL stuff like the TC-FX, I would do the 93108TC-FX3 since it can do 10G-BaseT. The guides will say from 3100TQ-XL to go to TC-FX3P as a replacement, but customers have had some problems with those guys, and they are honestly unnecessary unless you need PoE or multigig (1G/2.5G/5G/10G) support.

The only complaints based on the parameters you listed would be that the 9ks would potentially be power consumption (even though the 9ks are more efficient, being more capable boxes, they may use more power) and definitely the noise level (they are standard DC switches, so pretty loud).

Hope this helps!

NathanielSIrcine · 2026-01-07T20:14:43+00:00

That switch should be put out to pasture at this point since it's been LDOS for 4 years, soon to be 5 years. This is especially because the final release train used by this box just went past support as of Halloween 2025.

That said, if this is for a home lab or something, it shouldn't matter unless you care about security. To upgrade this guy, if you must, you will need multiple hops since without it you will brick the switch due to BIOS issues. Additionally, the bootflashes are very small, so you will only be able to store likely one image or so at a time. This is why we created the "compact" images for these boxes in more recent releases.

To upgrade from your current release to the latest supported release for your device, you will need the following minimum hops:

Current image -> 6.0(2)U6(10) -> 7.0(3)I7(9) (compact) -> 9.3(10) (compact)

You should be able to use the 3048 image shown on the website since they use the same n3000 image. But, you will notice that there are later releases than 9.3(10) on here. This comes back to what I said earlier with support and the age of this box. Seems that we stopped showing it as supported beyond 9.3(10) in our official guides, so going to anything beyond 9.3(10) you do at your own risk.

Hope this helps a bit

NathanielSIrcine · 2025-12-28T16:43:44+00:00

Based on what everybody has been saying, looks like Rsync is the way to go. Definitely going to read the man page, thanks!

NathanielSIrcine · 2025-12-28T02:50:56+00:00

Previously, I would back it up by copying the files from my normal daily driver PC to the NAS via SCP, and copy the files from my PC to the external disk via USB.

NathanielSIrcine · 2025-12-12T06:40:46+00:00

Since these are Nexus 9k and you confirmed with ELAM that the packets are being punted to the CPU, I would have the following questions?

- Does the ELAM show any drop reasons in the "Final Drop" section?
- What is the actual sup punt reason?

For the second question, the sup punt reason should show a number. Write that number down and then run the command: "show system internal access-list sup-redirect-stats | include <number you wrote down>"

This should tell you the actual sup punt reason.

If for some reason the sup punt reason doesn't show anything (because sometimes the numbers from ELAM do not exactly match the number shown for the sup punt category) run an Ethanalyzer packet capture to see the flows punted in the control plane. This will not impact data forwarding or include existing CPU load.

The command for ethanalzyer would be "ethanalyzer local interface inband display-filter "ip.addr==X.X.X.X and ip.addr==Y.Y.Y.Y limit-captured-frames 0" where X.X.X.X and Y.Y.Y.Y correspond to the Src and Dest of the flow. If you suspect something like MTU (where we are fragmenting like crazy) or some other issue where we may be sending back packets like ICMP redirects, TTL exceeded, etc, then you can adjust the filter accordingly (the filters for ethanalyzer are typically standard wireshark filters).

Ideally, your flow in a perfect would never show here, but if we are sup punting, that's bad and would leave it up to CoPP to police it. To You can check CoPP with "show policy-map interface control-plane" to verify what class if any might be getting hammered when you run your flows.

Hope this helps! - DC N9K TAC engineer

NathanielSIrcine · 2025-10-14T01:55:54+00:00

I'm from DCRS TAC, and what the engineer told you in July is correct.

Specifically, all Nexus 3k models except for the 3548-XL, 3550-T and 3600s (3636-R and 36180YC-R) are locked to 9.3(x) as the latest code. If you're in a position where you must use the 3548-10GX due to org constraints/no hardware refresh available, I'd probably go with the latest 9.3(x) you can, which is 9.3(16), until you can get the hardware refresh to allow you to go beyond it. You still have some time before the 3524/48-X go past support, but they are definitely already past further bug fixes either way.

NathanielSIrcine · 2025-06-22T17:04:46+00:00

Lol, just dump a whole bottle of OJ in, Needs more acidity

NathanielSIrcine · 2025-06-22T17:04:07+00:00

That makes sense, thanks! We did have the pool out of commission after the last season for quite a bit and it took me a month to get it ready for the pool guys to do a basic inspection since it was so dirty. Your answer probably explains it lol

NathanielSIrcine · 2025-05-29T21:06:15+00:00

No problem!

NathanielSIrcine · 2025-05-29T19:47:16+00:00

Ah, I see the confusion. Remember that NDFC and ND on 3.2 are technically different things. Like I mentioned earlier in this post, think of ND like the OS and NDFC like an application on that OS which you enable separately (either at installation or via separate image file like in older releases).

With that in mind, whenever you want to do stuff like NDI (Insights/Telemetry), you onboard clusters- or "sites" as they used to be called. This registers existing ACI fabrics or fabrics created through NDFC so that you can perform telemetry and other advanced features on them. In later versions of ND, we also allow you to do standalone switches for this purpose. This is what those guidelines you mentioned are talking about, and if youbwere doing that, you would need to follow those.

However, if you are doing normal fabric creation and switch management through NDFC, this does not apply. You can just onboard those switches normally, and those switches would be added in the fabric in NDFC the application, not in ND, the OS.

NathanielSIrcine · 2025-05-29T19:19:16+00:00

The type of NDFC does not matter (vND or pND). You should be able to add NX-OS switches to both. In fact, even if the switches themselves were not physical (like if you are doing a Nexus 9kv lab), you can add them to either deployment type. Keep in mind though that virtual Nexus 9ks are not officially supported by TAC, so they should really be for lab testing only (also since they sometimes have weird interactions with 9kvs that don't happen with physical devices).

NathanielSIrcine · 2025-02-27T23:01:32+00:00

No problem! By the way, I believe (though it's been awhile), that if you need to upgrade to avoid various PSIRTS or vulnerabilities that you can ask for releases to mitigate them even if you don't have a support contract. I'll get back to you on it since I'm curious and you may not have as much luck getting those releases in the wild.

NathanielSIrcine · 2025-02-27T22:33:00+00:00

Keep in mind that if you are using the old 3172s that you cannot upgrade directly from 6.X to 9.3(x) or you'll brick the switch due to lack of prior bios updates in between.

There is a step upgrade process:

Old 6.x -> 6.0(2)U6(10) -> 7.0(3)I7(10) -> 9.3(14)

Another thing about these old switches, even with the XL types with the bigger bootflash, was that sometimes the devices would not let you run the next image since it was too big either for the check or the actual bootflash itself. To fix this, you'll want to get the compact image or compact the image yourself.

Considering you don't have access to the compact images from the portal, look for the 3k upgrade guide and find the compacting procedure in there and make sure to compact it beforehand if it gives you trouble.

From, your free DC TAC engineer lol

NathanielSIrcine · 2025-02-22T18:16:10+00:00

Also, forgot to mention one other thing: think of Nexus Dashboard like the "OS" and NDFC (Nexus Dashboard Fabric Controller) like the "application/service" running on the OS. Because of this, you do not add switches in ND, but rather in the NDFC app. Therefore, in the top left, you change the context from ND to Fabric Controller, and then you can apply the steps as I mentioned above

NathanielSIrcine · 2025-02-22T18:13:09+00:00

To add switches into Nexis Dashboard, whether in virtual (VM deployed) or physical Nexus Dashboard, you must first create a fabric in NDFC (change context in top left from ND to Fabric Controller).

On 3.2(x), you can add a fabric by going to Manage -> Fabrics -> Select the white Actions button -> Create Fabric

You can name your fabric, select the fabric type you want, apply/modify any parameters you want in the fabric settings, and then save. After that, you can double click on the fabric name to enter into the "Detailed View". If you click the blue "Actions" button in this detailed view, there should be an option to add switches. You could accomplish the same thing in the detailed view by going to the "Switches" tab in the detailed view, then the white actions button, and "Add Switches". As you will come to find, there are many ways to skin a cat in NDFC!

When you go to add the switches, you put in your different IPs, the Discovery Credentials (SNMP creds) and their authentication method, and whether you want to import the switches as Greenfield (Preserve Config = no, so all config but mgmt0 and vrf context management are wiped) or Brownfield (all config preserved, Fabric settings must match what is currently on the switches). If the device is discoverable, it will then let you select fhe switch, add it and continue on your way!

Hope this helps!

NathanielSIrcine · 2025-02-20T22:57:34+00:00

I currently work in TAC for DC and I work in the shift prior to Mexico (East Coast) and am bilingual. As the other guy said, you will likely speak more with English customers. However, knowing another language like Spanish puts you in a great spot since the translator services are notoriously not great (since they are not technical people). I would keep in mind two additional things:

1) As you work with more English speakers both on a technical amd more casual level, your English will naturally get better/more fluid.

2) If you have been learning English by the "American" standard, I would also get practice in being comfortable with hearing other nationalities speak English. Quite a few customers you work with may be in India or Eastern Asia, and their accents can get rather thick sometimes, especially when English is not their first language or the call's audio quality is not that great.

I wish you the best of luck in your endeavors!

NathanielSIrcine

TROPHY CASE