Building network automation solutions

9 module online course

Start now!

Security or Convenience, That’s the Question

One of my readers was so delighted that something finally happened after I wrote about a NX-OS bug that he sent me a pointer to another one that has been pending for a long while, and is now officially terminated as FAD (Functions-as-Designed… even documented in the Further Problem Description).

Here’s what he wrote (slightly reworded)…

The exec-timeout configuration is part of the fundamental NX-OS hardening guide that Cisco recommends. However, whenever a show command is executed, the timeout is disabled.

The end result: any unfinished show command such as show run that requires hitting enter to finish (for example, at the more prompt), will cause the console or VTY to stay logged in indefinitely. As NX-OS doesn’t have absolute-timeout there’s no workaround.

So if by accident, an engineer disconnects from a console in the middle of a show command, that console will stay logged in forever.

BU was telling me they changed this behavior from IOS because it could "cause incomplete/corrupted output while doing script automated data collection".

Let me just mention that exec-timeout takes number of minutes as its argument, and the recommend value in Cisco’s documentation is “ten or fifteen minutes”. I sincerely hope NX-OS doesn’t take that long to execute a single show command, so it’s a bit hard to believe the explanation my reader got.

Anyhow, someone within Cisco decided to prefer convenience over security, and provided a workaround when closing the bug report: “quit to prompt”. Awesome ;)

We migrated our blog a few days ago, and the commenting functionality is not there yet. In the meantime enjoy the older comments, or find our content on LinkedIn and comment there.

1 comments:

  1. I have the same problem in IOS.

Sidebar