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.
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).
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.
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.