Config Push - new Advanced Settings in Unimus 2.1.0
A new "Advanced Settings" menu is being added to Mass Config Push in the Unimus 2.1.0 release. In this article we look at when these new settings can be useful and how they change the default Config Push behavior.
Based on user requests, we are adding a few new Advanced Settings
to Config Push in Unimus 2.1.0. For the vast majority of use cases the default Config Push behavior doesn't need adjustments and works as expected. However, in a few specific cases there was a need to fine tune how Config Push behaves, and the new Advanced Settings
allow those adjustments.
Prompt recognition mode
Normally, Unimus learns the full prompt of the device, and waits for it before sending the next command from the Push preset (unless the $[no-wait]
modifier is used). Check out the Mass Config Push documentation on the Wiki for more details.
Here is an example of device communication during a Push. In the Config Push preset, we would check Require enable (privileged-exec) mode
and Require configure (configuration) mode
, and provide these commands:
interface ethernet 1/1
description "Server Link"
exit
Here is how the device communication would looks like:
switch-rack1> <enter> # "device-rack1" is learned as the hostname
switch-rack1> enable<enter> # bring devices into desired CLI mode (enable first)
switch-rack1# <enter>
switch-rack1# configure terminal<enter> # now bring devices to configure mode
switch-rack1(config)#interface ethernet 1/1<enter> # device is in desired CLI mode, send commands
switch-rack1(config-if)#description "Server Link"<enter>
switch-rack1(config-if)#exit
switch-rack1(config)#
The prompt learning behavior in Unimus exists to make sure Unimus knows when to interact with the device (send commands to it) and when to wait and collect output from the devices while it's outputting the output of those commands. There is however one case where this is not desired, when you actually want to change the hostname (and therefore change the prompt) on the device. Here is an example:
Commands in Config Push preset:
hostname switch-backup-r1
write memory
Here is how the device communication would looks like (skipping the CLI mode changes):
...
switch-rack1(config)#hostname switch-backup-r1<enter>
switch-backup-r1(config)# # Unimus fails here, unable to recognize new prompt
The issue here is that even tho the change was deployed, Unimus failed to recognize the new prompt, and the write memory
command was not sent. This is where the new Prompt recognition mode
setting comes into effect. You can now set the prompt to Simple
recognition mode, which will make Unimus use a much simpler prompt recognition method (just looking at the ending character), and the above preset would work as expected.
Please note the Learning
prompt mode should be used whenever possible, as it makes Config Push much more reliable. You should only use the Simple
recognition mode when you know the hostname / prompt of the device will change as a part of the Push.
Overriding timeouts
As described in our Wiki article on timeout configuration, Unimus uses multiple different timeouts when communicating with your devices. For some very long operations however, you might want to increase this timeout - since if the device takes too long to finish outputting some output, or if some operation on the device (such as saving it's config) takes longer than the timeout, the job would be considered as failed. Here is an example:
copy tftp://server.local/file nvram:file
y$[no-enter]
In this example, we are copying a file from a remote server to all devices this Push will be executed on. Here is how the device communication would look like:
(lab-swch1) #copy tftp://server.local/file nvram:file<enter>
Mode........................................... TFTP
Set Server IP.................................. server.local
Path........................................... ./
Filename....................................... file
Data Type...................................... file
Management access will be blocked for the duration of the transfer
Are you sure you want to start? (y/n) <y>
#
# this operation take a very long time - over 1 minute
#
File transfer operation completed successfully.
(lab-swch1) #
Since the file transfer in this case takes over 1 minute, the job would fail due to the timeout running out. In this case, checking Override timeouts
and setting the timeouts to 100000 (100 seconds) would fix the failure. Please note that the override will set ALL the timeouts to the specified value (more in the Wiki article).
Overriding credentials
The final new option in the Advanced Settings
is the ability to override the credentials Unimus will use when communicating with the device. This is useful in cases when you have read-only credentials in the Credentials
screen for security purposes. You do however want to be able to use Config Push, but without having full credentials available system-wide. In this case, you can check the Override credentials
box, and provide whichever of the available credentials you want to override. You can keep the credentials you don't want to override empty.
Final words
We hope these settings provide another bit of missing flexibility to Config Push and fix a few edge-cases which were Config Push could fail before, These new Advanced Settings
are available in Config Push starting with Unimus 2.1.0. Please head over to the Download section to download the latest Unimus release.