Config Mode
Configuration Mode Editing
Configuration mode (often called "config mode") can be used if the current session is connected to a server. If not, requests to enter configuration mode will be rejected with an error message.
This additional editing mode is similar to a router command line interface. It can be used to edit YANG datastore nodes with a simplified interface:
A small number of Configuration Mode Commands are available
All YANG configuration data node names are command keywords
Data node names can be abbreviated just like RPC operation parameter names
Tab completion for data node names is context-sensitive and based on the YANG modules available within the session
The current context node can be changed to different YANG data nodes within the configuration, which are called Sub-Modes
The command sequence follows the YANG data node hierarchy
XPath Example: /interfaces/interface[name='eth0'] CLI Example: interfaces interface eth0 CLI Example With Allowed Keyword Matching: int int eth0
List entries are always followed by all the key leaf values (e.g., interface eth0).
The names of the key leafs are omitted (e.g. 'name' is not specified after 'interface')
Quotes are needed for key values if they have any whitespace or special characters
Configuration Value Errors
yp-shell and yangcli-pro validate configuration values locally before sending an edit to the server. A value rejected during command parsing produces a config mode error; no edit request is sent for that command.
For numeric range errors, the diagnostic includes the YANG range
statement, if one is defined, and its error-message, if present.
The min and max range keywords are displayed as their resolved
numeric values, including limits inherited from typedefs. For example,
range "min .. max" on a uint8 leaf is displayed as 0 .. 255.
This also provides range guidance when the input exceeds the numeric
base type's limits. For pattern failures, the diagnostic includes the
first failing pattern and its error-message, if present. Inherited
patterns are checked, and inverted patterns are marked invert-match.
These details are also reported for list key and leaf-list values.
For example, a leaf with range "1..3600" can produce:
Error: Invalid value for 'interval' leaf
range: 1..3600
error-message: Interval must be between 1 and 3600.
Warning: Config Mode Error: value not in range
The additional text describes the local schema constraint. Server
rpc-error replies continue to be displayed when a request reaches
the server and is rejected there.
Configuration Mode Variations
There are some CLI parameters that affect how config mode works. Each parameter may also have a corresponding system variable that can be set at run-time instead of program invocation time.
--autocomp: If set to 'false' then only exact node names are allowed. The default is 'true' which allows partial matching of keywords.
--autoconfig: If set to 'false' then tab completion may not be available. A copy of the 'running' datastore is maintained if 'true'. This is needed to populate existing nodes and values.
--autoconfig-conf-mode: If 'autoconfig is set to 'false' then and this parameter is also set to 'false' then some tab completion will not be available.
--with-enable-mode: Only available in 'yp-shell'. If 'true' then enable mode must be entered first before config mode can be entered.
--restrict-edit-mode: Only available in 'yp-shell'. If 'true' then config mode is the only editing mode available to users.
--config-autosave: Controls how edits are saved to NV-storage on the server.
--config-commit-mode: If 'true' then edits will be applied to the 'candidate' datastore. This allows edits to be sent in any order to the server, and then applied all at once, using the commit command.
--config-edit-mode: This most important parameter controls how edits are applied to the server. The apply and exit commands work differently, depending on this parameter.
There are 3 modes:
line: The edit(s) are automatically applied after each line is entered.
level: The edits(s) are automatically applied with the exit command, or manually applied with the apply command. This is the default mode.
manual: The edit(s) are only applied manually with the apply command.
Refer to the config-edit-mode Examples section for more details.
Configuration Mode Commands
The following table shows the special configuration mode commands and keywords. They are only allowed in configuration mode. The behavior may depend on the config mode variation that is in use.
Command |
Description |
|---|---|
Apply any pending edits to the |
|
Use commit operation to apply any pending edits |
|
Invoke a normal command in configuration mode |
|
Return to the parent mode and apply any pending edits |
|
Exit all sub-modes until the top level config mode is reached |
|
Keyword to start a command to delete a data node |
|
Return to normal mode from configuration mode without applying any edits |
Changing Config Modes and Sub-Modes
Enter Configuration Mode
To enter configuration mode, use the config command:
mysession> config term
mysession#
Once configuration mode is active, the prompt will change (notice (c) above), the available top-level configuration data nodes advertised by the server are available as 'commands'. Only a few special commands are available in configuration mode:
Enter Configuration Sub-Mode
The configuration context node can be changed to simplify editing. Conceptually, the context node represents a YANG container or list node within the server database.
mysession# interfaces
mysession(interfaces)# int eth0
mysession(interface)#
Exit Configuration Sub-Mode
The exit command is used to exit the current configuration level and return to the parent level.
If the config-edit-mode parameter is set to 'level' then any pending edits at the current level will be applied to the server.
mysession(interface)# exit
mysession(interfaces)#
Go to the Top in Configuration Mode
The gotop command is used to exit the current configuration level and return to the top-level.
This is similar to the exit command, except the prompt returns to the top-level instead of the parent level.
Using this command at the top-level instead of a sub-mode has no affect.
This is much different than the return command which discards all pending edits and exits configuration mode
If the config-edit-mode parameter is set to 'level' then any pending edits at the current level will be applied to the server.
This command is available starting in the 22.10T-4 release
mysession(interface)# gotop
mysession#
Return from Configuration Editing Mode
The return command is used to exit all configuration levels and leave configuration mode.
Any pending edits will be abandoned and not applied to the current session.
mysession(interface)# return
mysession>
Editing Server Database Parameters
Specifying the name of an existing container or list node will cause new edits to be merged into the existing entry
Specifying the name of a node that does not currently exist will cause it to be created
The --config-edit-mode parameter (or its global variable setting) will affect when edits are applied to the server.
If the mode is 'level' (default):
If the context is currently the top level, then the edit is applied at once.
If the context is currently a sub-mode, then the edit is held until the 'apply' or 'exit' command is given.
If the mode is 'manual':
All edits are held until the 'apply' command is given.
If the mode is 'line':
The edit is applied at once.
Using The Tab Key in Config Mode
The context-sensitive command completion with the tab key can be used to display the available child nodes to enter. Once a node name is entered, the tab key can be used to show possible values for the current leaf or leaf-list.
For static data types like boolean, enumeration, bits, and identityref, the list of allowed values is derived from the YANG module(s).
For leafref data types the list of allowed values is derived from the YANG module(s) and server data (if possible).
Tab completion is now available for leaf-list nodes while the 'no' command is active.
Leafrefs
Note
For tab key value completion support for nodes using the 'leafref' data type, either the --autoconfig or --autoconfig-conf-mode CLI parameter or global variable must be set to 'true'.
Before release 25.10-13, the leafref command line completion is done using the latest copy of the server 'running' datastore. The context node is not known and set to the document root. Only simple leafref completions were supported.
Starting in release 25.10-13, the leafref command line completion is done using:
the latest copy of the server 'running' datastore.
the edit state represented in any unapplied edit(s) within the current top-level node being edited. If the --config-edit-mode is 'manual' then it is possible that some edits are not visible
the edit state represented in the command line that is present when the tab key is pressed.
prior versions set the context node to the document root.
the context node is now set to the node that contains the leafref data type.
relative XPath expressions and the function call 'current()' need the correct context node, or the XPath result will be incorrect.
Enumerations and Identities
For leaf nodes, all available enumeration or identity values are displayed.
For leaf-list nodes, multiple values are allowed. If a value is already used in the command line, then it is not displayed again:
# color <tab>
black blue brown green orange red
#color blue green <tab>
black brown orange red
# color blue green
Creating or Modifying Server Database Parameters
mysession(interface)# mtu 9000
mysession(interface)# exit
Applying 1 edit to session [mysession]
mysession(interfaces)# exit
mysession# exit
mysession>
Since the configuration editing mode is set to 'level' (the default). the 'mtu' edit is not applied until the exit or gotop or apply command is given. All pending edits are applied to the current session with these commands.
Commands can be entered in a flexible manner. The same command as above could be entered in 1 command line:
mysession# int int eth0 mtu 9000
Applying 1 edit to session [mysession]
mysession#
Deleting Server Database Parameters
To delete a database node, or return it to its default value, the 'no' prefix is used.
If the line begins with the 'no' keyword, then the target data node being deleted is expected:
If the target node is a leaf, then no data value is expected. The last node specified is the leaf name to be deleted
# no interfaces interface test1 description
If the target node is a container, then no data value is expected. The last node specified is the container name to be deleted
# no interfaces interface test1 ipv6
If the target node is a list, then all list keys are expected. The last node specified is the list name to be deleted, followed by one or more key value strings
# no interfaces interface test1
If the target node is a leaf-list, then one or more leaf-list values are expected. The last node specified is the leaf-list name to be deleted, followed by one or more leaf-list strings
# no color red green blue Applying 3 edits #
The --leaflist-multi-line parameter does not apply if the 'no' command is active.
Escaping Configuration Mode With 'do' Command
In order to enter normal yangcli-pro commands while in configuration mode, the 'do' keyword is used. Only a limited set of commands can be accessed from configuration mode in this manner.
mysession# do show session
[session info shown]
mysession#
Use leaflist-multi-line to Configure leaf-list
The --leaflist-multi-line parameter controls how the leaf-list can be edited in config-mode
If set to 'true', then multiple leaf-lists can be configured at the same line.
If set to 'false', then only one leaf-list can be configured and it must be configured at the end of the line.
The default value is 'false'.
Example YANG:
container top {
leaf foo { type string; }
leaf-list test { type string; }
leaf-list test2 { type string; }
}
leaflist-multi-line is FALSE
andy@myserver> show var leaflist-multi-line
leaflist-multi-line false
andy@myserver> config term
andy@myserver# no top
andy@myserver# top <TAB>
foo test test2
andy@myserver# top foo f1 test a1 a2 a3 test2 b1 b2 b3
Applying 1 edit
andy@myserver# do show run
nc:rpc-reply {
data {
ypshell-test4:top {
foo f1
test a1
test a2
test a3
test test2
test b1
test b2
test b3
}
}
}
leaflist-multi-line is TRUE
andy@myserver> $$leaflist-multi-line=true
System variable set
OK
andy@myserver> sho var leaflist-multi-line
leaflist-multi-line true
andy@myserver> conf t
andy@myserver# no top
andy@myserver# top foo f1 test a1 a2 a3 test2 b1 b2 b3
Applying 1 edit
andy@myserver# do sho run
nc:rpc-reply {
data {
ypshell-test4:top {
foo f1
test a1
test a2
test a3
test2 b1
test2 b2
test2 b3
}
}
}
Privilege Mode In Enable Mode
The yangcli-pro program supports a privileged mode in the yp-shell enable mode.
If CLI parameter --with-enable-mode=true is used, the user must enter the command 'enable' and provide the password if configured before they gain a privilege exec mode to change the configuration of the server. The command 'config term' will only be present in enable mode. Within enable mode, the 'config term' command is used to enter configuration mode.
Use the enable command to enter ‘enable mode’.
Use 'enable password' to create a password.
Use 'enable no-password' to delete the password.
The 'enable password' command is used to configure a password and
store it in the $HOME/.yumapro/.yangcli_password.pswd file. After
a password is configured, the privilege mode will be enabled and the
password file will be saved. Any time the user enters the enable mode,
the user is prompted for the password instead of just going to the
enable mode right away.
The 'enable no-password' command will delete the configured
password and the $HOME/.yumapro/.yangcli_password.pswd file. The
privilege mode will be disabled.
If the server does a factory restart then the
.yangcli_password.pswd file will be deleted by the server and
password will be removed. The privilege mode will be disabled.
The 'enable' command is only available in the yp-shell program. The yangcli-pro program does not have this command.
If --with-enable-mode=false, or not used, the 'config term' command will be present and the 'enable', 'enable password', and 'enable no-password' commands will not be present.
./yp-shell with-enable-mode=true --restrict-edit-mode=true
enable (config mode)
Use the enable command to enter enable mode. This command will cause the '#' prompt to be used. Only config mode commands such as "apply" and "exit" are allowed in this mode.
user1> show vars | include with-enable-mode
with-enable-mode true
user1> show vars | include restrict-edit-mode
restrict-edit-mode true
user1>
user1> enable <TAB>
no-password password
user1> help enable full
enable
Use 'enable' to enter enable mode for yp-shell.
Use 'enable password' to configure the password.
Use 'enable no-password' to remove the password.
If a password has been set, then it will be required to
enter enable mode.
input
choice pass
leaf password [string]
Configure the password.
leaf no-password [empty]
Remove the password.
user1> enable
user1#<TAB>
config exit
user1#
thue@andy-u14# config t
user1(config)#
user1(config)# int8.1 8
user1(config)# do show running
nc:rpc-reply {
data {
t:int8.1 8
}
}
user1(config)# exit
user1#
user1# exit
user1>
enable password
Use the 'enable password' command to configure a password. After the password is configured, future attempts to enter enable mode by the user will be prompted for the password instead of just going to enable mode right away.
user1> enable password=xxxxxxxxx
Re-enter password:
Enable password entered
user1> enable
Enter password:xxxxxxxxx
user1# config t
user1(config)# exit
user1# exit
user1> enable
Enter password:xxxxxxxxx
user1#
enable no-password
Use the 'enable no-password' to delete the configured password. After this command, the user will enter enable mode without getting prompted for password.
user1>enable no-password
Enable password entered:
xxxxxxxxx
Enable password removed
user1> enable
user1# <TAB>
user1# config exit
Privilege Mode In Config Mode
The yangcli-pro program supports a privileged mode in the yp-shell config mode.
The enable-password command is used to configure a password
and store it in the $HOME/.yumapro/.yangcli_password.pswd file.
After a password is configured, the privilege mode will be enabled and
the password file will be saved. Any time the user enters the config
mode, the user is prompted for the password instead of just going to the
config mode right away.
The “no” form of this command will remove the configured password and
the $HOME/.yumapro/.yangcli_password.pswd file. The privilege mode
will be disabled.
Enable Privilege Mode
Use the enable-password command in config mode to enable the privilege mode . There is no echo for the password (Example: fredlow2018) typed. After enable-password is set, the user will be prompted for the password instead of just going to config mode right away.
user1> config t
user1#
user1# enable-password
Enter string value for leaf <password>
user1:enable-password#
Re-enter password:
Enable password entered
user1#
Re-enter config mode after 'enable-password' is set. The user will be prompted for the password instead of just going in to config mode right away. There is no echo for the password typed.
user1#
user1# exit
user1> config t
Enter password:
user1#
Restart yp-shell after enable-password is set.
user1# exit
user1> q
user1:~/swdev/ypwork/netconf/target/bin$ ./yp-shell
user1> config t
Enter password:
user1#
Disable Privilege Mode
Use 'no enable-password' in config mode to disable the privilege mode. After this command, the user enters config mode without getting prompted for password.
user1# no enable-password
Enable password removed
user1# exit
user1> config t
user1#
user1# exit
user1> q
user1:~/swdev/ypwork/netconf/target/bin$ ./yp-shell
user1> config t
user1#