Thread by @_ChrisJHart

On Cisco Nexus switches in production environments, avoid working within a configuration context on the CLI unless you're actively configuring the switch. Otherwise, you might accidentally cause an outage by trying to run a show command.

Curious how that's possible? 🧵

Cisco IOS and IOS-XE require you to prepend show commands with the "do" keyword to execute them within a configuration context.

NX-OS does not require you to do this - you can run a show command within any configuration context without the "do" keyword.

However, old habits die hard. Engineers who have to manage IOS devices and NX-OS devices often use "do" out of habit, so NX-OS allows you to use the "do" keyword just like IOS.

On IOS, prepending the "do" keyword to a command executes the command within the privileged EXEC mode. We can tell this because the output of the "sh" command is identical when executed directly in privileged EXEC mode and when executed under a configuration context.

However, NX-OS operates a bit differently. Because the "do" keyword isn't necessary on NX-OS, NX-OS simply strips the "do" word from the command and executes the command in the current context.

For some commands, such as "sh" while under the configuration context of an interface, routing protocol, or VRF, this can have disastrous consequences. Instead of trying to run the "show" command, NX-OS will issue the "shutdown" command instead.

This is a difference in behavior between IOS and NX-OS. We can see that performing the same sequence of commands on IOS doesn't shut down the interface.

To be clear, this doesn't apply when the show command is valid, such as "show module" or "show version". This only applies if you happen to run "do sh" with nothing following it while under a configuration context where the "shutdown" command is valid.

This might seem silly - why would anybody try to execute "do sh", which isn't a valid command? - but I have seen it cause a handful of outages. It's rare, but it's possible!

I'm working on changing this NX-OS behavior through enhancement CSCvy92792 - however, because it's a relatively rare scenario, it's entirely possible this behavior never changes.

The moral of the story is, treat the configuration context of a production device's CLI as carefully as you would treat a weapon. Don't hang around in it, and don't troubleshoot problems while sitting in it. Get in, make your changes, and get out!