Using the AutoCLI

The AutoCLI is a special CLI mode which TNSR builds automatically based on its data model files.

The TNSR CLI uses hand-crafted command line specifications and often attempts to maintain familiar syntax, structure, and behavior. As such, it tends to err on the side of being user-friendly.

The AutoCLI can be more powerful in that it directly exposes the entire data model through a command line interface, similar to working directly with the API. This can enable more complex configuration operations but it is also more complicated to use than the traditional CLI.

The AutoCLI enables users to make changes across multiple modes without requiring users to enter and exit each mode in a strict order. It also supports making batch changes where all changes are committed at the end, instead of immediately or when exiting certain modes.

Note

The behavior of AutoCLI may also provide a familiar experience to users of JunOS.

See also

Entering the AutoCLI

To enter AutoCLI configuration mode, use the autocli-configure command:

tnsr# autocli-configure
tnsr(autocli) />

To leave the AutoCLI, use exit to return to the TNSR CLI:

tnsr(autocli) /> exit
tnsr#

The quit command will terminate both the AutoCLI and the TNSR CLI. Depending on how the user invoked the TNSR CLI, this may have the same effect as logging out.

tnsr(autocli) /> quit
user@example:~$

Autocomplete and Help

Users can press the <tab> key and the AutoCLI will attempt to automatically complete the current item. In cases where there is ambiguity between multiple items, the AutoCLI will print all valid choices.

tnsr(autocli) /> edit interfaces-config <tab>
 bond-table                bridge-table              interface                 loopback-table
 memif-table               socket-table              subinterfaces             tap-table
 vhost-user-interfaces     wireguard-interfaces

At any point in the AutoCLI, even in the middle of a command, users can press the ? key and the AutoCLI will print context-sensitive help with a list of available items to type next. This may be commands, option names, modes, parameters, available items/instances, and more. It prints this list one item per row, with a description where available. The output may also include validity constraints, such as valid ranges for integer-based options.

tnsr(autocli) /> edit interfaces-config ?
  <cr>
  bond-table             Bond interface configuration table.
  bridge-table           Bridge mapping table.
  interface              The list of configured interfaces on the device.
  loopback-table         Loopback name table.
  memif-table            Host memif interface configuration table.
  socket-table           Host memif socket table.
  subinterfaces          An interface may have subinterfaces.
  tap-table              Host Tap interface configuration table.
  vhost-user-interfaces  Data of the vhost-user interfaces.
  wireguard-interfaces   Wireguard interface.

Making Changes

The commands in this section make changes to the configuration. These commands can be executed from within a given mode to make changes in that mode or modes beneath the current location.

Create

To create a new configuration object or instance without a value or content, use create <path>:

tnsr(autocli) /> create <path>

Note

This command only works if the given path does not already exist.

Example:

tnsr(autocli) /> create gre-config gre-table tunnel exampletunnel

Merge

The merge command combines the given configuration values with the existing configuration data in the specified mode (similar to NETCONF merge) for YANG container or list items. For YANG leaf or leaf-list items this is identical to set.

tnsr(autocli) /> merge <path>

Example:

tnsr(autocli) /> merge interfaces-config interface DMZ enabled true

Set

The set command creates or replaces configuration items in the given area (similar to NETCONF replace) for YANG container or list items. For YANG leaf or leaf-list items this is identical to merge.

tnsr(autocli) /> set <path>

Example:

tnsr(autocli) /> set interfaces-config interface DMZ enabled true

It is safer to use merge rather than set during typical operations to avoid unintentionally removing configuration data.

Set Operation Container Example

If a user performs a set operation on a container directly, any leaf values would be removed. This does not happen when using merge.

First, set a leaf value inside a container and check that the value is present:

tnsr(autocli) /> set lldp-config system-name example
tnsr(autocli) /> validate
tnsr(autocli) /> commit
tnsr(autocli) /> show run lldp
lldp system-name example

Now perform a set operation on the container, commit, and check the value again:

tnsr(autocli) /> set lldp-config
tnsr(autocli) /> validate
tnsr(autocli) /> commit
tnsr(autocli) /> show run lldp

The existing configuration was removed since the set operation replaced the entire container!

Now perform the first step again, then for the second step use merge instead. This way it does not affect existing leaf values inside the container:

tnsr(autocli) /> merge lldp-config
tnsr(autocli) /> validate
tnsr(autocli) /> commit
tnsr(autocli) /> show run lldp
lldp system-name example

The previous leaf value is still in the configuration.

Delete

To delete a configuration object or instance, use the delete <path> command:

tnsr(autocli) /> delete <path>

Note

This command has no effect if the specified item does not exist.

For example, to delete all configuration for the DMZ interface:

tnsr(autocli) /> delete interfaces-config interface DMZ

Activating Changes

After making changes, AutoCLI requires an extra step to activate the changes. This does not happen automatically as several commands may be needed to make a complete change.

Discard

To discard all current edits and return to the previously committed configuration, use discard:

tnsr(autocli) /> discard

Validate

Before committing the changes, run the validate command so TNSR can ensure the configuration is valid. If the configuration would cause a known error or problem, the output will contain an error message.

tnsr(autocli) /> validate

Commit

To commit and activate all pending configuration changes, use commit:

tnsr(autocli) /> commit

Save Configuration

To save the current configuration so it is used the next time TNSR starts:

tnsr(autocli) /> copy running startup

See also

Saving the Configuration.

Session Protection

If multiple users are in the AutoCLI at the same time, users should activate a lock before making changes and then unlock after committing the changes. This will ensure that other users are unable to make potentially conflicting changes during a configuration session.

Lock

To set a configuration lock which prevents changes by other users or sessions until unlocked:

tnsr(autocli) /> lock

Note

A lock must be set before beginning configuration changes; a lock cannot be set if there are uncommitted configuration changes pending.

Unlock

To remove a current configuration lock to allow other users or sessions to make configuration changes:

tnsr(autocli) /> unlock

Note

This command will produce an error if no lock has been set.

Troubleshooting

Backend Ping

To check if the configuration backend is responding:

tnsr(autocli) /> backend ping

If the backend is responding properly, this command will print its response:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <ok/>
</rpc-reply>

Debug

To enable debugging at a given level (0..n):

tnsr(autocli) /> debug (backend|cli|restconf) <level>