Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To perform a push, you first need to create a "Push Preset" from the Mass Config Push home page. For the "Commands", you can provide the same sequence of commands and key-strokes to Unimus as you would when interacting with the device CLI manually.

After a preset is created, you can click  "Run now" to push the provided commands to the selected devices.

...

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

...

Code Block
languagetext
show version
show ip interface brief
show vlan brief

On 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:

Code Block
$[enter]
$[no-enter]

These modifiers have to be put at the end of the line, and control if Enter <Enter> will be sent after the command line.
The default behavior is to send enter<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.

Code Block
languagetext
$[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:

Code Block
$[0x01]

As mentioned above, Enter <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.

...

Code Block
languagetext
\$[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

...

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), answer "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 --"), send 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"), send 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 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. To understand more in depth how Unimus interacts with a device, here is a (still very simplified) chart:

Image Added

Note 1:
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,

Note 2:
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 config confirm change", etc.
For step 5, usual Password prompts like "Password: " or "Password for..." and similar password prompt are also properly 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 expectedand will advance to sending the next line from the "Commands"

Note 3:
If the device pages through output ("-- more --"), Unimus sends pagination key (space for most device types) to proceed to next page automatically.
IF device asks to confirm end of output ("press Q to finish"), Unimus sends the appropriate key to finish output automatically.

Command parsing examples

Push commands:

...

Panel

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:

Code Block
languagetext
banner motd ^$[no-wait]
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:

Panel

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

...