Page tree
Skip to end of metadata
Go to start of metadata

Basics

Mass Config Push in Unimus is used to send a set of commands to a group (or all) of devices in your network. This allows you to roll out mass config changes across your network, or query command outputs from a large set of devices. Before you can push to devices, each device must be in a "discovered" state (normally done during device addition into Unimus). Config push will not be performed on undiscovered devices, and they will be grouped in the "Un-discovered devices" group.

To perform a push, you first need to create a "Push Preset" from the Mass Config Push home page. After a preset is created, you can click  "Run now" to push the provided commands to the selected devices.

Output Grouping

The commands you specify in the Push Preset are sent to the devices, one line at a time (more info on how Unimus interacts with the device in How commands are sent to devices). The outputs of the executed commands are evaluated on all devices, and a new "Output Group" is created for each unique output during the push. If 2 devices reply with the same output, both devices are assigned to a single output group belonging to that unique output.

As an example, if you push a command to 200 devices, but across all devices there will only be 2 unique outputs to this command, Unimus will create only 2 output groups, and assign each device to the right output group. Output grouping means you don't need to inspect outputs of 200 devices after a config push - saving you time, and making navigation in large push outputs easy.

State of device before Push - require "enable" or "configure" CLI mode

You have the option of letting Unimus ensure that each device in the Push Preset is in a desired CLI mode before your specified commands are pushed. You can check "Require enable mode" and/or "Require configure mode" in the Push Preset, and Unimus will make sure the device is in the specified mode before executing your commands. Modes available on devices are discovered during Discovery, using mode credentials configured in the "Credentials" screen. You can check which modes Unimus was able to discover on devices using the "Devices > Info" window.

If a device can not be switched into the specified CLI mode before the push, Config Push will NOT push the provided commands to the device, and any devices failing the mode switch will be grouped in appropriate "mode not supported" output groups.

The "enable" and "configure" mode names are only symbolic - each device type has it's own modes. In general, the "enable" mode means the 2nd highest possible CLI mode on the device, and the "configure" mode the 3rd highest possible CLI mode on the device (if the device type supports this). Taking Cisco as an example, the "user exec" mode would be 1st possible login mode, "privilege exec" would be the 2nd (enable) mode, and "configure mode" would be the 3rd (configure).

Please see our Device mode table article for more info on how the modes in the push preset map to various vendors / device types.

Command parsing

In a Push Preset, you provide a command set to Unimus, which will be parsed for submission modifiers and control sequences, and then sent to the device(s).

If you do not provide any submission modifiers or control sequences, Unimus will split the provided command set line-by-line, and then send it to selected device(s) one-by-one.
Basically, you give Unimus a bunch of commands, and it will distribute them to your network.

For example, specifying push commands like this will work as expected, and Unimus will handle pagination ("-- more --") natively:

show version
show ip interface brief
show vlan brief

For details on exactly how commands are sent to devices, please see How commands are sent to devices.

Command sending modifiers and control sequences

Since version 2.0.3, Unimus supports command submission modifiers and sending control sequences.

There are 2 command submission modifiers possible:

$[enter]
$[no-enter]

These modifiers have to be put at the end of the line, and control if <Enter> will be sent after the command line.
The default behavior is to send <Enter> after each command line, UNLESS "$[no-enter]" is specified, or the command is a control sequence.
(please check the Command parsing examples section for more details)

 

Normally, Unimus waits for some know output (for example a prompt) after each sent command line (see How commands are sent to devices for more info).
There are 2 modifiers that can influence this behavior, with "$[wait]" being the default behavior.

$[wait]
$[no-wait]

Specifying "$[no-wait]" will cause Unimus to instantly continue sending the next command line without waiting for any device outputs.
This can be useful when for example the device doesn't respond with any data after sending some command/line, and you want Unimus to continue sending data to the device.
(please check the Command parsing examples section for more details)

 

Unimus supports sending various control sequences to the device, in this format:

$[0x01]

As mentioned above, <Enter> is not by default sent after a control sequence, but this can be forced by appending "$[enter]" to the end of the line.
Full list of command sequences available in this article: VT100 Control / Command sequences.

Both submission modifiers and command sequences support escaping by prefixing them with an additional "\":

\$[0x01]  = "$[0x01]" will be sent literally to the device(s), instead of a control sequence
\$[enter] = "$[enter]" will be sent literally to the device(s), instead of modifying command submission behavior

Please check the Command parsing examples section for more details on how modifiers and control sequences work.

How commands are sent to devices

Config Push in Unimus has a few stages:

  • connect to device, login to the CLI
  • switch the device to desired CLI mode (if require "enable" or "configure" mode is set)
  • send each command line from the "Commands" to the device (more info below)
  • collect all output from device
  • disconnect the CLI session
  • create a new output group for this device OR assign the device into an existing output group

The main (and most important) portion of Config Push is sending the actual commands provided in the "Commands" set to the devices.

Unimus here works as following:

  1. from the command set, send the next command line to the device, followed by Enter
  2. collect all output, up until a known (recognizable) output occurs (unless "$[no-wait]" specified)
  3. IF "$[no-wait]" specified, GO TO step 1
  4. IF device asks if it should continue with output (more info below), Unimus answers "Y", GO TO step 2
  5. IF device outputs a question (such as a "[y/n]" question - more info below), stop, GO TO step 1.
  6. IF device asks for a password, or another "secret", stop, GO TO step 1
  7. IF device pages through output ("-- more --"), Unimus sends pagination key (space for most device types) to proceed to next page, GO TO step 2
  8. IF device asks to confirm end of output, ("press Q to finish"), Unimus sends the appropriate key to finish output, GO TO step 2
  9. IF a prompt is received, stop, GO TO step 1

As per the description above, pagination ("-- more --"), and output termination which some devices require ("Output finished, press Q to continue") will be handled completely automatically by Unimus.

For step 3, Unimus will automatically answer "Y" to questions like "Show all items?" or "Do you want to show sensitive items?" or "Confirm command...", etc.
For step 4, Unimus recognizes any generic questions asked by devices that end in the "[y/n]" or "(yes/no)" prompts, but also things like "Press enter to confirm change", etc.
For step 5, usual "Password:" or "Password for..." and similar password prompt are recognized

To make this simple - you can provide the same sequence of commands and key-strokes to Unimus as you would when interacting with the device CLI, and Unimus will properly interact with the device as expected.

Command parsing examples

Push commands:

write memory
y

Device output (keys sent by Unimus in green):

device# write memory<enter>
This may take some time, continue? [y/n] y<enter>
..........
device#

 

For the "y" confirmation, it will be sent as "y" and then Enter. Here is an example of how to send a control sequence, and send the "y" without enter:

commit
$[0x1A]
y$[no-enter]

Device output (keys sent by Unimus in green):

device# commit<enter>
Press CTRL + Z to continue, or Q to quit... <CTRL+Z>
Are you sure you want to contiue? [y/n] y
..... done
device#

 

Sometimes, you want Unimus to send commands to the device even if the device doesn't output any known outputs after sending a command line.
For example, many devices don't respond with anything if you need to provide a text block. You can avoid "INTERACTION_ERROR" in this case like this:

banner motd ^
This is the start of the banner$[no-wait]
And this is a 2nd line of the banner$[no-wait]
This is the end of the banner^

It is important to NOT specify "$[no-wait]" after the last line, since the device will respond with a prompt after the last line, and you want Unimus to wait for the prompt and collect the output.

The interaction with the device will look like this:

device (config)# banner motd ^<enter>
Enter TEXT message.  End with the character '^'.
This is the start of the banner<enter>
And this is a 2nd line of the banner<enter>
This is the end of the banner^<enter>

device (config)#

Debugging failed pushes - "INTERACTION_ERROR" group

If there is an "INTERACTION_ERROR" output group in your Push results, this means Unimus was not able to identify any known / expected output from some devices (see How commands are sent to devices). If this happens, Unimus will stop pushing to the device(s) for safety reasons, and place these devices in the "INTERACTION_ERROR" group.

The easiest way to find out why a push is failing is to enable Device Output Logging in "Zones > Your_zone > Debug Mode > Device output logging". After this is enabled, re-run your push and wait for it to fail.
After the push fails, download the Device Output Log file, and check what exactly in the device communication caused Unimus to fail.

You can also create a Support Ticket on our Portal and attach the log file - and we will be happy to investigate why the push failed.

  • No labels