Tip
This is the documentation for the 25.06 version. Looking for the documentation of the latest version? Have a look here.
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.
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
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>