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)

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

\$[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:

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
  3. IF device asks if it should continue with output (more info below), Unimus answers "Y", GO TO step 2
  4. IF device outputs a question (such as a "[y/n]" question - more info below), stop, GO TO step 1.
  5. IF device asks for a password, or another "secret", stop, GO TO step 1
  6. IF device pages through output ("-- more --"), Unimus sends pagination key (space for most device types) to proceed to next page, GO TO step 2
  7. IF device asks to confirm end of output, ("press Q to finish"), Unimus sends the appropriate key to finish output, GO TO step 2
  8. 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#

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.