YumaPro yangcli-pro Manual¶
YANG-Based Unified Modular Automation Tools
NETCONF Over SSH Client
NETCONF Over TLS Client
RESTCONF Over HTTP(S) Client
NETCONF Over SSH Call Home Server
NETCONF Over TLS Call Home Server
Program Components
yangcli-pro Introduction¶
The yangcli-pro program is a NETCONF over SSH client application. It is driven directly by YANG modules, and provides a simple but powerful application interface that can utilize any YANG file to drive the user interface. Full server management features and server testing features are supported. There is no configuration required at all to use any YANG file, since the yangdump-pro YANG compiler is built into the application.
yangcli-pro Features¶
The yangcli-pro client has the following features:
Support for multiple sessions to multiple servers at once
Support for configured named sessions saved in a secure configuration file
Easy to use configuration mode for editing; provides an IOS CLI-like user interface to edit server configurations
Command line history, recall
Output filtering with 'pipe' commands
Terminal pagination with –More-- prompt controls
Supports NETCONF 1.0, NETCONF 1.1, and RESTCONF protocols
Automated session reconnect for NETCONF and RESTCONF sessions
Automated shadow configuration monitoring for each session; can be referenced in scripts and tab completion
Automated notification monitoring for each session; callback framework for event handling
Automated regression testing support to verify server operation, including
setup and cleanup sections per test-suite
multiple tests per suite
each test step can check for ok, rpc-error, data responses
Automatic recording of test suites
The record-test command used to automatically record commands in a re-usable test script.
The test-suite command is used to run previously recorded tests and verify the same results are obtained as when the test was recorded.
Automatic monitoring of server notifications
The <create-subscription> operation is automatically sent if --autonotif=true and the server supports notifications.
Configuration change events are monitored to know when configuration updates are needed for that session
Automatic shadowing of the running configuration
The <get-config> operation is automatically sent if --autoconfig=true. A shadow of the running configuration is maintained for the session, and updated automatically if notifications are active.
The config command uses the shadow configuration for tab completion and comparison purposes.
Automatic support for all NETCONF protocol operations, including several 'short-hand' commands for the most common operations:
<edit-config> high level functions:
<get> and <get-config> high-level functions:
NMDA <get-data> high-level functions:
Automated database locking, unlocking and error cleanup, using the high-level get-locks and release-locks commands.
Automatic, standards-based, server schema synchronization, using the YANG module capability URI information in the <hello> PDU, and the <get-schema> operation:
For each session, the exact view of the server schema definition tree is created, based on the module capability:
module namespace
module name
module revision date
enabled features
names of any modules that contain deviations for this module
The help text and parameter validation for each session will be tailored to the capabilities advertised by the server.
Parses each potential matching YANG file to make sure the module name, revision date, and namespace URI value are all exactly the same as the values in the module capability URI.
Understands all NETCONF protocol capabilities, and complex hard-wired logic simplifies protocol usage, and allows high-level commands to pick appropriate defaults for many RPC operation parameters.
Load any YANG module at boot-time or run-time and start using it immediately.
Full concurrent support for multiple revisions of the same module.
Supports NETCONF notifications, including :interleave capability.
Full XPath 1.0 and subtree filtering support.
Automatic support for all YANG language mechanisms, including extensions.
Any YANG <rpc> operation is automatically available as a yangcli-pro command.
Uses YANG files directly as input, so no pre-processing or configuration needed to use a new module.
Can be called from unix scripts in 'batch-mode' to automatically establish a NETCONF session, issue a command or invoke a yangcli-pro script, close the session, and return the results.
Extensive interactive shell environment, including user variables, file variables, smart parameter set completion, and a simple scripting environment for automatic operation.
Automatic, context-sensitive (tab key) command-line completion.
Full support for XPath, instance-identifier, leafref, and identityref parameters.
Automatic, context-sensitive help system, based completely on YANG files and using the exact modules supported by the current NETCONF session, if connected.
Full, customizable command line editing, using 'emacs' by default, but 'vi' or a custom set of keystroke bindings are also supported.
Command line history and command recall.
Store and recall command line history files for later use.
Automatic NETCONF session management, including support for all YANG extensions to the <capability> element.
Automatic recognition and support for all NETCONF 'capability' related operations.
Automatic support for all YANG additions to the NETCONF protocol, such as the insert operation
Unlimited nested scripts with up to 10 parameters each can automate testing and other management tasks
User configurable command aliases that can be saved and restored.
Differentiate between local and server commands when the <tab> and ?<cr> used. A star '*' will be printed after each server command.
Configurable NETCONF Call-Home over SSH support (RFC 8071)
Support the privileged mode in yp-shell for config mode.
Support of restricting all editing to the yp-shell config mode.
Configurable break-key behavior to cancel current command ot exit program
Ability to invoke yangcli or shell scripts to automate command processing
Supports the Event Condition Action (ECA) to allow the user to run shell scripts based on a notification.
Starting yangcli-pro¶
The current working directory in use when yangcli-pro is invoked is important. It is most convenient to run yangcli-pro from a work directory, rather than the installation directory or within the module library.
The yangcli-pro program can be invoked several ways:
To get the current version and exit:
yangcli-pro --version
To get program help and exit:
yangcli-pro --help yangcli-pro --help --brief yangcli-pro --help --full
To start an interactive session with the default parameters:
yangcli-pro
To start an interactive session with a new log file:
yangcli-pro --log=mylogfileTo start an interactive session and append to an existing log file:
yangcli-pro --log=mylogfile --log-appendTo get parameters from a configuration file:
yangcli-pro --config=~/yangcli-pro.confTo begin to connect to a server upon startup, provide the --server parameter. The connect command will be started upon startup and the user will be prompted to enter the rest of the mandatory parameters to the connect command.
yangcli-pro server=myserver.example.com
To connect to a server and automatically connect without any interactive interruption, enter the --server, --user, and --password parameters. A session startup will be attempted right away, using these parameters. Any optional parameters for the connect command (e.g., --port or --timeout) may be entered as well. All parameters can be entered from a config file, and/or the command line.
yangcli-pro --server=myserver.example.com --user=andy --password=yangrocks
To automatically connect to a server, run a script in non-interactive mode, and then remain connected to the server, add the --run-script parameter to the connection parameters. The --runpath parameter can also be entered, if needed.
yangcli-pro --run-script=mytestscript --server=myserver.example.com --user=andy --password=yangrocks
To automatically connect to a server, run a script in non-interactive mode, and then exit the program, add the --batch-mode and --run-script parameters to the connection parameters. The --runpath parameter can also be entered, if needed.
yangcli-pro --run-script=mytestscript --batch-mode --server=myserver.example.com --user=andy --password=yangrocks
To automatically connect to a server, and run a single command instead of a script, and then exit, use the --run-command parameter instead of the --run-script parameter. The --batch-mode parameter can be left out to remain in the current session (in interactive mode) after the command is invoked.
yangcli-pro --run-command=”sget /system” --batch-mode --server=myserver.example.com --user=andy --password=yangrocks
To automatically connect to a server, and just listen for notifications, and never exit, use the --autonotif=true** parameter instead of the --run-command or --run-script parameter. The --batch-mode parameter must be provided in this mode.
yangcli-pro --batch-mode --autonotif=true --server=myserver.example.com --user=andy --password=yangrocks
Stopping yangcli-pro¶
To terminate the yangcli-pro program, use the quit command.
The control-C character sequence will also cause the program to be terminated.
Statements¶
The yangcli-pro script interpreter accepts several types of statements:
yangcli-pro Statements
type |
description |
example |
command |
invoke a local command and/or send an <rpc> to the server |
sget /system |
variable assignment |
set a user variable to some value |
$system = sget /system |
file assignment |
set the contents of a file to some value |
@save.txt = $system |
variable deletion |
delete a user variable or clear a system variable |
$system = |
A command can be as simple like 'get' or complex, like 'edit-config'.
A variable assignment sets the specified user or system variable to the right hand side of the expression. An expression has many forms, including the result from a local command or a remote NETCONF operation.
If a string that matches a command is used as the assignment value, then it must be entered in quotes (single or double). For example, the $$default-operation system configuration variable accepts enumeration values which also match RPC commands:
> $$default-operation = 'merge'
A file assignment is essentially the same as a variable assignment, except the right hand side of the expression is saved in the specified file, instead of a user variable.
To delete a user variable, leave the right hand side of the expression empty (or just whitespace).
Commands¶
The yangcli-pro program has several built-in commands, defined in yangcli-pro.yang, yuma-netconf.yang, and notifications.yang.
The YANG 'rpc' statement is used to define the syntax and behavior of each command.
There are 3 types of yangcli-pro commands:
local: the command is executed within the yangcli-pro application, and can be invoked at any time.
remote: the command is executed on the remote server, and is only available when a NETCONF session is active. Any YANG rpc statement that yangcli-pro does not recognize as a local command is treated as a remote command available on the server.
config mode: the command is executed within the yangcli-pro application, in config mode. This is only available while a session is established.
Local Commands¶
Command |
Description |
|---|---|
Show or set a specific yangcli-pro command alias |
|
Manage the yangcli-pro command aliases |
|
Run automatic edit testing on the specified session |
|
Clear 1 or all entries from the YANG module cache |
|
Change the current working directory |
|
Clear the screen |
|
Enter the configuration mode for the current session |
|
Connect to a server and start a NETCONF session |
|
Access a named device configuration |
|
Access the named device configuration file |
|
Start an 'else-if' conditional block |
|
Start an 'else' conditional block |
|
Enable the privileged mode in yp-shell to enter the config mode. |
|
End an 'if' or 'while' block |
|
Evaluate an XPath expression |
|
Access an event handler mapping configuration. |
|
Controls access to the saved event-handlers file. |
|
View or clear the notification event log |
|
Exit configuration mode for the current session |
|
Fill a user variable |
|
Manage the session groups. |
|
Get context-sensitive help |
|
Manage the command history buffer |
|
Start an 'if' conditional block |
|
List modules, objects, or other properties of the session |
|
Log a debug message |
|
Log an error message |
|
Log an info message |
|
Log a warning message |
|
Load a YANG file into the client only |
|
Save the running datastore to the startup datastore |
|
Print the current working directory |
|
Exit the program |
|
Recall a line from the command history buffer |
|
Record commands and responses for a regression test |
|
Refresh the module version list used to determine the 'best-match' for imports. |
|
Run a script |
|
Run a shell script. The allow-shell parameter must be ‘true’ |
|
Access a named schema-server-cfg configuration |
|
Access the named schema-servers-cfg configuration file |
|
Set the current session |
|
Access a named session configuration |
|
Access the named session configuration file |
|
Show variables and objects currently available |
|
Sleep for a number of seconds (for use in scripts) |
|
Start <rpc> timing mode and save statistics to a file |
|
Stop a named session |
|
Stop a script timer and display the elapsed time |
|
Set the terminal length |
|
Access a configured unit-test suite for automated testing |
|
Access a named user configuration |
|
Access the named user configuration file |
|
Update the shadow configuration for the current session< |
|
Remove a command alias from memory |
|
Manage the yangcli-pro user variables |
|
Start a 'while' conditional loop block |
Standard NETCONF Commands¶
The following table shows the standard NETCONF protocol operations that are directly available for use, depending on the capabilities of the server.
Command |
Description |
|---|---|
Cancel the current confirmed commit procedure |
|
Stop receiving NETCONF notifications (RFC 5277 subscription) |
|
Close the current NETCONF session |
|
Make the candidate database be the running config |
|
Copy an entire NETCONF database |
|
Start receiving NETCONF notifications (RFC 5277 subscription) |
|
Delete an entire NETCONF database |
|
Terminate a NETCONF notification subscription for the current session |
|
Discard any edits in the candidate database |
|
Alteration of the target database |
|
Start receiving NETCONF notifications (RFC 8639 subscription) |
|
Filtered retrieval of state data and running config |
|
Filtered retrieval of any NETCONF database |
|
Filtered retrieval of a NETCONF NMDA database |
|
Get a data model definition file from the server |
|
Force close another NETCONF session |
|
Force close a notification subscription for another NETCONF session |
|
Lock a NETCONF database that is currently unlocked |
|
Modify the NETCONF notification subscription parameters |
|
Re-synchronize a YANG Push datastore subscription |
|
Unlock a NETCONF database that is currently locked |
|
Validate the contents of a NETCONF database |
Custom NETCONF Commands¶
The following yangcli-pro commands are available for simplified access to standard NETCONF operations
Command |
Description |
|---|---|
Invoke a YANG 1.1 <action> |
|
Invoke an <edit-config> create operation |
|
Invoke an <edit-config> delete operation |
|
Invoke an <edit-config> delete operation using the netconfd-pro "delete-all" nc:operation value. |
|
Lock all the databases with the <lock> operation |
|
Walk the entries of a YANG list. |
|
Invoke an <edit-config> YANG insert operation |
|
Invoke an <edit-config> merge operation |
|
Unlock all the locked databases with the <unlock> operation |
|
Invoke an <edit-config> remove operation |
|
Invoke an <edit-config> remove operation using the netconfd-pro "remove-all" nc:operation value. |
|
Invoke an <edit-config> replace operation |
|
Save the current edits on the server in NV-storage |
|
Invoke a <get> operation with a subtree filter |
|
Invoke a <get-config> operation with a subtree filter |
|
Invoke a <get-data> operation with a subtree filter |
|
Invoke a <get> operation with an XPath filter |
|
Invoke a <get-config> operation with an XPath filter |
|
Invoke a <get-data> operation with an XPath filter |
Extended netconfd-pro Commands¶
The following table shows the extended NETCONF protocol operations that are available on the netconfd-pro server only.
Command |
Description |
|---|---|
Retrieve session customization parameters |
|
Load a module into the server. |
|
No operation. |
|
Restart the server. |
|
Set the server logging verbosity level. |
|
Set session customization parameters. |
|
Shutdown the server. |
Configuration Mode Commands¶
The following table shows the special configuration mode commands and keywords. They are only allowed in configuration mode.
Command |
Description |
|---|---|
Apply any pending edits to the current session |
|
Use commit operation to apply any pending edits in the current session |
|
Return to the parent mode and apply and pending edits |
|
Run a command in configuration mode |
|
Prefix to configuration mode command used to delete a node |
|
Return to normal mode from Confing mode without applying ny edits |
Variables¶
The yangcli-pro program utilizes several types of user-accessible variables. These variables can be listed with the 'show vars' command and other commands as well.
A variable reference consists of 1 or 2 dollar signs ('$'), followed
immediately by a valid identifier string (e.g., $$global-log or
$local-log).
Variables can be 1 or more characters in length, and follow the YANG rules for identifier names.
The first character must be a letter, 'A' to 'Z', or 'a' to 'z'.
The 2nd to last characters can be a letter 'A' to 'Z', or 'a' to 'z', number ('0' to '9'), an underscore ('_'), a dash ('-'), or a period ('.') character.
There are 4 categories of parameters supported:
Read-only system variables
Read-write system variables
Read-write global user variables (saved in
$HOME/.yumadirectory)Read-write local user variables
It is an error if a variable is referenced (in the right-hand-side of a statement) that does not exist.
The first 3 types are global variables, which means that they are available to all run-levels of all scripts. The last type, called a local variable, is only visible to the current run-level of the current script (or interactive shell). Refer to the following section for more details on run levels.
Variable Syntax
Syntax |
Description |
Example |
|---|---|---|
$$<variable-name> |
Left hand side: set the global variable to some value |
$$saved_get = get |
$$<variable-name> |
Right hand side: access the value of a global variable |
fill --target=$$mytarget |
$<variable-name> |
Left hand side: set the local variable to some value |
$myloglevel = $$log-level |
$<variable-name> |
Right hand side: access the value of any variable with this name |
$myuser = $user |
Read-only System Variables¶
The following table shows the unix environment variables that are available as read-only global variables in yangcli-pro. These variables are set once when the program is started, and cannot be used in the the left hand side of an assignment statement.
Variable |
Description |
$$HOME |
$HOME environment variable |
$$HOSTNAME |
$HOST or $HOSTNAME environment variable |
$$LANG |
$LANG environment variable |
$$PWD |
$PWD environment variable, when yangcli-pro was invoked |
$$SHELL |
$SHELL environment variable |
$$USER |
$USER environment variable |
$$YUMAPRO_DATAPATH |
$YUMAPRO_DATAPATH environment variable |
$$YUMAPRO_HOME |
$YUMAPRO_HOME environment variable |
$$YUMAPRO_MODPATH |
$YUMAPRO_MODPATH environment variable |
$$YUMAPRO_RUNPATH |
$YUMAPRO_RUNPATH environment variable |
Read-write System Variables¶
The following table shows the CLI configuration parameters that can be read or changed (but not deleted). If a particular parameter was not set during program invocation, then the associated variable will contain the empty string.
Variable |
Description |
|---|---|
$$aliases-file |
--aliases-file configuration parameter |
$$allow-shell |
--allow-shell configuration parameter |
$$alt-names |
--alt-names configuration parameter |
$$ask-password |
--ask-password configuration parameter |
$$auto-discard-changes |
--auto-discard-changes parameter |
$$auto-keepalive |
--auto-keepalive configuration parameter |
$$auto-reconnect |
--auto-reconnect configuration parameter |
$$auto-reconnect-interval |
--auto-reconnect-interval configuration parameter |
$$auto-reconnect-max |
--auto-reconnect-max configuration parameter |
$$autoaliases |
--autoaliases configuration parameter |
$$autocomp |
--autocomp configuration parameter |
$$autoconfig |
--autoconfig configuration parameter |
$$autoconfig-conf-mode |
--autoconfig-conf-mode configuration parameter |
$$autodevices |
--autodevices configuration parameter |
$$autoeventhandlers |
--autoeventhandlers configuration parameter |
$$autohistory |
--autohistory configuration parameter |
$$autoload |
--autoload configuration parameter |
$$autoload-cache |
--autoload-cache configuration parameter |
$$autoload-get |
--autoload-get configuration parameter |
$$autoload-save-cache |
--autoload-save-cache configuration parameter |
$$autonotif |
--autonotif configuration parameter |
$$autonvsave |
--autonvsave configuration parameter |
$$autoschemaservers |
--autoschemaservers configuration parameter |
$$autosessions |
--autosessions configuration parameter |
$$autotest |
--autotest configuration parameter |
$$autousers |
--autousers configuration parameter |
$$autouservars |
--autouservars configuration parameter |
$$bad-data |
--bad-data configuration parameter |
$$break-key-mode |
--break-key-mode configuration parameter |
$$callhome-address |
--callhome-address configuration parameter |
$$callhome-enabled |
--callhome-enabled configuration parameter |
$$callhome-port |
--callhome-port configuration parameter |
$$callhome-tls-port |
--callhome-tls-port configuration parameter |
$$check-output |
--check-output configuration parameter |
$$check-output-error |
--check-output-error configuration parameter |
$$check-replies |
--check-replies configuration parameter |
$$check-replies-error |
--check-replies-error configuration parameter |
$$config-autosave |
--config-autosave configuration parameter |
$$config-commit-mode |
--config-commit-mode configuration parameter |
$$config-edit-mode |
--config-edit-mode configuration parameter |
$$default-module |
--default-module configuration parameter |
$$default-operation |
<default-operation> parameter for <edit-config> operations |
$$display-mode |
--display-mode configuration parameter |
$$echo-notif-loglevel |
--echo-notif-loglevel configuration parameter |
$$echo-notifs |
--echo-notifs configuration parameter |
$$echo-replies |
--echo-replies configuration parameter |
$$encoding |
--encoding configuration parameter |
$$error-option |
<error-option> parameter for <edit-config> operations |
$$fill-optional |
--fill-optional configuration parameter |
$$fixorder |
--fixorder configuration parameter |
$$help-width |
--help-width configuration parameter |
$$ignore-missing-vars |
--ignore-missing-vars configuration parameter |
$$indent |
--indent configuration parameter |
$$keepalive-interval |
--keepalive-interval configuration parameter |
$$leaflist-multi-line |
--leaflist-multi-line configuration parameter |
$$log-level |
--log-level configuration parameter |
$$match-names |
--match-names configuration parameter |
$$message-indent |
--message-indent configuration parameter |
$$optional |
--optional configuration parameter |
$$prompt |
--prompt configuration parameter (yp-shell only) |
$$prompt-type |
--prompt-type configuration parameter |
$$save-session-vars |
--save-session-vars configuration parameter |
$$script-input |
--script-input configuration parameter |
$$server |
--server configuration parameter |
$$shell-command |
--shell-command configuration parameter |
$$ssl-fallback-ok |
--ssl-fallback-ok configuration parameter |
$$term-length |
--term-length configuration parameter |
$$test-option |
<test-option> parameter for the <edit-config> operation |
$$test-suite-file |
--test-suite-file configuration parameter |
$$time-rpcs |
--time-rpcs configuration parameter |
$$time-rpcs-stats |
--time-rpcs-stats configuration parameter |
$$time-rpcs-stats-file |
--time-rpcs-stats-file configuration parameter |
$$timeout |
--timeout configuration parameter |
$$use-data-templates |
--use-data-templates configuration parameter |
$$use-rawxml |
--use-rawxml configuration parameter |
$$use-session-vars |
--use-session-vars configuration parameter |
$$use-traceid |
--use-traceid configuration parameter |
$$use-xmlheader |
--use-xmlheader configuration parameter |
$$user |
--user configuration parameter |
$$uservars-file |
--uservars-file configuration parameter |
$$with-defaults |
<with-defaults> retrieval parameter |
$$with-term-msg |
--with-term-msg configuration parameter |
Read-write Global User Variables¶
If a unrecognized global variable (e.g., $$foo) is used in the left-hand side of an assignment statement, then a global user variable will be created with that name. If the global user variable already exists, then its value will be overwritten.
The uservars command can be used to load or store these variables
so they are loaded at boot-time. By default, the XML file used to
store these variables is $HOME/.yumapro/yangcli-pro_uservars.xml.
Read-write Local User Variables¶
If a local variable (e.g., $foo) is used in the left-hand side of an assignment statement, then a local user variable will be created with that name. If the local user variable already exists, then its value will be overwritten. If the variable is created within a script (i.e., run-level greater than zero), then it will be deleted when the script exits.
Read-write Session User Variables¶
If the $$use-sessionvars variable is true, then global variables will be treated as session-specific variables, while the active session is a named session. In this case, if a unrecognized global variable (e.g., $$foo) is used in the left-hand side of an assignment statement, then a session user variable will be created with that name. If the session user variable already exists, then its value will be overwritten.
If data templates are used, then the session-specific variables will be used to replace a variable reference within the template, instead of the global variable.
Files¶
File contents can be used in yangcli-pro statements, similar to user variables.
A file reference consist of the 'at-sign' character ('@') followed immediately by a valid file specification.
session1> @foo.yang = get-schema --identifier=foo --format=YANG
session1> mgrload --module=foo
If the file extension is “.yang”, “.log”, “.txt”, or “.text”, then the value (or command output) will be saved, and yangcli-pro will strip off the outermost XML (if needed) to save the requested file as a pure text file.
If the file extension is ".json", the file will be saved in JSON format.
Otherwise, the file will be saved in XML format. The display mode set by the user can affect XML output.
If the display mode i s'xml-nons' then XML without namespace (xmlns) attributes will be generated instead of normal XML.
Files may also be used as parameter replacements, within a command.
session1> $saved_get = get --filter=@filter.xml --with-defaults=explicit
It is an error if the file referenced does not exist or cannot be read.
Scripts¶
Any command can be entered at the interactive shell, or stored in a script file, and invoked with the run command. Scripts are simply text files, and the extension used does not matter.
There are no formal templates for scripts, like there are for RPC operations, at this time. Instead, positional parameters can be passed to any script.
The parameters named '--P1' to '--P9' allow up to 9 parameters to be passed to any script. Within each script, the numbered parameters '$1' to '$9' are available, and contain the value that was passed as the corresponding --Pn parameter when calling the script.
If a line contains only optional whitespace, followed by the pound sign character '#', then the line is treated as a comment. These lines will be skipped.
If an error occurs during a command within a script, or an <rpc-error> is received from the server during a NETCONF session, then the running script will be canceled, and if this was a nested script, then all parent scripts will also be canceled.
Script Example:
> run connect --P1=andy --P2==localhost --P3=yangrocks
// connect script
# start a NETCONF session
$user = $1
$server = $2
$password = $3
> connect --user=$user --server=$server --password=$password
Run Levels¶
The run command can appear in a script.
When yangcli-pro starts up, either in interactive mode or in batch mode, the script interpreter is at run level zero. Each time a run command is invoked, either at the command line or within a script currently being invoked, a new run level with the next higher value is assigned. Local variables are only visible within the current run level.
A maximum of 512 run levels are supported in yangcli-pro.
Scripts can be called recursively, but a stop condition needs to be used to break the recursion (e.g., call the script from within a conditional code block.
Conditional Command Blocks¶
The if, elif, else, and end commands are used to create an 'if command sequence'.
Any other commands that appear between these commands are part of a conditional command block.
These blocks can be nested. The current conditional state is inherited, so an if command sequence within a false conditional block will not be executed. A block can contain zero or more command lines,
These command work exactly like an 'if' expression within a program language such as Python. Note that indentation is not significant, but it may be used to make scripts more readable.
The if command starts a new if-command sequence. It is followed by a conditional command block. This block ends when an elif, else, or end command within the same if command block is encountered.
At most, only one conditional code block within the if command sequence will be executed. Once a conditional command block has been executed, any remaining blocks will be skipped.
All user and system variables that are available to the current script run level can be used within the XPath expressions for determining the conditional block state (true or false).
Conditional Command Loop Blocks¶
The while and end commands are used to create an 'while loop sequence'.
Any other commands that appear between these commands are part of a conditional command loop block.
These blocks can be nested. The current conditional state is inherited, so a while loop sequence within a false conditional block will not be executed. A block can contain zero or more command lines,
The loop condition can be a constant expression. The maxloops parameter will prevent infinite looping, and can be utilized to use the while loop sequence as a simple 'for' loop, iterating a specific number of times.
All user and system variables that are available to the current script run level can be used within the XPath expressions for determining the conditional block state (continue or terminate loop).
The following script does not do any useful work. It is provided to demonstrate some simple script constructs.
# Sample Script 1
$x = 0
while '$x < 2'
# this is a comment
log-info 'start 1'
$x = eval '$x + 1'
$y = 0
while '$y < 4'
log-info 'start 2'
$y = eval '$y + 1'
if "module-loaded('test')"
log-info 'module test loaded'
elif '$x > 1'
log-info 'x>1'
elif "feature-enabled('test3', 'feature1')"
log-info 'feature1'
else
log-info 'else'
end
log-info 'end 2'
end
log-info 'end 1'
end
if "feature-enabled('test5', 'feature-foo')"
log-info 'feature-foo'
run add-foo-parms
end
The following script demonstrates how to run multiple edits on the ietf-interfaces.yang data module:
# Sample Script 2
$x = 0
$y = interfaces
$z = interface
$value = ianaift:l2vlan
while '$x < 5'
create /if:$y/if:$z[if:name='vlan$x']/if:type value=$value
commit
$x = eval '$x + 1'
end
Configuration Mode Editing¶
In addition to the normal NETCONF low-level and high-level editing commands, there is also a configuration mode similar to a router CLI. This mode can be used to edit YANG datastore nodes with a simplified interface.
Configuration 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.
In configuration mode, data node names can be abbreviated just like RPC operation parameter names.
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)#
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>
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 command is given. To force all pending edits to be sent to the current session, the apply command can be used within a given context level.
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:
mysession# no int int eth0 mtu
Applying 1 edit to session [mysession]
mysession#
Note that to delete leaf nodes no value is given. A value is only required for YANG list and leaf-list data nodes, to identity the keys for the instance that should be deleted.
Escaping Configuration Mode¶
In order to enter normal yangcli-pro commands while in configuration mode, the 'do' prefix 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#
yangcli-pro Configuration Parameter List¶
The following configuration parameters are used by yangcli-pro. Refer to the YumaPro CLI Reference for more details.
Parameter |
Description |
|---|---|
Specifies the command aliases file to use. |
|
Enable or disable the run-shell command. |
|
Controls whether alternate names will be checked for UrlPath searches. |
|
Controls whether the 'connect' command will prompt for password parameter (if it is not provided). |
|
Controls automatic sending of <discard-changes> to cleanup edit |
|
Controls automatic sending of keepalive messages. NOT IMPLEMENTED - IGNORED. |
|
Controls automatic reconnecting to dropped sessions |
|
Controls how often automatic reconnect is attempted. |
|
Controls maximum number of reconnect attempts |
|
Controls automatic loading and saving of the command aliases |
|
Controls whether partial commands are allowed or not. |
|
Controls whether the running configuration will be retrieved automatically for active sessions. |
|
Controls whether the running configuration will be retrieved automatically for active sessions, while editing in config mode |
|
Controls whether saved device configurations are loaded at startup and saved upon exit. |
|
Controls whether the saved event_handlers will be loaded into memory at startup and saved to file at exit. |
|
Controls whether th command line history buffer will be automatically loaded at startup and saved on exit. |
|
Controls whether modules used by the server will be loaded automatically, as needed. |
|
Controls whether the modules retrieved with the <get-schema> operation are cached for use by the running instance of yangcli-pro. |
|
Controls whether the <get> operation will be used to retrieve the /netconf-state/schemas sub-tree. |
|
Controls whether the cached YANG modules will be saved upon exit |
|
Controls whether notifications will automatically be enabled when a session starts. |
|
Controls whether the 'save' and 'apply' commands will NV-save the configuration changes or not. |
|
Controls whether saved session configurations are loaded at startup and saved upon exit. |
|
Controls whether the saved schema servers will be loaded into memory at startup and saved to file at exit. |
|
Controls whether the saved sessions will be loaded into memory at startup and saved to file at exit. |
|
Controls whether the saved test suites will be loaded into memory at startup and saved to file at exit. |
|
Controls whether saved user configurations are loaded at startup and saved upon exit. |
|
Controls automatic loading and saving of the global user variables |
|
Controls how bad data about to be sent to the server is handled. |
|
Indicates the interactive shell should not be used. |
|
Maximum number of bytes o display of binary data for a YANG object |
|
Controls the behavior when the break key (Control C) is pressed |
|
IP address to use to listen for CallHome SSH requests |
|
Enable or disable the IETF Call Home protocol |
|
TCP port number to use to listen for NETCONF over SSH CallHome requests |
|
TCP port number to use to listen for NETCONF over TLS CallHome requests |
|
One or more name of a configured user entries to use for Call Home connections |
|
Controls whether YANG <rpc> validation is done |
|
Controls whether YANG <rpc> validation errors are treated as errors or warnings |
|
Controls whether YANG <rpc-reply> validation is done |
|
Controls whether YANG <rpc-reply> validation errors are treated as errors or warnings |
|
Specifies the configuration file to use for parameters. |
|
Controls how edits in config term mode are saved to NV-storage if the server supports the :startup capability. |
|
If 'true' then edits done in config mode will be made to the candidate datastore if possible. The edits will not be committed to the running datastore automatically. |
|
Controls how edits are applied during configuration mode |
|
Sets the data file search path. |
|
Specifies the default module to use to resolve identifiers. |
|
Species one or more YANG modules to load as deviations.` |
|
Specifies a top-level command that should be disabled and not visible or available to a user. If the value does not contain a module name prefix, then the command will be disabled in all modules. |
|
Specifies how values should be displayed. |
|
Specifies the log-level needed to echo unregistered notifications to the log and/or STDOUT. |
|
Specifies whether unregistered notifications will be output to the log or STDOUT. |
|
Controls whether RPC replies will be displayed in the log output, if log-level >= 'info' |
|
Controls the desired RESTCONF encoding format. |
|
RESTCONF entry point. Use this string instead of retrieving the XRD from the RESTCONF server to discover the entry point |
|
Leaf list of features to disable |
|
Specifies a feature that should be enabled |
|
Specifies if a feature should be enabled or disabled by default |
|
Specifies the default value for the –optional flag for the operations that fill YANG datastore contents |
|
Controls whether PDUs are changed to canonical order before sending them to the server. |
|
Controls whether the candidate or running configuration datastore will be used as the default edit target, when both are supported by the server. |
|
Controls the behavior of the XML parser and dictates how a bad RPC reply will be handled. |
|
Get program help. |
|
Adjust the help output (--brief or --full). |
|
Width of help text line for '?' help key output |
|
Specifies the libtecla command line history file to use |
|
Override the $HOME environment variable. |
|
Specifies whether a missing variable in a data template is an error or the variable expands to an empty string |
|
Specifies the indent count to use when writing data. |
|
Specifies if unverified client certificates will be accepted (DEBUG only) |
|
Specifies the keepalive message interval. NOT IMPLEMENTED. |
|
Specifies if multiple leaf-lists allowed in 1 line in config mode |
|
Specifies the log file to use instead of STDOUT. See the YumaPro User Manual for a general discussion of logging. |
|
Controls whether a log file will be reused or overwritten. |
|
Append stack trace information to log messages. |
|
Add additional (compiler/OS dependent) detail to stack trace information. |
|
Specify message level(s) for which stack trace information will be generated. |
|
Include stack trace information in the specified output stream(s |
|
Specifies that log output will be sent to STDOUT after being sent to log file and/or syslog |
|
Include additional information (level/date/time) with log message. |
|
Specifies verbosity level of log message output |
|
Synonym for log-console. |
|
Specifies that error level log messages will be sent to STDERR. |
|
If present, strip certain control characters from output in order to modify log formatting. |
|
Send log message output to the syslog daemon. |
|
Sets the syslog debug logging level filter for output to the syslog file |
|
Match mode to use for UrlPath searches |
|
The number of spaces to indent for each level of output in a protocol message, e.g. NETCONF request. |
|
Sets the module search path. |
|
Specifies one or more YANG modules to load upon startup. |
|
Specifies the NETCONF server port number to use in the connect command. |
|
Disables the alias substitution feature. |
|
Specifies that the default configuration file should not be loaded if it exists. Not a configuration file parameter. |
|
Specifies that keys will be used instead of a password. Ignored if used as a configuration file parameter. |
|
Specifies the default value of the $$optional variable. This will affect all input, not just YANG datastore contents. Use with caution! |
|
Specifies the password to use in the connect command. |
|
Contains the file path specification for the file containing the client-side private key. |
|
Set a complete custom prompt for yp-shell |
|
Customize a prompt name for yp-shell. |
|
Selects the type of prompt string that will be used in interactive mode. |
|
Controls which NETCONF protocol versions will be enabled. Ignored if used in a configuration file. |
|
Contains the file path specification for the file containing the client-side public key |
|
Controls whether an 'restrict edit mode' will be supported for yp-shell. |
|
Sets the executable file search path. |
|
Specifies the command to run at startup time. |
|
Specifies the script to run at startup time. |
|
Specifies if session variables will be saved when the program exits. |
|
Controls whether the program will stop for input when running a script in interactive mode. |
|
Specifies the server address to use in the connect command. |
|
Specifies whether RPC operations learned from server YANG modules will be added as a command available to the user. |
|
The shell program to invoke for the run-shell command. |
|
Contains the file path specification for the file containing the client-side SSL certificate. |
|
If true then an attempt to establish a plain TCP connection will be made if an SSL connection cannot be made. |
|
Contains the file path specification for the file containing the client-side SSL key |
|
Contains the file path specification for the file containing the client-side ssl trust-store, or the path specification for the directory to use for finding trusted certificates` |
|
Specifies whether child sub-directories should be searched when looking for files.` |
|
Specifies the number of lines that should be printed per page if paginated output is used. |
|
Specifies the name of the test suite file to load if --autotest=true. |
|
Measure the round-trip time of each <rpc> request and <rpc-reply> at the session level. |
|
Save rpc statistics to the specified or default statistics file if the time-rpcs variable is also true. |
|
Save rpc statistics to the specified file if the --time-rpc-stats and time-rpcs variables are true. |
|
Specifies the timeout to use in the connect command. |
|
Specified the transport protocol to use (ssh, tcp, or tpc-ncx) |
|
Controls whether data templates are enabled |
|
Controls how file result variables will be read. If true then the YANG object template will not be used when parsing the XML file. |
|
Controls how global variables will be handled when set from the context of a named session. If true then session-specific variables will be used. |
|
Controls whether the 'trace-id' attribute will be set in the RPC calls or not. By default, 'trace-id' attribute is disabled. |
|
Specifies how file result variables will be written for XML files. Controls whether the XML preamble header will be written or not. |
|
The default user name for NETCONF sessions. |
|
Specifies the global user variable files to load. |
|
Prints the program version and exits. |
|
Treat all warnings as errors |
|
Controls how identifier lengths are checked. |
|
Controls how line lengths are checked. |
|
Suppresses the specified warning number. |
|
Elevates the specified warning number to an error |
|
Enable wildcards on key leaf values |
|
Controls whether an enable mode will be supported for yp-shell. |
|
Controls whether notification commands are available in yp-shell |
|
Controls whether OpenConfig pattern syntax will be checked |
|
Controls whether Terminal Diagnostic events are supported |
|
Specifies a yangmap XML file that should be loaded into the program |
|
Specifies the $YUMAPRO_HOME project root to use when searching for files. |
Invoking yangcli-pro Commands¶
Commands can be entered with parameters:
in one continuous line
session1> merge target=/toaster/toastControl --value=”down”
in several lines (using line continuation)
session1> merge target=/toaster/toastControl \ more> --value=”down”
interactively prompted for each parameter
session1> merge (will be prompted for target and value)
a combination of the above
session1> merge target=/toaster/toastControl (will be prompted for value)
When a command is entered, and the yangcli-pro script interpreter is running in interactive mode (--batch-mode not active), then the user will be prompted for any missing mandatory parameters.
If the --optional parameter is present (or the $$optional system variable is set to 'true'), then the user will be prompted for any optional parameters that are missing.
A command has the basic form:
<name (QName)> <parameter (any YANG type)>\*
The command name is a qualified name matching the name used in the YANG rpc statement. This is followed by zero or more parameters (in any order).
A command parameter has the same syntax as a CLI configuration parameter.
The command name syntax is described below.
An un-escaped end-of-line character ('enter key') terminates command line input.
Command Prompt¶
The yangcli-pro command prompt changes, depending on the context.
It can also be configured and changed at run-time by the user (yp-shell only).
If the --prompt CLI parameter or $$prompt configuration variable is used to set the prompt to a user-specified value, then that will be the prompt shown in Idle Mode, and also used as the base prompt string in Config Mode. See the --prompt parameter for more details.
Idle Mode¶
If the script interpreter is idle and there is no NETCONF session active, then the prompt is simply a 'less than' sign:
>
If the script interpreter is idle and the default NETCONF session active, then the prompt is of the form <user>@<server>', depending on the parameters used in the connect command. Note that the <server> portion of the prompt can be configured in yp-shell, using the 'prompt-name' CLI parameter.
andy@myserver>
If a named session is active, then the '<user>@<server>' text will not be shown. Instead, the session name will be shown 'mysession'.
mysession>
Configuration Mode¶
If configuration mode is entered, the final prompt character will change from '>' to '#'.
Default session:
andy@myserver#
Named session:
mysession#
If the configuration mode context node is changed, then the new datastore target object name will be shown as well:
mysession# interfaces
mysession(interfaces)# interface eth0
mysession(interface)#
Continuation Mode¶
If a backslash, end-of-line sequence ended the previous line, the prompt will simply be the word 'more' indented 3 spaces:
andy@myserver> get \
more>
The 'more>' prompt will continue if the new line also ends in with an escaped end-of-line. When a new line is finally terminated, all the fragments are spliced together and delivered as one command line.
Note: context-sensitive command completion is not available in this mode.
Choice Mode¶
If a partial command has been entered in interactive mode, and the script interpreter needs to prompt for a YANG 'choice' parameter, then a list of numbered cases will be presented, and the prompt will be the same as it was before (depending on whether a NETCONF session is active or not), except a colon character (':'), followed by the command name, will be added at the end. As long as parameters for the same command are being entered (i.e., prompted for child nodes within a selected case, the command name will be appended to the prompt.
andy@myserver> sget
Enter a number of the selected case statement:
1: case varref:
leaf varref
2: case from-cli:
leaf target
leaf optional
anyxml value
Enter choice number [1 - 2]:
andy@myserver:sget>
Parameter Mode¶
If a partial command has been entered in interactive mode, and the script interpreter needs to prompt for a leaf or leaf-list, then the parameter name will appear in angle brackets ('<' and '>').
Filling mandatory case /sget/input/from/from-cli:
Enter string value for leaf <target>
andy@myserver:sget>
If the ncx:password extension is part of the YANG definition for
the leaf or leaf-list, then the characters entered at the prompt in this
mode will not be echoed, and they will not be saved in the command
history buffer. Any default value will not be printed either. Instead, 4
asterisks **** will be printed, even though the correct value will be
used in the command.
If a default value is available, it will appear in square brackets ('[' and ']'). In this case, entering 'return' will not be interpreted as an empty string, but rather the default value that was presented.
> connect
Enter string value for leaf <user> [andy]
:connect>
Enter string value for leaf <server> [myserver]
:connect>
Enter string value for leaf <password> [****]
:connect>
Enter uint16 value for leaf <port> [830]
:connect>
Enter uint32 value for leaf <timeout> [30]
[connect sequence text printed, and then prompt changes...)
andy@myserver>
Note: After a NETCONF session is terminated for any reason, the connection parameters will be remembered , and presented as defaults the next time the connect command is entered.
False Conditional Block Mode
If a conditional command (if, elif, else, or while command) is active, but the conditional expression is false, then any commands defined within that conditional block will not be executed. If this occurs in interactive mode instead of a script, the string '[F]' will be added to the command prompt. Note that the 'help' and 'log-info' commands do not get executed in the following example:
> if 0
[F]> help
[F]> log-info 'this will not get printed'
[F]> end
>
Command Name¶
The command name can be entered with or without an XML prefix:
session1> nc:get
session1> get
If there is a prefix (e.g., 'nc:get'), then it needs to be one of the XML prefixes in use at the time. Use the 'show modules' command to see the modules and prefixes in use. The YANG prefix will usually be the same as the XML prefix, but not always.
XML prefixes are required to be unique, so if any 2 YANG modules pick the same prefix, then 1 of them has to be changed for XML encoding purposes.
If the --default-module configuration parameter (or $$default-module system variable) is set, it will be used to resolve a command name without any prefix, if it is not a NETCONF or yangcli-pro command.
An error message will be printed if the command entered cannot be found in any YANG module, or if there are multiple commands that match the same string.
Using the ncx:default-parm Extension¶
Each command may define a default parameter, by placing an ncx:default-parm extension in the rpc input section in the YANG rpc statement. This extension allows less typing in yangcli-pro to accomplish the same thing.
If the script interpreter encounters a string in the command line that is not a recognized parameter for that command, and there is a default parameter defined, then the string will be used as a value for the default parameter.
For example, the 'show' parameter is the default parameter for the 'history' command, so both of these commands will be interpreted to mean the same thing:
> history --show=10
> history 10
Note: the default parameter does not allow the wrong form of a parameter type to be entered, to accept the default for that parameter. For example, the 'show' parameter above has a default value of '25':
# this is the same as history show=25
> history
# this is an error, not the same as the above
> history show
The following table shows most of the default parameters that are available. If a command has only 1 parameter then it is made the default parameter automatically.
Default Parameters
Command |
Default Parameter |
|---|---|
target |
|
var |
|
show |
|
dir |
|
server |
|
target |
|
expr |
|
expr |
|
expr |
|
show |
|
target |
|
command |
|
show |
|
target |
|
module |
|
msg |
|
msg |
|
msg |
|
msg |
|
target |
|
module |
|
index |
|
target |
|
script |
|
log-level |
|
target |
|
target |
|
target |
|
select |
|
select |
|
select |
|
expr |
Parameter Mode Escape Commands¶
There are 4 escape sequence commands that can be used while entering parameters.
They all begin with the question mark character ('?'), and end with the 'Enter' key.
Control key sequences are not used because that would interfere with command line editing keys.
Parameter mode escape sequences
Escape Sequence |
Description |
? |
Print some help text |
?? |
Get all available help text |
?s |
Skip this parameter |
?se |
Skip to the end of the current parameter set |
?c |
Cancel this command. If --break-key-mode=command then Control-C can also be used to cancel a command. |
Note: If the current parameter is considered hidden (ncx:hidden extension used in the YANG definition), then no help will be available for the parameter, even though it is accessible. This also apples to the help command. Any command or parameter designated as ncx:hidden will be treated as an unknown identifier, and no help will be given.
Note: Skipping mandatory nodes with the '?s' command is affected by the --bad-data configuration parameter and $$bad-data system variable. An error, warning, or confirmation check may occur. Refer to the YumaPro CLI Reference for more details.
The '?s' command to skip a parameter will allow the current command to be skipped, even if it is a mandatory parameter.
The '?se' command will allow the current command to be skipped, even if it is a mandatory parameter. The rest of the parameters in the same sibling set will also be skipped, but only if they are optional parameters. This mode is only active if the –optional parameter is used in the command that is causing parameters to be entered, or the $$optional global variable is set to 'true'. The sibling set is defined as the nodes in the parent containment node (case, list, or container).
Note: If there are any YANG defined values (e.g., enumeration, bits, default-stmt) available for the current parameter, then pressing the tab key will list the full or partial completions available.
Using Inline XML or JSON Data¶
It is possible to assign JSON or XML encoded data to a variable or command parameter.
This can be done at the command prompt or within a script.
A special string consisting of 3 double quotes is used to indicate the beginning or end of the inline data.
The syntax is simple:
<start-tag> [wsp] <XML element -or- JSON object> [wsp] <end-tag>
Example <edit-config> command setting the <config> container to an XML value:
sesA> edit-config target=candidate config="""<config><int8.1>5</int8.1></config>"""
The end-of-line continuation marker '' is not needed when entering inline data. The data may appear or multiple lines.
Example script using JSON:
> edit-config target=candidate config="""
{"config": {
"container.1" : {
"uint16.1" : 42,
"uint32.1" : 4200,
"int32.1" : -4200
}
}
}
"""
Example script using XML:
> edit-config target=candidate config="""
<config>
<container.1>
<uint16.1>42</uint16.1>
<uint32.1>4200</uint32.1>
<int32.1>-4200</int32.1>
</container.1>
</config>
"""
When entering inline data at the command line, the “more>” command prompt mode will be entered automatically if an odd number of tags are found on the input line.
When assigning inline data to a variable, there is no object specified, so the YANG “anydata” type is used. In this case any valid XML element or JSON object can be assigned.
Example Variable Assignment:
andy@localhost> $foo = """
more> <A>
more> <leaf1>testing</leaf1>
more> </A>
more> """
OK
andy@localhost> show var foo
foo [/struct]
A {
leaf1 testing
}
andy@localhost>
Restrictions:
Only the following YANG data node types are supported:
container
list
anyxml
anydata
input
output
The maximum length of an input line, including all inline data, is 65535 bytes.
If a JSON array is entered instead of a JSON object, then only the first instance will be used. Any additional instances will be ignored.
Using External XML¶
It is possible to specify command parameters and even the entire command
with an external XML file. This file needs to be located in the data
path, such as the $HOME/data directory.
The CLI parameter --use-rawxml affects the parsing of the external XML file. By default, the XML will be parsed and converted to internal data format. If --use-rawxml=true is used then the file will be used as-is if the XML file is invalid.
If this parameter is ‘false’ then xmlns attributes will be ignored in the external XML file.
External XML Parameters¶
A parameter can be specified using an external XML file using the @<filename> syntax
> get filter=@myfilter.xml
andy@localhost> get filter=@myfilter.xml
RPC Data Reply 6 for session 3 [default]:
rpc-reply {
data {
netconf-state {
statistics {
netconf-start-time 2019-12-03T01:30:04Z
in-bad-hellos 0
in-sessions 1
dropped-sessions 0
in-rpcs 5
in-bad-rpcs 0
out-rpc-errors 0
out-notifications 0
}
}
}
}
andy@localhost>
In this example, the contents of the <filter> element will be filled using the contents of the file “myfilter.xml”. The contents will be used as the child nodes of the <filter> element. This is suitable for sending subtree filters.
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<statistics/>
</netconf-state>
The message sent to the server:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<statistics/>
</netconf-state>
</filter>
</get>
</rpc>
External XML Commands¶
It is possible to provide the entire command in the external XML file. In this case the top-level element must match the command, and the contents of this command will be used for the input parameters.
> $$use-rawxml = true
> get @myget.xml
The contents of the myget.xml contain a filter element using an XPath expression. In this case the prefixes need to be defined if any are used in the XPath expression. Note that the <get> operation needs a namespace definition as well or else the namespace will default to “yuma-ncx”.
<get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<filter type="xpath" select="/n:netconf-state/n:statistics"
xmlns:n="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring" />
</get>
Using XPath Expressions¶
There are some command parameters, such as the --target parameter for the create command, that accept XPath absolute path expressions.
If prefixes are present, then they must match the set of XML prefixes in
use at the time. Use the show modules command to see the current set
of prefixes.
If prefixes are not used, then the first available matching XML namespace will be used instead.
If the starting forward slash character ('/') is missing, then it will be added.
# these are all the same value (entered in 'fill' command)
# these are all the same value (entered in 'fill' command)
:fill> system
:fill> /system
:fill> /sys:system
It is important to remember 2 simple rules to avoid common errors in XPath expressions:
String constants must be quoted with single quote characters. The expression [name=fred] is not the same as [foo='fred']. The former compares the 'name' node value to the 'fred' node value. The latter compares the 'name' node value to the string 'fred'.
The double quote character ('”') is not allowed in XPath --select parameter expressions because the expression will be sent to the server inside a double-quoted string.
If an incomplete XPath absolute path expression is entered, and the script interpreter is in interactive mode, then the user will be prompted to fill in any missing mandatory nodes or key leafs.
# complete form of ifMtu leaf
:fill> /interfaces/interface[name='eth0']/ifMtu
# incomplete form of ifMtu leaf
:fill> /interfaces/interface/ifMtu
Filling key leaf <name>:
Enter string value:
The 'select' parameter for the xget and xget-config commands accepts full XPath expressions. The expression must yield a node-set result in order to be used as a filter in NETCONF get and get-config operations.
When interface (or any list) entries are returned by netconfd-pro, they will contain the the entire path back to the root of the YANG module, not just the specified node. Also, any key leafs within a list are added. This is only done if the XPath expression is missing any predicates for key leafs.
This is different than XPath 1.0 as used in XSLT. Since NETCONF get and get-config operations return complete XML instance documents, not node-sets, the ancestor nodes and naming nodes need to be added.
# reply shown with --display-mode=plain
data {
interfaces {
interface eth0 {
name eth0
ifMtu 1500
}
interface eth1 {
name eth1
ifMtu 1518
}
}
}
Special Parameter Handling¶
Some special handling of YANG data structures is done by the script interpreter. This special handling only apples to command mode.
Containers¶
Mandatory containers will be filled (in interactive mode) by default. The '$$optional' variable should be set to 'true' to cause optional containers to be filled as well.
Container DataStore Selection¶
Some parameters, such as the 'source' and 'target' parameters in many commands, are actually represented as a container with a single child -- a choice of several leaf nodes. In this situation, just the name of the desired leaf node can be entered as the 'contents' of the container parameter.
andy@myserver> sget-config /system source=candidate
This behavior is only supported for the following basic structure:
container with 1 child that is a choice
child choice has 1 or more cases
each child case contains one leaf with type 'empty'
Example: The special handling is supported for these commands for the source' parameter:
Container Child Node Selection¶
A leaf or leaf-list child node within a container can be set from the command line, without requiring interactive editing, inline XML, or external XML files.
A container name can be followed by a forward slash '/', followed by a leaf or leaf-list name. The syntax for setting a simple value is allowed after the leaf or leaf-list name.
Example: start a YANG Push periodic subscription of the running datastore:
> establish-subscription datastore=running periodic/period=3000
There are some restrictions at this time:
Only top-level containers or containers within top-level choices are supported
Tab completion for this mode is not supported
Choices and Cases¶
If a parameter name exact-match is not found, and a partial match is attempted, then choice and case node names will be ignored, and not cause a match.
Since these nodes never appear in the XML PDUs they are treated as transparent nodes (wrt/ parameter searches) unless they are specified with their full name.
Parameters that are a choice of several nodes, similar to above, except without a parent container node, (e.g., --help-mode) can be omitted. The accessible child nodes within the case nodes can be entered directly (e.g., sget target parameter).
# this is not allowed because 'help-mode' is not complete
> help --command=help --help-mo=brief
# this is allowed because 'help-mode' is complete,
# even though help-mode is a choice and 'brief' is
# an empty leaf
> help help help-mode=brief
# choice and case names are transparent when
# searching for parameter names, so the
# following command is the same as above
> help help brief
Lists and Leaf-Lists¶
When filling a data structure and a descendant node is entered, which is a YANG list or leaf-list, then multiple entries can be entered. After the node is filled in, there will be a prompt (Y/N, default no) to add more list or leaf-list entries.
Binary Data Type¶
The YANG binary data type is supported. Parameters of this type should be entered in plain text and they will be converted to binary format.
Command Completion¶
The 'tab' key is used for context-sensitive command completion:
If no command has been started, a list of available commands is printed
If a partial command is entered, a list of commands which match the characters entered so far is printed
If a command is entered, but no parameters, then a list of available parameters is printed
If a command is entered, and the cursor is within a command name, then a list of parameters which match the characters entered so far is printed
If a command is entered, and the cursor is after a command name, but not within a value string, then a list of available parameters is printed
If a command is entered, and the cursor is within a command value, then a list of possible values which match the characters entered so far is printed. Note that not all data types support value completion at this time.
If no values are available, but a default value is known, that value will be printed
If a session is active, and whitespace followed by the forward slash '/' character is entered, a list of top-level data node names is printed. Once a top-level name and a trailing slash '/' character is entered, pressing the tab key again will print the names of the child nodes of the current data node. Only schema-node strings are supported at this time. Auto-completion will not work if predicates are present in the absolute path expression.
Command list example: no NETCONF session is active:
> <hit tab key>
cd fill history mgrload quit run
connect help list pwd recall show
Command list example: NETCONF session is active
andy@myserver.example.com> <hit tab key>
cd get-schema recall
close-session help replace
commit history restart
connect insert run
copy-config kill-session save
create list sget
create-subscription load sget-config
delete load-config show
delete-config lock shutdown
discard-changes merge unlock
edit-config mgrload validate
fill no-op xget
get pwd xget-config
get-config quit
Command Line Editing¶
The command line parser is based on libtecla, a freely available library.
Refer to the complete user guide for information on configuring libtecla.
If the file
$HOME/.teclarcexists, then libtecla will use it to configure the key bindings.By default, libtecla uses emacs key bindings. There is no need for any further libtecla configuration if emacs mode is desired.
In order to use the vi editor key bindings, the
$HOME/.teclarcfile must exist, and it must contain the following line:edit-mode vi
Custom key bindings are also available. Refer to the libtecla documentation for more details on command line editing key customization.
The control key sequence (^F == control key and f key at the same time). The letter is not case-sensitive, so ^F and ^f are the same command.
The alt key sequence (M-f == alt key and f key at the same time). The letter is not case-sensitive, so M-F and M-f are the same command.
The following table shows the the most common default key bindings:
Common editing key bindings
Command |
Description |
^C |
clear screen |
^F |
cursor right |
^B |
cursor-left |
^A |
beginning of line |
^E |
end of line |
^U |
delete line |
M-f |
forward-word |
M-b |
backward word |
^P |
up history |
^N |
down history |
Command History¶
Each command line is saved in the command history buffer, unless a password is being entered in parameter mode. A command line can be recalled using the recall command.
By default, the previous history line (if any) will be shown if the ^P key is pressed.
By default, the next history line (if any) will be shown if the ^N key is pressed.
In addition, the history command can be used to control the command line buffer further. This command has 4 sub-modes:
show: show maximum of N history entries (default is 25)
clear: clear the history buffer
save: save the history buffer to a file
load: load the history buffer from a file
By default, the command line history buffer is loaded when the program starts, and saved when the program exits. This behavior can be turned off by setting the --autohistory configuration parameter to 'false'.
If --autohistory is ‘true’, then by default, the command line
history buffer is loaded from the file
$HOME/.yumapro.yangcli_pro_history This behavior can be changed by
setting the --history-file configuration parameter to the file
specification to use instead of the default file location. The same
parameter needs to be used each time the program is loaded in order to
maintain the same history file.
The '!' character is special when editing commands. If the first character is '!', and it is followed by a number or a non-zero character, the line will be interpreted as a recall request:
> !42 == recall command number 42 (same as recall 42)
> !get == recall the most recent command line starting with 'get'
Refer to the history command section for more details on this command.
Command Responses¶
The command output and debugging messages within yangcli-pro is controlled by the current log level (error, warn, info, debug, debug2, debug3).
If a command is executed by the script interpreter, then a response will be printed, depending on the log level value.
If the log level is 'info' or higher, and there were no errors and no response, then the string 'OK' is printed.
> $foo = 7
OK
>
If the log-level is set to 'error' or 'warn', then the 'OK' messages will be suppressed.
If the log level is set to 'debug' or higher, then responses from the server will be echoed to the log stream (STDOUT, log file and/or syslog). The current display mode will be used when printing data structures such as <rpc-error> and <notification> element contents.
If an error response is received from the server, it will always be printed to the log.
andy@myserver> create /system
Filling container /system:
RPC Error Reply 5 for session 8:
rpc-reply {
rpc-error {
error-type application
error-tag access-denied
error-severity error
error-app-tag limit-reached
error-path /nc:rpc/nc:edit-config/nc:config/sys:system
error-message 'max-access exceeded'
}
}
andy@myserver>
Refer to the --log-level section for more details. Logging capabilities are also discussed in more detail in the YumaPro User Manual.
Controlling Terminal Output¶
The yangcli-pro and yp-shell programs support terminal output filtering and paginated output. Pipe commands allow the line-by-line terminal output to be filtered, formatted, or redirected.
Pipe Commands: filter show command output and server response output
Pagination: pause output after each page, allowing the user to continue or quit the output
Display Mode: Specifies the display format (e.g., plain, cli, XML, JSON)
Pipe Commands¶
Pipe commands are used to control the terminal output
Pipe Commands: filter show command output and server response output
begin: start output after this pattern matches
include: include lines that match this pattern
exclude: exclude lines that match this pattern
redirect: send output to a text file instead of the screen
display: format the output in XML, JSON, CLI, or plain format
Usage Notes:
The pipe commands can be combined.
The “include” and “exclude” commands can be specified multiple times
The “redirect” filespec is relative to the current working directory
The “display” parameter is used to over-ride the current $$display-mode variable setting.
Examples:
The “show fan” command is an external command from the example-show.yang module.
It is not a real command within yangcli-pro.
The full output of the command is shown first, without any pipe commands:
> show fan 1 --full
Report for Fan 1
put fan status here...
put more fan status here...
put even more fan status here...
The “begin” command: this is case-sensitive so the first “fan” matches, not “Fan”
> show fan 1 --full | begin fan
put fan status here...
put more fan status here...
put even more fan status here...
>
The “include” command:
> show fan 1 --full | include more
put more fan status here...
put even more fan status here…
>
The “exclude” command:
> show fan 1 --full | exclude more
Report for Fan 1
put fan status here...
>
The “display” command:
andy@localhost> sget /system/uname|display json
Filling container /system/uname:
RPC Data Reply 11 for session 3 [default]:
{
"yuma-netconf:rpc-reply": {
"yuma-netconf:data": {
"yuma-system:system": {
"uname": {
"sysname":"Linux",
"release":"4.4.0-104-generic",
"version":"#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017",
"machine":"x86_64",
"nodename":"andy-2i7"
}
}
}
}
}
andy@localhost>
The “display” and “redirect” commands combined:
andy@localhost> sget /system|redirect ~/test1.json display json
Filling container /system:
andy@localhost>
pipe YANG Definition¶
container pipe {
ncx:abstract;
ncx:hidden;
description
"Pipe command sub-commands.
The 'begin', 'include', and 'exclude' parameters are used
to filter command output. If these parameters contain
any pattern meta-characters, then they will be treated
as a YANG pattern string. If a plain string is found
instead, then this string must be found in the line
to be considered a match.
Each output line is processed in the following manner:
1) if begin set and not triggered yet, then test
the line. If a match then disable this step
for future lines and continue testing output,
else skip this line.
2) check each exclude parameter. If any match then
skip this line.
3) check each include parameter. If any match then
include this line, else skip this line.
4) include the line in the output.
If the 'redirect' parameter is present then the filtered
output will be sent to a file instead of the session.
If the 'display' parameter is present then the specified
display format will be used for the output and the
filtering format. By default, the current display-mode
is used for both filtering and output formats.";
leaf begin {
type string;
description
"Specifies the pipe begin line pattern.";
}
leaf-list include {
type string;
description
"Specifies a pipe include line pattern.
Multiple parameters are treated as a logical-OR
expression.";
}
leaf-list exclude {
type string;
description
"Specifies a pipe exclude line pattern.
Multiple parameters are treated as a logical-OR
expression.";
}
leaf redirect {
type string;
description
"Specifies the pipe output redirect filespec.
If this filespec already exists then output
will be appended to the file.";
}
leaf display {
type enumeration {
enum xml {
description "Display output in XML";
}
enum json {
description "Display output in JSON";
}
enum curmode {
description
"Display output is the current $$display-mode";
}
enum plain {
description "Display output in plain format";
}
enum cli {
description "Display output in CLI format";
}
}
default "curmode";
description
"Specifies the pipe output display format.";
}
}
Pagination¶
Pagination: pause output after each page, allowing the user to continue or quit the output
--More-- prompt displayed at each pause
terminal length command controls number of lines printed per page
$$term-length variable also controls number of lines printed per page
space bar prints next page, return prints next line, ‘q’ to quit output
leaf term-length {
description
"Specifies the length of the terminal to use for page
mode output with the -More- prompt. This parameter
is ignored in batch mode. It is only used if the
output session is operating in interactive mode.
If the value 0 is used then the 'More' prompt will
be disabled. Otherwise this value represents the
number of lines to output for each screen in pagination
output mode.";
type uint16 {
range "0 .. 511";
}
default 0;
}
Example using pagination and pipe commands together:
andy@localhost> term length 10
OK
andy@localhost> sget /system/uname|display json
Filling container /system/uname:
RPC Data Reply 12 for session 3 [default]:
{
"yuma-netconf:rpc-reply": {
"yuma-netconf:data": {
"yuma-system:system": {
"uname": {
"sysname":"Linux",
"release":"4.4.0-104-generic",
"version":"#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017",
--More--
Examples setting terminal length:
> $$term-length = 20
> term length 20
Display Mode¶
The display mode controls the output format used to display YANG data:
Not all commands use YANG data so the display mode does not affect all commands.
Some show commands for example use plain text output only.
Commands that return “OK” or some error message are not affected by the display mode.
Commands that return server data and display the response support all display modes
Setting the Display Mode:
$$display-mode variable controls the output display format
The pipe command “display” overrides the $$display-mode setting for the current command
Displaying the current display mode:
> show var display-mode
display-mode cli
Display Mode YANG Definition¶
leaf display-mode {
description
"Controls how values are displayed during output
to STDOUT or a log file.";
type enumeration {
enum plain {
description
"Plain identifier without any prefix format.";
}
enum prefix {
description
"Plain text with XML prefix added format.";
}
enum module {
description
"Plain text with module name as prefix added format.";
}
enum xml {
description
"XML format.";
}
enum xml-nons {
description
"XML format, but no namespace (xmlns) attributes
will be generated.";
}
enum json {
description
"JSON format.";
}
enum cli {
description
"CLI format.";
}
}
default plain;
}
Plain Mode Example:
andy@localhost> sget /system/uname
Filling container /system/uname:
RPC Data Reply 14 for session 3 [default]:
rpc-reply {
data {
system {
uname {
sysname Linux
release 4.4.0-104-generic
version '#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017'
machine x86_64
nodename andy-2i7
}
}
}
}
andy@localhost>
CLI Mode example:
andy@localhost> sget /system/uname
Filling container /system/uname:
RPC Data Reply 15 for session 3 [default]:
rpc-reply
data
system
uname
sysname Linux
release 4.4.0-104-generic
version '#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017'
machine x86_64
nodename andy-2i7
andy@localhost>
NETCONF Device Configuration¶
The yangcli-pro program can be configured to associate a name with a set of device parameters to start a NETCONF device with a server. These named devices are saved in a configuration file. Use the --autodevices to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.
By default, the devices configuration is saved in
$HOME/.yumapro/yangcli_pro_devices.conf. To override this file, set
--autodevices=false and use the devices-cfg command to load a
specific devices configuration file.
Creating Devices¶
> device-cfg create=device-B server=192.168.0.57 protocols=netconf1.0
A new device is created: device-id=device-B name=device-B server=192.168.0.57
> device-cfg show=device-B
Device 'device-B':
server: 192.168.0.57
connected: false
Saving Devices¶
To save a device, the text configuration file can be edited or the device-cfg 'save' command can be used.
> connect user=andy server=myserver password=mypassword
... startup screen ...
andy@myserver> device-cfg save device-A
Saved current device as 'device-A'
andy@myserver>
Multiple Devices¶
Multiple devices can be active at once, however only one command at a time can be sent. This will be improved in a future release. Just use the start-session command to start a different session. Only one instance of each named session with its device can be active at the same time.
Saving the Configured Devices¶
The device configuration can be saved or loaded at run-time, even if the --autodevices=true parameter is used (the default). The devices-cfg command is used to load and save this file.
session-A> devices-cfg save
Saved 2 sessions OK to '~/.yumapro/yangcli_pro_devices.conf'
session-A>
To save the devices to a different file, simply provide the filespec in the 'devices-cfg save' command:
session-A> devices-cfg save myusers.conf
Saved 2 devices OK to 'mydevices.conf'
session-A>
Loading Additional Configured Devices¶
Additional devices can be added to the configuration in memory with the 'devices-cfg load' command. The named devices in the file cannot conflict with names already in use or the duplicate devices will be skipped.
session-A> devices-cfg load devices.conf
Loaded 3 sessions OK from 'devices.conf'
session-A>
Displaying the Configured Devices¶
The devices that are available can be displayed with the devices-cfg 'show' command. The --brief and --full extensions are available for this command.
session-A> devices-cfg show
Saved devices source: '~/.yumapro/.yangcli_pro_devices.conf'
Device 'desktop':
server: 10.0.0.7
connected: false
Device 'device-A':
server: localhost
connected: false
Device 'device-B':
server: 192.168.0.57
connected: false
Displaying Devices¶
Displaying a Specific Device
To see information about a specific device, use the 'device-cfg show' command:
> device-cfg show device-A
Device 'device-A':
server: localhost
connected: false
Saved Device Configuration File Format¶
The saved sessions are stored in a YumaPro configuration file.
The file contents must conform to the following YANG container definition:
container saved-devices {
ncx:abstract;
description
"Represents all the saved devices in
the ~/.yumapro/yangcli_pro_devices file.
Use the 'devices' command to access this file.
Edit by hand only if you follow this YANG definition.";
list device {
description
"The list of devices to use during this test-suite.";
key name;
leaf name {
type nt:NcxName;
description
"The name of the saved device.
The 'device save' command will use the
string <user>@<server-address> as the default.";
}
leaf devicetype {
type string;
description
"Device type for NETCONF devices.";
}
leaf server {
type inet:host;
mandatory true;
description
"IP address or DNS name of the NETCONF server target.";
}
leaf ncport {
type uint16 {
range "1..max";
}
default 830;
description
"NETCONF port number to use. If not present, then
port 830, followed by port 22, will be tried.";
}
uses EntryPointParm;
uses ncxapp:ProtocolsParm;
leaf transport {
description
"Identifies the transport protocol that should be used.";
type ywt:transport-type;
default ssh;
}
uses CommentParm;
}
}
Device Configuration File Example¶
The following example file shows a valid device configuration file:
saved-devices
device 'desktop' {
server '10.0.0.7'
ncport 830
protocols "netconf1.0 netconf1.1"
}
device 'device-A' {
server 'localhost'
ncport 830
protocols "netconf1.0 netconf1.1"
}
device 'device-B' {
server '192.168.0.57'
ncport 830
protocols "netconf1.1"
}
}
NETCONF Schema Server Configuration¶
The yangcli-pro program can be configured to associate a name with a set of schema server parameters to start a NETCONF schema device with a server. These named schema servers are saved in a configuration file. Use the --autoschemaservers to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.
By default, the schema server configuration is saved in
$HOME/.yumapro/yangcli_pro_schema_servers.conf. To override this file,
set --autoschemaservers=false and use
the schema-servers-cfg command to load a specific schema server
configuration file.
If a session that is starting up goes not support get-schema then yangcli will check its get-schema-servers list and do a special side session to that remote server to get the missing YANG modules. Leave the remote session open until all autoload is done then close it.
Creating New Schema Servers¶
A schema server is created with a saved device id and a saved user id.
Example: Use the saved user id of userA and the saved device id of deviceA to create a new schema-serverA.
> user-cfg show=userA
User 'userA':
user: admin
password: fredlow
connected: false
> device-cfg show=deviceA
Device 'deviceA':
server: 192.168.0.57
connected: false
> schema-server-cfg create=schema-serverA device-id=deviceA user-id=userA
A new schema_server is created:
schema_server-id=schema-serverA name=schema-serverA device=deviceA user=userA
Saving Schema Servers¶
To save schema servers, the text configuration file can be edited or the schema-servers-cfg 'save' command can be used.
> schema-servers-cfg save
Saved 1 schema_servers OK to '~/.yumapro/.yangcli_pro_schema_servers.conf'
> schema-server-cfg show=schema-serverA
Schema Server: schema-serverA
Device Id: deviceA
User Id: userA
Connected: false
To save the schema servers to a different file, simply provide the filespec in the 'schema-servers-cfg save' command:
> schema-servers-cfg save=~/.yumapro/schema-servers.conf
Saved 3 schema_servers OK to '~/.yumapro/schema-servers.conf'
Multiple Schema Servers¶
Multiple schema servers can be configured, only one schema server can be active. If a session that is starting up does not support get-schema then yangcli will check its get-schema-servers list and do a special side session to that remote server to get the missing YANG modules. Leave the remote session open until all autoload is done then closes it.
Displaying the Configured Schema Servers¶
The schema servers that are available can be displayed with the schema-servers-cfg 'show' command. The --brief and --full extensions are available for this command.
> schema-servers-cfg
Saved schema_servers source: '~/.yumapro/.yangcli_pro_schema_servers.conf'
Schema Server: schema-serverA
Device Id: deviceA
User Id: userA
Connected: false
Schema Server: schema-server-ACER
Device Id: device-ACER
User Id: user-ACER
Connected: false
Schema Server: schema-server-asus2
Device Id: asus2-device
User Id: asus2
Connected: false
Displaying A Schema Server¶
Displaying a Specific Schema Server
To see information about a specific device, use the schema-server-cfg 'show' command:
> schema-server-cfg show=schema-serverA
Schema Server: schema-serverA
Device Id: deviceA
User Id: userA
Connected: false
Saved Schema Server Configuration File Format¶
The saved schema servers are stored in a YumaPro configuration file.
The file contents must conform to the following YANG container definition:
container saved-schema-servers {
ncx:abstract;
description
"Represents all the saved schema-servers in
the ~/.yumapro/yangcli_pro_schema_server file.
Use the 'schema-server' command to access this file.
Edit by hand only if you follow this YANG definition.";
list schema-server-id {
description
"The list of schema-servers to use.";
key name;
leaf name {
type nt:NcxName;
description
"The id of the saved server.";
}
leaf user-id {
type nt:NcxName;
description
"The id of the saved user.";
}
leaf device-id {
type nt:NcxName;
description
"The id of the saved device.";
}
}
}
Schema Server Configuration File Example¶
The following example file shows a valid schema server configuration file:
saved-schema-servers {
schema-server-id 'schema-serverA' {
user-id 'userA'
device-id 'deviceA'
}
schema-server-id 'schema-server-ACER' {
user-id 'user-ACER'
device-id 'device-ACER'
}
schema-server-id 'schema-server-asus2' {
user-id 'asus2'
device-id 'asus2-device'
}
}
NETCONF User Configuration¶
The yangcli-pro program can be configured to associate a name with a set of user parameters to start a NETCONF user with a server. These named users are saved in a configuration file. Use the --autousers parameter to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.
By default, the users configuration is saved in
$HOME/.yumapro/yangcli_pro_users.conf. To override this file, set
--autousers=false and use the users-cfg command to load a
specific users configuration file.
Creating New Users¶
To create a new user, use the user-cfg 'create' command.
> user-cfg create=usr1 user-name=admin password=admin
A new user is created: user-id=usr1 name=admin password=admin
> user-cfg show usr1
User 'usr1':
user: admin
password: admin
connected: false
>
Saving Users¶
To save a user, the text configuration file can be edited or the user-cfg 'save' command can be used.
> connect user=andy server=myserver password=mypassword
... startup screen ...
andy@myserver> user-cfg save user-A
Saved current user as 'user-A'
andy@myserver>
Multiple Users¶
Multiple users can be active at once, however only one command at a time can be sent. This will be improved in a future release. Just use the start-session command to start a different session. Only one instance of each named session with its user can be active at the same time.
Saving the Configured Users¶
The user configuration can be saved or loaded at run-time, even if the --autousers=true parameter is used (the default). The users-cfg command is used to load and save this file.
session-A> users-cfg save
Saved 2 sessions OK to '~/.yumapro/yangcli_pro_users.conf'
session-A>
To save the user to a different file, simply provide the filespec in the 'users-cfg save' command:
session-A> users-cfg save myusers.conf
Saved 2 users OK to '**myusers.conf**'
session-A>
Loading Additional Configured Users¶
Additional users can be added to the configuration in memory with the users-cfg "load" command. The named users in the file cannot conflict with names already in use or the duplicate users will be skipped.
session-A> users-cfg load users.conf
Loaded 3 sessions OK from 'users.conf'
session-A>
Displaying the Configured Users¶
The users that are available can be displayed with the users-cfg 'show' command. The --brief and --full extensions are available for this command.
session-A> users-cfg show
Saved users source: '~/.yumapro/.yangcli_pro_users.conf'
User 'userA':
user: userNameA
password: password A
connected: false
User 'userB':
user: userNameB
password: password B
connected: false
User 'userC':
user: userNameC
password: password C
connected: false
Displaying Users¶
To see information about a specific user, use the user-cfg 'show' command:
> user-cfg show userA
User 'userA':
user: userNameA
password: password A
connected: false
Saved User Configuration File Format¶
The saved sessions are stored in a YumaPro configuration file.
The file contents must conform to the following YANG container definition:
container saved-users {
ncx:abstract;
description
"Represents all the saved users in
the ~/.yumapro/yangcli_pro_users file.
Use the 'users' command to access this file.
Edit by hand only if you follow this YANG definition.";
list userid {
description
"The list of users to use.";
key name;
leaf name {
type nt:NcxName;
description
"The id of the saved user.";
}
leaf user {
type nt:NcxName;
mandatory true;
description
"The user name of the session.";
}
choice pass {
mandatory true;
leaf password {
type string;
ncx:password;
description
"User password to use for NETCONF users.
If none, then user will be prompted before connecting.";
}
leaf no-password { type empty; }
}
uses ywapp:SshKeyParms;
uses ywapp:SslKeyParms;
uses CommentParm;
}
}
User Configuration File Example¶
The following example file shows a valid user configuration file:
saved-users {
userid 'userA' {
user 'userNameA'
password 'passwordA'
public-key '$HOME/.ssh/id_rsa.pub'
private-key '$HOME/.ssh/id_rsa'
ssl-fallback-ok true
ssl-trust-store '$HOME/.ssl/trust-store.pem'
ssl-key '$HOME/.ssl/yangapi-client.key'
ssl-certificate '$HOME/.ssl/yangapi-client.crt'
}
userid 'userB' {
user 'userNameB'
password 'passwordB'
public-key '$HOME/.ssh/id_rsa.pub'
private-key '$HOME/.ssh/id_rsa'
ssl-fallback-ok true
ssl-trust-store '$HOME/.ssl/trust-store.pem'
ssl-key '$HOME/.ssl/yangapi-client.key'
ssl-certificate '$HOME/.ssl/yangapi-client.crt'
}
}
NETCONF Session Configuration¶
The yangcli-pro program can be configured to associate a name with a set of session parameters to start a NETCONF session with a server. These named sessions are saved in a configuration file. Use the --autosessions to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.
By default, the sessions configuration is saved in
$HOME/.yumapro/yangcli_pro_sessions.conf. To override this file, set
--autosessions=false and use the sessions-cfg command to load
a specific sessions configuration file.
The start-session command is used to start a named session:
> start-session session-A
... startup screen ...
session-A>
Saving Sessions¶
To save a session, the text configuration file can be edited or the session-cfg 'save' command can be used.
> connect user=andy server=myserver password=mypassword
... startup screen ...
andy@myserver> session-cfg save session-A
Saved current session as 'session-A'
andy@myserver>
Session use-event-handler¶
The configured event-handler does not actually cause any event scripts to be invoked because there has to be a session-cfg mapping. The session-cfg has parameter ‘use-event-handler’ to do the mapping.
leaf-list use-event-handler {
type nt:NcxIdentifier;
description
"Name of an event-handler to use within this session.
When notification delivery for this session is started
the event handler will be installed. A warning will be
printed if no event-handler with this name is found.";
}
The event-handler has to be mapped to the session-cfg:
session-A> session-cfg use-event-handler=handler-ses-change
session-A> session-cfg use-event-handler=handler-ses-end
session-A> session-cfg use-event-handler=handler-ses-start
session-A>
session-A> sessions-cfg full
Saved sessions source: '~/.yumapro/.yangcli_pro_sessions.conf'
Session 'session-A':
user: username
password: password:
server: 192.168.0.11
connected: true
port: 830
protocols: netconf1.1
public-key: $HOME/.ssh/id_rsa.pub
private-key: $HOME/.ssh/id_rsa
ssl-fallback-ok: true
ssl-certificate:
ssl-key:
ssl-trust-store:
transport: netconf-ssh
Event Handler 'handler-ses-change'
module-name=ietf-netconf-notifications
event-name=netconf-config-change
shell-script=ses-change.sh
Event Handler 'handler-ses-start'
module-name=ietf-netconf-notifications
event-name=netconf-session-start
shell-script=ses-start.sh
Event Handler 'handler-ses-end'
module-name=ietf-netconf-notifications
event-name=netconf-session-end
shell-script=ses-end.sh
Multiple Sessions¶
Multiple sessions can be active at once, however only one command at a time can be sent. This will be improved in a future release. Just use the start-session command to start a different session. Only one instance of each named session can be active at the same time.
> start-session session-A
... startup screen ...
session-A> start-session session-B
... startup screen ...
session-B>
Note that when a session is started, the active session is set to that session.
Changing the Active Session¶
To change the active session and issue commands to a different server, use the session 'set-current' command. This command will cause all subsequent remote commands to be sent to the server associated with the named session.
session-A> session set-current session-B
session-B>
Since the “set-current” parameter is the default parameter, this command can be simplified:
session-A> session session-B
session-B>
To switch to the default session, use the session name “default”. If the default session is connected, then the user and host name will be shown. If not, a simple '>' prompt will be shown instead.
session-A> session default
andy@myserver>
Saving the Configured Sessions¶
The session configuration can be saved or loaded at run-time, even if the --autosessions=true parameter is used (the default). The sessions-cfg command is used to load and save this file.
session-A> sessions-cfg save
Saved 2 sessions OK to '~/.yumapro/yangcli_pro_sessions.conf'
session-A>
To save the sessions to a different file, simply provide the filespec in the sessions-cfg 'save' command:
session-A> sessions-cfg save mysessions.conf
Saved 2 sessions OK to 'mysessions.conf'
session-A>
Loading Additional Configured Sessions¶
Additional sessions can be added to the configuration in memory with the sessions-cfg 'load' command. The named sessions in the file cannot conflict with names already in use or the duplicate session will be skipped.
session-A> sessions-cfg load sessions.conf
Loaded 3 sessions OK from 'sessions.conf'
session-A>
Displaying the Configured Sessions¶
The sessions that are available can be displayed with the sessions-cfg 'show' command. The --brief and --full extensions are available for this command.
session-A> sessions-cfg show
Saved sessions source: 'mysessions.conf'
Session 'session-A':
user: andy
server: localhost
connected: true
Session 'session-B':
user: andy
server: eval.yumaworks.com
connected: false
Displaying Sessions¶
Displaying the Active Session
To see information about the active session, use the session-cfg command:
session-A> session-cfg
Session 'session-A':
user: andy
server: localhost
connected: true
Session 'session-B':
user: andy
server: eval.yumaworks.com
connected: false
Displaying a Specific Session
To see information about a specific session, use the session-cfg 'show' command:
session-A> session-cfg show session-B
Session 'session-B':
user: andy
server: eval.yumaworks.com
connected: false
session-A>
Terminating a Named Session¶
The stop-session command is used to terminate a specific session. The <close-session> operation will be sent on the specified session and the connection gracefully terminated.
session-A> stop-session session-B
session-A>
The active session can also be terminated although no new session will be selected automatically:
session-A> stop-session session-A
>
Saved Session Configuration File Format¶
The saved sessions are stored in a YumaPro configuration file.
The file contents must conform to the following YANG container definition:
container saved-sessions {
ncx:abstract;
description
"Represents all the saved sessions in
the ~/.yumapro/yangcli_pro_sessions file.
Use the 'sessions' command to access this file.
Edit by hand only if you follow this YANG definition.";
list session {
description
"The list of sessions to use during this test-suite.";
key name;
leaf name {
type nt:NcxName;
description
"The name of the saved session.
The 'session save' command will use the
string <user>@<server-address> as the default.";
}
leaf-list use-event-handler {
type nt:NcxIdentifier;
description
"Name of an event-handler to use within this session.
When notification delivery for this session is started
the event handler will be installed. A warning will be
printed if no event-handler with this name is found.";
}
leaf device {
type nt:NcxDeviceName;
mandatory true;
description
"Device name of the NETCONF server target.";
}
leaf userid {
type nt:NcxName;
mandatory true;
description
"User Id of the NETCONF user.";
}
leaf user {
type nt:NcxName;
mandatory true;
description
"The user name of the session.";
}
choice pass {
mandatory true;
leaf password {
type string;
ncx:password;
description
"User password to use for NETCONF sessions.
If none, then user will be prompted before connecting.";
}
leaf no-password { type empty; }
}
uses ywapp:SshKeyParms;
uses ywapp:SslKeyParms;
leaf server {
type inet:host;
mandatory true;
description
"IP address or DNS name of the NETCONF server target.";
}
leaf ncport {
type uint16 {
range "1..max";
}
default 830;
description
"NETCONF port number to use. If not present, then
port 830, followed by port 22, will be tried.";
}
uses EntryPointParm;
uses ncxapp:ProtocolsParm;
leaf transport {
description
"Identifies the transport protocol that should be used.";
type ywt:transport-type;
default ssh;
}
container start-commands {
ywx:cli-text-block;
description
"An optional block of yangcli commands to run
after the session is successfully started.";
}
uses VarsContainer;
uses CommentParm;
}
Session Configuration File Example¶
The following example file shows a valid session configuration file:
saved-sessions {
session session-A {
user andy
password mypassword
public-key $HOME/.ssh/id_rsa.pub
private-key $HOME/.ssh/id_rsa
server localhost
ncport 830
protocols "netconf1.0 netconf1.1"
}
session session-B {
user andy
password mypassword
public-key $HOME/.ssh/id_rsa.pub
private-key $HOME/.ssh/id_rsa
server localhost
ncport 830
protocols "netconf1.0 netconf1.1"
}
session A {
user andy2
password newpassword
public-key $HOME/.ssh/id_rsa.pub
private-key $HOME/.ssh/id_rsa
server localhost
ncport 830
protocols "netconf1.0 netconf1.1"
}
}
Event Handlers Configuration¶
The yangcli-pro program can access an event handler mapping configuration. An event-handler is a mapping between notification (or set of notifications) and an event handler script. A session-cfg can specify event-handlers to install when the session starts. The event-handler command can also be run in session mode to apply to the current session. These named event handler mapping configuration are saved in a configuration file. Use the --autoeventhandlers to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.
By default, the event handlers configuration is saved in
$HOME/.yumapro/yangcli_pro_event_handlers.conf. To override this file,
set --autoeventhandlers=false and use the event-handler-cfg command to
load a specific event-handlers configuration file.
Creating New Event Handlers¶
Use event-handler-cfg 'create' command to create a new event handler. The created event handler does not actually cause any event scripts to be invoked because there has to be a session-cfg mapping. The session-cfg command has a parameter ‘use-event-handler’.
> event-handler-cfg ?
brief Show brief help text
create An event-handler name to use to create a new event handler.
delete Delete the specified event-handler from the saved event hand...
event-name The event name for the event handler.
full Show full help text
module-name The module name for the event handler.
normal Show normal help text
save Save the specified event handler to the saved event handlers...
script The yangcli script name to use for the event handler.
shell-script The shell script name to use for the event handler.
show Show the specified event-handler or the current event-handle…
> event-handler-cfg create=handler-ses-change module-name=ietf-netconf-notifications event-name=netconf-config-change shell-script=ses-change.sh.
A new event_handler is created: event_handler-id=handler-ses-change
Event Handler 'handler-ses-change'
module-name=ietf-netconf-notifications
event-name=netconf-config-change
shell-script=ses-change.sh
> event-handler-cfg show=handler-ses-change
Event Handler 'handler-ses-change'
module-name=ietf-netconf-notifications
event-name=netconf-config-change
shell-script=ses-change.sh
> event-handler-cfg delete=handler-ses-change
Deleted saved event_handler 'handler-ses-change'
>
Multiple Event Handlers¶
Multiple event handlers can be active at once, however only one event script at a time can be invoked. This will be improved in a future release.
Saving the Configured Event Handlers¶
The event handlers configuration can be saved or loaded at run-time, if the --autoeventhandlers=true parameter is used (the default). The event-handlers-cfg save command is used to save this file.
> event-handlers-cfg save
Saved 3 event_handlers OK to '~/.yumapro/.yangcli_pro_event_handlers.conf'
>
To save the event handlers to a different file, simply provide the filespec in the 'event-handler-cfg save' command:
> event-handlers-cfg save myeventhandlers.conf
Saved 2 eventhandlers OK to 'myeventhandlers.conf'
>
Loading Additional Configured Event Handlers¶
Additional event handlers can be added to the configuration in memory with the 'event-handlers-cfg load' command. The named event handlers in the file cannot conflict with names already in use or the duplicate event handlers will be skipped.
session-A> event-handlers-cfg load myeventhandlers.conf
Loaded saved event_handlers OK from 'myeventhandlers.conf'
session-A>
Displaying the Configured Event Handlers¶
The event-handlers that are available can be displayed with the event-handlers-cfg 'show' command. The --brief and --full extensions are available for this command.
> event-handlers-cfg show
Saved event_handlers source: '~/.yumapro/.yangcli_pro_event_handlers.conf'
Event Handler 'handler-ses-change'
module-name=ietf-netconf-notification
event-name=netconf-config-change
shell-script=ses-change.sh
Event Handler 'handler-ses-start'
module-name=ietf-netconf-notification
event-name=netconf-config-start
shell-script=ses-start.sh
Event Handler 'handler-ses-end'
module-name=ietf-netconf-notification
event-name=netconf-config-end
shell-script=ses-end.sh
Event Handlers Variables¶
The event handler is passed 8 variables in the dollar parameters for the script
Parameter |
Description |
Example |
|---|---|---|
$0 |
script name |
|
$1 |
handler name being invoked |
|
$2 |
module name of the event |
|
$3 |
Event name |
|
$4 |
eventTime field from the notification |
|
$5 |
XML file of the <notification> element |
|
$6 |
session-name that received the event |
|
$7 |
IP address of the server that sent the event |
|
The raw event filespec to XML file that contains the complete <notification> element for this event. This file will be deleted after the script is invoked.
Example XML File:
<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2021-08-29T22:57:43Z</eventTime>
<netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
<changed-by>
<username>andy</username>
<session-id>3</session-id>
<source-host>127.0.0.1</source-host>
</changed-by>
<datastore>running</datastore>
<edit>
<target xmlns:nacm="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">/nacm:nacm</target>
<operation>create</operation>
</edit>
</netconf-config-change>
</notification>
NETCONF Group Configuration¶
The yangcli-pro program can be configured to manage the session groups. It associates a group name with a set of sessions to start NETCONF sessions with servers.
A group name is not allowed to have the same name as any session name. This allows the 'session set-current' command to select a group or an individual session.
The named groups and their sessions are saved in a configuration file. Use the --autosessions parameter to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.
By default, the group configuration is saved in
$HOME/.yumapro/yangcli_pro_sessions.conf. To override this file, set
--autosessions=false and use the sessions-cfg command to load
a specific sessions configuration file.
Create group¶
The group command is used to create a group. The 'session' parameter must also be present.
Example of 'group create':
> group create=AB session=session-A session=session-B
> group create=a1a2a3 session=a1 session=a2 session=a3
List group¶
The group 'list' command is used to list the names of all the groups.
> group list
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 2
Session 'session-A' connected:false
Session 'session-B' connected:false
Group 'a1a2a3'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 3
Session 'a1' connected:false
Session 'a2' connected:false
Session 'a3' connected:false
>
Delete group¶
The group 'delete' command is used to delete a group.
> group delete=AB
> group delete=a1a2a3
> group list
No groups found
>
Add group¶
The group 'add' command is used to add sessions to a named group. The 'session' parameter must also be present.
> group add=AB session=session-B
> group list
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 2
Session 'session-A' connected:false
Session 'session-B' connected:false
Remove Group¶
The group 'remove' command is used to remove the sessions from a name group. The 'session' parameter must also be present.
> group remove=AB session=session-A
> group list
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 1
Session 'session-B' connected:false
Show Group¶
The group 'show' command is used to show the name of the group to show.
Example of 'group show':
> group show=AB
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 1
Session 'session-B' connected:false
>
Connect Group¶
The group 'connect' command is used to start a named group with session group parameters: lost-ok, missing-connect-ok, missing-ok, reconnect-interval, and reconnect-tries.
The default parameters value are false.
> group connect=AB
yangcli-pro: Starting NETCONF session for andy on localhost over ssh on port 830
NETCONF session established for xxxxx on localhost
... startup screen ...
AB>
Client Session Id: 1
Server Session Id: 1
---------
---------
---------
NETCONF session established for xxxxx on localhost
... startup screen ...
AB>
Client Session Id: 2
Server Session Id: 2
---------
---------
---------
AB> group list
Group 'AB'
This group is fully connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 2
number_of_sessions: 2
Session 'session-A' connected:true
Session 'session-B' connected:true
Help Group¶
Use command of help 'group' to print all the group help text.
> help group
group
Manage the yangcli-pro session groups.
A group name is not allowed to have the same name as any
...
input
default parameter: session
choice groupcmd <Mandatory>
case connect
leaf connect [NcxIdentifier]
Connect to all sessions in the specified group.
leaf missing-ok [boolean] [d:false]
If truew, then it is OK to manage this group if 1 or
more sessions identified in...
leaf missing-connect-ok [boolean] [d:false]
If true, then it is OK to manage this group if 1 or
more sessions identified in ...
leaf lost-ok [boolean] [d:false]
If true, then it is OK to manage this group if 1 or
more sessions are lost after...
leaf reconnect-tries [uint32] [d:5]
Indicates the number of times yangcli will attempt
to reconnect to a session if ...
leaf reconnect-interval [uint32] [d:10]
Indicates the number of seconds yangcli will wait to
re-establish a connection i...
leaf create [NcxIdentifier]
Name of the group to create. The 'session' parameter
must also be present
leaf delete [NcxIdentifier]
Name of the group to delete
leaf add [NcxIdentifier]
Name of the group to add some sessions. The 'session'
parameter must also be presen...
leaf remove [NcxIdentifier]
Name of the group to remove some sessions. The
'session' parameter must also be pres...
leaf show [NcxIdentifier]
Name of the group to show
leaf list [empty]
List the names of all the groups saved-sessions {
leaf-list session [NcxIdentifier] <Mandatory>
Name of a session that is being added to the group.
>
Saving Groups¶
To save a group, the text configuration file can be edited or the sessions-cfg 'save' command can be used. The session configuration can be saved or loaded at run-time, even if the --autosessions=true parameter is used (the default). The sessions-cfg command is used to load and save this file.
AB> sessions-cfg save
session 'session-A' {
user 'andy'
password 'xxxxx'
public-key '$HOME/.ssh/id_rsa.pub'
private-key '$HOME/.ssh/id_rsa'
server 'localhost'
ncport 830
protocols "netconf1.0 netconf1.1"
}
session 'session-B' {
user 'andy'
password 'xxxxx'
public-key '$HOME/.ssh/id_rsa.pub'
private-key '$HOME/.ssh/id_rsa'
server 'localhost'
ncport 830
protocols "netconf1.0 netconf1.1"
}
group 'AB' {
missing-connect-ok false
missing-ok false
lost-ok false
reconnect-interval 30
reconnect-tries 5
session 'session-A'
session 'session-B'
}
}
Changing the Active Group¶
To change the active group and issue commands to a different server, use the session 'set-current' command. This command will cause all subsequent remote commands to be sent to the servers associated with the named group.
a1a2a3> session set-current AB
Group 'AB' is now active
AB>
Using NETCONF Sessions¶
The yangcli-pro program can be connected to up to 1000 NETCONF servers at a time.
Use the connect or start-session command to start a NETCONF session.
By default, a NETCONF over SSH session will be started.
Use the parameter 'transport=tls' in the connect command to start a NETCONF over TLS session.
When a NETCONF session starts up, a <capability> exchange is done, and the server reports exactly what content it supports. This information is used extensively to customize the session, and report errors and warnings for the session.
Connection Startup Screen¶
If the --log-level is set to 'info' or higher, then a startup screen will be displayed when a NETCONF session is started. It contains:
NETCONF session established for user on localhost
Client Session Id: 1
Server Session Id: 1
Server Protocol Capabilities
base:1.0
candidate:1.0
confirmed-commit:1.0
rollback-on-error:1.0
validate:1.0
url:1.0
xpath:1.0
notification:1.0
interleave:1.0
partial-lock:1.0
with-defaults:1.0
base:1.1
validate:1.1
confirmed-commit:1.1
yang-library:1.0
Server Module Capabilities
ietf-netconf@2011-06-01
ietf-inet-types@2013-07-15
ietf-netconf-acm@2012-02-22
ietf-netconf-monitoring@2010-10-04
ietf-netconf-notifications@2012-02-06
ietf-netconf-partial-lock@2009-10-19
ietf-netconf-with-defaults@2011-06-01
ietf-yang-library@2016-06-21
ietf-yang-types@2013-07-15
nc-notifications@2008-07-14
notifications@2013-03-15
yang-attributes@2013-02-18
yuma-app-common@2012-08-16
yuma-arp@2012-01-13
yuma-interfaces@2012-01-13
yuma-mysession@2013-10-05
yuma-ncx@2013-09-23
yuma-proc@2013-07-16
yuma-system@2013-07-15
yuma-time-filter@2012-11-15
yuma-types@2012-06-01
yumaworks-event-filter@2014-02-09
yumaworks-extensions@2014-06-05
yumaworks-ids@2014-07-12
yumaworks-sil-sa@2014-05-15
yumaworks-system@2014-05-27
yumaworks-types@2013-02-11
yumaworks-ycontrol@2014-04-08
Server Enterprise Capabilities
urn:yumaworks:params:xml:ns:netconf:config-id?id=7865
Protocol version set to: RFC 6241 (base:1.1)
Default target set to: <candidate>
Save operation mapped to: commit
Default with-defaults behavior: explicit
Additional with-defaults behavior: trim,report-all,report-all-tagged
Yang-Library set to: RFC 7895
module-set-id: 6765
Server Tailored Context¶
While a NETCONF session is active, the set of available YANG modules will be set to the modules that the server is using, if the --autoload configuration parameter is enabled.
If the schema-retrieval capability is also available on the server, then the <get-schema> operation will be attempted for any YANG module specified in the <hello> message capabilities, but not available to the yangcli-pro program.
When the server module capabilities are analyzed by the yangcli-pro client, the entire YANG module search path is checked for the specific module advertised in the capability. All the modules are partially parsed to check the actual namespace and revision date values. The following fields must exactly match in order for yangcli-pro to use a local YANG module, if --autoload=true.
module name
module revision date (if any)
module namespace
If the namespace URI value is different, it indicates that there is either a bug in one of the conflicting YANG modules, or that two different naming authorities picked the same module name. In this case, a warning will be generated during session initialization.
Any data returned from the server for YANG modules not currently available will be treated as a YANG 'anyxml' node, instead of the (unknown) YANG data type.
If the module contains YANG features that are not advertised in the <capabilities> exchange, then those data definitions will not be available (by default) for use in yangcli-pro commands.
If the module contains an object with a 'when' statement, and the 'when' XPath expression evaluates to 'false', then that data definition will not be available (by default) for use in yangcli-pro commands.
The help command will be tailored to the modules, capabilities, features, and module deviations reported by the server in <capability> exchange.
If --autoload-get is true, the <sget /netconf-state/schemas> operation will retrieve the /netconf-state/schemas sub-tree and the YANG sub-modules not known to yangcli-pro will be loaded correctly. If --autoload-get is false, then just the <hello> message module list will be used to retrieve YANG modules.
If --autoload-cache is true:
the YANG modules that are retrieved with the
sget /netconf-state/schemasoperation results will be cached. module can be used by yangcli-pro.the modules held in the YANG module cache are normally saved when yangcli-pro exits. If --autoload-save-cache is false, then the YANG modules that are cached will be not saved when yangcli-pro exits.
Retrieving Data¶
There are 8 commands available to retrieve generic data (i.e., an arbitrary subset of an entire NETCONF database):
Command |
Description |
|---|---|
raw NETCONF <get> operation |
|
raw NETCONF <get-config> operation |
|
raw NETCONF <get-data> operation |
|
high-level subtree filter, using the <get> protocol operation |
|
high-level subtree filter, using the <get-config> protocol operation |
|
high-level subtree filter, using the <get-data> protocol operation |
|
high-level XPath filter, using the <get> protocol operation |
|
high-level XPath filter, using the <get-config> protocol operation |
|
high-level XPath filter, using the <get-data> protocol operation |
All the high-level retrieval operations support the $$with-defaults system variable. The <with-defaults> parameter will be added the the NETCONF PDU if this variable is set to a value other than 'none' (the default). This system variable will be used as the default if not entered directly.
session1> sget /system --with-defaults=$$with-defaults
This parameter can also be specified directly, each time the command is used.
session1> xget-config //ifMtu --with-defaults=trim
The $$bad-data system variable is used to control how invalid operations and data are sent to the server. The xget, xget-data, and xget-config commands are affected by this parameter.
If the :xpath capability was not advertised by the server when the session started, an error or warning may occur if these commands are used.
If any data is received that yangcli-pro does not understand, then a warning message will be printed and the data will be treated as if it was defined with the YANG 'anydata' node types.
Modifying Data¶
The following commands are available to modify generic data (i.e., an arbitrary subset of an entire NETCONF database):
Command |
Description |
|---|---|
raw NETCONF <commit> operation |
|
high-level <edit-config> operation, with nc:operation='create' |
|
high-level <edit-config> operation, with nc:operation='delete' |
|
raw NETCONF <delete-config> operation |
|
raw NETCONF <discard-changes> operation |
|
raw NETCONF <edit-config> operation |
|
fill a variable for re-use in other operations |
|
high-level <edit-config> operation, with YANG insert operation extensions |
|
lock a NETCONF database |
|
high-level <edit-config> operation, with nc:operation='merge' |
|
high-level <edit-config> operation, with nc:operation='replace' |
|
High level save operation, depending on the default target (candidate or running) |
|
unlock a NETCONF database |
All the high-level editing operations use the --target parameter reported by the server when the session started up. If the server did not report the :candidate or :writable-running capabilities, then there will be no writable target, and an error will occur if these commands are entered.
All the high-level editing operations support the $$default-operation system variable. The <default-operation> parameter will be added the the NETCONF <edit-config> PDU if this variable is set to a value other than 'not-used'. The default is the enumeration 'none', which means do not use any default operation, and only use the explicit 'nc:operation' attribute.
All the high-level editing operations support the $$test-option system variable. The <test-option> parameter will be added the the NETCONF <edit-config> PDU if this variable is set to a value other than 'none' (the default). This system variable will be used as the default if not entered directly.
session1> replace /interfaces/interface[name='eth0']/ifMtu --test-option=$$test-option --value=$newvalue
This parameter can also be specified directly, each time the command is used.
session1> $newvalue = 1518
session1> replace /interfaces/interface[name='eth0']/ifMtu --test-option=test-only --value=$newvalue
All the high-level retrieval operations support the $$error-option system variable. The <error-option> parameter will be added the the NETCONF <edit-config> PDU if this variable is set to a value other than 'none' (the default). This system variable will be used as the default if not entered directly.
session1> replace /interfaces/interface[name='eth0']/ifMtu --error-option=$$error-option --value=1518
This parameter can also be specified directly, each time the command is used.
session1> replace /interfaces/interface[name='eth0']/ifMtu --error-option=rollback-on-error --value=1518
The high level save command is mapped to other commands, depending on the capabilities reported by the server. This command can be used instead of the multiple server variants of an "NV-save" operation.
save command
Capabilities |
Real Command(s) |
|---|---|
<none> |
|
copy-config --source=running --target=startup |
Using Notifications¶
The create-subscription command is used to start receiving notifications.
The netconfd-pro server will include a <sequence-id> element in any notification that is saved in the replay buffer. This unsigned integer can be used to help debug notification filters (i.e., if non-consecutive <sequence-id> values are received, then the notification was filtered, or dropped due to access control policy).
If any replay notifications are desired, then the 'startTime' parameter must be included. At the end of the stored notifications, the server will send the <replayComplete> Event. This notification type is not saved, and will not be found in the server replay buffer, if replay is supported by the server. The netconfd-pro server will not include a <sequence-id> element in this notification type.
If the notification subscription should stop at a certain time, then the 'stopTime' parameter must be included. At the end of the stored notifications, the server will send the <replayComplete> Event, followed by the <notificationComplete> Event. This notification type is not saved, and will not be found in the server replay buffer, if replay is supported by the server. The netconfd-pro server will not include a <sequence-id> element in this notification type.
Notifications are printed to the log, using the current $$display-mode system variable setting, when and if they are received.
Notifications are also logged. Use the eventlog command to access the notifications stored in the event log.
Configuration Parameters That Affect Sessions¶
The --server, --user, and --password configuration parameters can be used to start a NETCONF session automatically at startup time. The connect command will only be attempted at startup time if the --server parameter is present.
If all 3 of these parameters are present at startup time, then no interactive prompting for additional optional parameters will be done. Instead the connect command will be invoked right away.
During normal operation, the --optional configuration parameter, or the $$optional system variable, can be used to control interactive prompting for optional parameters.
The --server parameter is saved in the $$server system variable, which can be overwritten at any time. If set, this will be used as the initial default value for this parameter in the connect command.
The --user parameter is saved in the $$user system variable, which can be overwritten at any time. If set, this will be used as the initial default value for this parameter in the connect command.
The $$with-defaults system variable can be used to set the default value for the 'with-defaults' parameter extension for these NETCONF operations:
The $$error-option system parameter, can be used to set the default value for the 'error-option' parameter for the NETCONF <edit-config> protocol operation. The default is 'none'.
The $$test-option system parameter can be used to set the default value for the 'test-option' parameter for the NETCONF <edit-config> protocol operation. The default is 'none'.
The --bad-data configuration parameter, or the $$bad-data system variable, can be used to control how yangcli-pro handles parameter values that are known to be invalid, or usage of optional protocol operations that the current session does not support.
The default value is 'check'. To use yangcli-pro in a testing mode to send the server incorrect data on purpose, set this parameter to 'warn' or 'ignore'.
Trouble-shooting NETCONF Session Problems¶
If the NETCONF session does not start for any reason, one or more error messages will be printed, and the prompt will indicate 'idle' mode. This section assumes that the server is netconfd-pro, and these debugging steps may not apply to all NETCONF agents.
If the NETCONF session does not start:
make sure the server is reachable
try to 'ping' the server and see if it responds
make sure the SSH server is responding
try to login in to the server using normal SSH login on port 22
make sure a firewall is not blocking TCP port 830
try to connect to the NETCONF server using the --port=22 option
make sure the netconf-subsystem is configured correctly in /etc/ssh/sshd_config there should be the proper configuration commands for NETCONF to work. For example, the netconfd-pro server configuration might look like this:
Port 22 Port 830 Subsystemnetconf/usr/sbin/netconf-subsystem
make sure the netconfd-pro server is running. Use the unix 'ps' command, or check the netconfd-pro log file, to make sure it is running.
ps -alx | grep netconf (look for 1 'netconfd-pro' and N 'netconf-subsystem' -- 1 for each active session)
make sure the user name is correct
This must be a valid user name on the system
make sure the password is correct
This must be the valid password (in /etc/passwd or /etc/shadow) for the specified user name
If the NETCONF session stops responding:
make sure the server is still reachable
try to 'ping' the server and see if it responds
make sure the SSH server is still responding
try to login in to the server using normal SSH login on port 22
If the NETCONF server is not accepting a certain command:
make sure the command (or parameters used in the command) is actually supported by the server.
There may be features, when statements, or deviation statements that indicate the server does not support the command or one or more of its parameters.
make sure that access control configured on the server is not blocking the command. The error-tag should be 'access-denied' in this case.
If the NETCONF server is not returning the expected data in a <get> or <get-config> protocol operation:
Make sure all the parameters are supported by the server
the :xpath capability must be advertised by the server to use the 'select' attribute in the <get> or <get-config> operations
the :with-defaults capability must be advertised by the server to use the <with-defaults> parameter
if using a filter, try to retrieve the data without a filter and see if it is there
make sure that access control configured on the server is not blocking the retrieval. There will not be any error reported in this case. The server will simply skip over any unauthorized data, and leave it out of the <rpc-reply>.
set the logging level to debug2 or higher, and look closely at the PDUs being sent to the server. Set the display mode to a value other than 'plain' to make sure the correct namespaces are being used in the request.
If an <edit-config> operation is failing unexpectedly:
make sure that access control configured on the server is not blocking the request. The error-tag should be 'access-denied' in this case.
make sure an unsupported parameter or parameter value is not used
<test-option> is not supported unless the :validate capability is advertised by the server
<error-option> = 'rollback-on-error' is not supported unless the :rollback-on-error capability is advertised by the server
if the request contains an edit to a nested data structure, make sure the parent data structure(s) are in place as expected. The <default-operation> parameter is set to 'none' in the high level editing operations, so any data 'above' the edited data must already exist.
set the logging level to debug2 or higher, and look closely at the PDUs being sent to the server. Set the display mode to a value other than 'plain' to make sure the correct namespaces are being used in the request.
Automated Testing¶
Automated regression testing is provided using test-suite templates to describe actions and expected responses and results. The test-suite command is used to access this feature.
Tests rely on named sessions in order to send commands from different sessions. Each test step can be directed at a different session. The “locking” example in a later section shows how test step commands can be either expected to succeed (e.g., first session attempts <lock> command) and fail (e.g., second session attempts <lock> but the datastore is already locked).
A test suite that only needs to send commands to the current session does not need to use named sessions. The session connection and shutdown steps do not need to be done in the test-suite.
The start-session command is usually used within the 'setup' section for each session required in all of the tests within the test-suite. The server must already be running.
The 'setup' and 'cleanup' sections defined within a test suite are called 'CLI text blocks'. They use a special configuration file syntax which allows maximum flexibility for the test designer. These sections begin and and with square brackets ('[' and ']') instead of angle brackets ('{' and '}'). There are no leafs within these containers. Instead they contain plain command lines exactly like a script.
Test Templates¶
The test suite file structure is shown below:
test-suite-file: collection of test-suites in a single file. Multiple files can be loaded. If the --autotest CLI parameter is 'true' (default) then yangcli-pro will look for the default test file, called
$HOME/.yumapro/yangcli_pro_tests.conf.test-suite: collection of tests. Each test-suite has an optional 'setup' section which is executed once before the tests are run, and an optional 'cleanup' section that is run after all the tests have run
test: collection of steps to perform a specific test
step: a command to be executed locally or remotely to a specified session. Each step for a remote command can be configured to check the server response received.
YANG File Defining Test Templates¶
module yumaworks-test {
namespace "http://yumaworks.com/ns/yumaworks-test";
prefix "ywtest";
import yuma-types { prefix yt; }
import yumaworks-extensions { prefix ywx; }
organization "YumaWorks, Inc.";
contact
"Support <support@yumaworks.com>";
description
"This module contains data structures representing
replayable test suites for specific use cases and YANG modules
+---------------------+
+-+------------------+ |
| | |
| Test Suite | |
| |--+
+--------------------+
| |
| |
| V
| +---------------------+
| +-+------------------+ |
| | | |
| | Test | |
| | |--+
| +--------------------+
| |
| |
| V
| +---------------------+
| +-+------------------+ |
| | | |
| | Step | |
| | |--+
| +--------------------+
|
V
+---------------------+
+-+------------------+ |
| | |
| Servers | |
| |--+
+--------------------+
|
|
V
+---------------------+
+-+------------------+ |
| | |
| Sessions | |
| |--+
+--------------------+
Copyright (c) 2013 - 2014 YumaWorks, Inc. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the BSD 3-Clause License
http://opensource.org/licenses/BSD-3-Clause";
revision 2013-03-31 {
description
"Rename to yumaworks-test";
}
revision 2013-01-21 {
description
"Initial version";
}
typedef response-type {
type enumeration {
enum none {
description "Local command, no <rpc-reply> expected.";
}
enum ok {
description "Expecting the <ok> reply.";
}
enum data {
description "Expecting a data reply.";
}
enum error {
description "Expecting an rpc-error reply.";
}
}
description
"The type of response expected from the server
for this request.";
}
container test-suites {
list test-suite {
key name;
leaf name {
type yt:NcxName;
description
"The test suite name.";
}
leaf description {
type string;
description "Description of this test suite.";
}
container setup {
ywx:cli-text-block;
description "Test suite setup commands";
}
container cleanup {
ywx:cli-text-block;
description "Test suite cleanup commands";
}
leaf-list run-test {
ordered-by user;
type yt:NcxName;
min-elements 1;
description
"The ordered list of test names to run in this test suite.
At least 1 test must be specified.";
}
list test {
description
"The unit-tests that are configured to be run.
At least 1 test must be configured.";
ordered-by user;
min-elements 1;
key name;
leaf name {
type yt:NcxName;
description "The name of this unit test.";
}
leaf description {
type string;
description "Description of this unit test.";
}
leaf-list must-pass {
type yt:NcxName;
description
"The names of the tests that have already been
run and pased for this test to be attempted,
The test will be skipped if any test in the
must-pass list has been attempted and the
test failed.
If the named test has not been run yet
this test will fail and be skipped. If the named
test was skipped, then it will not cause this test
to be skipped, only if it did not run at all or
if it ran and passed.";
}
list step {
description
"A list of test steps to be done in order.";
ordered-by user;
key name;
leaf name {
type string {
length "1 .. 64";
}
description "The name of this unit test step.";
}
leaf description {
type string;
description "Description of this unit test step.";
}
leaf session-name {
type yt:NcxName;
description
"The name of the session to use.
Empty if the test session should be used";
}
leaf result-type {
type response-type;
description
"The expected response type. If this leaf is
missing then any response type is acceptable.";
}
leaf result-error-tag {
when "../result-type = 'error'";
type string;
description
"The error-tag value expected if the result-type
is 'error'. If not set, then any error-tag
value is acceptable.";
}
leaf result-error-apptag {
when "../result-type = 'error'";
type string;
description
"The error-app-tag value expected if the result-type
is 'error'. If not set, then any error-app-tag
value is acceptable.";
}
leaf-list result-error-info {
when "../result-type = 'error'";
type yt:NcxName;
description
"The error-info element name expected if the result-type
is 'error'.";
}
leaf command {
type string;
mandatory true;
description "The yangcli command line string to use";
}
anyxml rpc-reply-data {
when "../result-type = 'data'";
description
"The contents of <rpc-reply> element that are
expected to be returned in the reply.
This element itself represents <rpc-reply>
and any child nodes are the nodes returned
by the server.";
}
} // list step
} // list test
} // list test-suite
} // container test-suites
}
RPC Reply Testing¶
Each step has a “response-type” field that specifies what kind of RPC reply testing is expected.
none: Do not perform any RPC reply testing, or this step does not send an RPC request to a server
ok: An RPC reply is expected with an <ok> response
data: An RPC reply is expected with some sort of data response. The expected response is stored in an XML file and compared to the actual RPC reply when the step is executed.
Initial files are created automatically during the “record-test” procedure.
The files are stored in the
$HOME/.yumapro/recordtestdirectory.Each filename has the form <suite-name>_<test-name>_<step-number>_record.xml
During the test a temporary file will be created for each data file to save the RPC reply. These files will be deleted when the test suite is completed.
Each file contains a single <rpc-reply> element.
These files can be edited, created, by hand, or even deleted.
Wildcard fields can be used in this file to allow any value to match, removing this node from the comparison test.
error: An RPC reply is expected with an <rpc-error> response
error-tag: The expected error-tag in the <rpc-error> response
error-app-tag: The expected error-app-tag in the <rpc-error> response
result-error-info: A list of names of elements expected in the <error-info> container within the <rpc-error> response
Using Wildcards in Data Response Testing¶
It is possible simply test for a node within the RPC reply instead of comparing its actual value. Some data such as timestamps and counters may change on every retrieval. Such a node can cause the entire step to fail when comparing the <rpc-reply> contents.
The wildcard string is a sequence of 5 characters (underscore, asterisk, asterisk, asterisk, underscore)
_***_
If this string is used as the value for an element, then that node will be skipped in the comparison.
Example Step:
Suite: s1
Test: t1
Step: 2
Command: sget /netconf-state/datastores
File: $HOME/.yumapro/recordtest/s1_t1_2_record.xml
Original Data File Created During record-test:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<datastores>
<datastore>
<name>candidate</name>
<last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">2019-12-05T23:21:27Z</last-modified>
</datastore>
<datastore>
<name>running</name>
<last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">2019-12-05T23:21:27Z</last-modified>
</datastore>
</datastores>
</netconf-state>
</data>
</rpc-reply>
Altered Data File Wild Wildcard Strings:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<datastores>
<datastore>
<name>candidate</name>
<last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">_***_</last-modified>
</datastore>
<datastore>
<name>running</name>
<last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">_***_</last-modified>
</datastore>
</datastores>
</netconf-state>
</data>
</rpc-reply>
Example Test File¶
test-suites {
test-suite first-test {
description "A set of tests to validate NETCONF locking is working
correctly."
setup [
# example variables
$$server ="test1"
$$admin = "andy"
$$user1 = "andy"
$$pass1 = "fredlow"
$$user2 = "andy2"
$$pass2 = "fredlow"
$$testlog = "$HOME/tests/first-test.log"
$$testmod = "test"
# 2 sessions used in this test; server must already be running
start-session session-A
start-session session-B
]
cleanup [
stop-session session-A
stop-session session-B
]
run-test locks
test locks {
description "Use 2 sessions to test global locks on the
candidate and running datastores. Expects the server
to already be started with --module=test
and --access-control=off."
step 1 {
description "session A locks the running config;
needs to lock candidate too, but does not!"
session-name session-A
result-type ok
command "lock target=running"
}
step 2 {
description "session B tries to lock the running config"
session-name session-B
result-type error
result-error-tag lock-denied
result-error-info session-id
command "lock target=running"
}
step 3 {
description "session A tries to write to the target config"
session-name session-A
result-type ok
command "merge /uint8.1 value=10"
}
step 4 {
description "session B tries to write to the target config
candidate is not locked so this should work"
session-name session-B
result-type ok
command "merge /uint8.1 value=12"
}
step 5 {
description "session B tries to commit the candidate to running
running is locked so this should fail"
session-name session-B
result-type error
result-error-tag in-use
command "commit"
}
step 6 {
description "session A tries to lock the candidate config
this should fail since the candidate is dirty"
session-name session-A
result-type error
result-error-tag resource-denied
command "lock target=candidate"
}
step 7 {
description "session B tries to lock the candidate config
this should fail since the candidate is dirty"
session-name session-B
result-type error
result-error-tag resource-denied
command "lock target=candidate"
}
step 8 {
description "session B issues a discard-changes"
session-name session-B
result-type ok
command "discard-changes"
}
step 9 {
description "session A issues a discard-changes"
session-name session-A
result-type ok
command "discard-changes"
}
step 10 {
description "session B locks the candidate config"
session-name session-B
result-type ok
command "lock target=candidate"
}
step 11 {
description "session A tries to lock the candidate config,
which should fail because it is already locked"
session-name session-A
result-type error
result-error-tag lock-denied
result-error-info session-id
command "lock target=candidate"
}
step 12 {
description "session A tries to write to the target config,
which could fail because candidate is locked"
session-name session-A
result-type error
result-error-tag in-use
command "merge /uint8.1 value=10"
}
step 13 {
description "session B tries to write to the target config"
session-name session-B
result-type ok
command "merge /uint8.1 value=12"
}
step 14 {
description "session A tries to commit the candidate to running,
candidate is locked by B so this should fail"
session-name session-A
result-type error
result-error-tag in-use
command "commit"
}
step 15 {
description "session B tries to commit the candidate to running,
running is locked by A so this should fail"
session-name session-B
result-type error
result-error-tag in-use
command "commit"
}
step 16 {
description "session A tries to discard-changes,
candidate is locked by B so this should fail"
session-name session-A
result-type error
result-error-tag in-use
command "discard-changes"
}
step 17 {
description "session A tries to unlock candidate,
candidate is locked by B so this should fail"
session-name session-A
result-type error
result-error-tag in-use
command "unlock target=candidate"
}
step 18 {
description "session B tries to unlock running,
which is locked by A so this should fail"
session-name session-B
result-type error
result-error-tag in-use
command "unlock target=running"
}
step 19 {
description "session B unlocks candidate"
session-name session-B
result-type ok
command "unlock target=candidate"
}
step 20 {
description "session A unlocks candidate"
session-name session-A
result-type ok
command "unlock target=running"
}
step 21 {
description "session A commits nothing due to
discard-changes from B"
session-name session-A
result-type ok
command "commit"
}
}
}
}
Call Home Server¶
The yangcli-pro program supports the IETF NETCONF Call Home feature defined in RFC 8071.
Call Home for NETCONF over SSH Port Assignment:
Service Name: netconf-ch-ssh
Port Number: 4334
Transport Protocol(s): TCP
Description: NETCONF Call Home (SSH)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
Call Home for NETCONF over TLS Port Assignment:
Service Name: netconf-ch-tls
Port Number: 4335
Transport Protocol(s): TCP
Description: NETCONF Call Home (TLS)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
A server implementing Call Home will initiate the TCP connection for a NETCONF session to a pre-configured manager (e.g., yangcli-pro), which will start a normal SSH session for NETCONF, but using the incoming TCP connection instead of creating a new connection.
In Call Home Server mode, yangcli-pro will listen for incoming TCP connections on its Call Home port.
There must be pre-configured user or session entries for yangcli-pro to accept an incoming Call Home session.
Call Home Configuration¶
The following CLI parameters are available to Call Home configuration:
--callhome-address (default 0.0.0.0)
--callhome-enabled (default false)
--callhome-port (default 4334)
--callhome-tls-port (default 4335)
--callhome-user (no default)
This feature has to be enabled by setting --callhome-enabled=true in the configuration or command line.
If the default listen address (all IPv4 addresses) is not desired, then the --callhome-address parameter must be configured.
If the default TCP port number (4334) is not desired for NETCONF over SSH, then the --callhome-port parameter must be set.
If the default TCP port number (4335) is not desired for NETCONF over TLS, then the --callhome-tls-port parameter must be set.
One or more named sessions may be configured to use address-specific session configuration. The “session-cfg save” command can be used to save a current session. This mode requires the client to be able to connect to the desired server.
Zero or more named user entries can be be designated a “callhome-user” entry. The “user-cfg save” command can be used to create a suitable user entry. Then the --callhome-user parameter is set to the user-cfg name. In this mode the client does not need to connect to the desired server first, but the user and credentials need to be pre-configured on the NETCONF server in advance.
The success of a callhome-user entry is tracked for each server address attempting a connection.
If the first callhome-user entry has failed when a server attempts to reconnect, then that entry will be skipped and the next entry will be attempted.
The failed server list cannot be cleared at this time. The program must be restarted to clear the failed server mappings for each callhome-user.
Refer to the --callhome-user CLI parameter section for more details
It is not possible to attempt multiple users or connection attempts on the same TCP connection. This is a security feature built into the transport protocols.
Call Home Accept Session Procedure¶
If --callhome-enabled=true then yangcli-pro will listen for callhome sessions.
When an incoming call home connection is received, yangcli-pro will attempt to start a new NETCONF session in the following manner:
The source IP address is checked against the IP address of any named session configurations. If a match is found, that session will be used. If it is already in use then the incoming session will be rejected.
For yp-client applications, it is possible that a callhome user-select callback has been registered. If so, then the callback will be invoked with the server address. The callback will do 1 of 3 things
Reject the session so it will be dropped without a connection attempt
Return the callhome-user entry to use for a connection attempt
Return no callhome-user so proceed to step 3 as if no callback was invoked
If no matching IP address session entry found, then check if any callhome-user entries are configured. If so, find the first entry that has not failed for this address, then create a temporary session using the user-cfg data and the incoming address information for the server configuration.
If no callhome-user entry is configured then the incoming connection is dropped
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.
..code-block:: bash
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#
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
}
}
}
Customizing the Keyboard¶
The command line editing and history is provided by the libtecla library. This library is configurable.
Editing mode can be changed: (emacs or vi) [default: emacs]
Keyboard character sequence to command bindings
The libtecla configuration file for yangcli-pro and yp-shell
is called $HOME/.teclarc. If this file is found then the
settings will be applied when the program starts.
Any number of key binding lines can be present
in this file.
Changing the Editing Mode¶
Key bindings for the "emacs" or "vi" editor can be selected. The default mode is "emacs". To change the mode to "vi", use the following line in the .teclarc file:
edit-mode vi
Changing Key Bindings¶
The key bindings within an edit mode (emacs or vi) can be changed with the 'bind' command.
Example .teclarc:
bind C-w backward-delete-word
This command would change the function bound to the Control-w key sequence. The default mapping is 'kill-region' and this 'bind' command will change the binding for Control-w to 'backward-delete-word'.
Refer to the tecla documentation for details on all the key bindings available and default key bindings.
The following sections are from the libtecla documentation, and describe the key bindings available, and the default key bindings used in yangcli-pro.
Available Key Bindings¶
user-interrupt - Send a SIGINT signal to the
parent process.
abort - Send a SIGABRT signal to the
parent process.
suspend - Suspend the parent process.
stop-output - Pause terminal output.
start-output - Resume paused terminal output.
literal-next - Arrange for the next character
to be treated as a normal
character. This allows control
characters to be entered.
cursor-right - Move the cursor one character
right.
cursor-left - Move the cursor one character
left.
insert-mode - Toggle between insert mode and
overwrite mode.
beginning-of-line - Move the cursor to the
beginning of the line.
end-of-line - Move the cursor to the end of
the line.
delete-line - Delete the contents of the
current line.
kill-line - Delete everything that follows
the cursor.
backward-kill-line - Delete all characters between
the cursor and the start of the
line.
forward-word - Move to the end of the word
which follows the cursor.
forward-to-word - Move the cursor to the start of
the word that follows the
cursor.
backward-word - Move to the start of the word
which precedes the cursor.
goto-column - Move the cursor to the
1-relative column in the line
specified by any preceding
digit-argument sequences (see
ENTERING REPEAT COUNTS below).
find-parenthesis - If the cursor is currently
over a parenthesis character,
move it to the matching
parenthesis character. If not
over a parenthesis character
move right to the next close
parenthesis.
forward-delete-char - Delete the character under the
cursor.
backward-delete-char - Delete the character which
precedes the cursor.
list-or-eof - This is intended for binding
to ^D. When invoked when the
cursor is within the line it
displays all possible
completions then redisplays
the line unchanged. When
invoked on an empty line, it
signals end-of-input (EOF) to
the caller of gl_get_line().
del-char-or-list-or-eof - This is intended for binding
to ^D. When invoked when the
cursor is within the line it
invokes forward-delete-char.
When invoked at the end of the
line it displays all possible
completions then redisplays
the line unchanged. When
invoked on an empty line, it
signals end-of-input (EOF) to
the caller of gl_get_line().
forward-delete-word - Delete the word which follows
the cursor.
backward-delete-word - Delete the word which precedes
the cursor.
upcase-word - Convert all of the characters
of the word which follows the
cursor, to upper case.
downcase-word - Convert all of the characters
of the word which follows the
cursor, to lower case.
capitalize-word - Capitalize the word which
follows the cursor.
change-case - If the next character is upper
case, toggle it to lower case
and vice versa.
redisplay - Redisplay the line.
clear-screen - Clear the terminal, then
redisplay the current line.
transpose-chars - Swap the character under the
cursor with the character just
before the cursor.
set-mark - Set a mark at the position of
the cursor.
exchange-point-and-mark - Move the cursor to the last
mark that was set, and move
the mark to where the cursor
used to be.
kill-region - Delete the characters that lie
between the last mark that was
set, and the cursor.
copy-region-as-kill - Copy the text between the mark
and the cursor to the cut
buffer, without deleting the
original text.
yank - Insert the text that was last
deleted, just before the
current position of the cursor.
append-yank - Paste the current contents of
the cut buffer, after the
cursor.
up-history - Recall the next oldest line
that was entered. Note that
in vi mode you are left in
command mode.
down-history - Recall the next most recent
line that was entered. If no
history recall session is
currently active, the next
line from a previous recall
session is recalled. Note that
in vi mode you are left in
command mode.
history-search-backward - Recall the next oldest line
who's prefix matches the string
which currently precedes the
cursor (in vi command-mode the
character under the cursor is
also included in the search
string). Note that in vi mode
you are left in command mode.
history-search-forward - Recall the next newest line
who's prefix matches the string
which currently precedes the
cursor (in vi command-mode the
character under the cursor is
also included in the search
string). Note that in vi mode
you are left in command mode.
history-re-search-backward -Recall the next oldest line
who's prefix matches that
established by the last
invocation of either
history-search-forward or
history-search-backward.
history-re-search-forward - Recall the next newest line
who's prefix matches that
established by the last
invocation of either
history-search-forward or
history-search-backward.
complete-word - Attempt to complete the
incomplete word which
precedes the cursor. Unless
the host program has customized
word completion, filename
completion is attempted. In vi
commmand mode the character
under the cursor is also
included in the word being
completed, and you are left in
vi insert mode.
expand-filename - Within the command line, expand
wild cards, tilde expressions
and dollar expressions in the
filename which immediately
precedes the cursor. In vi
commmand mode the character
under the cursor is also
included in the filename being
expanded, and you are left in
vi insert mode.
list-glob - List any filenames which match
the wild-card, tilde and dollar
expressions in the filename
which immediately precedes the
cursor, then redraw the input
line unchanged.
list-history - Display the contents of the
history list for the current
history group. If a repeat
count of > 1 is specified,
only that many of the most
recent lines are displayed.
See the "ENTERING REPEAT
COUNTS" section.
read-from-file - Temporarily switch to reading
input from the file who's
name precedes the cursor.
read-init-files - Re-read teclarc configuration
files.
beginning-of-history - Move to the oldest line in the
history list. Note that in vi
mode you are left in command
mode.
end-of-history - Move to the newest line in the
history list (ie. the current
line). Note that in vi mode
this leaves you in command
mode.
digit-argument - Enter a repeat count for the
next key-binding function.
For details, see the ENTERING
REPEAT COUNTS section.
newline - Terminate and return the
current contents of the
line, after appending a
newline character. The newline
character is normally '\n',
but will be the first
character of the key-sequence
that invoked the newline
action, if this happens to be
a printable character. If the
action was invoked by the
'\n' newline character or the
'\r' carriage return
character, the line is
appended to the history
buffer.
repeat-history - Return the line that is being
edited, then arrange for the
next most recent entry in the
history buffer to be recalled
when Tecla is next called.
Repeatedly invoking this
action causes successive
historical input lines to be
re-executed. Note that this
action is equivalent to the
'Operate' action in ksh.
ring-bell - Ring the terminal bell, unless
the bell has been silenced via
the nobeep configuration
option (see the THE TECLA
CONFIGURATION FILE section).
forward-copy-char - Copy the next character into
the cut buffer (NB. use repeat
counts to copy more than one).
backward-copy-char - Copy the previous character
into the cut buffer.
forward-copy-word - Copy the next word into the cut
buffer.
backward-copy-word - Copy the previous word into the
cut buffer.
forward-find-char - Move the cursor to the next
occurrence of the next
character that you type.
backward-find-char - Move the cursor to the last
occurrence of the next
character that you type.
forward-to-char - Move the cursor to the
character just before the next
occurrence of the next
character that the user types.
backward-to-char - Move the cursor to the
character just after the last
occurrence before the cursor
of the next character that the
user types.
repeat-find-char - Repeat the last
backward-find-char,
forward-find-char,
backward-to-char or
forward-to-char.
invert-refind-char - Repeat the last
backward-find-char,
forward-find-char,
backward-to-char, or
forward-to-char in the
opposite direction.
delete-to-column - Delete the characters from the
cursor up to the column that
is specified by the repeat
count.
delete-to-parenthesis - Delete the characters from the
cursor up to and including
the matching parenthesis, or
next close parenthesis.
forward-delete-find - Delete the characters from the
cursor up to and including the
following occurence of the
next character typed.
backward-delete-find - Delete the characters from the
cursor up to and including the
preceding occurence of the
next character typed.
forward-delete-to - Delete the characters from the
cursor up to, but not
including, the following
occurence of the next
character typed.
backward-delete-to - Delete the characters from the
cursor up to, but not
including, the preceding
occurence of the next
character typed.
delete-refind - Repeat the last *-delete-find
or *-delete-to action.
delete-invert-refind - Repeat the last *-delete-find
or *-delete-to action, in the
opposite direction.
copy-to-column - Copy the characters from the
cursor up to the column that
is specified by the repeat
count, into the cut buffer.
copy-to-parenthesis - Copy the characters from the
cursor up to and including
the matching parenthesis, or
next close parenthesis, into
the cut buffer.
forward-copy-find - Copy the characters from the
cursor up to and including the
following occurence of the
next character typed, into the
cut buffer.
backward-copy-find - Copy the characters from the
cursor up to and including the
preceding occurence of the
next character typed, into the
cut buffer.
forward-copy-to - Copy the characters from the
cursor up to, but not
including, the following
occurence of the next
character typed, into the cut
buffer.
backward-copy-to - Copy the characters from the
cursor up to, but not
including, the preceding
occurence of the next
character typed, into the cut
buffer.
copy-refind - Repeat the last *-copy-find
or *-copy-to action.
copy-invert-refind - Repeat the last *-copy-find
or *-copy-to action, in the
opposite direction.
vi-mode - Switch to vi mode from emacs
mode.
emacs-mode - Switch to emacs mode from vi
mode.
vi-insert - From vi command mode, switch to
insert mode.
vi-overwrite - From vi command mode, switch to
overwrite mode.
vi-insert-at-bol - From vi command mode, move the
cursor to the start of the line
and switch to insert mode.
vi-append-at-eol - From vi command mode, move the
cursor to the end of the line
and switch to append mode.
vi-append - From vi command mode, move the
cursor one position right, and
switch to insert mode.
vi-replace-char - From vi command mode, replace
the character under the cursor
with the the next character
entered.
vi-forward-change-char - From vi command mode, delete
the next character then enter
insert mode.
vi-backward-change-char - From vi command mode, delete
the preceding character then
enter insert mode.
vi-forward-change-word - From vi command mode, delete
the next word then enter
insert mode.
vi-backward-change-word - From vi command mode, delete
the preceding word then
enter insert mode.
vi-change-rest-of-line - From vi command mode, delete
from the cursor to the end of
the line, then enter insert
mode.
vi-change-line - From vi command mode, delete
the current line, then enter
insert mode.
vi-change-to-bol - From vi command mode, delete
all characters between the
cursor and the beginning of
the line, then enter insert
mode.
vi-change-to-column - From vi command mode, delete
the characters from the cursor
up to the column that is
specified by the repeat count,
then enter insert mode.
vi-change-to-parenthesis - Delete the characters from the
cursor up to and including
the matching parenthesis, or
next close parenthesis, then
enter vi insert mode.
vi-forward-change-find - From vi command mode, delete
the characters from the
cursor up to and including the
following occurence of the
next character typed, then
enter insert mode.
vi-backward-change-find - From vi command mode, delete
the characters from the
cursor up to and including the
preceding occurence of the
next character typed, then
enter insert mode.
vi-forward-change-to - From vi command mode, delete
the characters from the
cursor up to, but not
including, the following
occurence of the next
character typed, then enter
insert mode.
vi-backward-change-to - From vi command mode, delete
the characters from the
cursor up to, but not
including, the preceding
occurence of the next
character typed, then enter
insert mode.
vi-change-refind - Repeat the last
vi-*-change-find or
vi-*-change-to action.
vi-change-invert-refind - Repeat the last
vi-*-change-find or
vi-*-change-to action, in the
opposite direction.
vi-undo - In vi mode, undo the last
editing operation.
vi-repeat-change - In vi command mode, repeat the
last command that modified the
line.
Default Key Bindings for Emacs¶
The cursor keys are refered to by name, as follows. This is necessary because different types of terminals generate different key sequences when their cursor keys are pressed.
right -> cursor-right
left -> cursor-left
up -> up-history
down -> down-history
The remaining bindings don't depend on the terminal setttings.
^F -> cursor-right
^B -> cursor-left
M-i -> insert-mode
^A -> beginning-of-line
^E -> end-of-line
^U -> delete-line
^K -> kill-line
M-f -> forward-word
M-b -> backward-word
^D -> del-char-or-list-or-eof
^H -> backward-delete-char
^? -> backward-delete-char
M-d -> forward-delete-word
M-^H -> backward-delete-word
M-^? -> backward-delete-word
M-u -> upcase-word
M-l -> downcase-word
M-c -> capitalize-word
^R -> redisplay
^L -> clear-screen
^T -> transpose-chars
^@ -> set-mark
^X^X -> exchange-point-and-mark
^W -> kill-region
M-w -> copy-region-as-kill
^Y -> yank
^P -> up-history
^N -> down-history
M-p -> history-search-backward
M-n -> history-search-forward
^I -> complete-word
^X* -> expand-filename
^X^F -> read-from-file
^X^R -> read-init-files
^Xg -> list-glob
^Xh -> list-history
M-< -> beginning-of-history
M-> -> end-of-history
\n -> newline
\r -> newline
M-o -> repeat-history
M-^V -> vi-mode
M-0, M-1, ... M-9 -> digit-argument
yangcli-pro Command Reference¶
This section describes all the yangcli-pro local and remote commands built-in when using the netconfd-pro server.
There may be more or less commands available, depending on the YANG modules actually loaded at the time.
The specific NETCONF capabilities needed are listed for each remote command. No capabilities are ever needed for a local command.
It is possible that other servers will support protocol operations that
netconfd-pro does not support. If yangcli-pro has the YANG file
available for the module, then it can be managed with the high level
commands. Low-level commands can still be used with external data (e.g.,
@mydatafile.xml).
Any YANG 'rpc' statement can be used as a remote yangcli-pro command. Refer to the server vendor documentation for details on the protocol operations, database contents, and notification definitions that they support.
action¶
The 'action' command is a high-level operation to invoke a YANG 1.1 action. This is essentially an RPC operation that is specific to a data resource. It is defined within a YANG container or list. It is used to invoke data model specific actions that are unrelated to editing.
A target node must be an action, and then any missing key leafs (if any) within the data structure are filled in. If the specified action node has input parameters, they will be filled in.
A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true' or the –optional parameter is provided.
Refer to the fill command for more details on interactive mode data structure completion.
+---x action
+---w input
+---w (from)
| +--:(varref)
| | +---w varref? string
| +--:(from-cli)
| +---w (target-parm)?
| | +--:(target)
| | | +---w target yang:xpath1.0
| | +--:(urltarget-case)
| | +---w urltarget ywt:UrlPath
| | +---w match-names? ywt:NameMatchMode
| | +---w alt-names? ywt:AltNameMode
| | +---w wildcard-keys? boolean
| +---w optional? empty
| +---w value? <anyxml>
+---w timeout? nt:Timeout
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
5 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the action. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the target of the action. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: mandatory
default: none
This parameter specifies the database target node of the action. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the action. This is an UrlPath string.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
TBD: THIS PARAMETER IS NOT SUPPORTED YET
This parameter specifies the value that should be used for the contents of the input parameters for the action. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false').
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
YANG Module Example:
module act1 {
yang-version 1.1;
namespace "http://netconfcentral.org/ns/act1";
prefix a;
revision "2017-10-14";
container objs {
config false;
list obj {
key "idx";
leaf idx { type int32; }
leaf col1 { type string; }
action draw {
description "Draw this object";
input {
leaf i { type uint32; mandatory true; }
leaf j { type uint32; }
}
}
}
}
}
Invoke “draw” action:
andy@localhost> action /objs/obj[idx="10"]/draw
Filling mandatory action /objs/obj/draw:
Enter uint32 value for leaf <i>
andy@localhost:action> 10
RPC OK Reply 2 for session 3 [default]:
andy@localhost>
XML sent to NETCONF server:
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="2"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<objs xmlns="http://netconfcentral.org/ns/act1">
<obj>
<idx>10</idx>
<draw>
<i>10</i>
</draw>
</obj>
</objs>
</action>
</rpc>
Reference:
RFC 7950, section 7.15
alias¶
The 'alias' command is used to set or display a specific command alias, or display all command aliases if no parameter is given. It is similar to the 'alias' command in unix shells such as 'bash'.
Note: This command can be disabled with the --no-aliases CLI parameter.
There are 3 forms of the alias command:
alias: display all command aliases in memory
alias <name>: display the command alias with the specified name
alias <name>=<value>: set the command alias with the specified name to the string value
Use the unset command to delete an alias.
+---x alias
+---w input
+---w var? string
Command type: |
local |
Default parameter: |
var |
Min parameters: |
0 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
var
type: string
usage: optional
default: none
The 'var' string must contain either a valid alias name or a string setting an alias. There cannot be any whitespace between the '=' and other characters when setting an alias. The alias value must be quoted if it contains whitespace.
A double-quoted string can contain single quotes:
> alias get-eth0=”xget /interfaces/interface[name='eth0']”
A single-quoted string can contain double quotes:
alias get-eth0='xget /interfaces/interface[name=”eth0”]'
An unquoted string can be used if the <value> does not contain any whitespace:
> alias gc=get-config
Positive Response:
If no parameter given:
The current list of command aliases is displayed.
If a <name> parameter given:
The specified alias is displayed.
If a <name>=<value> parameter is given:
'Updated alias foo' if alias foo already exists.
'Added alias foo' if this is a new alias
Negative Response:
If no parameter given:
Not applicable
If a <name> parameter given:
Error: alias 'foo' not found
If a <name>=<value> parameter is given:
Error message printed if value is invalid
Usage:
> alias get-running=”get-config --source=running”
Added alias 'get-running'
>
apply¶
The 'apply' command is available in config mode to apply pending edits to the server configuration.
+---x apply
Command type: |
config mode |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none |
YANG file: |
none |
Command Parameters:
none
Positive Response:
A message indicated action performed will be printed if --log-level is
infoor above.
Negative Response:
An error message will be printed
Usage:
Example with --config-commit-mode=false (default):
server1# nacm groups group mygroup
server1(group)# !us
server1(group)# user-name fred
server1(group)# user-name barney
server1(group)# apply
Applying 1 edit
server1(group)#
Example with --config-commit-mode=true:
server1# nacm groups group mygroup
server1(group)# user-name fred
server1(group)# user-name barney
server1(group)# apply
Applying 1 edit
Warning:edits have been made to candidate, but no commit done.
Use config-commit to commit the current configuration to the running datastore.
server1(group)#
aliases¶
The 'aliases' command is used to load, save, or clear the command aliases, or display all command aliases if no parameter is given.
Note: This command can be disabled with the --no-aliases CLI parameter.
There are 4 forms of the aliases command:
aliases [show]: display all command aliases in memory
aliases clear: clear all command aliases in memory
aliases save [alias-filespec]: save the command aliases in memory in an '.aliases' file.
aliases load [alias-filespec]: load the command aliases from an '.aliases' file into memory.
+---x aliases
+---w input
+---w (alias-action)?
+--:(show)
| +---w show? empty
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
alias-action
type: choice
usage: optional
default: show
clear
Delete all aliases from memory. This will not affect the aliases file until the 'aliases save' command is used, or the program exits and the --autoaliases parameter is set to 'true'.
load [alias-filespec]
Load an aliases file into memory. If the 'alias-filespec' parameter is not given, then the default aliases file (
$HOME/.yumapro/.yangcli_pro_aliases) will be used.
save [alias-filespec]
Save the command aliases into memory to an alias file. If the 'alias-filespec' parameter is not given, then the default aliases file (
$HOME/.yumapro/.yangcli_pro_aliases) will be used.
show
Displays all aliases in memory.
Positive Response:
show:
The current list of command aliases is displayed.
clear, load, save:
A status message is displayed.
Negative Response:
An error message is printed if any error occurs.
Usage:
> aliases save
Saved aliases OK to '~/.yumapro/.yangcli_pro_aliases'
>
auto-test¶
The 'auto-test' command is used to test edit operations and performance on a NETCONF server.
It can be used to generate pseudo-random <edit-config> operations for a specified data node. All configuration descendant nodes will be created. Each time an edit is done the NETCONF “replace” operation is used.
If the :startup capability is not present then the edit will be saved to non-volatile storage by the server after each edit is completed. Otherwise the auto-test command will automatically save all edits at the end of the test.
The 'target' parameter is used to specify the database configuration node to use for the test. This is a schema identifier string. No key value predicates are allowed, just object names.
The 'iterations' parameter specifies how many edits to complete. If the candidate database is the server target, then an edit is an <edit-config> operation, followed by a <commit> operation. If the running database is the server target, then an edit is simply an <edit-config> operation.
If the session-name parameter is present, then that named session will be used, or else the current session will be used. The session must be connected to the server and the session must be active. The user must have read and write access to all the nodes indicated by the target parameter. Access to the <edit-config>, <commit>, and <copy-config> operations is also required.
Note: choice statements are not supported at this time. Only string and numeric simple types are supported at this time.
+---x auto-test
+---w input
+---w target string
+---w session-name? nt:NcxIdentifier
+---w iterations? uint32
Command type: |
local |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
Command Parameters:
target
type: schema identifier string
usage: mandatory
default: none
This parameter specifies the data node to test.
session-name
type: identifier string
usage: optional
default: current session
This parameter specifies the session name to use for the test
iterations
type: uint32
usage: optional
default: 1
This parameter specifies the number of edits to perform for the test.
Positive Response:
show:
The current list of command aliases is displayed.
clear, load, save:
A status message is displayed.
Negative Response:
An error message is printed if any error occurs.
Usage:
andy@myserver> auto-test target=/ptest1 iterations=100
[edits done on current session]
andy@myserver>
cache¶
The 'cache' command is used to clear 1 or all entries from the YANG module cache.
There are 3 forms of the cache command:
cache clear: Clear the YANG module cache on disk.
cache delete= module-name Delete the specified module name from the YANG module cache. All revisions will be deleted from the cache.
cache delete= module-name [revision=revision-date] Delete the specified module name and revision date from the YANG module cache.
+---x cache
+---w input
+---w (cache-input)
+--:(clear)
| +---w clear? empty
+--:(delete-cache)
+---w delete nt:NcxIdentifier
+---w revision? nt:Date
Command type: |
local |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
none |
YANG file: |
Command Parameters:
cache-action
type: choice
usage: optional
default: none
clear
Clear the YANG module cache on disk.
delete [name of module]
delete the specified YANG modules from YANG module cache.
revision [revision-date of module]
deletes the specified YANG modules from YANG module cache.
Positive Response:
none. Use 'show cache' to verify the result of the action.
Negative Response:
none. Use 'show cache' to verify the result of the action.
Usage:
Example: show the cache
> show cache
yumaworks-event-filter@2014-02-09
ietf-netconf-notifications@2012-02-06
yuma-ncx@2013-09-23
yuma-types@2012-06-01
yuma-netconf@2013-09-28
t79@2014-06-19
yumaworks-types@2013-02-11
ietf-netconf-partial-lock@2009-10-19
test1a@2011-07-14
ietf-inet-types@2013-07-15
yuma-proc@2013-07-16
yuma-mysession@2013-10-05
test1c@2008-10-12
yumaworks-system@2014-05-27
yang-attributes@2013-02-18
ietf-netconf-with-defaults@2011-06-01
ietf-netconf-monitoring@2010-10-04
yuma-interfaces@2012-01-13
ietf-netconf-acm@2012-02-22
test1@2008-10-12
yuma-system@2013-07-15
ietf-yang-types@2013-07-15
yuma-app-common@2012-08-16
test1b@2008-10-12
test@2009-12-26
yuma-time-filter@2012-11-15
Example: delete all revisions of one module in the cache
andy@myserver> cache delete=test1b
andy@myserver>
andy@myserver> show cache
yumaworks-event-filter@2014-02-09
ietf-netconf-notifications@2012-02-06
yuma-ncx@2013-09-23
yuma-types@2012-06-01
yuma-netconf@2013-09-28
t79@2014-06-19
yumaworks-types@2013-02-11
ietf-netconf-partial-lock@2009-10-19
test1a@2011-07-14
ietf-inet-types@2013-07-15
yuma-proc@2013-07-16
yuma-mysession@2013-10-05
test1c@2008-10-12
yumaworks-system@2014-05-27
yang-attributes@2013-02-18
ietf-netconf-with-defaults@2011-06-01
ietf-netconf-monitoring@2010-10-04
yuma-interfaces@2012-01-13
ietf-netconf-acm@2012-02-22
test1@2008-10-12
yuma-system@2013-07-15
ietf-yang-types@2013-07-15
yuma-app-common@2012-08-16
Example: delete one revision of one module in the cache
andy@myserver> cache delete=test1 revision=2008-10-12
andy@myserver>
andy@myserver> show cache
yumaworks-event-filter@2014-02-09
ietf-netconf-notifications@2012-02-06
yuma-ncx@2013-09-23
yuma-types@2012-06-01
yuma-netconf@2013-09-28
t79@2014-06-19
yumaworks-types@2013-02-11
ietf-netconf-partial-lock@2009-10-19
test1a@2011-07-14
ietf-inet-types@2013-07-15
yuma-proc@2013-07-16
yuma-mysession@2013-10-05
test1c@2008-10-12
yumaworks-system@2014-05-27
yang-attributes@2013-02-18
ietf-netconf-with-defaults@2011-06-01
ietf-netconf-monitoring@2010-10-04
yuma-interfaces@2012-01-13
ietf-netconf-acm@2012-02-22
test@2009-12-26 yuma-arp@2012-01-13
test@2009-9-26
yuma-system@2013-07-15
ietf-yang-types@2013-07-15
yuma-app-common@2012-08-16
yuma-time-filter@2012-11-15
yuma-arp@2012-01-13
ietf-netconf@2011-06-01
nc-notifications@2008-07-14
notifications@2013-03-15
ietf-netconf@2011-06-01
nc-notifications@2008-07-14
notifications@2013-03-15
yuma-time-filter@2012-11-15
yuma-arp@2012-01-13
ietf-netconf@2011-06-01
nc-notifications@2008-07-14
notifications@2013-03-15
ietf-netconf@2011-06-01
nc-notifications@2008-07-14
notifications@2013-03-15
Example: clear the cache
andy@myserver> cache clear
empty cache: ./yumapro/.yangcli
andy@myserver>
Reference:
cancel-commit¶
The 'cancel-commit' command is used to stop a confirmed commit procedure on the server. A commit operation must be done before this command is relevant.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <cancel-commit> operation for parameter details.
Usage:
server1> commit confirmed
RPC OK Reply 3 for session 3 [default]:
server1> cancel-commit
RPC OK Reply 4 for session 3 [default]:
server1>
cancel-subscription¶
The cancel-subscription command is used to stop receiving notifications from the server, from a previous create-subscription command.
The :notification capability must be supported by the server to use this command.
Unless the :interleave capability is also supported by the server, then only the close-session command can be used while notifications are being delivered.
This command is provided by the NETCONF server, not yangcli-pro.
Refer to the <cancel-subscription> operation for parameter details.
Usage:
andy@myserver> cancel-subscription
RPC OK Reply 13 for session 10:
OR
andy@myserver>
Reference:
none
cd¶
The 'cd' command is used to change the current working directory.
+---x cd
+---w input
+---w dir string
Command type: |
local |
Default parameter: |
dir |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
dir
type: string
usage: mandatory
default: none
The 'dir' string must contain a valid directory specification
Positive Response:
the new current working directory is printed
Negative Response:
an error message will be printed describing the error
Usage:
> cd ~/modules
Current working directory is /home/andy/modules
> cd --dir=$YUMAPRO_HOME
Current working directory is /home/andy/swdev/yumapro/trunk/netconf
>
clear¶
The 'clear' command is used to clear the screen and reposition the prompt at the top of the screen.
This command is only applied in interactive mode, and has no affect in batch mode.
+---x clear
Command type: |
local |
Default parameter: |
N/A |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none |
YANG file: |
Command Parameters: none
Positive Response:
the screen is cleared
Negative Response:
no change to screen
Usage:
> clear
After the command the screen is cleared and a new prompt is printed in on the first line.
close-session¶
The 'close-session' command is used to terminate the current NETCONF session. A NETCONF server should always accept this command if it is valid, and not reject it due to access control enforcement or if the server is in notification delivery mode. This command is provided by the NETCONF server, not yangcli-pro.
This is a server command. Refer to the <close-session> operation for parameter details.
Usage:
andy@myserver> close-session
RPC OK Reply 2 for session 10:
>
Reference:
RFC 6241, section 7.8
commit¶
The 'commit' command is used to save the edits in the <candidate> database into the <running> database. If there are no edits it will have no effect.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <commit> operation for parameter details.
Usage:
andy@myserver> commit
RPC OK Reply 5 for session 10:
andy@myserver>
Reference:
RFC 6241, section 8.3
config¶
The 'config' command is used to enter configuration mode. It can only be used if the current session is connected to a NETCONF or RESTCONF server.
The configuration source is given as the only parameter
The value 'terminal' is the only supported configuration source at this time.
The max command line length is 4095 character.
+---x config
+---w input
+---w (config-source)?
+--:(term)
+---w term? empty
Command type: |
local |
Default parameter: |
term |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
none (enter configuration mode) |
YANG file: |
Command Parameters:
term
type: empty
usage: mandatory
default: present
This parameter specifies that the terminal is the configuration source
Positive Response:
the prompt will change indicating configuration mode is active
Negative Response:
An error message will be printed
Usage:
andy@myserver> config term
andy@myserver#
config-commit¶
The 'config-commit' command is used to commit the candidate datastore to the running datastore in config mode.
This command is only used in config mode when --config-commit-mode=true.
+---x config-commit
Command type: |
config |
Default parameter: |
0 |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none |
YANG file: |
none |
Command Parameters:
none.
Positive Response:
No error message.
Negative Response:
An error message will be printed
Usage:
andy@myserver> config term
andy@myserver# config-commit
connect¶
The 'connect' command is used to start a session with a NETCONF server.
This command can be used in 3 forms:
Default session: All required connection parameters are specified and the default session is used. The parameters are only saved as defaults for the next connect command. They are not saved in any template.
Named Session: Only the 'session-name` parameter is used. The specified session-cfg template is used for all connection parameters.
Modified Named Session: The 'session-name' parameter is used and additional parameters are also specified, which will cause the session-cfg template to be updated if the connection is successful.
If there already is a NETCONF session active, then an error message will be printed and the command will not be executed.
+---x connect
+---w input
+---w user nt:NcxUserName
+---w server inet:host
+---w (pass)
| +--:(password)
| | +---w password? string
| +--:(no-password)
| +---w no-password? empty
+---w ncport? uint16
+---w timeout? nt:Timeout
+---w public-key? string
+---w private-key? string
+---w ssl-fallback-ok? boolean
+---w ssl-certificate? string
+---w ssl-key? string
+---w ssl-trust-store? string
+---w protocols? bits
+---w entry-point? string
+---w transport? ywt:transport-type
+---w encoding? ywt:encoding-type
+---w session-name? nt:NcxIdentifier
Command type: |
remote |
Default parameter: |
server |
Min parameters: |
1 |
Max parameters: |
10 |
Return type: |
status |
YANG file: |
Command Parameters:
server
type: inet:ip-address (string containing IP address or DNS name
usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration.
default: previous server used, if any, will be presented as the default, but not used automatically
This parameter specifies the server address for the session.
password
type: string (ncx:password)
usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration, of if no-password parameter is present.
default: previous password used, if any, will be presented as the default, but not used automatically
This parameter specifies the password string to use to establish the session. It will not be echoed in parameter mode or saved in the command history buffer.
no-password
type: empty
usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration, of if password parameter is present.
default:not present
This parameter specifies that there is no password needed for this connection
ncport
type: uint16
usage: optional
default: 830
This parameter specifies the TCP port number that should be used for the session.
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
user
type: string
usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration.
default: previous user name used, if any, will be presented as the default, but not used automatically
This parameter specifies the user name to use for the session. This must be a valid user name on the NETCONF server.
protocols
type: bits (netconf1.0 netconf1.1 yang-api restconf)
usage: optional
default: --protocols configuration parameter setting
Specifies which NETCONF protocol versions to enable. Overrides --protocols configuration parameter.
netconf1.0: request RFC 4741 NETCONFnetconf1.1: request RFC 6241 NETCONFyang-api: request Yuma YANG-API protocolrestconf: request IETF RESTCONF protocol
private-key
type: string
usage: optional
default: --private-key configuration parameter setting
Specifies the SSH private key file to use. Overrides --private-key configuration parameter.
public-key
type: string
usage: optional
default: --public-key configuration parameter setting
Specifies the SSH public key file to use. Overrides the --public-key configuration parameter.
session-name
type: identifier string
usage: optional
default: none
Specifies the named session configuration entry to use for the connection information. Sessions can be saved while active with the 'session-cfg save' command.
If this parameter is used and the named session configuration is found, then that session will be used for connection parameters. Any additional parameters will be used to update the existing named session entry.
If this parameter is used and the named session configuration is not found, then other parameters will be checked, and a connection attempt will be made. If successful, the session parameters will be saved as a new saved session.
transport
type: enumeration (ssh, tcp, tcp-ncx, tls)
usage: optional
default: ssh
This parameter specifies the transport protocol to use.
ssh:Selects the standard NETCONF transport (and 'ncport' specifies the SSH port to use).
tcp:Selects the tail-f NETCONF over TCP protocol.
The 'ncport' value is set to
2023.The 'protocols' value is set to
netconf1.0.The 'password' value will be ignored if present.
A direct TCP connection will be used instead of SSH, using the tail-f structured connection string protocol.
tcp-ncx:Selects the YumaWorks NETCONF over TCP protocol.
The 'ncport' value is set to
2023.The 'protocols' value is set to
netconf1.0.The 'password' value will be ignored if present.
A direct TCP connection will be used instead of SSH, using the YumaWorks <ncx-connect> protocol.
tls:Selects the TLS protocol
entry-point
type: string
usage: RESTCONF entry point. Use this string instead of retrieving the XRD from the RESTCONF server to discover the entry point.
Positive Response:
the session is started and the prompt changes to include the
user@serverstring.
Negative Response:
One or more error messages will be printed. Refer to the section on trouble-shooting NETCONF Session problems for more details.
Usage:
> connect myserver user=andy password=yangrocks
<startup screen printed>
andy@myserver>
copy-config¶
The 'copy-config' command is used to copy one entire NETCONF database to another location.
Not all possible parameter combinations will be supported by every server. In fact, the NETCONF protocol does not require any parameters to be supported unless the :startup or :url capabilities is supported by the server.
If the server supports the :startup capability, then it must support the following operation:
andy@myserver> copy-config source=running target=startup
This is the standard way to save a snapshot of the current running configuration in non-volatile storage, if the server has a separate startup database. If not, the server will automatically save any changes to the running configuration to non-volatile storage.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <copy-config> operation for parameter details.
Usage:
andy@myserver> copy-config source=candidate
Enter a number of the selected case statement:
1: case candidate:
leaf candidate
2: case running:
leaf running
3: case startup:
leaf startup
4: case url:
leaf url
Enter choice number [1 - 4]:
andy@myserver:copy-config> 4
Enter string value for leaf <url>:
andy@myserver:copy-config> file:///myconfig.xml
RPC OK Reply 12 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.3
create¶
The 'create' command is a high-level <edit-config> operation. It is used to create some new nodes in the default target database.
A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'.
Refer to the fill command for more details on interactive mode data structure completion.
+---x create
+---w input
+---w (from)
| +--:(varref)
| | +---w varref? string
| +--:(from-cli)
| +---w (target-parm)?
| | +--:(target)
| | | +---w target yang:xpath1.0
| | +--:(urltarget-case)
| | +---w urltarget ywt:UrlPath
| | +---w match-names? ywt:NameMatchMode
| | +---w alt-names? ywt:AltNameMode
| | +---w wildcard-keys? boolean
| +---w optional? empty
| +---w value? <anyxml>
+---w timeout? nt:Timeout
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
5 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the create operation. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the target of the create operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: mandatory
default: none
This parameter specifies the database target node of the create operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the create operation. This is an UrlPath string.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> create varref=myvar
RPC OK Reply 10 for session 10:
andy@myserver> create /nacm/rules/data-rule
(user will be prompted to fill in the data-rule contents)
RPC OK Reply 11 for session 10:
andy@myserver> create target=/nacm/rules/data-rule[name='test rule']/comment value=”this test rule is temporary. Do not remove!”
(no user prompting; <edit-config> request sent right away)
RPC OK Reply 12 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.2
create-subscription¶
The 'create-subscription' command is used to start receiving notifications from the server.
The :notification capability must be supported by the server to use this command.
Unless the :interleave capability is also supported by the server, then only the close-session command can be used while notifications are being delivered.
This command is provided by the NETCONF server, not yangcli-pro.
Refer to the <create-subscription> operation for parameter details.
Usage:
andy@myserver> create-subscription
RPC OK Reply 13 for session 10:
OR
andy@myserver> create-subscription startTime=2009-01-01T00:00:00Z
RPC OK Reply 14 for session 10:
andy@myserver>
Reference:
RFC 5277, section 2.1.1
device-cfg¶
The 'device-cfg' command is used to access a named device.
There are 3 sub-commands:
delete
save
show (default)
Refer to the section on NETCONF Device Configuration for more details on using saved devices.
+---x device-cfg
+---w input
+---w (device-action)?
+--:(show-case)
| +---w show? IdentifierOrZero
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(delete)
| +---w delete? nt:NcxIdentifier
+--:(save)
| +---w save? nt:NcxIdentifier
+--:(create)
+---w create nt:NcxName
+---w server inet:host
+---w ncport? uint16
+---w entry-point? string
+---w protocols? bits
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
delete
type: name string
This parameter specifies the name of the device to delete from the saved devices in memory. An active device cannot be deleted.
save
type: name string
This parameter specifies the name of the device to save in the saved devices in memory.
show
type: name string; default: empty string == current device
This parameter specifies the name of the device to show. An empty string indicates that the current device should be used.
The --brief, --normal, or --full parameter can be used for this sub-command.
Positive Response:
A message indicating the save or delete was done will be printed. The show command will generate some formatted output showing information on the requested device.
Negative Response:
An error message will be printed if errors are detected locally.
andy@myserver> device-cfg save device-A
Saving current device as 'device-A'
andy@myserver>
devices-cfg¶
The 'devices-cfg' command is used to access the named device files.
There are 4 sub-commands:
clear
load
save
show (default)
Refer to the section on NETCONF Device Configuration for more details on using saved devices.
+---x devices-cfg
+---w input
+---w (devices-action)?
+--:(show-case)
| +---w show? empty
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
clear
type: empty
This parameter indicates that all saved devices in memory be deleted. This cannot be done if any of the devices are currently active. Use 'device-cfg load' to restore the saved devices.
load
type: string
This parameter identifies the file specification for the saved devices to load. Any new named devices will be added to the named devices in memory.
save
type: name string
This parameter identifies the file specification for the saved devices config file to load. The saved devices in memory will be saved to this file.
show
type: name string; default: empty string == all devices
This parameter specifies the name of the device to show.
The --brief, --normal, or --full parameter can be used for this sub-command.
Positive Response:
A message indicating the load, save or clear was done will be printed. The show command will generate some formatted output showing information on the requested devices.
Negative Response:
An error message will be printed if errors are detected locally.
session-A> devices-cfg load ~/more-devices.conf
Loading saved devices from '/home/andy/more-devices.conf'
Loaded saved devices OK from '~/more-devices.conf'
session-A>
delete¶
The 'delete' command is a high-level <edit-config> operation. It is used to delete an existing subtree in the default target database.
A target node is specified, and then any missing key leafs (if any) within the data structure are filled in. If the target is a leaf-list, then the user will be prompted for the value of the leaf-list node to be deleted.
Refer to the fill command for more details on interactive mode data structure completion.
+---x delete
+---w input
+---w (delete-target)
| +--:(target)
| | +---w target? string
| +--:(urltarget)
| +---w urltarget? ywt:UrlPath
+---w value? <anyxml>
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
Command Parameters:
target
type: string
usage: optional (urltarget or target must be present)
default: none
This parameter specifies the database target node of the delete operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the delete operation. This is an UrlPath string.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$optional
Controls whether optional descendant nodes will be filled into the target parameter contents
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> delete /nacm/rules/data-rule
(user will be prompted to fill in the data-rule 'name' key leaf)
RPC OK Reply 15 for session 10:
andy@myserver> delete target=/nacm/rules/data-rule[name='test rule']/comment
(no user prompting; <edit-config> request sent right away)
RPC OK Reply 16 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.2
delete-all¶
The 'delete-all' command is a high-level <edit-config> operation. It is used to delete all instances of a list or leaf-list in the default target database.
This is only supported for the netconfd-pro server.
The --allow-leaflist-delete-all parameter must be set to 'true' to use this operation on a leaf-list.
The --allow-list-delete-all parameter must be set to 'true' to use this operation on a list.
A target node is specified, and then any missing key leafs (if any) within the data structure are filled in. If the target is a leaf-list, then the user will be prompted for the value of the leaf-list node to be deleted.
Refer to the fill command for more details on interactive mode data structure completion.
+---x delete-all
+---w input
+---w (delete-target)
+--:(target)
| +---w target? string
+--:(urltarget)
+---w urltarget? ywt:UrlPath
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
Command Parameters:
target
type: string
usage: optional (urltarget or target must be present)
default: none
This parameter specifies the database target node of the delete operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the delete operation. This is an UrlPath string.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$optional
Controls whether optional descendant nodes will be filled into the target parameter contents
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> delete-all /nacm/rules/data-rule
(user will be prompted to fill in the data-rule 'name' key leaf)
RPC OK Reply 15 for session 10:
andy@myserver>
Reference:
none
delete-config¶
The 'delete-config' command is used to delete an entire NETCONF database.
Not all possible 'target' parameter values will be supported by every server. In fact, the NETCONF protocol does not require that any database be supported by this operation.
If the server supports the :url capability, then it may support deletion of local file databases in this manner.:
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <delete-config> operation for parameter details.
Usage:
andy@myserver> delete-config target=startup
RPC OK Reply 17 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.4
delete-subscription¶
The 'delete-subscription' command is used to terminate
your own notification subscription on the connected NETCONF server.
The netconfd-pro server must have the yang-push bundle enabled
for this operation to be available.
The subscription-id returned in the establish-subscription command must be used as the parameter, since a session can have multiple subscriptions active at once.
The server should also send a <subscription-terminated> Event notification as a result of the operation.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <delete-subscription> operation for parameter details.
Usage:
server1> delete-subscription id=1
Incoming notification for session 2 [default]:
notification {
eventTime 2022-01-13T02:56:35Z
subscription-terminated {
id 1
reason sn:no-such-subscription
}
}
RPC OK Reply 5 for session 3 [default]:
server1>
discard-changes¶
The 'discard-changes' command is used to delete any edits that exist in the <candidate> database, on the NETCONF server. The server will only accept this command if the :candidate capability is supported. If the <candidate> database is locked by another session, then this request will fail with an 'in-use' error.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <discard-changes> operation for parameter details.
Usage:
andy@myserver> discard-changes
RPC OK Reply 18 for session 10:
andy@myserver>
Reference:
RFC 6241, section 8.3.4.2
do¶
The 'do' command is available in config mode to invoke a non-config mode command, such as show.
Only 3 sub-commands are supported:
Command type: |
config mode |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
none |
YANG file: |
none |
Command Parameters:
1 parameter expected, which is start of 1 of the 3 supported commands
Positive Response:
No error message.
Negative Response:
An error message will be printed
Usage:
server1# do show var optional
optional false
server1#
edit-config¶
The 'edit-config' command allows a subset of a NETCONF database on the server to be changed.
If the server supports the :url capability, then it may support editing of local file databases.
If the server supports the :candidate capability, then it will allow edits to the <candidate> database.
If the server supports the :writable-running capability, it will support edits to the <running> database.
It is not likely that a server will support the <candidate> and <running> database as targets at the same time, since changes to the <running> configuration would not be reflected in the <candidate> database, while it was being edited by a different session.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <edit-config> operation for parameter details.
Usage:
andy@myserver> edit-config target=candidate default-operation=merge test-option=test error-option=stop-on-error config=@myconfig.xml
RPC OK Reply 19 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.2
elif¶
The 'elif' command is used to define a conditional command block after an if command.
This command must be entered within the same script as the if command, when used within a script. It can be used zero or more times within an if command sequence.
The 'expr' parameter is used to specify the XPath expression to test if the elif conditional block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.
The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.
Even if the 'expr' expression is true, the conditional block will only be executed if no conditional block in the if command sequence has already been executed.
if command
....
[elif command]
....
[elif-command]
...
[else command]
...
end
The 'elif' command must be paired with a matching end command. It can also be continued with consecutive 'elif' statements.
+---x elif
+---w input
+---w expr yang:xpath1.0
+---w docroot? <anyxml>
Command type: |
local |
Default parameter: |
expr |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
Command Parameters:
expr
type: XPath expression string
usage: mandatory
default: none
This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.
docroot
type: anyxml
usage: optional (typically a variable reference is used)
default: none
This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
elif without a previous if command will cause an error
elif following an 'else' command will cause an error
invalid XPath expression or invalid docroot reference will cause an error
Usage:
andy@myserver> elif expr='$x > 4'
andy@myserver>
else¶
The 'else' command is used to define a final conditional command block after an if command. It must eventually be terminated by a end command.
This command must be entered within the same script as the if command, when used within a script. It can be used zero or one time within an if command sequence.
if command
....
[elif command]
....
[elif-command]
...
[else command]
...
end
The conditional command block following the else command will only be executed if no conditional block has already been executed in the same if command sequence.
+---x else
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
status |
YANG file: |
Command Parameters: none
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
else without a previous if command will cause an error
Usage:
> else
enable¶
The 'enable' command is used to enter enable mode.
This command is available in yp-shell and only if yp-shell
is started with the --with-enable-mode parameter set to true.
+---x enable
+---w input
+---w (pass)?
+--:(password)
| +---w password? string
+--:(no-password)
+---w no-password? empty
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
1 |
Return type: |
none |
YANG file: |
Command Parameters:
password
type: string (ncx:password)
usage: optional
default: none
This parameter specifies the password string to use to enter the enable mode.
no-password
type: empty
usage: optional
default: none
This parameter specifies that there is no password needed to enter the enable mode.
Usage:
server1> enable
server1# enable
enable-password¶
The 'enable-password' command is used to configure the password in config mode for yp-shell.
This command is available in yp-shell and only if yp-shell
is started with the --with-enable-mode parameter set to true.
+---x enable-password
+---w input
+---w password string
Command type: |
config-mode |
Default parameter: |
password |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
none |
YANG file: |
Command Parameters:
password
type: string (ncx:password)
usage: optional
default: none
This parameter specifies the password string to use to enter the enable mode.
Usage:
server1> enable-password my-password
end¶
The 'end' command is used to terminate a conditional command block after an 'if' command block, or after a 'while' command block.
This command must be entered within the same script as the if or while command that started the conditional block.
if command
....
[elif command]
....
[elif-command]
...
[else command]
...
end
while command
...
end command
+---x end
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
status |
YANG file: |
Command Parameters: none
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
else without a previous if command will cause an error
Usage:
> end
>
establish-subscription¶
The 'establish-subscription' command is used to start
a notification subscription on the connected NETCONF server.
The netconfd-pro server must have the yang-push bundle enabled
for this operation to be available.
The server is expected to return the subscription-id if the operation succeeds.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <establish-subscription> operation for parameter details.
Usage:
session1> establish-subscription stream=mystream
RPC Data Reply 1 for session 3 [default]:
rpc-reply {
id 1
}
server1>
eval¶
The 'eval' command is used to evaluate an XPath expression..
The 'expr' parameter is used to specify the XPath expression to evaluate. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.
The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.
+---x eval
+---w input
| +---w expr yang:xpath1.0
| +---w docroot? <anyxml>
+--ro output
+--ro data <anyxml>
Command type: |
local |
Default parameter: |
expr |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
data |
YANG file: |
Command Parameters:
expr
type: XPath expression string
usage: mandatory
default: none
This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.
docroot
type: anyxml
usage: optional (typically a variable reference is used)
default: none
This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
elif without a previous if command will cause an error
elif following an 'else' command will cause an error
invalid XPath expression or invalid docroot reference will cause an error
Output:
data
type: anyxml
This element will contain the result from the XPath expression. A node-set result will produce a complex element return value, and all other XPath result types will produce a string return value.
Usage:
session1> $x = eval '$x + 1'
session1> $sysname = eval '//sysName' docroot=$backup
event-handler-cfg¶
The 'event-handler-cfg' command is used to access a named event-handler.
There are 4 sub-commands:
delete
save
show (default)
create
+---x event-handler-cfg
+---w input
+---w (user-action)?
+--:(show-case)
| +---w show? IdentifierOrZero
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(delete)
| +---w delete? nt:NcxIdentifier
+--:(save)
| +---w save? nt:NcxIdentifier
+--:(create)
+---w create nt:NcxName
+---w module-name? nt:NcxName
+---w event-name? nt:NcxName
+---w (script-type)
+--:(script)
| +---w script? string
+--:(shell-script)
+---w shell-script? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
delete
type: name string
This parameter specifies the name of the event-handler to delete from the saved event-handlers in memory.
save
type: name string
This parameter specifies the name of the event-handler to save in the saved event-handlers in memory.
show
This parameter specifies the name of the event-handler to show.
The --brief, --normal, or --full parameter can be used for this sub-command.
create
type: name string
This parameter specifies a new event-handler to create.
Positive Response:
A message indicating the save or delete was done will be printed. The show command will generate some formatted output showing information on the requested user.
Negative Response:
An error message will be printed if errors are detected locally.
event-handlers-cfg¶
The 'event-handlers-cfg' command is used to access the named event-handlers files.
There are 4 sub-commands:
clear
load
save
show (default)
+---x event-handlers-cfg
+---w input
+---w (event-handlers-action)?
+--:(show-case)
| +---w show? empty
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
clear
type: empty
This parameter indicates that all saved event-handlers in memory be deleted. This cannot be done if any of the event-handlers are currently active. Use 'event-handlers-cfg load' to restore the saved users.
load
type: string
This parameter identifies the file specification for the saved event-handlers to load. Any new named event-handlers will be added to the named users in memory.
save
type: name string
This parameter identifies the file specification for the saved event-handlers config file to load. The saved event-handlers in memory will be saved to this file.
show
type: name string; default: empty string == all devices
eventlog¶
The 'eventlog' command is used to view or clear all or part of the notification event log. This log will be empty if no well-formed notifications have been received from any server.
The 'eventlog show' command is used to display some event log entries.
The 'eventlog clear' command is used to delete some event log entries.
If no parameters are entered, it is the same as entering eventlog show=-1.
The event log is not automatically emptied when a session terminates, in case the session was dropped unexpectedly. New entries will be appended to the event log as new sessions and/or subscriptions are started.
+---x eventlog
+---w input
+---w (eventlog-action)?
+--:(show-case)
| +---w show? LogCount
| +---w start? LogIndex
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(clear)
+---w clear? LogCount
Command type: |
local |
Default parameter: |
show |
Min parameters: |
0 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
Command Parameters:
choice eventlog-action (not entered):
type: choice of case 'show-case' or leaf 'clear'
usage: optional
default: show=-1 is used as the default if nothing entered
This parameter specifies the event log action that should be performed.
clear
type: int32 (-1 to clear all entries; 1 to max to delete N entries)
usage: optional
default: -1
This parameter specifies the maximum number of event log entries to be deleted, starting from the oldest entries in the event log. The value -1 means delete all the entries. Otherwise the value must be greater than zero, and up to that many entries will be deleted.
case show-case (not entered)
choice help-mode (not entered) (default choice is 'normal')
brief
type: empty
usage: optional
default: none
This parameter specifies that brief documentation mode should be used. The event log index, sequence ID, and <eventType> will be displayed in this mode.
normal
type: empty
usage: optional
default: none
This parameter specifies that normal documentation mode should be used. The event log index, <eventTime>, sequence ID, and <eventType> will be displayed in this mode.
full
type: empty
usage: optional
default: none
This parameter specifies that full documentation mode should be used. The event log index, <eventTime>, sequence ID, and <eventType> will be displayed in this mode. In addition, the entire contents of the notification PDU will be displayed, using the current $$display-mode setting.
show
type: int32 (-1 for all, 1 to max for N entries)
usage: optional
default: -1
This parameter specifies the number of event log entries that should be displayed. The value '-1' indicates all the entries should be displayed. Otherwise, the value must be greater than zero, indicating the number of entries to display.
start
type: uint32
usage: optional
default: 0
This parameter specifies the start position in the event log to start displaying entries. The first entry is number zero. Each time the event log is cleared, the numbering restarts.
System Variables:
$$display-mode
The log entries printed when help-mode='full' are formatted according to the current value of this system variable.
Positive Response:
the event log entries are printed or cleared as requested
Negative Response:
An error message will be printed if errors are detected.
Usage:
> eventlog show=5 start=3
[3] [2009-07-10T02:21:10Z] (4) <sysSessionStart>
[4] [2009-07-10T02:23:14Z] (5) <sysSessionEnd>
[5] [2009-07-10T02:23:23Z] (6) <sysSessionStart>
[6] [2009-07-10T02:24:52Z] (7) <sysConfigChange>
[7] [2009-07-10T02:24:57Z] (8) <sysSessionEnd>
>
exit¶
The 'exit' command is used to exit configuration editing mode or exit the current editing sub-mode if the configuration context node is not the root.
If the $$config-edit-mode system parameter is set to 'level', then exiting from a sub-mode to the top-level configuration mode will cause any pending edits to be applied to the current session.
If the $$config-edit-mode system parameter is set to 'mode', then exiting from the top-level configuration mode will cause any pending edits to be applied to the current session.
There are no parameters for this command.
+---x exit
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none (prompt is changed) |
YANG file: |
Command Parameters:
none
System Variables:
none
Positive Response:
the prompt is changed to indicate the new level. If edits are applied a message will be displayed indicating edits were applied to the session.
Negative Response:
An error message will be printed if errors are detected.
Usage:
andy@myserver# exit
andy@myserver>
fill¶
The 'fill' command is used to create a user variable for reuse in other commands.
It is used in an assignment statement to create a variable from various sources.
If it is not used in an assignment statement, then the result will not be saved, so the command will have no effect in this case.
The value contents will mirror the subtree within the NETCONF database indicated by the target parameter. If not completely provided, then missing descendant nodes will be filled in interactively, by prompting for each missing node.
+---x fill
+---w input
| +---w (target-parm)?
| | +--:(target)
| | | +---w target yang:xpath1.0
| | +--:(urltarget-case)
| | +---w urltarget ywt:UrlPath
| | +---w match-names? ywt:NameMatchMode
| | +---w alt-names? ywt:AltNameMode
| | +---w wildcard-keys? boolean
| +---w optional? empty
| +---w value? <anyxml>
+--ro output
+--ro data? <anyxml>
Command type: |
local |
Default parameter: |
target |
Min parameters: |
2 |
Max parameters: |
3 |
Return type: |
data |
YANG file: |
Command Parameters:
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
target
type: string
usage: mandatory
default: none
This parameter specifies the database target node of the create operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the content to use for the filled variable.
If this parameter is not entered, then the user will be prompted interactively to fill in the 'target' data structure.
If a string is entered, then the target value being filled must be a leaf or leaf-list.
If a variable reference is entered, then it will be used as the content, if the target value being filled is a leaf or a leaf-list.
If the target value is a complex object, then the referenced variable must also be a complex object of the same type.
An error will be reported if the global or local variable does not reference the same object type as the target parameter.
System Variables:
$$optional
Controls whether optional descendant nodes will be filled into the 'target' parameter contents
Positive Response:
OK
Negative Response:
An error message will be printed if errors are detected.
Output:
data
type: anyxml
The data structure will mirror the requested target object.
The variable (if any) will retain the target object name and namespace so it can be used in other operations more easily. In the example below, the '$my_interface' local variable will have the module name 'interfaces' and name 'interface', when used in other commands such as create or merge.
Usage:
> $my-interface = fill target=/interfaces/interface optional
(user will be prompted to fill in all fields of the <interface> element)
OK
>
get¶
The 'get' command is used to retrieve data from the server. This command is provided by the NETCONF server, not yangcli-pro.
The 'module-tag' parameter is only supported if netconfd-pro is the server used.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get> operation for parameter details.
Usage:
session1> get
RPC Data Reply 20 for session 10:
rpc-reply {
data {
…. data returned by the server
}
}
session1> get filter=@myfilter.xml
RPC Data Reply 21 for session 10:
rpc-reply {
data {
}
}
(the previous response will occur if the filter did not
match anything or the server access control filtered the
entire response)
session1>
Reference:
RFC 6241, section 7.7
get-bulk¶
The 'get-bulk' command is used to retrieve YANG list data one or more entries at a time.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-bulk> operation for parameter details.
Usage:
Reference:
none
get-config¶
The 'get-config' command is used to retrieve configuration data from the server.
The 'module-tag' parameter is only supported if netconfd-pro is the server used.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-config> operation for parameter details.
Usage:
session1> $my-config = get-config target=running
RPC Data Reply 22 for session 10:
rpc-reply {
data {
…. entire database returned by the server
}
}
yangcli-pro andy@myserver[d]> @saved-config.xml = get-config \
filter=@myfilter.xml \
target=candidate
rpc-reply {
data {
… data requested by the filter
}
}
session1>
Reference:
RFC 6241, section 7.1
get-data¶
The get-data command is used to retrieve configuration or operational NMDA datastores from the server. The server must have NMDA enabled for this operation to be present.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-data> operation for parameter details.
Usage:
Reference:
RFC 8526, section 3.1.1
get-locks¶
The 'get-locks' command is a high-level wrapper for the <lock> operation. It is used to lock all the databases (<running> plus <candidate> and/or <startup> if they exist). If all the locks cannot be obtained, then release all the locks that were obtained (all-or-nothing).
The entire time to wait for a lock in use is set with the lock-timeout parameter.
The retry-interval parameter is used when the <lock> operation fails with a 'lock-denied' error-tag, because some other session has the lock.
If the <candidate> cannot be locked for another reason, a <discard-changes> operation will be attempted to clear any leftover edits.
Normally, the errors received while attempting to acquire locks are not printed to the log, like normal commands. Instead, if $$log-level system parameter is set to 'debug2' or 'debug3', then these messages will be printed.
+---x get-locks
+---w input
+---w lock-timeout? nt:Timeout
+---w retry-interval? uint32
+---w cleanup? boolean
Command type: |
remote |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
Command Parameters:
lock-timeout
type: uint32 (seconds)
usage: optional
default: 120 seconds (2 minutes)
This parameter specifies how long to wait for a lock that is in use by another session.
retry-interval
type: uint32 (seconds)
usage: optional
default: 2 seconds
This parameter specifies how long to wait to retry for a lock.
cleanup
type:boolean
usage: optional
default: true
This parameter controls whether the 'release-locks' command will be called automatically if the entire set of required locks cannot be granted.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
session1> get-locks lock-timeout=0
Sending <lock> operations for get-locks...
RPC OK Reply 6 for session 23:
RPC OK Reply 7 for session 23:
get-locks finished OK
session1>
get-my-session¶
The 'get-my-session' command is used to retrieve the session customization parameters from the server. It is only supported by the netconfd-pro server.
The session indent amount, session line size, and default behavior for the with-defaults parameter can be controlled at this time.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-my-session> operation for parameter details.
get-schema¶
The 'get-schema' command is used to retrieve data model definition files from the server. This is part of the NETCONF monitoring draft. The server must support the :schema-retrieval capability to use this command.
If the server reports a module or module version that yangcli-pro cannot find in its local module library, then an error message will be printed. The get-schema command can then be used to retrieve the missing module from the server.
The ietf-netconf-monitoring.yang module includes a list of the schema supported by the server, which can be retrieved from a server that supports this module, such as netconfd-pro.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-schema> operation for parameter details.
Usage:
session1> @notifications.yang = get-schema \
identifier=notifications \
version=2009-06-04 \
format=YANG
RPC Data Reply 24 for session 10:
rpc-reply {
data {
…. entire notifications.yang contents
}
}
(after retrieval, the module can be loaded locally
with the mgrload command)
session1> mgrload notifications.yang
OK
session1>
Reference:
get-walk¶
This command walks the entries of a YANG list using the netconfd-pro <get-bulk> operation. This command will send <get-bulk> requests to the server until the entire list has been retrieved or the user quits the walk.
If the yumaworks-getbulk.yang module is not supported by the server then this command will not be attempted.
If the program is in interactive mode, then after each retrieval, the user will be prompted to continue or quit the walk. In batch mode the entries will be displayed until the walk terminates.
The server will wait the normal 'timeout' period after each request. It will display each response and check it for 'last-keys' data. If present, these values will be used for the 'last-keys' parameter in the next request If not present, then the walk will end.
The walk will be done on the YANG list specified by the 'list-target' parameter. Each retrieval will request 1 or more entries, based on the 'count' parameter. The data returned can be filtered according to the 'content', 'depth', 'with-defaults', and 'list-test' parameters, which as passed to the <get-bulk> operation each time.
The 'list-target' parameter is used to specify that YANG list that will be retrieved.
The 'list-test' parameter allows an XPath boolean expression to be used to test each list-target entry. It is used to select only a subset of the list entries to reduce the number of entries returned.
If a portion of the requested data is not available due to access control restrictions, then that data is silently dropped from the <rpc-reply> message. It is implicitly understood that the client is only requesting data for which it is authorized to receive, in the event such data is selected in the request.
+---x get-walk
+---w input
+---w datastore? enumeration
+---w list-target string
+---w count? uint32
+---w content? enumeration
+---w depth? union
+---w with-defaults? with-defaults-mode
+---w list-test? yang:xpath1.0
+---w fixed-keys? <anydata>
Command type: |
remote |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
7 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
none |
Mandatory Parameters:
list-target
type: string (RESTCONF path URI)
usage: mandatory
This parameter identifies the list object that is being retrieved. This must be a path expression used to represent a list data node. It is formatted like a RESTCONF path expression, except module names are not mandatory if they are unique.
Optional Parameters:
datastore
type: enumeration (candidate running startup)
usage: optional
default: running
This parameter specifies the name of the source database for the retrieval operation. It is ignored if the 'list-target' specifies a non-configuration data node.
enum:
candidatecapabilities needed: :candidate
enum :
runningcapabilities needed: none
enum:
startupcapabilities needed: :startup
count
type: unint32
usage: optional
default: 1
The maximum number of list entries to return.
content
type: enumeration
usage: optional
default: all
This parameter specifies which type of content to include, exactly the same as the RESTCONF “content” query parameter
enum:
configInclude only config=true descendant data nodes
enum:
nonconfiginclude only config=false descendant data nodes
enum:
allinclude all descendant data nodes
depth
type: uint32
usage: optional
default: unbounded
This parameter is used as defined in the RESTCONF protocol. The value '1' is associated with the list-object node itself. This value can be used to simply test for the existence of any instances of the list-object.
with-defaults
type: enumeration (none report-all report-all-tagged trim explicit)
usage: --default-style configuration parameter used as the default if no value is provided
This parameter controls how default leaf and leaf-list nodes are returned by the server.
list-test
type: leaf containing an XPath expression
usage: optional
default: return all selected list-target entries
This parameter contains an XPath expression. The document root and the context node are set to the list instance being tested.
Example to continue walk.
andy@server> get-walk count=5 list-target=/modules-state/module \
list-test="starts-with(name, 'ietf-netconf')" \
content=all datastore=running depth=unbounded
rpc-reply {
bulk {
data {
module {
conformance-type implement
feature candidate
feature confirmed-commit
feature rollback-on-error
feature validate
feature url
feature xpath
name ietf-netconf
namespace urn:ietf:params:xml:ns:netconf:base:1.0
revision 2011-06-01
}
module {
conformance-type implement
name ietf-netconf-acm
namespace urn:ietf:params:xml:ns:yang:ietf-netconf-acm
revision 2018-02-14
schema http://localhost/restconf/yang/ietf-netconf-acm/2018-02-14
}
module {
conformance-type implement
name ietf-netconf-monitoring
namespace urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
revision 2010-10-04
schema http://localhost/restconf/yang/ietf-netconf-monitoring/2010-10-04
}
module {
conformance-type implement
name ietf-netconf-notifications
namespace urn:ietf:params:xml:ns:yang:ietf-netconf-notifications
revision 2012-02-06
schema http://localhost/restconf/yang/ietf-netconf-notifications/2012-02-06
}
module {
conformance-type implement
name ietf-netconf-partial-lock
namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0
revision 2009-10-19
schema http://localhost/restconf/yang/ietf-netconf-partial-lock/2009-10-19
}
}
last-keys {
name ietf-netconf-partial-lock
revision 2009-10-19
}
}
}
Press Enter to continue, q to quit get-walk:
rpc-reply {
bulk {
data {
module {
conformance-type implement
name ietf-netconf-with-defaults
namespace urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
revision 2011-06-01
schema http://localhost/restconf/yang/ietf-netconf-with-defaults/2011-06-01
}
module {
conformance-type implement
name ietf-restconf
namespace urn:ietf:params:xml:ns:yang:ietf-restconf
revision 2017-01-26
schema http://localhost/restconf/yang/ietf-restconf/2017-01-26
}
module {
conformance-type implement
name ietf-restconf-monitoring
namespace urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring
revision 2017-01-26
schema http://localhost/restconf/yang/ietf-restconf-monitoring/2017-01-26
}
module {
conformance-type implement
name ietf-yang-library
namespace urn:ietf:params:xml:ns:yang:ietf-yang-library
revision 2016-06-21
schema http://localhost/restconf/yang/ietf-yang-library/2016-06-21
}
module {
conformance-type implement
name ietf-yang-patch
namespace urn:ietf:params:xml:ns:yang:ietf-yang-patch
revision 2017-02-22
schema http://localhost/restconf/yang/ietf-yang-patch/2017-02-22
}
}
last-keys {
name ietf-yang-patch
revision 2017-02-22
}
}
}
Press Enter to continue, q to quit get-walk:
rpc-reply {
bulk {
data {
module {
conformance-type import
name ietf-yang-types
namespace urn:ietf:params:xml:ns:yang:ietf-yang-types
revision 2013-07-15
schema http://localhost/restconf/yang/ietf-yang-types/2013-07-15
}
module {
conformance-type implement
name nc-notifications
namespace urn:ietf:params:xml:ns:netmod:notification
revision 2008-07-14
schema http://localhost/restconf/yang/nc-notifications/2008-07-14
}
module {
conformance-type implement
name notifications
namespace urn:ietf:params:xml:ns:netconf:notification:1.0
revision 2013-03-15
schema http://localhost/restconf/yang/notifications/2013-03-15
}
module {
conformance-type implement
name yang-data-ext
namespace urn:ietf:params:xml:ns:yang:yang-data-ext
revision 2017-07-03
schema http://localhost/restconf/yang/yang-data-ext/2017-07-03
}
module {
conformance-type import
name yuma-app-common
namespace http://netconfcentral.org/ns/yuma-app-common
revision 2017-07-25
schema http://localhost/restconf/yang/yuma-app-common/2017-07-25
}
}
last-keys {
name yuma-app-common
revision 2017-07-25
}
}
}
Press Enter to continue, q to quit get-walk:
rpc-reply {
bulk {
data {
module {
conformance-type implement
name yuma-ncx
namespace http://netconfcentral.org/ns/yuma-ncx
revision 2015-10-16
schema http://localhost/restconf/yang/yuma-ncx/2015-10-16
}
module {
conformance-type implement
name yuma-system
namespace http://netconfcentral.org/ns/yuma-system
revision 2013-07-15
schema http://localhost/restconf/yang/yuma-system/2013-07-15
}
module {
conformance-type implement
name yuma-time-filter
namespace http://netconfcentral.org/ns/yuma-time-filter
revision 2012-11-15
schema http://localhost/restconf/yang/yuma-time-filter/2012-11-15
}
module {
conformance-type import
name yuma-types
namespace http://netconfcentral.org/ns/yuma-types
revision 2015-09-25
schema http://localhost/restconf/yang/yuma-types/2015-09-25
}
module {
conformance-type import
name yumaworks-app-common
namespace http://yumaworks.com/ns/yumaworks-app-common
revision 2018-06-26
schema http://localhost/restconf/yang/yumaworks-app-common/2018-06-26
}
}
last-keys {
name yumaworks-app-common
revision 2018-06-26
}
Press Enter to continue, q to quit get-walk:
rpc-reply {
bulk {
data {
module {
conformance-type implement
name yumaworks-event-filter
namespace http://yumaworks.com/ns/yumaworks-event-filter
revision 2014-02-09
schema http://localhost/restconf/yang/yumaworks-event-filter/2014-02-09
}
module {
conformance-type implement
name yumaworks-getbulk
namespace http://yumaworks.com/ns/yumaworks-getbulk
revision 2018-04-06
schema http://localhost/restconf/yang/yumaworks-getbulk/2018-04-06
}
module {
conformance-type implement
name yumaworks-ids
namespace http://yumaworks.com/ns/yumaworks-ids
revision 2014-07-12
schema http://localhost/restconf/yang/yumaworks-ids/2014-07-12
}
module {
conformance-type implement
name yumaworks-restconf
namespace urn:ietf:params:xml:ns:yang:yumaworks-restconf
revision 2017-07-03
schema http://localhost/restconf/yang/yumaworks-restconf/2017-07-03
}
module {
conformance-type implement
name yumaworks-support-save
namespace urn:ietf:params:xml:ns:yang:yumaworks-support-save
revision 2017-07-27
schema http://localhost/restconf/yang/yumaworks-support-save/2017-07-27
}
}
last-keys {
name yumaworks-support-save
revision 2017-07-27
}
}
}
Press Enter to continue, q to quit get-walk:
rpc-reply {
bulk {
data {
module {
conformance-type implement
name yumaworks-system
namespace http://yumaworks.com/ns/yumaworks-system
revision 2019-01-22
schema http://localhost/restconf/yang/yumaworks-system/2019-01-22
}
module {
conformance-type implement
name yumaworks-templates
namespace http://yumaworks.com/ns/yumaworks-templates
revision 2017-02-20
schema http://localhost/restconf/yang/yumaworks-templates/2017-02-20
}
module {
conformance-type import
name yumaworks-types
namespace http://yumaworks.com/ns/yumaworks-types
revision 2018-05-03
schema http://localhost/restconf/yang/yumaworks-types/2018-05-03
}
}
last-keys {
name yumaworks-types
revision 2018-05-03
}
}
}
Press Enter to continue, q to quit get-walk:
rpc-reply {
bulk {
data
}
}
get-walk has completed.
andy@server>
Example to quit walk.
andy@server> get-walk count=5 list-target=/modules-state/module \
list-test="starts-with(name, 'ietf-netconf')" \
content=all datastore=running depth=unbounded
rpc-reply {
bulk {
data {
module {
conformance-type implement
feature candidate
feature confirmed-commit
feature rollback-on-error
feature validate
feature url
feature xpath
name ietf-netconf
namespace urn:ietf:params:xml:ns:netconf:base:1.0
revision 2011-06-01
}
module {
conformance-type implement
name ietf-netconf-acm
namespace urn:ietf:params:xml:ns:yang:ietf-netconf-acm
revision 2018-02-14
schema http://localhost/restconf/yang/ietf-netconf-acm/2018-02-14
}
module {
conformance-type implement
name ietf-netconf-monitoring
namespace urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
revision 2010-10-04
schema http://localhost/restconf/yang/ietf-netconf-monitoring/2010-10-04
}
module {
conformance-type implement
name ietf-netconf-notifications
namespace urn:ietf:params:xml:ns:yang:ietf-netconf-notifications
revision 2012-02-06
schema http://localhost/restconf/yang/ietf-netconf-notifications/2012-02-06
}
module {
conformance-type implement
name ietf-netconf-partial-lock
namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0
revision 2009-10-19
schema http://localhost/restconf/yang/ietf-netconf-partial-lock/2009-10-19
}
}
last-keys {
name ietf-netconf-partial-lock
revision 2009-10-19
}
}
}
Press Enter to continue, q to quit get-walk:q
andy@server>
group¶
The 'group' command is used to manage the session groups. Refer to the NETCONF Group Configuration section for details on the format of this file.
There are 7 sub-commands:
create
add
delete
remove
list
show
connect
+---x group
+---w input
+---w (groupcmd)
| +--:(connect)
| | +---w connect? nt:NcxIdentifier
| | +---w missing-ok? boolean
| | +---w missing-connect-ok? boolean
| | +---w lost-ok? boolean
| | +---w reconnect-tries? uint32
| | +---w reconnect-interval? uint32
| +--:(create-case)
| | +---w create? nt:NcxIdentifier
| +--:(delete-case)
| | +---w delete? nt:NcxIdentifier
| +--:(add-case)
| | +---w add? nt:NcxIdentifier
| +--:(remove-case)
| | +---w remove? nt:NcxIdentifier
| +--:(show-case)
| | +---w show? nt:NcxIdentifier
| +--:(list-case)
| +---w list? empty
+---w session* nt:NcxIdentifier
Command type: |
local |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
6 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
create
type: group name string
This parameter indicates the name of the group to create. The 'session' parameter must also be present. The session cannot be currently active.
add
type: group name string
This parameter indicates the name of the group to add specified sessions. The 'session' parameter must also be present. The session cannot be currently active.
delete
type: group name string
An active group cannot be deleted.
remove
type: group name string
This parameter specifies the name of the session to delete from the group in memory. An active session cannot be deleted.
show
type: group name string
This parameter specifies the name of the group to show.
list
type: empty
List the names of all the groups.
connect
type: name string
This parameter specifies the name of the group to connect.
missing-ok
type: boolean
If true, then it is OK to manage this group if 1 or more sessions identified in the session leaf-list are not found in the session list. The default is to require all session names to exist in the session list for the group to be used.
missing-connect-ok
type: boolean
If true, then it is OK to manage this group if 1 or more sessions identified in the session leaf-list are not found in the session list. The default is to require all sessions to connect OK for the group to be used.
lost-ok
type: boolean
If true, then it is OK to manage this group if 1 or more sessions are lost after connection is made. The default is to require all sessions to remain connected for the group to be used.
reconnect-tries
type: uint32
This parameter Indicates the number of times yangcli will attempt to reconnect to a session if the server becomes unreachable. The default is 5 tries.
reconnect-interval
type: uint32
This parameter indicates the number of seconds yangcli will wait to re-establish a connection if a session is dropped and the server becomes unreachable. The default is 10 seconds. units: seconds
Positive Response:
An group is started and the prompt changes to
>AB
Negative Response:
One or more error messages will be printed.
Example 'group' commands:
> group list
No groups found
> group create=AB session-A
> group list
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 1
Session 'session-A' connected:false >
> group add=AB session-B
> group list
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 2
Session 'session-A' connected:false
Session 'session-B' connected:false
> group remove=AB session=session-A
> group list
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 1
Session 'session-B' connected:false
> group delete=AB
> group list
No groups found
>group connect=AB
Error: group 'AB' not found
> group create=AB session=session-A session=session-B
> group list
Group 'AB'
This group is not connected.
missing-ok: false
missing-connect-ok: false
lost-ok: false
reconnect-interval: 30
reconnect-tries: 5
connected_cnt: 0
number_of_sessions: 2
Session 'session-A' connected:false
Session 'session-B' connected:false
> group connect=AB
yangcli-pro: Starting NETCONF session for trshue on localhost over ssh on port 830
NETCONF session established for trshue on localhost
Client Session Id: 1
Server Session Id: 13
Server Protocol Capabilities
base:1.0
candidate:1.0
confirmed-commit:1.0
rollback-on-error:1.0
------
------
about to send <get>:on Group of 'AB' Session of 'session-A'
yangcli-pro: Starting NETCONF session for trshue on localhost over ssh on port 830
NETCONF session established for trshue on localhost
Client Session Id: 2
Server Session Id: 14
Server Protocol Capabilities
base:1.0
candidate:1.0
------
AB> get-my-session
about to send <get-my-session>:on Group of 'AB' Session of 'session-A'
about to send <get-my-session>:on Group of 'AB' Session of 'session-B'
RPC Data Reply 3 for session 13 [session-A]:
rpc-reply {
indent 2
linesize 72
with-defaults explicit
message-indent -1
}
RPC Data Reply 2 for session 14 [session-B]:
rpc-reply {
indent 2
linesize 72
with-defaults explicit
message-indent -1
}
AB>
AB> set-my-session indent=8 linesize=68 with-defaults=report-all message-indent=-1
about to send <set-my-session>:on Group of 'AB' Session of 'session-A'
about to send <set-my-session>:on Group of 'AB' Session of 'session-B'
RPC OK Reply 4 for session 13 [session-A]:
RPC OK Reply 5 for session 14 [session-B]:
AB> get-my-session
about to send <get-my-session>:on Group of 'AB' Session of 'session-A'
about to send <get-my-session>:on Group of 'AB' Session of 'session-B'
RPC Data Reply 3 for session 13 [session-A]:
rpc-reply {
indent 8
linesize 68
with-defaults repo
message-indent -1
}
RPC Data Reply 2 for session 14 [session-B]:
rpc-reply {
indent 8
linesize 68
with-defaults repo
message-indent -1
}
AB>
help¶
The help command is used to print documentation to STDOUT.
If no session is active, then only help for the local commands and the standard NETCONF commands will be available.
If a NETCONF session is active, then the documentation shown will attempt to exactly match the capabilities of the server.
If additional (i.e., augment generated) parameters are available, then they will be shown in the command output. If the server does not implement some parameters (e.g., feature not supported) then these parameters will not be shown in the command output.
If the server has modified an object with deviation statements, then the altered object will be shown.
The ncx:hidden extension suppresses the 'help' command. If this extension is present in the YANG definition associated with the request, then no help will be available for that object or command.
+---x help
+---w input
+---w (helptype)?
| +--:(command)
| | +---w command? nt:NcxIdentifier
| +--:(commands)
| | +---w commands? empty
| +--:(notification)
| | +---w notification? nt:NcxIdentifier
| +--:(object)
| | +---w object? union
| +--:(type)
| +---w type? nt:NcxIdentifier
+---w (help-mode)?
+--:(brief)
| +---w brief? empty
+--:(normal)
| +---w normal? empty
+--:(full)
+---w full? empty
Command type: |
local |
Default parameter: |
command |
Min parameters: |
3 |
Max parameters: |
3 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
Command Parameters:
choice helptype (not entered)
command
type: string
usage: mandatory
default: none
This parameter specifies the name of the command for which documentation is requested
commands
type: empty
usage: mandatory
default: none
This parameter will request documentation for all available commands
notification
type: string
usage: mandatory
default: none
This parameter specifies the name of the notification for which documentation is requested
object
type: string
usage: mandatory
Only top-level typedefs are supported by this command. Local typedefs within groupings, containers, or lists are not exportable in YANG.
default: none
This parameter specifies the name of the NETCONF database object for which documentation is requested.
Only top level objects are supported by this command.
Documentation for the entire object subtree will be printed, if the object is a container, choice, or list.
Documentation for nested objects is only available in parameter mode, using the escape commands for help ('?') and full help ('??')
type
type: string
usage: mandatory
default: none
This parameter specifies the name of the YANG typedef for which documentation is requested
choice help-mode (not entered) (default choice is 'normal')
brief
type: empty
usage: optional
default: none
This parameter specifies that brief documentation mode should be used.
normal
type: empty
usage: optional
default: none
This parameter specifies that normal documentation mode should be used.
full
type: empty
usage: optional
default: none
This parameter specifies that full documentation mode should be used.
Positive Response:
the server prints the requested help text
Negative Response:
An error message will be printed if errors are detected.
Usage:
> help help full
help
Print the yangcli-pro help text
input
default parameter: command
choice helptype
leaf command [NcxIdentifier]
Show help for the specified command,
also called an RPC method
leaf commands [empty]
Show info for all local commands
leaf notification [NcxIdentifier]
Show help for the specified notification
leaf object [NcxIdentifier]
Show help for the specified object
leaf type [NcxIdentifier]
Show help for the specified type
choice help-mode
leaf brief [empty]
Show brief help text
leaf normal [empty]
Show normal help text
leaf full [empty]
Show full help text
andy@myserver> help notification sysConfigChange
notification sysConfigChange
Generated when the <running> configuration is changed.
leaf userName [string]
leaf sessionId [SessionId]
range: 1..max
leaf remoteHost [ip-address]
leaf target [string]
leaf operation [EditOperationType] [d:merge]
enum values: merge replace create delete
andy@svnserver>
history¶
The 'history' command is used to show, clear, load, or save the command line history buffer.
Use the recall command to recall a previously executed command line, after getting the line number from the 'history show' command.
All lines entered will be saved in the history buffer except an ncx:password value entered in parameter mode.
When yangcli-pro starts, the command line history buffer is empty. If a history file was previously stored with the 'history save' command, then it can be recalled into the buffer with the 'history load' command. This is done automatically if the --autohistory parameter is set to 'true'.
The 'history clear' command is used to delete the entire command line history buffer.
The 'history save' command is used to save the history to the history file. This is done automatically when yangcli-pro exits, if the --autohistory parameter is set to 'true'.
The numbering sequence for commands, starts from zero and keeps incremented until the program exits. If the history buffer is cleared, then the number sequence will continue, not start over at zero.
+---x history
+---w input
+---w (history-action)?
+--:(show-case)
| +---w show? LogCount
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
0 |
Max parameters: |
2 |
Return type: |
data |
YANG file: |
Command Parameters:
choice history-action (not entered)
clear
type: empty
usage: optional
default: none
This parameter specifies that the history buffer should be cleared. Unless the contents have been saved with the history save command, there is no way to recover the cleared buffer contents after this command is executed.
load
type: string
usage: optional
default: $HOME/.yangcli-pro_history
This parameter specifies a command history file, and causes the current command line history contents to be loaded from that file.
Special processing for this command allows the history file to be omitted in idle mode, even though the load parameter is not type 'empty'.
> history load same as: > history load=$HOME/.yangcli-pro_history
save
type: string
usage: optional
default: $HOME/.yangcli-pro_history
This parameter specifies a command history file, and causes the current command line history contents to be saved to that file.
Special processing for this command allows the history file to be omitted in idle mode, even though the save parameter is not type 'empty'.
> history save same as: > history save=$HOME/.yangcli-pro_history
show
type: int32 (-1 for all entries; 1..max for N entries)
usage: optional
default: -1
This parameter specifies the maximum number of history entries to show.
If no case is selected from this choice, then the command 'history show=-1' will be used by default.
The help-mode choice parameter is only used with the 'history show' command.
If the --brief or --normal modes are selected the the format will include the command number and the command line.
If the --full mode is selected, then the command data and time will also be printed.
Positive Response:
the requested history entries will be printed for the 'history show' command
all other commands will return OK
Negative Response:
An error message will be printed if errors are detected.
Usage:
> history show=3 full
[27] 2009-07-04 09:25:34 sget /system --nofill
[28] 2009-07-04 09:34:17 @myconfig = get-config source=running
[29] 2009-07-04 09:43:54 history show=3 full
> history save=~/my-temp-history-file
OK
>
if¶
The 'if' command is used to start a conditional command block.
The 'expr' parameter is used to specify the XPath expression to test if the if conditional block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.
The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.
If the 'expr' expression is true, the conditional block will be executed, and no further conditional blocks within the same if command sequence will be executed.
if command
....
[elif command]
....
[elif-command]
...
[else command]
...
end
The 'if' command must be paired with a matching end command. It can also be continued with consecutive elif statements or one else statement.
+---x if
+---w input
+---w expr yang:xpath1.0
+---w docroot? <anyxml>
Command type: |
local |
Default parameter: |
expr |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
Command Parameters:
expr
type: XPath expression string
usage: mandatory
default: none
This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.
docroot
type: anyxml
usage: optional (typically a variable reference is used)
default: none
This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
invalid XPath expression or invalid docroot reference will cause an error
Usage:
andy@myserver> if "$sysname = 'localhost'"
andy@myserver>
insert¶
The 'insert' command is used to insert or move YANG list or leaf-list data into a NETCONF database. It is a high level command with utilizes the YANG 'insert' extensions to the NETCONF <edit-config> operation.
+---x insert
+---w input
+---w (from)
| +--:(varref)
| | +---w varref? string
| +--:(from-cli)
| +---w (target-parm)?
| | +--:(target)
| | | +---w target yang:xpath1.0
| | +--:(urltarget-case)
| | +---w urltarget ywt:UrlPath
| | +---w match-names? ywt:NameMatchMode
| | +---w alt-names? ywt:AltNameMode
| | +---w wildcard-keys? boolean
| +---w optional? empty
| +---w value? <anyxml>
+---w timeout? nt:Timeout
+---w order? enumeration
+---w operation? enumeration
+---w edit-target? string
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
2 |
Max parameters: |
7 |
Return type: |
status |
YANG file: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the insert operation. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the target of the insert operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: mandatory
default: none
This parameter specifies the database target node of the insert operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.
edit-target
type: string
usage: optional (must be present if the order parameter is set to 'before' or 'after').
default: none
This parameter specifies the value or key clause that should be used, as the list or leaf-list insertion point. It identifies the existing entry that the new entry will be inserted before or after, depending on the 'order' parameter.
For a leaf-list, the edit-target contains the value of the target leaf-list node within the configuration being edited. E.g., edit-target='fred'.
For a list, the edit-target contains the key values of the target list node within the configuration being edited. E.g., edit-target=[name='fred'][zipcode=90210].
order
type: enumeration (first last before after)
usage: optional
default: last
The insert order that should be used. If the value 'before' or 'after' is selected, then the 'edit-target' parameter must also be present.
operation
type: enumeration (create merge replace)
usage: optional
default: merge
This parameter specifies the 'nc:operation' attribute value for the NETCONF <edit-config> operation. The insert operation is secondary to the NETCONF operation attribute.
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> insert varref=myvar order=first
RPC OK Reply 25 for session 10:
andy@myserver> insert /nacm/rules/data-rule order=after edit-target=”[name='test-rule']”
(user will be prompted to fill in the data-rule contents)
RPC OK Reply 26 for session 10:
andy@myserver>
Reference:
kill-session¶
The 'kill-session' command is used to terminate a NETCONF session (other than the current session). All NETCONF implementations must support this command. It is needed sometimes to unlock a NETCONF database locked by a session that is idle or stuck.
If the lock command returns a 'lock-denied' <error-tag>, it will also include an <error-info> field called <session-id>. This is the session number that currently holds the requested lock. The same value should be used for the 'session-id' parameter in this command, to terminate the session will the lock.
Note
Use of the kill-session operation is an extreme measure, which should be used with caution.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <kill-session> operation for parameter details.
Usage:
andy@myserver> kill-session session-id=11
RPC OK Reply 27 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.9
kill-subscription¶
The 'kill-subscription' command is used to terminate
the notification subscription for another session
on the connected NETCONF server.
The netconfd-pro server must have the yang-push bundle enabled
for this operation to be available.
The subscription-id returned in the establish-subscription command must be used as the parameter, since a session can have multiple subscriptions active at once.
The server should also send a "subscription-terminated" notification as a result of the operation.
Note
The nacm:default-deny-all access restriction applies to this operation.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <kill-subscription> operation for parameter details.
Usage:
fred@server1> kill-subscription id=2
RPC OK Reply 3 for session 4 [default]:
fred@server1>
The session that has the subscription (possibly on another client) will get the "subscription-terminated" event.
andy@server1>
Incoming notification for session 2 [default]:
notification {
eventTime 2022-01-13T03:04:48Z
subscription-terminated {
id 2
reason sn:no-such-subscription
}
}
andy@server1>
list¶
This 'list' command is used to display the commands, objects, and oids (object identifiers) that are available at the time.
The 'list commands' command will display the local commands and the remote commands that are available in the current NETCONF session, or which have been loaded with the mgrload command.
The 'list files command will display the data files that are in the current data search path. The module parameter has no affect in this mode.
The 'list modules' command will display the YANG files that are in the current YANG module search path. The module parameter has no affect in this mode.
The 'list objects' command will display the top-level objects that are currently available in the current NETCONF session, or which have been loaded with the mgrload command.
The 'list oids' command will display the object identifiers of the top-level objects that are currently available in the current NETCONF session, or which have been loaded with the mgrload command.
The 'list scripts' command will display the script files that are in the current script search path. The module parameter has no affect in this mode.
+---x list
+---w input
+---w (listtype)
| +--:(commands)
| | +---w commands? empty
| +--:(files)
| | +---w files? empty
| +--:(objects)
| | +---w objects? empty
| +--:(oids)
| | +---w oids? empty
| +--:(modules)
| | +---w modules? empty
| +--:(scripts)
| +---w scripts? empty
+---w module? nt:NcxIdentifier
+---w (help-mode)?
+--:(brief)
| +---w brief? empty
+--:(normal)
| +---w normal? empty
+--:(full)
+---w full? empty
Command type: |
local |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
6 |
Return type: |
data |
YANG file: |
Command Parameters:
choice help-mode (not entered)
brief
type: empty
usage: optional
default: none
This parameter specifies that brief documentation mode should be used.
normal
type: empty
usage: optional
default: none
This parameter specifies that normal documentation mode should be used.
full
type: empty
usage: optional
default: none
This parameter specifies that full documentation mode should be used.
choice 'listtype' (not entered)
usage: mandatory
default: none
This parameter specifies the what type of data should be listed.
commands
type: empty
usage: mandatory
default: none
This parameter specifies that the available commands should be listed.
If the help-mode is set to 'brief', then only the command names will be listed.
If the help-mode is set to 'normal', then the XML prefix and the command name will be listed.
If the help-mode is set to 'full', then the module name and the command name will be listed.
files
type: empty
usage: mandatory
default: none
This parameter specifies that all the data files in the current data search path should be listed.
modules
type: empty
usage: mandatory
default: none
This parameter specifies that all the YANG files in the current module search path should be listed.
objects
type: empty
usage: mandatory
default: none
This parameter specifies that the available top-level objects should be listed.
If the help-mode is set to 'brief', then only the object names will be listed.
If the help-mode is set to 'normal', then the XML prefix and the object name will be listed.
If the help-mode is set to 'full', then the module name and the object name will be listed.
oids
type: empty
usage: mandatory
default: none
This parameter specifies that the available top-level object identifiers should be listed.
The help-mode parameter has no effect
scripts
type: empty
usage: mandatory
default: none
This parameter specifies that all the script files in the current script search path should be listed.
module
type: string
usage: optional
default: none
This parameter specifies a module name. If present then only information for the specified YANG module will be displayed.
Positive Response:
the requested information will be printed
Negative Response:
An error message will be printed if errors are detected.
Usage:
andy@myserver> list objects full module=test
test:instance1
test:instance2
test:leafref1
test:leafref2
test:test1
test:test2
test:test3
test:idtest
test:musttest
test:anyxml.1
test:binary.1
test:bits.1
test:boolean.1
test:empty.1
test:enumeration.1
test:identityref.1
test:instance-identifier.1
test:instance-identifier.2
test:int8.1
test:int16.1
test:int32.1
test:int64.1
test:leafref.1
test:leafref.2
test:string.1
test:uint8.1
test:uint16.1
test:uint32.1
test:uint64.1
test:dec64.1
test:dec64.2
test:dec64.3
test:union.1
test:container.1
test:container.2
test:list.1
test:choice.1
test:xpath.1
andy@myserver>
load¶
The load command is used to load a YANG module into the server.
This command is only supported by the netconfd-pro server.
The YANG files must be available in the module search path for the server.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <load> operation for parameter details.
Usage:
andy@myserver> load toaster revision=2009-06-23
RPC Data Reply 27 for session 10:
rpc-reply {
mod-revision 2009-06-23
}
andy@myserver>
lock¶
The 'lock' command is used to request a global lock on a NETCONF database. It is used, along with the unlock command, to obtain exclusive write access to the NETCONF server.
The scope of a lock command is the lifetime of the session that requested the lock. This means that if the session that owns the lock is dropped for any reason, all the locks it holds will be released immediately by the server.
The use of database locks is optional in NETCONF, but it must be implemented by every server. It is strongly suggested that locks be used if multiple managers are likely to log into the particular NETCONF server.
One or more locks may be needed to execute a transaction safely:
If the :writable-running capability is supported, then a lock on the <running> database is needed. This database can be locked at any time.
If the :startup capability is supported, then a lock on the <startup> database is needed. This database can be locked at any time.
If the :candidate capability is supported, then a lock on the <candidate> database is needed. A lock on the <running> database is also needed.
The <candidate> database can only be locked if there are no active edits in it.
The discard-changes command may be needed to clear a <candidate> database that has been left edited by a session that terminated unexpectedly.
Note: There is no way in NETCONF to tell the difference between an actively edited <candidate> database and an 'abandoned' <candidate> database. The server will almost never clear the <candidate> database. It will only clear any locks held. Use the discard-changes command (for other session's edits) with extreme caution.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <lock> operation for parameter details.
Usage:
andy@myserver> lock target=candidate
RPC OK Reply 29 for session 10:
andy@myserver>
log-debug¶
The 'log-debug' command prints a message to the program log, if the $$log-level system variable is set to 'debug' or a higher enumeration (e.g., 'debug2').
The 'msg' parameter is used to provide the message string to print.
+---x log-debug
+---w input
+---w msg string
Command type: |
local |
Default parameter: |
msg |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
msg
type: string
usage: mandatory
default: none
This parameter specifies the string to print to the program log.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if the 'msg' parameter contains errors.
Usage:
andy@myserver> log-debug 'starting strict foo'
Debug: starting script foo
andy@myserver>
log-error¶
The 'log-error' command prints a message to the program log, if the $$log-level system variable is set to 'error' or a higher enumeration (e.g., 'info').
The 'msg' parameter is used to provide the message string to print.
+---x log-error
+---w input
+---w msg string
Command type: |
local |
Default parameter: |
msg |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
msg
type: string
usage: mandatory
default: none
This parameter specifies the string to print to the program log.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if the 'msg' parameter contains errors.
Usage:
andy@myserver> log-error 'sysName not correct'
Error: sysName not correct
andy@myserver>
log-info¶
The 'log-info' command prints a message to the program log, if the $$log-level system variable is set to 'info' or a higher enumeration (e.g., 'debug').
The 'msg' parameter is used to provide the message string to print.
+---x log-info
+---w input
+---w msg string
Command type: |
local |
Default parameter: |
msg |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
msg
type: string
usage: mandatory
default: none
This parameter specifies the string to print to the program log.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if the 'msg' parameter contains errors.
Usage:
andy@myserver> log-info 'sysName is correct'
Info: sysName is correct
andy@myserver>
log-warn¶
The 'log-warn' command prints a message to the program log, if the $$log-level system variable is set to 'warn' or a higher enumeration (e.g., 'debug').
The 'msg' parameter is used to provide the message string to print.
+---x log-warn
+---w input
+---w msg string
Command type: |
local |
Default parameter: |
msg |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
msg
type: string
usage: mandatory
default: none
This parameter specifies the string to print to the program log.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if the 'msg' parameter contains errors.
Usage:
andy@myserver> log-warn 'sysName object not found'
Warning: sysName object not found
andy@myserver>
merge¶
The 'merge' command is a high-level <edit-config> operation. It is used to merge some new nodes into the default target database.
A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'.
Refer to the fill command for more details on interactive mode data structure completion.
+---x merge
+---w input
+---w (from)
| +--:(varref)
| | +---w varref? string
| +--:(from-cli)
| +---w (target-parm)?
| | +--:(target)
| | | +---w target yang:xpath1.0
| | +--:(urltarget-case)
| | +---w urltarget ywt:UrlPath
| | +---w match-names? ywt:NameMatchMode
| | +---w alt-names? ywt:AltNameMode
| | +---w wildcard-keys? boolean
| +---w optional? empty
| +---w value? <anyxml>
+---w timeout? nt:Timeout
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
5 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the merge operation. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the target of the merge operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: optional (target or urltarget must be entered)
default: none
This parameter specifies the database target node of the merge operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the merge operation. This is an UrlPath string.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> merge \
target=/nacm/rules/moduleRule[moduleName='netconf']\
[allowed-rights='read write']/allowed-group \
value=ncx:guest
Reference:
RFC 6241, section 7.2
modify-subscription¶
The 'modify-subscription' command is used to modify
a notification subscription on the connected NETCONF server.
The netconfd-pro server must have the yang-push bundle enabled
for this operation to be available.
The subscription-id that was returned in the establish-subscription operation must be used in this operation.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <modify-subscription> operation for parameter details.
Usage:
session1> modify-subscription id=2 stream-filter-name=alarms-stream
RPC OK Reply 37 for session 10:
session1>
mgrload¶
The 'mgrload' command is used to load a YANG module into yangcli-pro. The YANG files must be available in the module search path for yangcli-pro.
+---x mgrload
+---w input
+---w module nt:NcxName
+---w revision? nt:Date
+---w deviation* yt:NcModuleSpec
Command type: |
local |
Default parameter: |
module |
Min parameters: |
1 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
Command Parameters:
module
type: string (length 1 .. 63)
usage: mandatory
default: none
This parameter specifies the name of the module to load.
revision
type: date string (YYYY-MM-DD)
usage: optional
default: none
This parameter specifies the revision date of the module to load.
deviation:
type: leaf-list of deviation module names
usage: optional (0 or more instances)
default: none
This parameter specifies a deviation module to load prior to loading the requested module.
Positive Response:
OK
Negative Response:
An error message will be printed if errors are detected.
Usage:
> mgrload toaster
Load module toaster OK
>
no¶
The 'no' command is available in config mode to start a delete operation.
A normal config-mode command line is expected.
The specified node is deleted
A sub-mode is not-expected and not entered if the 'no' keyword is used
A complete node specification to deleted is expected
Command type: |
config mode |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
none |
YANG file: |
none |
Command Parameters:
A complete command specifying the node to delete is expected
Positive Response:
A message indicated action performed will be printed if --log-level is
infoor above.
Negative Response:
An error message will be printed
Usage:
session1> conf t
session1# no nacm groups group mygroup
Applying 1 edit
session1#
no-op¶
The 'no-op' command is used to test server message processing response times, by providing a baseline response time to do nothing except return <ok/>.
It can also be used as an application-level keep-alive to prevent proxy idle timeout or server idle timeout problems from occurring.
This command is only supported by the netconfd-pro server. The server will simply respond 'OK', if the request is well-formed.
This command is only available if the yuma-system.yang module is loaded in the server.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <no-op> operation for parameter details.
Usage:
andy@myserver> no-op
RPC OK Reply 31 for session 10:
andy@myserver>
nvsave¶
The 'nvsave' command is used to save the running datastore to the startup datastore on the current session.
If the server does not support the :startup capability then this command will fail. It has the save purpose as “copy-config source=running target=startup”.
+---x nvsave
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
status |
YANG file: |
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> nvsave
RPC OK Reply 32 for session 10:
andy@myserver>
pwd¶
The 'pwd' command is used to print the current working directory.
+---x pwd
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
status |
YANG file: |
Positive Response:
the current working directory is printed to the log or STDOUT
Negative Response:
An error message will be printed if errors are detected.
Usage:
> pwd
Current working directory is /home/andy
>
quit¶
The 'quit' command is used to terminate the yangcli-pro program.
If a NETCONF session is in progress, it will be dropped without sending a close-session command first. This should be taken into account if the server reports dropped TCP connections as an error.
+---x quit
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none |
YANG file: |
Positive Response:
The program terminates; no response will be printed.
Negative Response:
An error message will be printed if errors are detected.
Usage:
> quit
andy@myworkstation>
recall¶
The 'recall' command is used to recall a previously entered command line from the command line history buffer. It is used together with the history command.
A command is recalled by its command ID number. Use the 'history show` command to see the contents of the command line history buffer.
The command is not executed (like in bash). Instead the command is available for editing.
The 'bang' command character '!' can be used instead of this command to recall a command by searching the most recent commands for a match.
Example: search for most recent 'sget' command
server1> !sget server1> sget /proc
+---x recall
+---w input
+---w index LogIndex
Command type: |
local |
Default parameter: |
index |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
data |
YANG file: |
Positive Response:
The specified command line is recalled into the current command line.
Negative Response:
An error message will be printed if errors are detected.
Usage:
> recall 7
> sget /system
record-test¶
The 'record-test' command is used to automatically record commands into a test script that is compatible with the test-suite command.
The 'start' sub-command is used to start recording a test. Once recording starts, all the commands entered are recorded for the test.
The 'finish' sub-command is used to finish recording a test. The recorded commands will be saved in the default or configured test suite file.
The 'cancel' sub-command is used to cancel recording a test. The recorded commands will be discarded.
The 'pause' sub-command is used to pause recording a test. The commands entered after this command will not be recorded.
The 'resume' sub-command is used to resume recording a paused test. The commands entered after this command will be recorded.
+---x record-test
+---w input
+---w (record-test-action)
+--:(cancel)
| +---w cancel? empty
+--:(start-case)
| +---w start empty
| +---w suite-name nt:NcxIdentifier
| +---w test-name nt:NcxIdentifier
+--:(finish)
| +---w finish? empty
+--:(pause)
| +---w pause? empty
+--:(resume)
+---w resume? empty
Command type: |
local |
Default parameter: |
suite-name |
Min parameters: |
1 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
Command Parameters:
choice record-test-action (not entered)
choice usage: mandatory
default: case: none
start-case
start
type: empty
Start recording a new test or replace an existing test. Only one test can be recorded at a time.
suite-name
type: NcxIdentifier
usage: mandatory
default: none
This parameter specifies the name of the test suite to use.
test-name
type: NcxIdentifier
usage: mandatory
default: none
This parameter specifies the name of the test to use.
finish
type: empty
default: none
Finish recording of the test in progress
cancel
type: empty
default: none
Cancel recording of the test in progress
pause
type: empty
default: none
Pause recording of the test in progress
resume
type: empty
default: none
Resume recording of the paused test in progress
Positive Response:
The requested action is performed for the specified test-suite and test.
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
andy@myserver> record-test start suite1 test-name=test1
Start recording: suite=suite1 test=test1
andy@myserver>
refresh-library¶
The 'refresh-library' is used to force yangcli-pro to re-scan for YANG modules.
If the YANG modules available on disk changes while the program is running, then this command can be used to refresh the module version list used to determine the 'best-match' for imports.
+---x refresh-library
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
status |
YANG file: |
Positive Response:
The specified command refreshes the module version list available for “best-match” imports revision tracking.
Negative Response:
An error message will be printed if errors are detected.
Usage:
> help refresh-library
rpc refresh-library
If the YANG modules available on disk changes while
the program is running, then this command can be
used to refresh the module version list used
to determine the 'best-match' for imports.
> refresh-library
OK
> show search-path-module
YANG Module Search Path
Current dir only: /home/username/swdev/ypwork/netconf/target/bin
HOME/modules: /home/username/modules
Default YUMAPRO_INSTALL: /usr/share/yumapro/modules
Start Dir: /home/username/swdev/ypwork/netconf/target/bin/modules
yangcli Cache: /home/username/.yumapro/.yangcli_cache
release-locks¶
The 'release-locks' command is used to release all the locks that were previously granted with the get-locks command.
If the get-locks command was not used, then this command will fail with an error message that no locks are active to unlock.
+---x release-locks
Command type: |
remote |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
status |
YANG file: |
Positive Response:
The previously granted locks are released.
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage: (showing 2 locks being released)
andy@myserver> release-locks
RPC OK Reply 8 for session 23:
RPC OK Reply 9 for session 23:
andy@myserver>
remove¶
The 'remove' command is a high-level <edit-config> operation. It is used to remove an existing subtree in the default target database, using the remove” operation, defined in RFC 6241,
This command will only work on NETCONF servers that support the RFC 6241 :base:1.1 capability
This command does not generate an error if the entry to delete does not exist.
A target node is specified, and then any missing key leafs (if any) within the data structure are filled in. If the target is a leaf-list, then the user will be prompted for the value of the leaf-list node to be removed.
Refer to the fill command for more details on interactive mode data structure completion.
+---x remove
+---w input
+---w target string
+---w value? <anyxml>
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
:base:1.1 :candidate or :writable-running |
Command Parameters:
target
type: string
usage: optional (urltarget or target must be present)
default: none
This parameter specifies the database target node of the delete operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$optional
Controls whether optional descendant nodes will be filled into the target parameter contents
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> remove /nacm/rules/data-rule
(user will be prompted to fill in the data-rule 'name' key leaf)
RPC OK Reply 15 for session 10:
andy@myserver> remove target=/nacm/rules/data-rule[name='test rule']/comment
(no user prompting; <edit-config> request sent right away)
RPC OK Reply 16 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.2
remove-all¶
The 'remove-all' command is a high-level <edit-config> operation. It is used to remove all instances of a list or leaf-list.
This is only supported for the netconfd-pro server.
The --allow-leaflist-delete-all parameter must be set to 'true' to use this operation on a leaf-list.
The --allow-list-delete-all parameter must be set to 'true' to use this operation on a list.
This command does not generate an error if the entry to delete does not exist.
The same restrictions as the remove command apply to this command.
Refer to the fill command for more details on interactive mode data structure completion.
+---x remove-all
+---w input
+---w (delete-target)
+--:(target)
| +---w target? string
+--:(urltarget)
+---w urltarget? ywt:UrlPath
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
:base:1.1 :candidate or :writable-running |
Command Parameters:
Choice of:
target
type: string
usage: optional (urltarget or target must be present)
default: none
This parameter specifies the database target node of the delete operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the replace operation. This is an UrlPath string.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$optional
Controls whether optional descendant nodes will be filled into the target parameter contents
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> remove-all /nacm/rules/data-rule
(user will be prompted to fill in the data-rule 'name' key leaf)
RPC OK Reply 15 for session 10:
andy@myserver>
Reference:
none
replace¶
The 'replace' command is a high-level <edit-config> operation. It is used to replace an existing subtree with some new nodes, in the default target database.
Only the subtree indicated by the 'target' or 'varref' parameter will be replaced.
A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'.
Refer to the fill command for more details on interactive mode data structure completion.
+---x replace
+---w input
+---w (from)
| +--:(varref)
| | +---w varref? string
| +--:(from-cli)
| +---w (target-parm)?
| | +--:(target)
| | | +---w target yang:xpath1.0
| | +--:(urltarget-case)
| | +---w urltarget ywt:UrlPath
| | +---w match-names? ywt:NameMatchMode
| | +---w alt-names? ywt:AltNameMode
| | +---w wildcard-keys? boolean
| +---w optional? empty
| +---w value? <anyxml>
+---w timeout? nt:Timeout
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
5 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the replace operation. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the target of the replace operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: optional (target or urltarget must be present)
default: none
This parameter specifies the database target node of the replace operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the replace operation. This is an UrlPath string.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
System Variables:
$$default-operation
The <default-operation> parameter for the <edit-config> operation will be derived from this variable.
$$error-option
The <error-option> parameter for the <edit-config> operation will be derived from this variable
$$test-option
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> replace \
target=/nacm/rules/moduleRule[moduleName='yuma-system']\
[allowed-rights='exec']
(user prompted to fill in specified <moduleRule> element)
RPC OK Reply 31 for session 10:
andy@myserver>
Reference:
RFC 6241, section 7.2
return¶
The 'return' command is available in config mode to cancel and discard all edits and exit config mode.
Command type: |
config mode |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none |
YANG file: |
none |
Command Parameters:
none
Positive Response:
The command prompt will change back to a normal session prompt
Negative Response:
An error message will be printed (e.g. invoked outside config mode)
Usage:
session1> conf t
session1# nacm groups group mygroup
session1(group)# user-name fred
session1(group)# user-name barney
session1(group)# return
session1>
restart¶
The 'restart' command is used to restart the NETCONF server.
This command is only supported by the netconfd-pro server.
The default access control configuration for netconfd-pro will not allow any user except the designated 'superuser' account to invoke this command.
The yuma-system.yang module must be loaded in the server for this command to be available.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <restart> operation for parameter details.
Usage:
andy@myserver> restart
ses: session 10 shut by remote peer
>
run¶
The 'run' command is used to invoke a yangcli-pro script.
Refer to the section on Scripts for details on how to write a script.
The script name is the only mandatory parameter.
There are 9 generic parameters (named P1 to P9) that can be used to pass string parameters to scripts.
Within a script, these are referenced with local variables ($1 to $9).
The run command can be used within a script.
Scripts do not return any status or data.
The run command can appear inside a script, starting a new run level. An error will occur if a loop occurs or too many nest levels are used. Up to 64 run levels are supported in yangcli-pro.
+---x run
+---w input
+---w script string
+---w P1? string
+---w P2? string
+---w P3? string
+---w P4? string
+---w P5? string
+---w P6? string
+---w P7? string
+---w P8? string
+---w P9? string
Command type: |
local |
Default parameter: |
script |
Min parameters: |
1 |
Max parameters: |
10 |
Return type: |
status |
YANG file: |
Command Parameters:
P1, P2, P3, P4, P5, P6, P7, P8, P9
type: string
usage: optional
default: none
These parameters provide a generic string parameter passing mechanism for each script invocation, similar to unix shell scripts. Within the script, the parameters $1, $2, $3, $4, $5, $6, $7, $8 and $9 will be non-NULL only if the corresponding 'Pn' parameter was set in the script invocation.
script
type: string
usage: mandatory
default: none
This parameter specifies the name of the script to be run. If a path specification is included, then it will be used. Otherwise the current script search path will be used to find the script.
System Variables:
$$runpath
Controls where yangcli-pro will look for files specified in the 'script' parameter.
Positive Response:
the specified script will be executed
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error, if any remote commands are contained in the script.
Usage:
> run connect P1=yangrocks
(commands and responses are printed as if they were typed)
andy@myserver>
resync-subscription¶
The 'resync-subscription' command is used to request
a full Push Update from the server.
The netconfd-pro server must have the yang-push bundle enabled
for this operation to be available.
The subscription-id that was returned in the establish-subscription operation must be used in this operation.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <resync-subscription> operation for parameter details.
Usage:
session1> resync-subscription id=2
RPC OK Reply 37 for session 10:
session1>
run-shell¶
The 'run-shell' command is an internal command to run a shell script The --allow-shell parameter must be set to 'true' for this command to be present.
The script name is the only mandatory parameter.
There are 9 generic parameters (named P1 to P9) that can be used to pass string parameters to scripts.
Within a script, these are referenced with local variables ($1 to $9).
Scripts do not return any status or data at this time.
The parameters P1 .. P9 will be converted to dollar parameters $0 to $N, where N is the number of 'Pn' parameters provided.
The parameters will be added to the command line in named order P1 through P9.
Environment variables are not used for script parameters since they could have naming conflicts, especially for recursive scripts.
Example:
server1> run-script test1.sh P3=foo P6=bar P1=baz
This script will be invoked with parameters $1=baz $2=foo $3=bar
+---x run-shell
+---w input
+---w script string
+---w P1? string
+---w P2? string
+---w P3? string
+---w P4? string
+---w P5? string
+---w P6? string
+---w P7? string
+---w P8? string
+---w P9? string
Command type: |
local |
Default parameter: |
script |
Min parameters: |
1 |
Max parameters: |
10 |
Return type: |
status |
YANG file: |
Command Parameters:
P1, P2, P3, P4, P5, P6, P7, P8, P9
type: string
usage: optional
default: none
These parameters provide a generic string parameter passing mechanism for each script invocation, similar to unix shell scripts. Within the script, the parameters $1, $2, $3, $4, $5, $6, $7, $8 and $9 will be non-NULL only if the corresponding 'Pn' parameter was set in the script invocation.
script
type: string
usage: mandatory
default: none
This parameter specifies the name of the script to be run. If a path specification is included, then it will be used. Otherwise the current script search path will be used to find the script.
System Variables:
$$runpath
Controls where yangcli-pro will look for files specified in the 'script' parameter.
Positive Response:
the specified script will be executed
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
> run-script test1.sh P3=foo P6=bar P1=baz
andy@myserver>
save¶
The 'save' command is used to save NETCONF database edits to non-volatile storage, on the server. It is a pseudo-command, mapped to other remote commands depending on which database target is supported by the server (<candidate> or <running>).
The 'save' command usually maps to either the commit or the copy-config command. Refer to the Using NETCONF Sessions section for more details.
+---x save
Command type: |
remote |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none |
YANG file: |
Positive Response:
The server returns one or two <ok/> responses.
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Usage:
andy@myserver> save
RPC OK Reply 34 on session 10
andy@myserver>
schema-server-cfg¶
The 'schema-server-cfg' command is used to access a named schema server.
There are 3 sub-commands:
create
show
delete
+---x schema-server-cfg
+---w input
+---w (schema-server-action)?
+--:(show-case)
| +---w show? IdentifierOrZero
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(delete)
| +---w delete? nt:NcxIdentifier
+--:(create)
+---w create nt:NcxName
+---w user-id nt:NcxName
+---w device-id? nt:NcxName
Command type: |
local |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
create
type: name string
This parameter specifies a new schema server to create.
show
type: name string.
This parameter specifies the name of the schema server to show.
The --brief, --normal, or --full parameter can be used for this sub-command.
delete
type: name string
This parameter specifies the name of the schema server to delete from the saved schema server in memory. An active schema server cannot be deleted.
Positive Response
A message indicating the create or delete was done will be printed. The show command will generate some formatted output showing information on the requested schema server.
Negative Response:
An error message will be printed if errors are detected.
Usage:
> schema-server-cfg create=schema-server-B user-id=userB device-id=deviceB
A new schema_server is created:
schema_server-id=schema-server-B name=schema-server-B device=deviceB user=userB
> schema-server-cfg show=schema-server-B
Schema Server: schema-server-B
Device Id: deviceB
User Id: userB
Connected: false
> schema-server-cfg delete=schema-server-B
Deleting saved schema_server 'schema-server-B'
schema-servers-cfg¶
The 'schema-servers-cfg' command is used to access the named schema server files.
There are 4 sub-commands:
clear
load
save
show (default)
+---x schema-servers-cfg
+---w input
+---w (schema-servers-action)?
+--:(show-case)
| +---w show? empty
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
clear
type: empty
This parameter indicates that all saved schema servers in memory be deleted. This cannot be done if any of the schema servers are currently active. Use 'schema-servers-cfg load' to restore the saved schema servers.
load
type: string
This parameter identifies the file specification for the saved chema servers to load. Any new named schema servers will be added to the named schema servers in memory.
save
type: name string
This parameter identifies the file specification for the saved schema servers config file to load. The saved chema servers in memory will be saved to this file.
show
type: name string; default: empty string == all schema servers
The --brief, --normal, or --full parameter can be used for this sub-command.
Positive Response:
A message indicating the load, save or clear was done will be printed. The show command will generate some formatted output showing information on the requested schema servers.
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
> schema-servers-cfg clear
Deleting 3 saved schema_servers
> schema-servers-cfg load=~/.yumapro/.yangcli_pro_schema_servers.conf-save
Loaded saved schema_servers OK from '~/.yumapro/.yangcli_pro_schema_servers.conf-save'
> schema-servers-cfg save
Saved 3 schema_servers OK to '~/.yumapro/.yangcli_pro_schema_servers.conf'
> schema-servers-cfg show
Saved schema_servers source: '~/.yumapro/.yangcli_pro_schema_servers.conf'
Schema Server: schema-serverA
Device Id: deviceB
User Id: userA
Connected: false
Schema Server: schema-server-ACER
Device Id: device-ACER
User Id: user-ACER
Connected: false
Schema Server: schema-server-asus2
Device Id: asus2-device
User Id: asus2
Connected: false
session¶
The 'session' command is used to set the current named session, if named sessions are used. The current session is used by yangcli-pro to decide where to send remote commands. Changing the current session allows commands typed at the CLI to be sent to the desired server session.
The only sub-command at this time is 'set-current', and the name of the session to be used as the new current session is the only parameter.
Refer to the section on “NETCONF Session Configuration” for more details on using saved sessions.
+---x session
+---w input
+---w set-current nt:NcxIdentifier
Command type: |
local |
Default parameter: |
set-current |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
set-default
type: name string
This mandatory parameter specifies the name of the session to set as the current session. The special session name 'default' is reserved for the session that can be activated with the 'connect' command.
Positive Response:
The session prompt should change to indicate the new current session.
Negative Response:
An error message will be printed if errors are detected locally.
andy@myserver> session set-current session-A
session-A>
session-cfg¶
The 'session-cfg' command is used to access a named session.
There are 3 sub-commands:
delete
save
show (default)
Refer to the NETCONF Session Configuration section for more details on using saved sessions.
+---x session-cfg
+---w input
+---w (session-action)?
+--:(show-case)
| +---w show? IdentifierOrZero
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(delete)
| +---w delete? nt:NcxIdentifier
+--:(save)
| +---w save? nt:NcxIdentifier
+--:(use-event-handler)
+---w use-event-handler* nt:NcxIdentifier
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
delete
type: name string
This parameter specifies the name of the session to delete from the saved sessions in memory. An active session cannot be deleted.
save
type: name string
This parameter specifies the name of the session to save in the saved sessions in memory.
show
type: name string; default: empty string == current session
This parameter specifies the name of the session to show. An empty string indicates that the current session should be used.
The --brief, --normal, or --full parameter can be used for this sub-command.
Positive Response:
A message indicating the save or delete was done will be printed. The show command will generate some formatted output showing information on the requested session.
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
andy@myserver> session-cfg save session-A
Saving current session as 'session-A'
andy@myserver>
sessions-cfg¶
The 'sessions-cfg' command is used to access the named session files.
There are 4 sub-commands:
clear
load
save
show (default)
Refer to the NETCONF Session Configuration section for more details on using saved sessions.
+---x sessions-cfg
+---w input
+---w (sessions-action)?
+--:(show-case)
| +---w show? empty
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
clear
type: empty
This parameter indicates that all saved sessions in memory be deleted. This cannot be done if any of the sessions are currently active. Use 'session-cfg load' to restore the saved sessions.
load
type: string
This parameter identifies the file specification for the saved sessions to load. Any new named sessions will be added to the named sessions in memory.
save
type: name string
This parameter identifies the file specification for the saved sessions config file to load. The saved sessions in memory will be saved to this file.
show
type: name string; default: empty string == all sessions
This parameter specifies the name of the session to show.
The --brief, --normal, or --full parameter can be used for this sub-command.
Positive Response:
A message indicating the load, save or clear was done will be printed. The show command will generate some formatted output showing information on the requested sessions.
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
session-A> sessions-cfg load ~/more-sessions.conf
Loading saved sessions from '/home/andy/more-sessions.conf'
Loaded saved sessions OK from '~/more-sessions.conf'
session-A>
set-log-level¶
The 'set-log-level' command is used to configure the server logging verbosity level. It is only supported by the netconfd-pro server.
This operation is defined as nacm:default-deny-all, so only a system superuser account can invoke this command by default.
This operation is defined in the yuma-system.yang and yumaworks-system.yang module so a prefix may be needed to use this command, depending on the server configuration. Both commands are the same.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <set-log-level> operation for parameter details.
Usage:
andy@myserver> set-log-level log-level=debug2
RPC OK Reply 29 for session 10:
andy@myserver>
set-my-session¶
The 'set-my-session' command is used to configure the session customization parameters on the server. It is only supported by the netconfd-pro server.
Since all parameters are optional, they need to be entered in the same command line as the command name. Otherwise the $$optional system variable needs to be set to 'true'. If not, then no parameters will be sent to the server, and no session parameters will be changed.
The yuma-mysession.yang module must be loaded in the server for this command to be available.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <set-my-session> operation for parameter details.
Usage:
andy@myserver> set-my-session --linesize=64 --with-defaults=trim --message-indent=1
RPC OK Reply 25 for session 10:
andy@myserver>
sget¶
The 'sget' command is used to invoke a NETCONF <get> operation with a subtree filter.
A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the 'nofill' parameter.
Refer to the fill command for more details on interactive mode data structure completion.
+---x sget
+---w input
| +---w (from)
| | +--:(varref)
| | | +---w varref? string
| | +--:(from-cli)
| | +---w (target-parm)?
| | | +--:(target)
| | | | +---w target yang:xpath1.0
| | | +--:(urltarget-case)
| | | +---w urltarget ywt:UrlPath
| | | +---w match-names? ywt:NameMatchMode
| | | +---w alt-names? ywt:AltNameMode
| | | +---w wildcard-keys? boolean
| | +---w optional? empty
| | +---w value? <anyxml>
| +---w nofill? empty
| +---w with-defaults? CliWithDefaultsType
| +---w depth? union
| +---w module-tag* string
+--ro output
+--ro data? <anyxml>
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
1 |
Max parameters: |
6 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the subtree filter target of the <get> operation. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the subtree filter target of the <get> operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: optional (target or urltarget must be present)
default: none
This parameter specifies the database target node of the <get> operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
The escape command ('?s') can be used in parameter mode to skip a parameter completely.
Entering the empty string for a parameter will cause a subtree selection node to be created instead of a content match node
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the get operation. This is an UrlPath string.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.
nofill
type: empty
usage: optional
default: none
This parameter specifies the that no interactive prompting to fill in the contents of the specified subtree filter target will be done.
This causes the entire selected subtree to be requested in the filter.
yangcli-pro will attempt to figure out if there can be multiple instances of the requested subtree. If not, then 'nofill' will be the default for that target parameter.
with-defaults
type: enumeration (none report-all report-all-tagged trim explicit)
usage: optional
default: none
capabilities needed: with-defaults
This parameter controls how nodes containing only default values are returned in the <rpc-reply>.
depth
type: uint32 or “unbounded”
usage: optional
default: unbounded
capabilities needed: none: netconfd-pro NETCONF extension
This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.
module-tag:
type: string
default: none
capabilities needed: none
This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.
System Variables:
$$timeout
The response timeout interval will be derived from this system variable.
$$with-defaults
The <with-defaults> parameter for the <get> operation will be derived from this system variable.
Positive Response:
the server returns <data>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Output:
data
type: anyxml
This element will contain the requested data from the <running> database or non-config data structures.
Usage:
andy@myserver> sget system
Filling container /system:
RPC Data Reply 32 for session 10:
rpc-reply {
data {
system {
sysName myserver.localdomain
sysCurrentDateTime 2009-07-06T02:24:19Z
sysBootDateTime 2009-07-05T19:22:28Z
}
}
}
andy@myserver>
Reference:
RFC 6241, section 7.7
sget-config¶
The 'sget-config' command is used to invoke a NETCONF <get-config> operation with a subtree filter.
A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the 'nofill' parameter.
Refer to the fill command for more details on interactive mode data structure completion.
+---x sget-config
+---w input
| +---w (from)
| | +--:(varref)
| | | +---w varref? string
| | +--:(from-cli)
| | +---w (target-parm)?
| | | +--:(target)
| | | | +---w target yang:xpath1.0
| | | +--:(urltarget-case)
| | | +---w urltarget ywt:UrlPath
| | | +---w match-names? ywt:NameMatchMode
| | | +---w alt-names? ywt:AltNameMode
| | | +---w wildcard-keys? boolean
| | +---w optional? empty
| | +---w value? <anyxml>
| +---w nofill? empty
| +---w with-defaults? CliWithDefaultsType
| +---w depth? union
| +---w module-tag* string
| +---w source
| +---w (config-source)
| +--:(candidate)
| | +---w candidate? empty {nc:candidate}?
| +--:(running)
| | +---w running? empty
| +--:(startup)
| | +---w startup? empty {nc:startup}?
| +--:(url)
| +---w url? nc:ConfigURIType {nc:url}?
+--ro output
+--ro data? <anyxml>
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
2 |
Max parameters: |
7 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the subtree filter target of the <get> operation. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the subtree filter target of the <get> operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: optional (target or urltarget must be present)
default: none
This parameter specifies the database target node of the <get> operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
The escape command ('?s') can be used in parameter mode to skip a parameter completely.
Entering the empty string for a parameter will cause a subtree selection node to be created instead of a content match node
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the get-config operation. This is an UrlPath string.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.
nofill
type: empty
usage: optional
default: none
This parameter specifies the that no interactive prompting to fill in the contents of the specified subtree filter target will be done.
This causes the entire selected subtree to be requested in the filter.
yangcli-pro will attempt to figure out if there can be multiple instances of the requested subtree. If not, then nofill will be the default for that target parameter.
source
type: container with 1 of N choice of leafs
usage: mandatory
default: none
This parameter specifies the name of the source database for the retrieval operation.
container contents: 1 of N:
candidate
type: empty
capabilities needed: :candidate
running
type: empty
capabilities needed: none
startup
type: empty
capabilities needed: startup
url
with-defaults
type: enumeration (none report-all report-all-tagged trim explicit)
usage: optional
default: none
capabilities needed: with-defaults
This parameter controls how nodes containing only default values are returned in the <rpc-reply>.
depth
type: uint32 or “unbounded”
usage: optional
default: unbounded
capabilities needed: none: netconfd-pro NETCONF extension
This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.
module-tag:
type: string
default: none
capabilities needed: none
This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.
System Variables:
$$timeout
The response timeout interval will be derived from this system variable.
$$with-defaults
The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.
Positive Response:
the server returns <data>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Output:
data
type: anyxml
This element will contain the requested data from the database indicated by the 'source' parameter.
Usage:
andy@myserver> sget-config /nacm/rules/data-rule \
source=candidate \
nofill
RPC Data Reply 35 for session 10:
rpc-reply {
data {
nacm {
rules {
data-rule nacm-tree {
name nacm-tree
path /nacm:nacm
allowed-rights {
read
write
}
allowed-group nacm:admin
comment 'access to nacm config'
}
}
}
}
}
andy@myserver>
sget-data¶
The 'sget-data' command is used to invoke a NETCONF NMDA <get-data> operation with a subtree filter.
This command will not work unless the server supports the <get-data> operation from RFC 8526, in ietf-netconf-nmda.yang.
A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the 'nofill' parameter.
Refer to the fill command for more details on interactive mode data structure completion.
The ietf-netconf-nmda.yang module must be loaded in the server for this command to be available.
+---x sget-data
+---w input
| +---w datastore? enumeration
| +---w (from)
| | +--:(varref)
| | | +---w varref? string
| | +--:(from-cli)
| | +---w (target-parm)?
| | | +--:(target)
| | | | +---w target yang:xpath1.0
| | | +--:(urltarget-case)
| | | +---w urltarget ywt:UrlPath
| | | +---w match-names? ywt:NameMatchMode
| | | +---w alt-names? ywt:AltNameMode
| | | +---w wildcard-keys? boolean
| | +---w optional? empty
| | +---w value? <anyxml>
| +---w nofill? empty
| +---w with-defaults? CliWithDefaultsType
| +---w depth? union
| +---w module-tag* string
| +---w config-filter? boolean
| +---w (origin-filters)?
| | +--:(origin-filter)
| | | +---w origin-filter* or:origin-ref
| | +--:(negated-origin-filter)
| | +---w negated-origin-filter* or:origin-ref
| +---w with-origin? empty
+--ro output
+--ro data? <anyxml>
Command type: |
remote |
Default parameter: |
target |
Min parameters: |
2 |
Max parameters: |
8 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'from-cli'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the subtree filter target of the <get> operation. It is either a user variable or from interactive input at the command line.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable to use for the subtree filter target of the <get> operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.
case from-cli (not entered)
target
type: string
usage: optional (target or urltarget must be present)
default: none
This parameter specifies the database target node of the <get> operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.
The escape command ('?s') can be used in parameter mode to skip a parameter completely.
Entering the empty string for a parameter will cause a subtree selection node to be created instead of a content match node
urltarget
type: string
usage: optional
default: none
This parameter specifies the database target node of the get-config operation. This is an UrlPath string.
optional
type: empty
usage: optional
default: controlled by $$optional system variable
This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.
value
type: anyxml
usage: mandatory
default: none
This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.
nofill
type: empty
usage: optional
default: none
This parameter specifies the that no interactive prompting to fill in the contents of the specified subtree filter target will be done.
This causes the entire selected subtree to be requested in the filter.
yangcli-pro will attempt to figure out if there can be multiple instances of the requested subtree. If not, then nofill will be the default for that target parameter.
datastore
type: leaf containing a datastore-ref
usage: mandatory
This parameter specifies the name of the source NMDA datastore for the retrieval operation.
enumeration:
candidate
capabilities needed: :candidate
running
capabilities needed: none
startup
capabilities needed: startup
operational
capabilities needed: none
with-defaults
type: enumeration (none report-all report-all-tagged trim explicit)
usage: optional
default: none
capabilities needed: with-defaults
This parameter controls how nodes containing only default values are returned in the <rpc-reply>.
depth
type: uint32 or “unbounded”
usage: optional
default: unbounded
capabilities needed: none
This parameter controls how many levels of subtrees should be returned in the <rpc-reply>. This is called the <max-depth> parameter in the <get-data> operations.
config-filter:
type boolean
Specifies the type of data based on config-stmt. Retrieve all data if this parameter is not present. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.
Only relevant if the datastore parameter is ‘operational’.
If set to ‘false’ for any datastore other than ‘operational’ then an empty <data> element will be returned.
origin-filter:
type: leaf-list of type origin-ref..
This parameter will select data nodes with the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.
Cannot be used if negated-origin-filter present
Can only be used if the datastore parameter is ‘operational’
negated-origin-filter:
type: leaf-list of type origin-ref..
This parameter will select data nodes if they do not have the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.
Cannot be used if origin-filter present
Can only be used if the datastore parameter is ‘operational’
with-origin
type: empty
This parameter will cause the origin attribute to be added to data nodes returned by the server.
Can only be used if the datastore parameter is ‘operational’
System Variables:
$$timeout
The response timeout interval will be derived from this system variable.
$$with-defaults
The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.
Positive Response:
the server returns <data>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Output:
data
type: anyxml
This element will contain the requested data from the database indicated by the 'source' parameter.
Usage:
Reference:
RFC 8526, section 3.1.1
show¶
The 'show' command is used to show program status and YANG details that may be needed during management of a NETCONF server.
There are several variants of the 'show' command:
The show cache command prints the yangcli-pro YANG module cache.
The show connected command prints the all connected sessions.
The show cli command prints the contents of the yangcli-pro CLI and config file parameters.
The show diff command prints the differences between current config and the edits that have not been applied yet.
The show edit command prints subtree that is the current node which is from the current edit, not the stored config.
The show connected command prints a summary of the sessions that are currently connected
The show global command prints the contents of one global user variable.
The show globals command prints a summary or the contents of all the global user variables.
The show local command prints the contents of one local user variable.
The show locals command prints a summary or the contents of all the local user variables.
The show module command prints meta information or help text for one YANG module.
The show modules command prints meta information for all the currently available YANG modules. If a session is active, this will be the list of modules the server reported, plus any modules loaded with the mgrload command.
The show modules-state command prints cached modules-state for each server.
The show objects command prints the available objects or help text for the available objects.
The show running command prints the entire config for the current session , error if there is no current session.
The show session command prints the session startup screen information for the current session.
The show search-path-module command prints the YANG module search path in use.
The server-commands prints the server commands (not in config mode). It is top-level only and only relevant if session is connected.
The show system command prints the contents of the yangcli-pro system variables.
The show terminal command prints the terminal length
The show var command prints the contents of the specified variable.
The show vars command prints a summary or the contents of all the program variables.
The show version command prints the yangcli-pro version number
+---x show
+---w input
+---w (showtype)
| +--:(cache)
| | +---w cache? empty
| +--:(cli)
| | +---w cli? empty
| +--:(diff)
| | +---w diff? empty
| +--:(edit)
| | +---w edit? empty
| +--:(connected)
| | +---w connected? empty
| +--:(module)
| | +---w module? nt:NcxIdentifier
| +--:(modules)
| | +---w modules? empty
| +--:(modules-state)
| | +---w modules-state? empty
| +--:(local)
| | +---w local? nt:NcxName
| +--:(locals)
| | +---w locals? empty
| +--:(global)
| | +---w global? nt:NcxName
| +--:(globals)
| | +---w globals? empty
| +--:(group-vars)
| | +---w group-vars? IdentifierOrZero
| +--:(objects)
| | +---w objects? empty
| +--:(running)
| | +---w running empty
| | +---w select? string
| +--:(search-path-module)
| | +---w search-path-module? empty
| +--:(server-commands)
| | +---w server-commands? empty
| +--:(session)
| | +---w session? empty
| +--:(session-vars)
| | +---w session-vars? IdentifierOrZero
| +--:(system)
| | +---w system? empty
| +--:(terminal)
| | +---w terminal? empty
| +--:(var)
| | +---w var? nt:NcxName
| +--:(vars)
| | +---w vars? empty
| +--:(version)
| +---w version? empty
+---w (help-mode)?
+--:(brief)
| +---w brief? empty
+--:(normal)
| +---w normal? empty
+--:(full)
+---w full? empty
Command type: |
local |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
data |
YANG file: |
Command Parameters:
choice help-mode (not entered) (default choice is 'normal')
brief
type: empty
usage: optional
default: none
This parameter specifies that brief documentation mode should be used.
normal
type: empty
usage: optional
default: none
This parameter specifies that normal documentation mode should be used.
full
type: empty
usage: optional
default: none
This parameter specifies that full documentation mode should be used.
choice showtype (not entered)
mandatory 1 of N choice for the sub-command for the 'show' command
cli
type: empty
usage: mandatory
default: none
This parameter selects the yangcli-pro CLI and configuration variables.
Connected
type: empty
usage: mandatory
default: none
This parameter prints a summary of the currently connected sessions.
diff
type: empty
usage: mandatory
default: none
The parameter prints the differences between current config and the edits that have not been applied yet.
edit
type: empty
usage: mandatory
default: none
The parameter prints subtree that is the current node which is from the current edit, not the stored config.
global
type: string
usage: mandatory
default: none
This parameter specifies the name of the global variable to show information for.
If help-mode is 'brief', then the name, variable object, and type of the global variable object will be printed.
If help-mode is 'normal' or 'full', then the contents of the specified global variable will be printed.
globals
type: empty
usage: mandatory
default: none
This parameter specifies that information for all global variables should be printed.
If help-mode is 'brief', then the name, variable object, and type of each global variable object will be printed.
If help-mode is 'normal' or 'full', then the contents of each global variable will be printed.
local
type: string
usage: mandatory
default: none
This parameter specifies the name of the local variable to show information for.
If help-mode is 'brief', then the name, variable object, and type of the local variable object will be printed.
If help-mode is 'normal' or 'full', then the contents of the specified local variable will be printed.
locals
type: empty
usage: mandatory
default: none
This parameter specifies that information for all local variables should be printed.
If help-mode is 'brief', then the name, variable object, and type of each local variable object will be printed.
If help-mode is 'normal' or 'full', then the contents of each local variable will be printed.
module
type: string
usage: mandatory
default: none
This parameter specifies the name of the module to show information for.
If help-mode is 'brief' or 'normal', then the name, version, namespace, and source of the module will be printed.
If help-mode is 'full', then the module level help text for the specified module will be printed.
modules
type: empty
usage: mandatory
default: none
This parameter specifies that information for all available modules should be printed:
If help-mode is 'brief', then the name of each module will be printed.
If help-mode is 'normal', then the XML prefix, name, and revision date of each module will be printed.
If help-mode is 'full', then the name, revision date, prefix, namespace, and source of each module will be printed.
objects
type: empty
usage: mandatory
default: none
This parameter specifies that information for all available database objects should be printed:
If help-mode is 'brief', then the module name and name of each object will be printed.
If help-mode is 'normal', then the YANG object type, object name, and YANG base type will be printed.
If help-mode is 'full', then brief help text will be printed for every object.
running
type: empty
usage: mandatory
default: none
This parameter prints the entire config for the current session , error if there is no current session.
Search-path-module
type: empty
usage: mandatory
default: none
This parameter specifies that the YANG module search path should be printed.
Server-commands
type: empty
usage: mandatory
default: none
This parameter display server commands (not in config mode).
System
type: empty
usage: mandatory
default: none
This parameter specifies that information for all system variables should be printed.
terminal
type: empty
usage: mandatory
default: none
This parameter specifies that information about the terminal settings should be printed.
var
type: string
usage: mandatory
default: none
This parameter specifies the name of any variable to show information for.
If help-mode is 'brief', then the name, variable object, and type of the variable object will be printed.
If help-mode is 'normal' or 'full', then the contents of the specified variable will be printed.
vars
type: empty
usage: mandatory
default: none
This parameter specifies that information for all variables should be printed. This includes all CLI, read-only system, read-write system, global user, and local user variables.
If help-mode is 'brief', then the name, variable object, and type of each variable object will be printed.
If help-mode is 'normal' or 'full', then the contents of each variable will be printed.
version
type: empty
usage: mandatory
default: none
This parameter specifies that the yangcli-pro program version string should be printed.
Positive Response:
the server prints the requested information
Negative Response:
An error message will be printed if errors are detected.
Usage:
andy@myserver> show modules
nc:netconf/2009-04-10
inet:ietf-inet-types/2009-05-13
ns:ietf-netconf-monitoring/2009-03-03
wd:ietf-with-defaults/2009-04-10
yang:ietf-yang-types/2009-05-13
nacm:nacm/2009-05-13
manageEvent:nc-notifications/2008-07-14
ncx:ncx/2009-06-12
ncxapp:ncx-app-common/2009-04-10
nt:ncxtypes/2008-07-20
nd:netconfd-pro/2009-05-28
ncEvent:notifications/2008-07-14
sys:system/2009-06-04
t:test/2009-06-10
andy@myserver>
andy@myserver> show running
data {
nacm {
groups {
group aa {
name aa
user-name a1
user-name a2
}
}
}
}
andy@myserver> sho edit
Only available in config mode.
andy@myserver> sho diff
Only available in config mode.
andy@myserver> conf t
andy@myserver# nacm groups
andy@myserver(groups)# group bb
andy@myserver(group)# user-name b1
andy@myserver(group)# user-name b2
andy@myserver(group)# do show edit
nacm {
groups {
group bb {
name bb
user-name b1
user-name b2
}
}
}
andy@myserver(group)# do show diff
Edited to merge:
nacm {
groups {
group bb {
name bb
user-name b1
user-name b2
}
}
}
Configured:
nacm {
groups {
group aa {
name aa
user-name a1
user-name a2
}
}
}
andy@myserver(group)# apply
Applying 1 edit to session 'default'
andy@myserver(group)# do sho running
data {
nacm {
groups {
group aa {
name aa
user-name a1
user-name a2
}
group bb {
name bb
user-name b1
user-name b2
}
}
}
}
andy@myserver(group)#
shutdown¶
The 'shutdown' command is used to shut down the NETCONF server. This command is only supported by the netconfd-pro server.
The default access control configuration for netconfd-pro will not allow any user except the designated 'superuser' account to invoke this command. Refer to the Access Control section for details.
The yuma-system.yang module must be loaded in the server for this command to be available.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <shutdown> operation for parameter details.
Usage:
andy@myserver> shutdown
ses: session 10 shut by remote peer
>
sleep¶
The 'sleep' command is used to pause for a number of seconds. It is intended to be used within a script.
Example script:
# send 20 get-config requests, 1 per second
while 1 maxloops=20
get-config source=running
sleep 1
end
+---x sleep
+---w input
+---w seconds uint16
Command type: |
local |
Default parameter: |
seconds |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
none |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
none |
Command Parameters:
seconds
type: uint16 (1 .. 3600)
usage: mandatory
This parameter specifies the number of seconds to sleep
Positive Response:
none
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
session-B> sleep 1
session-B>
start-rpc-timing¶
The 'start-rpc-timing' command is used to start remote operation timing mode, except that statistics can be saved to a text file for plotting or for data entry into a database program. It is used to do simple roundtrip performance measurements. It is used along with the stop-rpc-timing command.
This command automatically sets the following variables to temporary values, which are restored when the stop-rpc-timing command is invoked.
$$echo-replies = false
$$rpc-timing = true
$$rpc-timing-stats = true
+---x start-rpc-timing
+---w input
+---w statfile? string
Command type: |
local |
Default parameter: |
statfile |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
none |
Command Parameters:
statfile
type: file specification
usage: mandatory
This parameter specifies the file specification for saving the timing statistics.
Positive Response:
the client prints OK
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
session-B> start-rpc-timing
OK
session-B>
start-session¶
The 'start-session' command is used to start a session with a NETCONF server. It is similar to the connect command except the parameters are derived from a saved session in memory instead of entered explicitly.
+---x start-session
+---w input
+---w name? nt:NcxIdentifier
Command type: |
local |
Default parameter: |
name |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
name
type: session name string
usage: mandatory
This parameter specifies the name of the session to start.
Positive Response:
The startup screen for the session should be generated and the prompt should change, indicating the new named session is now the current session.
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
session-A> start-session session-B
yangcli: Starting NETCONF session for user on myserver
NETCONF session established for user on myserver
Client Session Id: 2
Server Session Id: 4
Server Protocol Capabilities
base:1.0
candidate:1.0
confirmed-commit:1.0
rollback-on-error:1.0
validate:1.0
url:1.0
xpath:1.0
notification:1.0
interleave:1.0
partial-lock:1.0
with-defaults:1.0
base:1.1
validate:1.1
confirmed-commit:1.1
yang-library:1.0
Server Module Capabilities
ietf-inet-types@2010-09-24
ietf-netconf-acm@2012-02-22
ietf-netconf-monitoring@2010-10-04
ietf-netconf-partial-lock@2009-10-19
ietf-netconf-with-defaults@2011-06-01
ietf-yang-library@2016-06-21
ietf-yang-types@2010-09-24
nc-notifications@2008-07-14
notifications@2008-07-14
yuma-app-common@2012-08-16
yuma-arp@2012-01-13
yuma-interfaces@2012-01-13
yuma-mysession@2010-05-10
yuma-ncx@2012-01-13
yuma-proc@2010-06-01
yuma-system@2012-01-15
yuma-time-filter@2011-08-13
yuma-types@2012-06-01
yumaworks-app-common@2012-08-16
yumaworks-extensions@2012-06-28
Server Enterprise Capabilities
None
Protocol version set to: RFC 6241 (base:1.1)
Default target set to: <candidate>
Save operation mapped to: commit
Default with-defaults behavior: explicit
Additional with-defaults behavior: trim,report-all,report-all-tagged
Yang-Library set to: RFC 7895
module-set-id: 6765
Checking Server Modules...
session-B>
start-timer¶
The 'start-timer' command is used to start a timer to do simple performance measurements. It is used along with the stop-timer command.
+---x start-timer
+---w input
+---w id? TimerId
+---w restart-ok? boolean
Command type: |
local |
Default parameter: |
id |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
none |
Command Parameters:
id
type: number
usage: mandatory
default: 0
This parameter specifies the numeric ID of the timer. It is a number in the range 0 to 15.
restart-ok
type: boolean
usage: optional
default: true
Indicates whether the timer will be used if it is already running. If 'true', the timer will be restarted if it is already running. If 'false', an error will occur if the timer is already running.
Positive Response:
the client prints OK
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
andy@myserver> start-timer 1
OK
andy@myserver>
stop-rpc-timing¶
The 'stop-rpc-timing' command is used to stop remote operation timing mode. It is used with the start-rpc-timing command. This command automatically sets the following variables to the specified values:
$$echo-replies = <previous value before start-rpc-timing>
$$rpc-timing = false
$$rpc-timing-stats = false
+---x stop-rpc-timing
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
none |
Positive Response:
the client prints OK
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
session-B> stop-rpc-timing
OK
session-B>
stop-session¶
The 'stop-session' command is used to stop a session with a NETCONF server. It will invoke the close-session command for the specified session. It is used with the start-session command.
+---x stop-session
+---w input
+---w name nt:NcxIdentifier
Command type: |
local |
Default parameter: |
name |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
name
type: session name string
usage: mandatory
This parameter specifies the name of the session to stop. The string 'default' is used to identify the default session, if that was started with the start-session or connect command.
Positive Response:
The prompt should change if the current session is stopped
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
session-B> stop-session session-B
RPC OK Reply 4 for session 4 [session-B]:
ses: session 2 shut by remote peer
>
stop-timer¶
The 'stop-timer' command is used to stop a timer to do simple performance measurements. It is used along with the start-timer command.
+---x stop-timer
+---w input
| +---w id? TimerId
| +---w echo? boolean
+--ro output
+--ro delta? decimal64
Command type: |
local |
Default parameter: |
id |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
none |
Command Parameters:
id
type: number
usage: mandatory
default: 0
This parameter specifies the numeric ID of the timer. It is a number in the range 0 to 15.
echo
type: boolean
usage: optional
default: true
Indicates whether the delta result should be printed to the log.
Positive Response:
data: the elapsed time is returned and can be used in assignment statements
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
andy@myserver> $time = stop-timer 1
Elapsed time: 2.003345 seconds
andy@myserver>
terminal¶
The 'terminal' command is used to change the terminal settings.
It is used along with the 'show terminal' command.
+---x terminal
+---w input
+---w length uint16
Command type: |
local |
Default parameter: |
length |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
none |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
none |
Command Parameters:
length
type: number
usage: mandatory
default: 0
This parameter specifies the length of the terminal to use for page mode output with the -More- prompt. This parameter is ignored in batch mode. It is only used if the output session is operating in interactive mode.
If the value 0 is used then the 'More' prompt will be disabled. Otherwise this value represents the number of lines to output for each screen in pagination output mode.
Positive Response:
OK
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
andy@myserver> terminal length 20
OK
andy@myserver>
test-suite¶
The 'test-suite' command is used to access yangcli-pro regression test scripts. Refer to the section on Automated Testing for more details.
This command has 5 sub-commands:
load
run-all
show (default)
start ('log' parameter also allowed in this mode)
save
+---x test-suite
+---w input
+---w suite-name? nt:NcxIdentifier
+---w log? string
+---w (test-suite-action)?
+--:(delete)
| +---w delete? empty
+--:(delete-test-case)
| +---w delete-test? empty
| +---w test-name nt:NcxIdentifier
+--:(show-case)
| +---w show? IdentifierOrZero
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(load)
| +---w load? string
+--:(run-all)
| +---w run-all? empty
+--:(start)
| +---w start? nt:NcxIdentifier
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
0 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
none |
Command Parameters:
suite-name:
type: identifier string
usage: mandatory if 'delete' or 'delete-test' used.
This parameter identifies the test suite to delete for use with the delete and delete-test sub-commands.
test-name:
type: identifier string
usage: mandatory if 'delete-test' used.
This parameter identifies the test to delete for use with the delete-test sub-command.
choice test-suite-action (default show)
delete
type: empty
usage: optional
This parameter is used to delete a test-suite from memory. The 'suite-name' parameter must also be present.
delete-test
type: empty
usage: optional
This parameter is used to delete a test-suite from memory. The 'suite-name' and 'test-name' parameters must also be present.
load
type: string
usage: optional
This parameter specifies the name of the test-suite configuration file to load.
run-all
type: empty
usage: optional
Run all the test-suites defined in the test suite config files. The 'log' parameter may also be present if this parameter is used.
save
type: string
usage: optional
This parameter identifies the file specification of the test-suite configuration file where the test-suites in memory should be saved.
show
type: string
usage: optional
This parameter specifies the name of the test-suite in memory to show.
The --brief, --normal, or --full parameters can be used with this sub-command.
start
type: name string
usage: optional
This parameter specifies the name of the test-suite to start. This sub-command can only be used if a test-suite is not already in progress.
log (available only if 'start' or 'run-all' is present)
type: filespec string
usage: optional
This parameter specifies the name of the log file for the test-suite test run and results. If no parameter is specified, then STDOUT will be used instead.
Positive Response:
The appropriate data will be shown for a 'show' sub-command.
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
andy@myserver> test-suite start ~/mytests.conf
... commands from test executed
andy@myserver>
unlock¶
The 'unlock' command is used to request a global lock on a NETCONF database. It is used, along with the lock command, to obtain exclusive write access to the NETCONF server.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <unlock> operation for parameter details.
Usage:
andy@myserver> unlock target=candidate
RPC OK Reply 38 for session 10:
andy@myserver>
unset¶
The 'unset' command is used to delete a command alias from memory.
+---x unset
+---w input
+---w name nt:NcxName
Command type: |
local |
Default parameter: |
name |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
name
type: string
usage: mandatory
default: none
This parameter specifies the name of the command alias to delete.
Positive Response:
Deleted alias 'foo' is printed, where 'foo' is the name parameter string
Negative Response:
An error message will be printed.
An <rpc-error> message will be printed if the server detected an error.
Usage:
> unset get-running
Deleted alias 'get-running'
>
update-config¶
The 'update-config' command is used to
force an update of the configuration cache for the current session.
The current session must be connected and the
$$autoconfig system variable must be true,
or an error will be returned.
+---x update-config
Command type: |
local |
Default parameter: |
none |
Min parameters: |
0 |
Max parameters: |
0 |
Return type: |
none |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters: none
Positive Response:
Nothing will be printed unless the log-level is set to
debugor higher.
andy@myserver> update-config
andy@myserver>
Negative Response:
An error message will be printed if the current content is not an active session or the --autoconfig CLI parameter and
$$autoconfigvariable is set totrue.
andy@myserver> update-config
Error: auto-configure mode disabled for session 'default'
andy@myserver>
user-cfg¶
The 'user-cfg' command is used to access a named user.
There are 4 sub-commands:
delete
save
show (default)
create
Refer to the section on NETCONF User Configuration for more details on using saved users.
+---x user-cfg
+---w input
+---w (user-action)?
+--:(show-case)
| +---w show? IdentifierOrZero
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(delete)
| +---w delete? nt:NcxIdentifier
+--:(save)
| +---w save? nt:NcxIdentifier
+--:(create)
+---w create nt:NcxName
+---w user-name nt:NcxName
+---w password string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
delete
type: name string
This parameter specifies the name of the user to delete from the saved users in memory. An active user cannot be deleted.
save
type: name string
This parameter specifies the name of the user to save in the saved users in memory.
show
type: name string; default: empty string == current user
This parameter specifies the name of the user to show. An empty string indicates that the current user should be used.
The --brief, --normal, or --full parameter can be used for this sub-command.
create
type: name string
This parameter specifies a new user to create.
Positive Response:
A message indicating the save or delete was done will be printed. The show command will generate some formatted output showing information on the requested user.
Negative Response:
An error message will be printed if errors are detected locally.
andy@myserver> user-cfg save user-A
Saving current user as 'user-A'
andy@myserver>
> user-cfg create=usr1 user-name=admin password=password
A new user is created: user-id=usr1 name=admin password=password
users-cfg¶
The 'users-cfg' command is used to access the named user files.
There are 4 sub-commands:
clear
load
save
show (default)
Refer to the section on NETCONF User Configuration for more details on using saved users.
+---x users-cfg
+---w input
+---w (users-action)?
+--:(show-case)
| +---w show? empty
| +---w (help-mode)?
| +--:(brief)
| | +---w brief? empty
| +--:(normal)
| | +---w normal? empty
| +--:(full)
| +---w full? empty
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
show |
Min parameters: |
1 |
Max parameters: |
2 |
Return type: |
status |
YANG file: |
|
Capabilities needed: |
none |
Command Parameters:
clear
type: empty
This parameter indicates that all saved users in memory be deleted. This cannot be done if any of the users are currently active. Use 'user-cfg load' to restore the saved users.
load
type: string
This parameter identifies the file specification for the saved users to load. Any new named users will be added to the named users in memory.
save
type: name string
This parameter identifies the file specification for the saved users config file to load. The saved users in memory will be saved to this file.
show
type: name string; default: empty string == all devices
This parameter specifies the name of the user to show.
The --brief, --normal, or --full parameter can be used for this sub-command.
Positive Response:
A message indicating the load, save or clear was done will be printed. The show command will generate some formatted output showing information on the requested users.
Negative Response:
An error message will be printed if errors are detected locally.
Usage:
session-A> users-cfg load ~/more-users.conf
Loading saved users from '/home/andy/more-users.conf'
Loaded saved users OK from '~/more-users.conf'
uservars¶
The uservars command is used to clear, load, or save the global user variables.
+---x uservars
+---w input
+---w (uservars-action)
+--:(clear)
| +---w clear? empty
+--:(load)
| +---w load? string
+--:(save)
+---w save? string
Command type: |
local |
Default parameter: |
none |
Min parameters: |
1 |
Max parameters: |
1 |
Return type: |
status |
YANG file: |
Command Parameters:
uservars-action
type: choice
usage: mandatory
default: none
clear:
Delete all global user variables from memory
load [uservars-filespec]
Load global user variables into memory from an XML file. If the 'uservars-filespec' parameter is missing, then the default file (
$HOME/.yumapro/yangcli_pro_uservars.xml) will be used.
save [uservars-filespec]
Save the global user variables from memory into an XML file. If the 'uservars-filespec' parameter is missing, then the default file (
$HOME/.yumapro/yangcli_pro_uservars.xml) will be used.
Positive Response:
A status message is printed.
Negative Response:
An error message will be printed.
Usage:
> uservars clear
Deleted all global user variables from memory
>
validate¶
The 'validate' command is used to check if a complete NETCONF database is valid or not. The :validate capability must be supported by the server to use this command.
This command is provided by the NETCONF server, not yangcli-pro. Refer to the <validate> operation for parameter details.
Usage:
andy@myserver> validate source=candidate
RPC OK Reply 36 for session 10:
andy@myserver>
while¶
The 'while' command is used to start a conditional loop command block.
The 'expr' parameter is used to specify the XPath expression to test if the while conditional loop block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.
The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.
If the 'expr' expression is true, the conditional block will be executed, and no further conditional blocks within the same if command sequence will be executed.
The maxloops parameter specifies the maximum number of iterations that should be allowed, even if the expression continues to evaluate to 'true'. This allows constant expressions to be used to construct a simple 'for' loop.
while command
...
end command
The 'while' command must be paired with a matching end command.
+---x while
+---w input
+---w expr yang:xpath1.0
+---w docroot? <anyxml>
+---w maxloops? uint32
Command type: |
local |
Default parameter: |
expr |
Min parameters: |
1 |
Max parameters: |
3 |
Return type: |
status |
YANG file: |
Command Parameters:
expr
type: XPath expression string
usage: mandatory
default: none
This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.
docroot
type: anyxml
usage: optional (typically a variable reference is used)
default: none
This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.
maxloops
type: uint32
usage: optional
default: 65535
Set a maximum number of loops that can be iterated for this while command. The value zero means that no maximum will be enforced. Use this mode with caution.
Positive Response:
the server returns <ok/>
Negative Response:
An error message will be printed if errors are detected locally.
invalid XPath expression or invalid docroot reference will cause an error
Usage:
andy@myserver> while 1 --maxloops=10
SAME AS:
andy@myserver> while '$x < 10'
andy@myserver>
xget¶
The 'xget' command is used to invoke a NETCONF <get> operation with an XPath filter.
+---x xget
+---w input
| +---w (from)
| | +--:(varref)
| | | +---w varref? string
| | +--:(select)
| | | +---w select? string
| | +--:(urltarget)
| | +---w urltarget? ywt:UrlPath
| +---w timeout? nt:Timeout
| +---w with-defaults? CliWithDefaultsType
| +---w depth? union
| +---w module-tag* string
| +---w match-names? ywt:NameMatchMode
| +---w alt-names? ywt:AltNameMode
| +---w wildcard-keys? boolean
+--ro output
+--ro data? <anyxml>
Command type: |
remote |
Default parameter: |
select |
Min parameters: |
1 |
Max parameters: |
5 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
|
Capabilities optional: |
none |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'select'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the XPath filter target of the <get> operation. It is an XPath expression, either contained in a user variable or directly from the 'select' parameter.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable the contains the XPath expression for the XPath filter in the <get> operation. The parameter must exist (e.g., created with an assignment statement) or an error message will be printed.
select
type: string
usage: mandatory
default: none
This parameter specifies the XPath expression to use for the XPath filter in the <get> operation.
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
with-defaults
type: enumeration (none report-all report-all-tagged trim explicit)
usage: optional
default: none
capabilities needed: with-defaults
This parameter controls how nodes containing only default values are returned in the <rpc-reply>.
depth
type: uint32 or “unbounded”
usage: optional
default: unbounded
capabilities needed: none: netconfd-pro NETCONF extension
This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.
module-tag:
type: string
default: none
capabilities needed: none
This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.
System Variables:
$$timeout
The response timeout interval will be derived from this system variable.
$$with-defaults
The <with-defaults> parameter for the <get> operation will be derived from this system variable.
Positive Response:
the server returns <data>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Output:
data
type: anyxml
This element will contain the requested data from the <running> database or non-config data structures.
Usage:
andy@myserver> xget //name
RPC Data Reply 42 for session 10:
rpc-reply {
data {
nacm {
rules {
data-rule nacm-tree {
name nacm-tree
}
}
}
xpath.1 {
name barney
}
netconf-state {
datastores {
datastore {
name {
candidate
}
}
}
}
netconf {
streams {
stream NETCONF {
name NETCONF
}
}
}
}
}
}
andy@myserver>
Reference:
RFC 6241, section 7.7
xget-config¶
The 'xget-config' command is used to invoke a NETCONF <get-config> operation with an XPath filter.
+---x xget-config
+---w input
| +---w (from)
| | +--:(varref)
| | | +---w varref? string
| | +--:(select)
| | | +---w select? string
| | +--:(urltarget)
| | +---w urltarget? ywt:UrlPath
| +---w timeout? nt:Timeout
| +---w with-defaults? CliWithDefaultsType
| +---w depth? union
| +---w module-tag* string
| +---w match-names? ywt:NameMatchMode
| +---w alt-names? ywt:AltNameMode
| +---w wildcard-keys? boolean
| +---w source
| +---w (config-source)
| +--:(candidate)
| | +---w candidate? empty {nc:candidate}?
| +--:(running)
| | +---w running? empty
| +--:(startup)
| | +---w startup? empty {nc:startup}?
| +--:(url)
| +---w url? nc:ConfigURIType {nc:url}?
+--ro output
+--ro data? <anyxml>
Command type: |
remote |
Default parameter: |
select |
Min parameters: |
2 |
Max parameters: |
6 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
|
Capabilities optional: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'select'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the XPath filter target of the <get-config> operation. It is an XPath expression, either contained in a user variable or directly from the 'select' parameter.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable the contains the XPath expression for the XPath filter in the <get-config> operation. The parameter must exist (e.g., created with an assignment statement) or an error message will be printed.
select
type: string
usage: mandatory
default: none
This parameter specifies the XPath expression to use for the XPath filter in the <get-config> operation.
source
type: container with 1 of N choice of leafs
usage: mandatory
default: none
This parameter specifies the name of the source database for the retrieval operation.
container contents: 1 of N:
candidate
type: empty
capabilities needed: :candidate
running
type: empty
capabilities needed: none
startup
type: empty
capabilities needed: :startup
url
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
with-defaults
type: enumeration (none report-all report-all-tagged trim explicit)
usage: optional
default: none
capabilities needed: with-defaults
This parameter controls how nodes containing only default values are returned in the <rpc-reply>.
depth
type: uint32 or “unbounded”
usage: optional
default: unbounded
capabilities needed: none: netconfd-pro NETCONF extension
This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.
module-tag:
type: string
default: none
capabilities needed: none
This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.
System Variables:
$$timeout
The response timeout interval will be derived from this system variable.
$$with-defaults
The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.
Positive Response:
the server returns <data>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Output:
data
type: anyxml
This element will contain the requested data from the 'source' database.
Usage:
andy@myserver> xget-config /nacm/rules/data-rule source=candidate
RPC Data Reply 35 for session 10:
rpc-reply {
data {
nacm {
rules {
data-rule nacm-tree {
name nacm-tree
path /nacm:nacm
allowed-rights {
read
write
}
allowed-group nacm:admin
comment 'access to nacm config'
}
}
}
}
}
andy@myserver>
xget-data¶
The 'xget-data' command is used to invoke a NETCONF NMDA <get-data> operation with an XPath filter. This command will not work unless the server supports the <get-data> operation from RFC 8526 in ietf-netconf-nmda.yang.
+---x xget-data
+---w input
| +---w datastore? enumeration
| +---w (from)
| | +--:(varref)
| | | +---w varref? string
| | +--:(select)
| | | +---w select? string
| | +--:(urltarget)
| | +---w urltarget? ywt:UrlPath
| +---w timeout? nt:Timeout
| +---w with-defaults? CliWithDefaultsType
| +---w depth? union
| +---w module-tag* string
| +---w match-names? ywt:NameMatchMode
| +---w alt-names? ywt:AltNameMode
| +---w wildcard-keys? boolean
| +---w config-filter? boolean
| +---w (origin-filters)?
| | +--:(origin-filter)
| | | +---w origin-filter* or:origin-ref
| | +--:(negated-origin-filter)
| | +---w negated-origin-filter* or:origin-ref
| +---w with-origin? empty
+--ro output
+--ro data? <anyxml>
Command type: |
remote |
Default parameter: |
select |
Min parameters: |
2 |
Max parameters: |
6 |
Return type: |
data |
YANG file: |
|
Capabilities needed: |
none |
Capabilities optional: |
Command Parameters:
choice 'from' (not entered)
type: choice of case 'varref' or case 'select'
usage: mandatory
default: none
This parameter specifies the where yangcli-pro should get the data from, for the XPath filter target of the <get-config> operation. It is an XPath expression, either contained in a user variable or directly from the 'select' parameter.
varref
type: string
usage: mandatory
default: none
This parameter specifies the name of the user variable the contains the XPath expression for the XPath filter in the <get-config> operation. The parameter must exist (e.g., created with an assignment statement) or an error message will be printed.
select
type: string
usage: mandatory
default: none
This parameter specifies the XPath expression to use for the XPath filter in the <get-config> operation.
datastore
type: leaf containing a datastore-ref
usage: mandatory
This parameter specifies the name of the source NMDA datastore for the retrieval operation.
enumeration:
candidate
capabilities needed: :candidate
running
capabilities needed: none
startup
capabilities needed: :startup
operational
capabilities needed: none
timeout
type: uint32 (0 = no timeout, otherwise the number of seconds to wait)
usage: optional
default: set to the $$timeout system variable, default 30 seconds
This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.
with-defaults
type: enumeration (none report-all report-all-tagged trim explicit)
usage: optional
default: none
capabilities needed: with-defaults
This parameter controls how nodes containing only default values are returned in the <rpc-reply>.
depth
type: uint32 or “unbounded”
usage: optional
default: unbounded
capabilities needed: none: netconfd-pro NETCONF extension
This parameter controls how many levels of subtrees should be returned in the <rpc-reply>. This is called the <max-depth> parameter in the <get-data> operations.
config-filter:
type boolean
Specifies the type of data based on config-stmt. Retrieve all data if this parameter is not present. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.
Only relevant if the datastore parameter is ‘operational’.
If set to ‘false’ for any datastore other than ‘operational’ then an empty <data> element will be returned.
origin-filter:
type: leaf-list of type origin-ref..
This parameter will select data nodes with the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.
Cannot be used if negated-origin-filter present
Can only be used if the datastore parameter is ‘operational’
negated-origin-filter:
type: leaf-list of type origin-ref..
This parameter will select data nodes if they do not have the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.
Cannot be used if origin-filter present
Can only be used if the datastore parameter is ‘operational’
with-origin
type: empty
This parameter will cause the origin attribute to be added to data nodes returned by the server.
Can only be used if the datastore parameter is ‘operational’
System Variables:
$$timeout
The response timeout interval will be derived from this system variable.
$$with-defaults
The <with-defaults> parameter for the <get-data> operation will be derived from this system variable.
Positive Response:
the server returns <data>
Negative Response:
An error message will be printed if errors are detected locally.
An <rpc-error> message will be printed if the server detected an error.
Output:
data
type: anyxml
This element will contain the requested data from the 'source' database.
Usage: