YumaPro yangcli-pro Manual YANG-Based Unified Modular Automation Tools NETCONF Over SSH Client

Transcription

YumaPro yangcli-pro Manual
YANG-Based Unified Modular Automation Tools
NETCONF Over SSH Client
Version 14.08-2
Table Of Contents
1 Preface............................................................................................................................................7
1.1 Legal Statements......................................................................................................................7
1.2 Additional Resources................................................................................................................7
1.2.1 WEB Sites.................................................................................................................................... 7
1.2.2 Mailing Lists.................................................................................................................................. 8
1.3 Conventions Used in this Document........................................................................................8
2 yangcli-pro User Guide...................................................................................................................9
2.1 Introduction...............................................................................................................................9
2.1.1 Features....................................................................................................................................... 9
2.1.2 Starting yangcli-pro..................................................................................................................... 11
2.1.3 Stopping yangcli-pro................................................................................................................... 13
2.1.4 Statements................................................................................................................................. 13
2.1.5 Commands................................................................................................................................. 14
2.1.6 Variables..................................................................................................................................... 17
2.1.7 Files............................................................................................................................................ 21
2.1.8 Scripts........................................................................................................................................ 21
2.1.9 Configuration Mode Editing.........................................................................................................24
2.1.10 Configuration Parameter List....................................................................................................26
2.2 Invoking Commands...............................................................................................................30
2.2.1 Command Prompt....................................................................................................................... 31
2.2.2 Command Name........................................................................................................................ 34
2.2.3 ncx:default-parm Extension........................................................................................................ 34
2.2.4 Parameter Mode Escape Commands.........................................................................................36
2.2.5 Using XPath Expressions........................................................................................................... 36
2.2.6 Special Parameter Handling.......................................................................................................38
2.2.7 Command Completion................................................................................................................ 39
2.2.8 Command Line Editing............................................................................................................... 40
2.2.9 Command History....................................................................................................................... 41
2.2.10 Command Responses.............................................................................................................. 41
2.3 NETCONF Session Configuration..........................................................................................42
2.3.1 Saving Sessions......................................................................................................................... 43
2.3.2 Multiple Sessions........................................................................................................................ 43
2.3.3 Changing the Active Session......................................................................................................43
2.3.4 Saving the Configured Sessions.................................................................................................44
2.3.5 Loading Additional Configured Sessions.....................................................................................45
2.3.6 Displaying the Configured Sessions...........................................................................................45
2.3.7 Displaying Sessions.................................................................................................................... 45
2.3.8 Terminating a Named Session....................................................................................................46
2.3.9 Saved Session Configuration File Format...................................................................................46
2.3.10 Session Configuration File Example.........................................................................................48
2.4 NETCONF Group Configuration ............................................................................................48
2.4.1 Create group............................................................................................................................... 49
2.4.2 List group.................................................................................................................................... 49
2.4.3 Delete group............................................................................................................................... 49
2.4.4 Add group................................................................................................................................... 50
2.4.5 Remove Group........................................................................................................................... 50
2.4.6 Show Group................................................................................................................................ 50
2.4.7 Connect Group .......................................................................................................................... 50
2.4.8 Help Group................................................................................................................................. 51
2.4.9 Saving Groups ........................................................................................................................... 52
Version 14.08-2
Page 2
2.4.10 Changing the Active group .......................................................................................................53
2.5 Using NETCONF Sessions....................................................................................................53
2.5.1 Connection Startup Screen.........................................................................................................53
2.5.2 Server Tailored Context.............................................................................................................. 55
2.5.3 Retrieving Data........................................................................................................................... 56
2.5.4 Modifying Data............................................................................................................................ 57
2.5.5 Using Notifications...................................................................................................................... 59
2.5.6 Configuration Parameters That Affect Sessions..........................................................................59
2.5.7 Trouble-shooting NETCONF Session Problems.........................................................................60
2.6 Automated Testing..................................................................................................................62
2.6.1 Test Templates............................................................................................................................ 62
2.6.2 YANG File Defining Test Templates............................................................................................63
2.6.3 Example Test File....................................................................................................................... 66
2.7 Command Reference.............................................................................................................71
2.7.1 alias............................................................................................................................................ 71
2.7.2 aliases........................................................................................................................................ 73
2.7.3 auto-test...................................................................................................................................... 74
2.7.4 cache.......................................................................................................................................... 75
2.7.5 cd................................................................................................................................................ 78
2.7.6 close-session.............................................................................................................................. 79
2.7.7 commit........................................................................................................................................ 80
2.7.8 config.......................................................................................................................................... 81
2.7.9 connect....................................................................................................................................... 82
2.7.10 copy-config............................................................................................................................... 85
2.7.11 create........................................................................................................................................ 88
2.7.12 create-subscription................................................................................................................... 90
2.7.13 delete........................................................................................................................................ 92
2.7.14 delete-config............................................................................................................................. 94
2.7.15 discard-changes....................................................................................................................... 96
2.7.16 edit-config................................................................................................................................. 96
2.7.17 elif............................................................................................................................................. 99
2.7.18 else......................................................................................................................................... 101
2.7.19 end......................................................................................................................................... 102
2.7.20 eval......................................................................................................................................... 103
2.7.21 eventlog.................................................................................................................................. 104
2.7.22 exit.......................................................................................................................................... 106
2.7.23 fill............................................................................................................................................ 107
2.7.24 get.......................................................................................................................................... 109
2.7.25 get-config................................................................................................................................ 111
2.7.26 get-locks................................................................................................................................. 113
2.7.27 get-my-session........................................................................................................................ 114
2.7.28 get-schema............................................................................................................................. 115
2.7.29 group....................................................................................................................................... 118
2.7.30 help......................................................................................................................................... 122
2.7.31 history..................................................................................................................................... 125
2.7.32 if.............................................................................................................................................. 128
2.7.33 insert....................................................................................................................................... 129
2.7.34 kill-session.............................................................................................................................. 132
2.7.35 list........................................................................................................................................... 133
2.7.36 load......................................................................................................................................... 136
2.7.37 lock......................................................................................................................................... 138
2.7.38 log-debug................................................................................................................................ 139
Version 14.08-2
Page 3
2.7.39 log-error.................................................................................................................................. 140
2.7.40 log-info.................................................................................................................................... 141
2.7.41 log-warn.................................................................................................................................. 142
2.7.42 merge..................................................................................................................................... 143
2.7.43 mgrload................................................................................................................................... 145
2.7.44 no-op...................................................................................................................................... 146
2.7.45 pwd......................................................................................................................................... 147
2.7.46 quit.......................................................................................................................................... 148
2.7.47 recall....................................................................................................................................... 148
2.7.48 record-test.............................................................................................................................. 149
2.7.49 release-locks.......................................................................................................................... 151
2.7.50 remove.................................................................................................................................... 152
2.7.51 replace.................................................................................................................................... 153
2.7.52 restart..................................................................................................................................... 156
2.7.53 run.......................................................................................................................................... 156
2.7.54 save........................................................................................................................................ 158
2.7.55 session................................................................................................................................... 159
2.7.56 session-cfg............................................................................................................................. 159
2.7.57 sessions-cfg............................................................................................................................ 161
2.7.58 set-log-level............................................................................................................................ 162
2.7.59 set-my-session........................................................................................................................ 163
2.7.60 sget......................................................................................................................................... 164
2.7.61 sget-config.............................................................................................................................. 167
2.7.62 show....................................................................................................................................... 170
2.7.63 shutdown................................................................................................................................ 176
2.7.64 start-rpc-timing........................................................................................................................ 177
2.7.65 start-session........................................................................................................................... 178
2.7.66 start-timer............................................................................................................................... 179
2.7.67 stop-rpc-timing........................................................................................................................ 180
2.7.68 stop-session........................................................................................................................... 181
2.7.69 stop-timer................................................................................................................................ 182
2.7.70 test-suite................................................................................................................................. 183
2.7.71 unlock..................................................................................................................................... 185
2.7.72 unset....................................................................................................................................... 187
2.7.73 uservars.................................................................................................................................. 188
2.7.74 validate................................................................................................................................... 189
2.7.75 while....................................................................................................................................... 190
2.7.76 xget......................................................................................................................................... 192
2.7.77 xget-config.............................................................................................................................. 194
3 CLI Reference.............................................................................................................................198
3.1 --aliases-file..........................................................................................................................198
3.2 --alt-names............................................................................................................................198
3.3 --autoaliases.........................................................................................................................198
3.4 --autocomp............................................................................................................................199
3.5 --autoconfig...........................................................................................................................199
3.6 --autohistory..........................................................................................................................200
3.7 --autoload..............................................................................................................................200
3.8 --autoload-cache...................................................................................................................200
3.9 --autoload-get.......................................................................................................................201
3.10 --autoload-save-cache........................................................................................................201
3.11 --autonotif............................................................................................................................202
Version 14.08-2
Page 4
3.12 --autosessions....................................................................................................................202
3.13 --autotest.............................................................................................................................203
3.14 --autouservars....................................................................................................................203
3.15 --bad-data...........................................................................................................................204
3.16 --batch-mode......................................................................................................................204
3.17 --check-output.....................................................................................................................204
3.18 --check-output-error............................................................................................................205
3.19 --check-replies....................................................................................................................205
3.20 --check-replies-error...........................................................................................................206
3.21 --config................................................................................................................................206
3.22 --config-edit-mode..............................................................................................................207
3.23 --datapath...........................................................................................................................207
3.24 --default-module.................................................................................................................208
3.25 --deviation...........................................................................................................................208
3.26 --display-mode....................................................................................................................209
3.27 --echo-notif-loglevel............................................................................................................210
3.28 --echo-notifs........................................................................................................................210
3.29 --echo-replies......................................................................................................................211
3.30 --feature-disable..................................................................................................................211
3.31 --feature-enable..................................................................................................................212
3.32 --feature-enable-default......................................................................................................212
3.33 --fixorder.............................................................................................................................213
3.34 --force-target.......................................................................................................................213
3.35 --help...................................................................................................................................214
3.36 --help-mode........................................................................................................................214
3.37 --home................................................................................................................................215
3.38 --ignore-missing-vars..........................................................................................................216
3.39 --indent................................................................................................................................216
3.40 --log.....................................................................................................................................216
3.41 --log-append.......................................................................................................................217
3.42 --log-backtrace....................................................................................................................217
3.43 --log-backtrace-detail..........................................................................................................218
3.44 --log-backtrace-level...........................................................................................................218
3.45 --log-backtrace-stream.......................................................................................................219
3.46 --log-console.......................................................................................................................219
3.47 --log-header........................................................................................................................220
3.48 --log-level............................................................................................................................220
3.49 --log-mirroring.....................................................................................................................221
3.50 --log-stderr..........................................................................................................................221
3.51 --log-suppress-ctrl...............................................................................................................222
3.52 --log-syslog.........................................................................................................................222
3.53 --log-syslog-level................................................................................................................222
3.54 --match-names...................................................................................................................223
3.55 --message-indent................................................................................................................224
3.56 --modpath...........................................................................................................................224
3.57 --module..............................................................................................................................225
3.58 --ncport...............................................................................................................................225
3.59 --no-config...........................................................................................................................226
Version 14.08-2
Page 5
3.60 --password..........................................................................................................................226
3.61 --private-key........................................................................................................................227
3.62 --prompt-type......................................................................................................................227
3.63 --protocols...........................................................................................................................228
3.64 --public-key.........................................................................................................................228
3.65 --runpath.............................................................................................................................228
3.66 --run-command...................................................................................................................229
3.67 --run-script..........................................................................................................................229
3.68 --save-session-vars............................................................................................................230
3.69 --server...............................................................................................................................230
3.70 --subdirs..............................................................................................................................230
3.71 --test-suite-file.....................................................................................................................231
3.72 --time-rpcs...........................................................................................................................231
3.73 --time-rpcs-stats..................................................................................................................232
3.74 --time-rpc-stats-file..............................................................................................................232
3.75 --timeout..............................................................................................................................232
3.76 --transport...........................................................................................................................233
3.77 --use-data-templates..........................................................................................................233
3.78 --use-rawxml.......................................................................................................................234
3.79 --use-session-vars..............................................................................................................234
3.80 --use-xmlheader.................................................................................................................235
3.81 --user..................................................................................................................................235
3.82 --uservars-file......................................................................................................................235
3.83 --version..............................................................................................................................236
3.84 --warn-idlen.........................................................................................................................236
3.85 --warn-linelen......................................................................................................................237
3.86 --warn-off............................................................................................................................237
3.87 --yumapro-home.................................................................................................................238
Version 14.08-2
Page 6
1 Preface
1.1 Legal Statements
Copyright 2009 – 2012, Andy Bierman, All Rights Reserved.
Copyright 2012 - 2014, YumaWorks, Inc., All Rights Reserved.
1.2 Additional Resources
This document assumes you have successfully set up the software as described in the printed document:
YumaPro Installation Guide
Other documentation includes:
YumaPro Quickstart Guide
YumaPro User Manual
YumaPro netconfd-pro Manual
YumaPro yangdiff-pro Manual
YumaPro yangdump-pro Manual
YumaPro Developer Manual
YumaPro yp-system API Guide
To obtain additional support you may contact YumaWorks technical support department:
support@yumaworks.com
1.2.1
•
•
WEB Sites
YumaWorks
◦
http://www.yumaworks.com
◦
Offers support, training, and consulting for YumaPro.
Netconf Central
◦
http://www.netconfcentral.org/
▪
•
•
Free information on NETCONF and YANG, tutorials, on-line YANG module validation and
documentation database
Yang Central
◦
http://www.yang-central.org
◦
Free information and tutorials on YANG, free YANG tools for download
NETCONF Working Group Wiki Page
◦
http://trac.tools.ietf.org/wg/netconf/trac/wiki
◦
Free information on NETCONF standardization activities and NETCONF implementations
Version 14.08-2
Page 7
•
•
NETCONF WG Status Page
◦
http://tools.ietf.org/wg/netconf/
◦
IETF Internet draft status for NETCONF documents
libsmi Home Page
◦
http://www.ibr.cs.tu-bs.de/projects/libsmi/
◦
Free tools such as smidump, to convert SMIv2 to YANG
•
1.2.2
•
•
Mailing Lists
NETCONF Working Group
◦
http://www.ietf.org/html.charters/netconf-charter.html
◦
Technical issues related to the NETCONF protocol are discussed on the NETCONF WG mailing list.
Refer to the instructions on the WEB page for joining the mailing list.
NETMOD Working Group
◦
http://www.ietf.org/html.charters/netmod-charter.html
◦
Technical issues related to the YANG language and YANG data types are discussed on the NETMOD WG
mailing list. Refer to the instructions on the WEB page for joining the mailing list.
1.3 Conventions Used in this Document
The following formatting conventions are used throughout this document:
Documentation Conventions
Convention
Version 14.08-2
Description
--foo
CLI parameter foo
<foo>
XML parameter foo
foo
yangcli-pro command or parameter
$FOO
Environment variable FOO
$$foo
yangcli-pro global variable foo
some text
Example command or PDU
some text
Plain text
Page 8
2 yangcli-pro User Guide
Program Components
2.1 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.
2.1.1
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
•
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
Version 14.08-2
Page 9
•
•
•
•
•
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:
▪
create
▪
delete
▪
insert
▪
merge
▪
replace
▪
remove
<get> and <get-config> high-level functions:
▪
sget
▪
sget-config
▪
xget
▪
xget-config
•
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
Version 14.08-2
Page 10
▪
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.
2.1.2
Starting yangcli-pro
The current working directory in use when yangcli-pro is invoked is important. It is most convenient to run yangclipro from a work directory, rather than the installation directory or within the module library.
Version 14.08-2
Page 11
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=mylogfile
•
To start an interactive session and append to an existing log file:
yangcli-pro --log=mylogfile --log-append
•
To get parameters from a configuration file:
yangcli-pro --config=~/yangcli-pro.conf
•
To 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 (--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 \
Version 14.08-2
Page 12
--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.
--user=andy --password=yangrocks \
--run-script=mytestscript
•
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.
--run-script=mytestscript --batch-mode
•
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.
--batch-mode --run-command=”sget /system”
2.1.3
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.
2.1.4
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
Version 14.08-2
Page 13
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).
Note: More statement types will be available in the next release.
2.1.5
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 2 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.
Local Commands
Version 14.08-2
Page 14
command
description
alias
Show or set a specific yangcli-pro command alias
aliases
Manage the yangcli-pro command aliases
auto-test
Run automatic edit testing on the specified session
cache
Clear 1 or all entries from the YANG module cache
cd
Change the current working directory
config
Enter the configuration mode for the current session
connect
Connect to a server and start a NETCONF session
elif
Start an 'else-if' conditional block
else
Start an 'else' conditional block
end
End an 'if' or 'while' block
eval
Evaluate an XPath expression
eventlog
View or clear the notification event log
exit
Exit configuration mode for the current session
fill
Fill a user variable
group
Manage the session groups.
help
Get context-sensitive help
history
Manage the command history buffer
if
Start an 'if' conditional block
list
List modules, objects, or other properties of the session
log-debug
Log a debug message
log-error
Log an error message
log-info
Log an info message
log-warn
Log a warning message
mgrload
Load a YANG file into the client only
pwd
Print the current working directory
quit
Exit the program
recall
Recall a line from the command history buffer
record-test
Record commands and responses for a regression test
run
Run a script
session
Set the current session
session-cfg
Access a named session configuration
sessions-cfg
Access the named session configuration file
show
Show variables and objects currently available
start-rpc-timing
Start <rpc> timing mode and save statistics to a file
start-session
Start a named session from the saved sessions configuration
start-timer
Start a script timer
stop-rpc-timing
Stop <rpc> timing mode
Version 14.08-2
Page 15
stop-session
Stop a named session
stop-timer
Stop a script timer and display the elapsed time
test-suite
Access a configured unit-test suite for automated testing
update-config
Update the shadow configuration for the current session<
unset
Remove a command alias from memory
uservars
Manage the yangcli-pro user variables
while
Start a 'while' conditional loop block
Table 1
The following table shows the standard NETCONF protocol operations that are directly available for use, depending
on the capabilities of the server.
Standard NETCONF Commands
command
description
cancel-commit
Cancel the current confirmed commit procedure
close-session
Close the current NETCONF session
commit
Make the candidate database be the running config
copy-config
Copy an entire NETCONF database
create-subscription
Start receiving NETCONF notifications
delete-config
Delete an entire NETCONF database
discard-changes
Discard any edits in the candidate database
edit-config
Alteration of the target database
get
Filtered retrieval of state data and running config
get-config
Filtered retrieval of any NETCONF database
get-schema
Get a data model definition file from the server
kill-session
Force close another NETCONF session
lock
Lock a NETCONF database that is currently unlocked
unlock
Unlock a NETCONF database that is currently locked
validate
Validate the contents of a NETCONF database
The following yangcli-pro commands are available for simplified access to standard NETCONF operations
Custom NETCONF Commands
command
description
create
Invoke an <edit-config> create operation
delete
Invoke an <edit-config> delete operation
get-locks
Lock all the databases with the <lock> operation
Version 14.08-2
Page 16
insert
Invoke an <edit-config> YANG insert operation
merge
Invoke an <edit-config> merge operation
release-locks
Unlock all the locked databases with the <unlock> operation
remove
Invoke an <edit-config> remove operation
replace
Invoke an <edit-config> replace operation
save
Save the current edits on the server in NV-storage
sget
Invoke a <get> operation with a subtree filter
sget-config
Invoke a <get-config> operation with a subtree filter
xget
Invoke a <get> operation with an XPath filter
xget-config
Invoke a <get-config> operation with an XPath filter
The following table shows the extended NETCONF protocol operations that are available on the netconfd-pro server
only.
Extended netconfd-pro Commands
command
description
get-my-session
Retrieve session customization parameters
load
Load a module into the server.
no-op
No operation.
restart
Restart the server.
set-log-level
Set the server logging verbosity level.
set-my-session
Set session customization parameters.
shutdown
Shutdown the server.
The following table shows the special configuration mode commands and keywords. They are only allowed in
configuration mode.
Configuration Mode Commands
command
2.1.6
description
apply
Apply any pending edits to the current session
do
Run a command in configuration mode
no
Prefix to configuration mode command used to delete a node
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.
Version 14.08-2
Page 17
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:
1.
Read-only system variables
2.
Read-write system variables
3.
Read-write global user variables (saved in $HOME/.yuma directory)
4.
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 (try
local, then global)
$myuser = $user
The following table shows the unix environment variables that are available as read-only global variables in yangclipro. These variables are set once when the program is started, and cannot be used in the the left hand side of an
assignment statement.
Read-only system variables
variable
description
$$HOME
the HOME environment variable
$$HOSTNAME
the HOST or HOSTNAME environment variable
$$LANG
the LANG environment variable
$$PWD
the PWD environment variable, when yangcli-pro was
invoked
Version 14.08-2
Page 18
$$SHELL
the SHELL environment variable
$$USER
the USER environment variable
$$YUMAPRO_DATAPATH
the YUMAPRO_DATAPATH environment variable
$$YUMAPRO_HOME
the YUMAPRO_HOME environment variable
$$YUMAPRO_MODPATH
the YUMAPRO_MODPATH environment variable
$$YUMAPRO_RUNPATH
the YUMAPRO_RUNPATH environment variable
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.
Read-write system variables
variable
description
$$aliases-file
the --aliases-file configuration parameter
$$alt-names
the –alt-names configuration parameter
$$autoaliases
the --autoaliases configuration parameter
$$autocomp
the --autocomp configuration parameter
$$autoconfig
the --autoconfig configuration parameter
$$autohistory
the --autohistory configuration parameter
$$autoload
the --autoload configuration parameter
$$autoload-cache
the --autoload-cache configuration parameter
$$autoload-save-cache
the –autoload-save-cache configuration parameter
$$autoload-get
the --autoload-get configuration parameter
$$autonotif
the --autonotif configuration parameter
$$autosessions
the --autosessions configuration parameter
$$autotest
the --autotest configuration parameter
$$autouservars
the --autouservars configuration parameter
$$baddata
the --baddata configuration parameter
$$check-output
the --check-output configuration parameter
$$check-output-error
the --check-output-error configuration parameter
$$check-replies
the --check-replies configuration parameter
$$check-replies-error
the --check-replies-error configuration parameter
$$config-edit-mode
the --config-edit-mode configuration parameter
$$default-module
the --default-module configuration parameter
$$default-operation
the <default-operation> parameter for the <edit-config>
operation
$$display-mode
the --display-mode configuration parameter
$$echo-notif-loglevel
the --echo-notif-loglevel configuration parameter
$$echo-notifs
the --echo-notifs configuration parameter
Version 14.08-2
Page 19
$$echo-replies
the --echo-replies configuration parameter
$$error-option
the default <error-option> parameter for the <edit-config>
operation
$$fixorder
the --fixorder configuration parameter
$$ignore-missing-vars
the –ignore-missing-vars configuration parameter
$$indent
the –indent configuration parameter
$$log-level
the --log-level configuration parameter
$$match-names
the –match-names configuration parameter
$$message-indent
the --message-indent configuration parameter
$$optional
the --optional configuration parameter
$$prompt-type
the --prompt-type configuration parameter
$$save-session-vars
the --save-session-vars configuration parameter
$$script-input
the --script-input configuration parameter
$$server
the --server configuration parameter
$$test-option
the <test-option> parameter for the <edit-config> operation
$$test-suite-file
the --test-suite-file configuration parameter
$$time-rpcs
the –time-rpcs configuration parameter
$$time-rpcs-stats
the --time-rpc-stats configuration parameter
$$time-rpcs-stats-file
the --time-rpc-stats-file configuration parameter
$$timeout
the --timeout configuration parameter
$$use-data-templates
the --use-data-templates configuration parameter
$$use-rawxml
the --use-rawxml configuration parameter
$$use-sessionvars
the --use-sessionvars configuration parameter
$$use-xmlheader
the –use-xmlheader configuration parameter
$$user
the --user configuration parameter
$$uservars-file
the --uservars-file configuration parameter
$$with-defaults
the --with-defaults 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
Version 14.08-2
Page 20
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.
2.1.7
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 yangclipro will strip off the outermost XML (if needed) to save the requested file as a pure text file. 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.
Note: The --display-mode configuration parameter, and $$display-mode system variable, only affect the output and
display of data in the yangcli-pro program. NETCONF protocol messages are always sent in 'xml' mode.
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.
2.1.8
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.
Version 14.08-2
Page 21
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 exectuted, 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).
Version 14.08-2
Page 22
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).
Sample Script
The following script does not do any useful work.
It is provided to demonstrate some simple constructs.
$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
2.1.9
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.
Version 14.08-2
Page 23
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:
•
apply: Use this command to force all pending edits to be applied to the current session
•
exit: Use this command to exit the current configuration sub-mode to its parent mode. If already at the top
level, then this command will cause configuration mode to be terminated
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.
Version 14.08-2
Page 24
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
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
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.
Version 14.08-2
Page 25
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#
2.1.10
Configuration Parameter List
The following configuration parameters are used by yangcli-pro. Refer to the CLI Reference for more details.
yangcli-pro CLI Parameters
parameter
description
--aliases-file
Specifies the command aliases file to use.
--alt-names
Controls whether alternate names will be checked for UrlPath
searches.
--autoaliases
Controls automatic loading and saving of the command aliases
--autocomp
Controls whether partial commands are allowed or not.
--autoconfig
Controls whether the running configuration will be retrieved
automatically for active sessions.
--autohistory
Controls whether th command line history buffer will be automatically
loaded at startup and saved on exit.
--autoload
Controls whether modules used by the server will be loaded
automatically, as needed.
-autoload-cache
Controls whether the modules retrieved with the <get-schema>
operation are cached for use by the running instance of yangcli-pro.
-autoload-get
Controls whether the <get> operation will be used
to retrieve the /netconf-state/schemas sub-tree.
-autoload-save-cache
Controls whether the modules held in the YANG module cache
(retrieved with the <get-schema> operation) are saved when yangclipro exits.
--autonotif
Controls whether notifications will automatically be enabled when a
session starts.
--autosessions
Controls whether saved session configurations are loaded at startup
and saved upon exit.
--autotest
Controls whether the saved test suites will be loaded into memory at
startup and saved to file at exit.
--autouservars
Controls automatic loading and saving of the global user variables
Version 14.08-2
Page 26
--bad-data
Controls how bad data about to be sent to the server is handled.
--batch-mode
Indicates the interactive shell should not be used.
--check-output
Controls whether YANG <rpc> validation is done
--check-output-error
Controls whether YANG <rpc> validation errors are treated as errors
or warnings
--check-replies
Controls whether YANG <rpc-reply> validation is done
--check-replies-error
Controls whether YANG <rpc-reply> validation errors are treated as
errors or warnings
--config
Specifies the configuration file to use for parameters.
The --no-config option can be used instead to prevent the default
config file from being used.
--config-edit-mode
Controls how edits are applied during configuration mode
--datapath
Sets the data file search path.
--default-module
Specifies the default module to use to resolve identifiers.
--deviation
Species one or more YANG modules to load as deviations.`
--display-mode
Specifies how values should be displayed.
--echo-notif-loglevel
Specifies the log-level needed to echo unregistered notifications to
the log and/or STDOUT.
--echo-notifs
Specifies whether unregistered notifications will be output to the log
or STDOUT.
--echo-replies
Controls whether RPC replies will be displayed in the log output, if
log-level >= 'info'
--feature-disable
Leaf list of features to disable
--feature-enable
Specifies a feature that should be enabled
--feature-enable-default
Specifies if a feature should be enabled or disabled by default
--fixorder
Controls whether PDUs are changed to canonical order before
sending them to the server.
--force-target
Controls whether the candidate or running configuration datastore will
be used as the default edit target, when both are supported by the
server.
--help
Get program help.
--help-mode
Adjust the help output (--brief or --full).
--home
Override the $HOME environment variable.
--ignore-missing-vars
Specifies whether a missing variable in a data template is an error or
the variable expands to an empty string
--indent
Specifies the indent count to use when writing data.
--log
Specifies the log file to use instead of STDOUT. See the YumaPro
User Manual for a general discussion of logging.
--log-append
Controls whether a log file will be reused or overwritten.
--log-backtrace
Append stack trace information to log messages.
--log-backtrace-detail
Add additional (compiler/OS dependent) detail to stack trace
information.
Version 14.08-2
Page 27
--log-backtrace-level
Specify message level(s) for which stack trace information will be
generated.
--log-backtrace-stream
Include stack trace information in the specified output stream(s
--log-console
Specifies that log output will be sent to STDOUT after being sent to
log file and/or syslog (assumes –log=file and/or --log-syslog are
present).
--log-header
Include additional information (level/date/time) with log message.
--log-level
Specifies verbosity level of log message output
--log-mirroring
Synonym for log-console.
--log-stderr
Specifies that error level log messages will be sent to STDERR.
--log-suppress-ctrl
If present, strip certain control characters from output in order to
modify log formatting.
--log-syslog
Send log message output to the syslog daemon.
--match-names
Match mode to use for UrlPath searches
--message-indent
The number of spaces to indent for each level of output in a protocol
message, e.g. NETCONF request.
--modpath
Sets the module search path.
--module
Specifies one or more YANG modules to load upon startup.
--ncport
Specifies the NETCONF server port number to use in the connect
command.
--no-config
Specifies that the default configuration file should not be loaded if it
exists
--password
Specifies the password to use in the connect command.
--private-key
Contains the file path specification for the file containing the clientside private key.
--protocols
Controls which NETCONF protocol versions will be enabled
--public-key
Contains the file path specification for the file containing the clientside public key.
--runpath
Sets the executable file search path.
--run-command
Specifies the command to run at startup time.
--run-script
Specifies the script to run at startup time.
--save-session-vars
Specifies if session variables will be saved when the program exits.
--script-input
Controls whether the program will stop for input when running a script
in interactive mode.
--server
Specifies the server address to use in the connect command.
--subdirs
Specifies whether child sub-directories should be searched when
looking for files.
--test-suite-file
Specifies the name of the test suite file to load if --autotest=true. The
default value is $HOME/.yumapro/yangcli_pro_tests.conf
--time-rpcs
Measure the round-trip time of each <rpc> request
and <rpc-reply> at the session level.
--time-rpcs-stats
Save rpc statistics to the specified or default statistics file if the time-
Version 14.08-2
Page 28
rpcs variable is also true.
--time-rpcs-stats-file
Save rpc statistics to the specified file if the --time-rpc-stats and timerpcs variables are true. The default value is
$HOME/yangcli_pro_rpc_stats.txt
--timeout
Specifies the timeout to use in the connect command.
--transport
Specified the transport protocol to use (ssh, tcp, or tpc-ncx)
--use-data-templates
Controls whether data templates are enabled
--use-rawxml
Controls how file result variables will be read. If true then the YANG
object template will not be used when parsing the XML file.
--use-session-vars
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.
--use-xmlheader
Specifies how file result variables will be written for XML files.
Controls whether the XML preamble header will be written or not.
--user
The default user name for NETCONF sessions.
--uservars-file
Specifies the global user variable files to load.
--version
Prints the program version and exits.
--warn-idlen
Controls how identifier lengths are checked.
--warn-linelen
Controls how line lengths are checked.
--warn-off
Suppresses the specified warning number.
--yumapro-home
Specifies the $YUMAPRO_HOME project root to use when searching
for files.
2.2 Invoking 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
Version 14.08-2
Page 29
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.
2.2.1
Command Prompt
The yangcli-pro command prompt changes, depending on the context.
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.
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.
Version 14.08-2
Page 30
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:
Version 14.08-2
Page 31
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>
Version 14.08-2
Page 32
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
>
2.2.2
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.
Version 14.08-2
Page 33
2.2.3
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
Version 14.08-2
default parameter
alias
var
aliases
show
cd
dir
connect
server
create
target
elif
expr
else
expr
if
expr
eventlog
show
fill
target
help
command
history
show
insert
target
Page 34
2.2.4
load
module
log-debug
msg
log-error
msg
log-info
msg
log-warn
msg
merge
target
mgrload
module
recall
index
replace
target
run
script
set-log-level
log-level
sget
target
sget-config
target
xget
select
xget-config
select
while
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
?c
Cancel this 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 CLI Reference for more
details.
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.
Version 14.08-2
Page 35
2.2.5
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)
:fill> system
:fill> /system
:fill> /sys:system
It is important to remember 2 simple rules to avoid common errors in XPath expressions:
1.
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'.
2.
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.
One of the simplest XPath filters to use is the descendant-or-self filter ('//<expr>').
For example, this command will retrieve all instances of the 'ifMtu' leaf:
andy@myserver> xget //ifMtu
Version 14.08-2
Page 36
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
}
}
}
2.2.6
Special Parameter Handling
Some special handling of YANG data structures is done by the script interpreter.
Containers
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 (when in idle mode), as the 'contents' of the container parameter.
andy@myserver> sget-config /system source=candidate
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., --helpmode) 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
Version 14.08-2
Page 37
#
#
#
>
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.
2.2.7
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>
Version 14.08-2
Page 38
cd
connect
fill
help
history
list
mgrload
pwd
quit
recall
run
show
Command list example: NETCONF session is active
andy@myserver.example.com> <hit tab key>
cd
get-schema
close-session
help
commit
history
connect
insert
copy-config
kill-session
create
list
create-subscription load
delete
load-config
delete-config
lock
discard-changes
merge
edit-config
mgrload
fill
no-op
get
pwd
get-config
quit
2.2.8
recall
replace
restart
run
save
sget
sget-config
show
shutdown
unlock
validate
xget
xget-config
Command Line Editing
The command line parser is based on libtecla, a freely available library.
The home page is located here:
http://www.astro.caltech.edu/~mcs/tecla/
The complete user guide for configuring libtecla is located here:
http://www.astro.caltech.edu/~mcs/tecla/tecla.html
If the file $HOME/.teclarc exists, 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/.teclarc file 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.
Version 14.08-2
Page 39
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
2.2.9
description
^F
cursor right
^B
cursor-left
Â
beginning of line
Ê
end of line
Û
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.
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 submodes:
•
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'.
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 Command Reference section for more details on the history command.
Version 14.08-2
Page 40
2.2.10
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 parameter in the CLI Reference for more details. Logging capabilities are also discussed in
more detail in the YumaPro User Manual.
2.3 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:
Version 14.08-2
Page 41
> start-session session-A
…. startup screeen ….
session-A>
2.3.1
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
andy@myserver> session-cfg save session-A
Saved current session as 'session-A'
andy@myserver>
2.3.2
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
session-A> start-session session-B
session-B>
Note that when a session is started, the active session is set to that session.
2.3.3
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.
Version 14.08-2
Page 42
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>
2.3.4
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>
Version 14.08-2
Page 43
2.3.5
Loading Additional Configured Sessions
Additional sessions canbe 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>
2.3.6
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
2.3.7
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
Version 14.08-2
Page 44
user: andy
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
user: andy
connected: false
session-A>
2.3.8
Terminating a Named Session
The stop-session command is used to terminate a specific session. The <close-session> command 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
>
2.3.9
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 {
description
"Represents all the saved sessions in
Version 14.08-2
Page 45
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 user {
type nt:NcxName;
mandatory true;
description
"The use name of the session.";
}
leaf password {
type string;
ncx:password;
description
"User password to use for NETCONF sessions.
If none, then user will be prompted before connecting.";
}
uses SshKeyParms;
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 ncxapp:ProtocolsParm;
container start-commands {
ywx:cli-text-block;
description
"An optional block of yangcli commands to run
after the session is successfully started.";
}
}
}
Version 14.08-2
Page 46
2.3.10
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
server localhost
ncport 830
}
session A {
user andy2
password newpassword
server localhost
ncport 830
}
}
2.4 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 to
automatic loading of this file. The default is to load this file at start-up and save it upon exit.
suppress
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.
2.4.1
Create group
The group command is used to create a group. The 'session' parameter must also be present.
Version 14.08-2
Page 47
Example of 'group create':
> group create=AB session=session-A session=session-B
>
> group create=a1a2a3 session=a1 session=a2 session=a3
>
2.4.2
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'
missing-ok: false
lost-ok: false
reconnect-tries: 5
connected_cnt: 0
Session 'a1' connected:false
<
2.4.3
Delete group
The group delete command is used to delete a group.
> group delete=AB
>
> group delete=a1a2a3
>
> group list
No groups found
>
2.4.4
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'
Version 14.08-2
Page 48
missing-ok: false
missing-connect-ok:
lost-ok: false
reconnect-interval:
reconnect-tries: 5
connected_cnt: 0
number_of_sessions:
Session 'session-A'
Session 'session-B'
2.4.5
false
30
2
connected:false
connected:false
Remove Group
The group remove command is used to remove the sessions from a name group. The 'session' parameer must also
be present.
> group remove=AB session=session-A
>
> group list
Group 'AB'
missing-ok: false
lost-ok: false
reconnect-tries: 5
connected_cnt: 0
2.4.6
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'
missing-ok: false
lost-ok: false
reconnect-tries: 5
connected_cnt: 0
>
2.4.7
Connect Group
The group connect command is used to start a named group with session group parameters: lost-ok, missingconnect-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
Version 14.08-2
Page 49
AB>
Client Session Id: 1
Server Session Id: 1
------------------------NETCONF session established for xxxxx on localhost
AB>
------------------------AB> group list
Group 'AB'
This group is fully connected.
missing-ok: false
lost-ok: false
reconnect-tries: 5
connected_cnt: 2
Session 'session-A' connected:true
Session 'session-B' connected:true
2.4.8
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]
Version 14.08-2
Page 50
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.
parameter must also be presen...
The 'session'
leaf remove [NcxIdentifier]
Name of the group to remove some sessions.
'session' parameer must also be pres...
The
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.
>
2.4.9
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
}
session 'session-B' {
user 'andy'
password 'xxxxx'
public-key '$HOME/.ssh/id_rsa.pub'
private-key '$HOME/.ssh/id_rsa'
server 'localhost'
ncport 830
}
group 'AB' {
missing-connect-ok false
missing-ok false
lost-ok false
reconnect-interval 30
reconnect-tries 5
session 'session-A'
session 'session-B'
}
}
Version 14.08-2
Page 51
2.4.10
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>
2.5 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.
This section explains how to use yangcli-pro to manage a NETCONF server.
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.
2.5.1
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:
•
startup banner
•
client session ID
•
server session ID
•
protocol capabilities supported by the server
◦
•
Includes revision-date of supported module
YANG modules supported by the server
◦
Includes any features and deviations supported in the module
•
Enterprise specific capabilities supported by the server
•
Default target database (<candidate> or <running>)
•
Save operation mapping for the server
•
with-defaults reporting capability reported by the server
The following example shows a typical startup screen connecting to the netconfd-pro server:
Version 14.08-2
Page 52
NETCONF session established for andy on localhost
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
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-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
Version 14.08-2
Page 53
2.5.2
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.
Version 14.08-2
Page 54
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/schemas> operation will
be cached. And cached module can be used by yangcli-pro.
If autoload-save-cache is true, the modules held in the YANG module cache are 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 exit.
2.5.3
Retrieving Data
There are 6 commands available to retrieve generic data (i.e., an arbitrary subset of an entire NETCONF database):
command
description
get
raw NETCONF <get> operation
get-config
raw NETCONF <get-config> operation
sget
high-level subtree filter, using the <get> protocol
operation
sget-config
high-level subtree filter, using the <get-config> protocol
operation
xget
high-level XPath filter, using the <get> protocol operation
xget-config
high-level XPath filter, using the <get-config> 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
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.
Version 14.08-2
Page 55
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 'anyxml' data type.
2.5.4
Modifying Data
The following commands are available to modify generic data (i.e., an arbitrary subset of an entire NETCONF
database):
command
description
commit
raw NETCONF <commit> operation
create
high-level <edit-config> operation, with nc:operation='create'
delete
high-level <edit-config> operation, with nc:operation='delete'
delete-config
raw NETCONF <delete-config> operation
discard-changes
raw NETCONF <discard-changes> operation
edit-config
raw NETCONF <edit-config> operation
fill
fill a variable for re-use in other operations
insert
high-level <edit-config> operation, with YANG insert
operation extensions
lock
lock a NETCONF database
merge
high-level <edit-config> operation, with nc:operation='merge'
replace
high-level <edit-config> operation, with
nc:operation='replace'
save
High level save operation, depending on the default target
(candidate or running)
unlock
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
Version 14.08-2
Page 56
session1> $newvalue = 1518
--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
--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.
save command
capabilities
2.5.5
real command(s)
:candidate
commit
:writable-running
<none>
:startup
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.
Version 14.08-2
Page 57
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.
2.5.6
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 the --server parameter in the connect command.
The --fixorder configuration parameter can be used to control XML PDU ordering. If set to 'true', then the PDU will be
reordered (if needed),to use the canonical order, according to the YANG specification. If 'false', the order parameters
are entered at the command line will be their NETCONF PDU order as well. The default is 'true'. To send the server
incorrectly ordered data structures on purposes, set this parameter to 'false'.
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 the --user parameter in the connect command.
The --with-defaults configuration parameter, or the $$with-defaults system variable, can be used to set the default
value for the 'with-defaults' parameter extension for the NETCONF get, get-config, and copy-config protocol
operations. The default is 'none'.
The --error-option configuration parameter, or 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 configuration parameter, or 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'.
2.5.7
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
Version 14.08-2
Page 58
◦
•
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 'ping' the server and see if it responds
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
Subsystem
•
netconf
/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.
Version 14.08-2
Page 59
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 <getconfig> 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 <rpcreply>.
•
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.
2.6 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).
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. (TBD: start-server and stop-server commands will be
available in a future release.)
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,
2.6.1
Test Templates
The test suite file structure is shown below:
Version 14.08-2
Page 60
•
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.
2.6.2
YANG File Defining Test Templates
module yumaworks-unit-test {
namespace "http://yumaworks.com/ns/yumaworks-unit-test";
prefix "ut";
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
Version 14.08-2
Page 61
server unit tests for specific use cases and YANG modules
";
revision 2012-09-03 {
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 unit-test {
presence
"If this node is present then the unit-test
service is enabled.";
list test-suite {
description
"A list of test-suites all run against a single server.";
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;
Version 14.08-2
Page 62
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.
Version 14.08-2
Page 63
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 {
must "../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 {
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 {
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";
}
/**** !!!! TBD leave out for now !!!!
anyxml rpc-reply-data {
must "../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 unit-test
}
Version 14.08-2
Page 64
2.6.3
Example Test File
unit-test {
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"
result-type ok
command "merge /uint8.1 value=10"
Version 14.08-2
Page 65
}
step 4 {
description "session B tries to write to the target config
candidate is not locked so this should work"
result-type ok
}
step 5 {
description "session B tries to commit the candidate to running
running is locked so this should fail"
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"
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"
result-type error
result-error-tag resource-denied
}
step 8 {
description "session B issues a discard-changes"
result-type ok
command "discard-changes"
}
step 9 {
description "session A issues a discard-changes"
result-type ok
}
step 10 {
description "session B locks the candidate config"
result-type ok
}
step 11 {
description "session A tries to lock the candidate config,
which should fail because it is already locked"
result-type error
Version 14.08-2
Page 66
result-error-tag lock-denied
result-error-info session-id
}
step 12 {
description "session A tries to write to the target config,
which could fail because candidate is locked"
result-type error
}
step 13 {
description "session B tries to write to the target config"
result-type ok
}
step 14 {
description "session A tries to commit the candidate to running,
candidate is locked by B so this should fail"
result-type error
command "commit"
}
step 15 {
description "session B tries to commit the candidate to running,
running is locked by A so this should fail"
result-type error
command "commit"
}
step 16 {
description "session A tries to discard-changes,
result-type error
}
step 17 {
description "session A tries to unlock candidate,
result-type error
command "unlock target=candidate"
}
step 18 {
description "session B tries to unlock running,
which is locked by A so this should fail"
result-type error
Version 14.08-2
Page 67
command "unlock target=running"
}
step 19 {
description "session B unlocks candidate"
result-type ok
command "unlock target=candidate"
}
step 20 {
description "session A unlocks candidate"
result-type ok
command "unlock target=running"
}
step 21 {
description "session A commits nothing due to
discard-changes from B"
result-type ok
command "commit"
}
}
}
}
Version 14.08-2
Page 68
2.7 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.
2.7.1
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'.
There are 3 forms of the alias command:
1.
alias: display all command aliases in memory
2.
alias <name>: display the command alias with the specified name
3.
alias <name>=<value>: set the command alias with the specified name to the string value
Use the unset command to delete an alias.
alias command
Command type:
local
Default parameter:
var
Min parameters:
0
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
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.
▪
Version 14.08-2
A double-quoted string can contain single quotes:
Page 69
> 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:
◦
•
If a <name> parameter given:
◦
•
The current list of command aliases is displayed.
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:
◦
•
If a <name> parameter given:
◦
•
Not applicable
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'
>
2.7.2
aliases
Version 14.08-2
Page 70
The aliases command is used to load, save, or clear the command aliases, or display all command aliases if no
parameter is given.
There are 4 forms of the aliases command:
1.
aliases [show]: display all command aliases in memory
2.
aliases clear: clear all command aliases in memory
3.
aliases save [alias-filespec]: save the command aliases in memory in an '.aliases' file.
4.
aliases load [alias-filespec]: load the command aliases from an '.aliases' file into memory.
aliases command
Command type:
local
Default parameter:
none
Min parameters:
0
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
alias-action
◦
type: choice
◦
usage: optional
◦
default: show
◦
clear
▪
◦
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]
▪
◦
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'.
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:
◦
•
clear, load, save:
◦
A status message is displayed.
Version 14.08-2
Page 71
Negative Response:
•
An error message is printed if any error occurs.
Usage:
> aliases save
Saved aliases OK to '~/.yumapro/.yangcli_pro_aliases'
>
2.7.3
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 <copyconfig> operations is also required.
Note: choice statements are not supported at this time. Only string and numeric simple types are supported at this
time.
auto-test command
Command type:
local
Default parameter:
target
Min parameters:
1
Max parameters:
3
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
target
◦
type: schema identifier string
◦
usage: mandatory
Version 14.08-2
Page 72
•
•
◦
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:
◦
•
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>
2.7.4
cache
The cache command is used to clear 1 or all entries from the YANG module cache. There are 3 forms of this
command:
cache clear
cache delete foo
cache delete=foo revision=2014-05-22
cache command
Command type:
Version 14.08-2
local
Page 73
Default parameter:
none
Min parameters:
1
Max parameters:
2
Return type:
none
YANG file:
yancli-pro.yang
There are 3 forms of the cache command:
1.
cache clear:
Clear the YANG module cache on disk.
2.
cache delete=module-name
Delete the specified module name from the YANG
module cache. All revisions will be deleted from the cache.
3.
cache delete=module-name revision=revision-date
Delete the specified module name and revision date from the YANG
module cache.
Command Parameters:
cache-action
◦
type: choice
◦
usage: optional
◦
default: none
◦
clear
▪
◦
delete [name of module]
▪
◦
Clear the YANG module cache on disk.
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:
> show cache
yuma-ncx@2013-09-23
yuma-netconf@2013-09-28
t79@2014-06-19
test1a@2011-07-14
Version 14.08-2
Page 74
test1c@2008-10-12
test1@2008-10-12
test1b@2008-10-12
,<==============
test@2009-12-26
andy@myserver> cache delete=test1b
andy@myserver>
andy@myserver> show cache
yuma-ncx@2013-09-23
t79@2014-06-19
test1a@2011-07-14
test1c@2008-10-12
test1@2008-10-12
<==============
andy@myserver> cache delete=test1 revision=2008-10-12
andy@myserver>
yuma-ncx@2013-09-23
t79@2014-06-19
test1a@2011-07-14
test1c@2008-10-12
Version 14.08-2
Page 75
test@2009-12-26 yuma-arp@2012-01-13
test@2009-9-26
yuma-arp@2012-01-13
yuma-arp@2012-01-13
andy@myserver>
andy@myserver> cache clear
andy@myserver>
andy@myserver> cache clear
empty cache: ./yumapro/.yangcli
andy@myserver>
Reference:
•
2.7.5
yangcli-pro.yang
cd
The cd command is used to change the current working directory.
cd command
Version 14.08-2
Command type:
local
Default parameter:
dir
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Page 76
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
>
2.7.6
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.
close-session command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yuma-netconf.yang
Command Parameters:
•
none
Positive Response:
•
the session is terminated and the command prompt is changed to indicate idle mode
Version 14.08-2
Page 77
Negative Response:
•
an <rpc-error> message will be printed describing the error
Usage:
andy@myserver> close-session
RPC OK Reply 2 for session 10:
>
Reference:
•
RFC 6241, section 7.8
2.7.7
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.
commit command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
2
Return type:
status
YANG file:
yuma-netconf.yang
Capabilities needed:
:candidate
Capabilities optional:
:confirmed-commit
Command Parameters:
•
•
confirmed
◦
type: empty
◦
usage: optional
◦
default: none
◦
capabilities needed: :confirmed-commit
◦
This parameter requests a confirmed commit procedure. The server will expect another commit
command before the confirm-timeout time period expires.
confirm-timeout
◦
type: uint32 (range: 1 .. max)
◦
usage: optional
◦
default: 600 seconds
Version 14.08-2
Page 78
•
•
◦
capabilities needed: :confirmed-commit
◦
This is the number of seconds to request before the timeout.
The 'confirmed' leaf must also be present for this parameter to have any affect.
persist
◦
type: string
◦
usage: optional
◦
persist ID used to start or extend the confirmed commit procedure
persist-id
◦
type: string
◦
usage: optional
◦
persist ID used to conform a previously started the confirmed commit procedure
Positive Response:
•
the session is terminated and the command prompt is changed to indicate idle mode
Negative Response:
•
an <rpc-error> message will be printed describing the error
Usage:
andy@myserver> commit
andy@myserver>
Reference:
•
2.7.8
RFC 4741, section 8.3.4
config
The config command is used to enter configuration mode. It can only be used if the current session is connected to a
NETCONF server. The configuration source is given as the only parameter. The 'terminal' is the only supported
configuration source at this time.
config command
Version 14.08-2
Command type:
local
Default parameter:
term
Min parameters:
1
Max parameters:
1
Return type:
none (enter configuration mode)
YANG file:
yangcli-pro.yang
Page 79
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#
2.7.9
connect
The connect command is used to start a session with a NETCONF server.
This command can be used in 3 forms:
1.
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.
2.
Named Session: Only the --session-name parameter is used. The specified session-cfg template for all
connection parameters.
3.
Modified Named Session: The --session-name parameter is used and additional parameters can also be
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.
connect command
Version 14.08-2
Command type:
remote
Default parameter:
server
Page 80
Min parameters:
1
Max parameters:
10
Return type:
status
YANG file:
yangcli-pro.yang
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)
◦
configuration.
◦
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.
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
◦
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
Version 14.08-2
Page 81
•
•
•
•
◦
type: bits (netconf1.0 netconf1.1)
◦
usage: optional
◦
default: --protocols configuration parameter setting
◦
Specifies which NETCONF protocol versions to enable. Overrides –protocols configuration parameter.
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 –public-key configuration parameter.
session-name
◦
◦
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, or tcp-ncx)
◦
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, and the
--protocols value is set to netconf1.0. The --password value will be ignored. 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, and the
--protocols value is set to netconf1.0 and netconf1.1. The --password value will be ignored. A
direct TCP connection will be used instead of SSH, using the YumaWorks <ncx-connect> protocol.
Version 14.08-2
Page 82
Positive Response:
•
the session is started and the prompt changes to include the 'user@server' string.
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>
2.7.10
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.
copy-config command
Version 14.08-2
Command type:
remote
Default parameter:
none
Min parameters:
2
Max parameters:
3
Return type:
status
YANG file:
yuma-netconf.yang
none
:candidate
:startup
:url
Page 83
:with-defaults
Command Parameters:
•
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 copy operation.
◦
container contents: 1 of N:
▪
▪
▪
▪
▪
•
candidate
•
type: empty
•
capabilities needed: :candidate
running
•
type: empty
•
capabilities needed: none
startup
•
type: empty
•
capabilities needed: startup
config:
•
type: container (in-line configuration data)
•
url
•
type: yang:uri
•
capabilities needed: :url, and the scheme used in the URL must be specified in the :url capability
'schemes' parameter
•
To enter this parameter, the interactive mode must be used. The shorthand mode (source=url)
cannot be used, since this parameter contains a string.
target
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the target database for the copy operation.
◦
▪
▪
Version 14.08-2
candidate
•
type: empty
•
running
Page 84
•
type: empty
•
capabilities needed: :writable-running (still optional to implement)
◦
▪
▪
•
netconfd-pro does not support this mode
startup
•
type: empty
•
url
•
type: yang:uri
•
'schemes' parameter.
•
To enter this parameter, the interactive mode must be used. The shorthand mode (target=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 copied to the target database.
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> 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
Filling optional case /copy-config/input/target/config-source/url
Enter string value for leaf <url>:
Version 14.08-2
Page 85
andy@myserver:copy-config> file://configs/myconfig.xml
andy@myserver>
Reference:
•
2.7.11
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.
create command
Command type:
remote
Default parameter:
target
Min parameters:
1
Max parameters:
5
Return type:
status
YANG file:
yangcli-pro.yang
:candidate or :writable-running
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.
▪
▪
Version 14.08-2
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)
Page 86
•
•
•
•
•
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
◦
◦
usage: optional
◦
◦
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
Version 14.08-2
Page 87
•
$$test-option
◦
The <test-option> parameter for the <edit-config> operation will be derived from this variable
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> create varref=myvar
andy@myserver> create /nacm/rules/data-rule \
(user will be prompted to fill in the data-rule contents)
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)
andy@myserver>
Reference:
•
2.7.12
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.
create-subscription command
Version 14.08-2
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
4
Return type:
status
Page 88
YANG file:
notifications.yang
:notification
:interleave
Command Parameters:
•
•
•
•
stream
◦
type: string
◦
usage: optional
◦
default: 'NETCONF'
◦
This parameter specifies the name of the notification stream for this subscription request. Only the
'NETCONF' stream is mandatory to implement. Any other stream contains vendor-specific content, and
may not be fully supported, depending on the stream encoding.
filter
◦
type: anyxml (same as the <get> or <get-config> filter parameter)
◦
usage: optional
◦
default: none
◦
This parameter specifies a boolean filter that should be applied to the stream. This is the same format as
the standard <filter> element in RFC 6241, except that instead of creating a subset of the database for an
<rpc-reply> PDU, the filter is used as a boolean test to send or drop each notification delivered from the
server.
▪
If any nodes are left in the 'test response', the server will send the entire notification.
▪
If the result is empty after the filter is applied to the “test response”, then the server will not send the
notification at all.
▪
It is possible that access control will either cause the a notification to be dropped entirely, or may be
pruned and still delivered. The standard is not clear on this topic. The netconfd-pro server will
prune any unauthorized payload from an eventType, but if the <eventType> itself is unauthorized, the
entire notification will be dropped.
startTime
◦
type: yang:date-and-time
◦
usage: optional
◦
default: none
◦
This parameter causes any matching replay notifications to be delivered by the server, if notification
replay is supported by the server. A notification will match if its <eventTime> value is greater or equal to
the value of this parameter.
◦
After all the replay notifications are delivered, the server will send a <replayComplete> eventType,
indicating there are no more replay notifications that match the subscription request.
stopTime
◦
type: yang:date-and-time
◦
usage: optional (not allowed unless startTime is also present)
◦
default: none
Version 14.08-2
Page 89
◦
This parameter causes any matching replay notifications to be delivered by the server, if notification
replay is supported by the server. A notification will match if its <eventTime> value is less than the value
of this parameter.
▪
This parameter must be greater than the startTime parameter, or an error will be returned by the
server.
▪
If this parameter is used, then the entire subscription will stop after this specified time, even if it is in
the future. The <notificationComplete> eventType will be sent by the server when this event occurs.
▪
If this parameter is not used (but startTime is used), then the server will continue to deliver 'live'
notifications after the <replayComplete> eventType is sent by the server.
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> create-subscription
OR
andy@myserver> create-subscription startTime=2009-01-01T00:00:00Z
andy@myserver>
Reference:
•
RFC 5277, section 2.1.1
2.7.13
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.
delete command
Version 14.08-2
Command type:
remote
Default parameter:
target
Min parameters:
1
Max parameters:
2
Page 90
Return type:
status
YANG file:
yangcli-pro.yang
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:schemainstance 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
◦
•
$$error-option
◦
•
$$optional
◦
•
Controls whether optional descendant nodes will be filled into the target parameter contents
$$test-option
◦
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> delete /nacm/rules/data-rule \
(user will be prompted to fill in the data-rule 'name' key leaf)
Version 14.08-2
Page 91
andy@myserver> delete \
target=/nacm/rules/data-rule[name='test rule']/comment
andy@myserver>
Reference:
•
2.7.14
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.:
delete-config command
Command type:
remote
Default parameter:
none
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yuma-netconf.yang
none
:candidate
:startup
:url
Command Parameters:
•
target
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the target database for the delete operation.
◦
▪
startup
•
Version 14.08-2
type: empty
Page 92
▪
•
•
a server may support this target
url
•
type: yang:uri
•
•
•
a server may support this parameter
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> delete-config target=startup
andy@myserver>
Reference:
•
2.7.15
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.
discard-changes command
Version 14.08-2
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
Page 93
YANG file:
yuma-netconf.yang
:candidate
Command Parameters: none
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> discard-changes
andy@myserver>
Reference:
•
RFC 6241, section 8.3.4.2
2.7.16
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.
edit-config command
Version 14.08-2
Command type:
remote
Default parameter:
none
Min parameters:
2
Max parameters:
5
Return type:
status
YANG file:
yuma-netconf.yang
Page 94
:url
:rollback-on-error
:validate
Command Parameters:
•
•
•
default-operation
◦
type: enumeration (merge replace none)
◦
usage: optional
◦
default: merge
◦
This parameter specifies which edit operation will be in effect at the start of the operation, before any
nc:operation attribute is found.
▪
The high-level edit operations provided by yangcli-pro will set this parameter to 'none'. This is the
safest value, since only subtrees that have an explicit nc:operation attribute in effect can possibly be
altered by the command.
▪
If the value is 'merge', then any missing nodes in the database will be automatically created as
needed.
▪
If the value is 'replace', then the target database will be pruned to match the edits, as needed. Only
the data from the config parameter will remain if this value is used. (Use with extreme caution).
error-option
◦
type: enumeration (stop-on-error continue-on-error rollback-on-error
◦
usage: optional
◦
default: stop-on-error
◦
This parameter specifies what the server should do when an error is encountered.
▪
The rollback-on-error value is only allowed if the :rollback-on-error capability is supported by the
server.
▪
The standard is not clear what continue-on-error really means. It is suggested that this value not be
used. It is possible that the server will validate all input parameters before making any changes, no
matter how this parameter is set.
choice edit-content (not entered)
◦
◦
config
▪
type: anyxml
▪
usage: mandatory
▪
default: none
▪
This parameter specifies the subset of the database that should be changed. This is the most
common way to edit a NETCONF server database, since it is mandatory to support by all agents.
url
▪
type: yang:uri
▪
▪
To enter this parameter, the interactive mode must be used. The shorthand mode (target=url) cannot
be used, since this parameter contains a string.
Version 14.08-2
Page 95
•
target
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the target database for the edit operation.
◦
container contents: choice: 1 of N:
▪
▪
•
candidate
•
type: empty
•
running
•
type: empty
•
capabilities needed: :writable-running
test-option
◦
type: enumeration (test-then-set set test-only)
◦
usage: optional
◦
default: set
◦
This parameter specifies how the server should test the edit-content parameter before using it.
▪
If the value is 'set' (normal case), the server will apply validation tests as needed for the individual
data structures being edited
▪
The value 'test-then-set' is only allowed if the :validate capability is supported by the server. The
server will test if the entire database will be valid after the edits are made, before making any
changes to the candidate configuration.
•
▪
This mode is very resource intensive. Set this parameter to 'set' for better performance, and run
the validation tests manually with the validate command.
The value 'test-only' is not supported by all agents. It will be in the next version of the NETCONF
protocol, but is non-standard at this time.
•
Use this value to check if a specific edit should succeed or not, allowing errors to be corrected
before altering the database for real.
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> edit-config target=candidate \
default-operation=merge \
test-option=test \
Version 14.08-2
Page 96
error-option=stop-on-error \
config=@myconfig.xml
andy@myserver>
Reference:
•
2.7.17
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 command
elif command
Version 14.08-2
Command type:
local
Default parameter:
expr
Min parameters:
1
Max parameters:
2
Return type:
status
YANG file:
yangcli-pro.yang
Page 97
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:
•
Negative Response:
•
◦
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>
2.7.18
else
The else command is used to define a final 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 one time within an if command sequence.
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.
if command
....
[elif command]
Version 14.08-2
Page 98
....
[elif-command]
...
[else command]
...
end command
else command
Command type:
local
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yangcli-pro.yang
Positive Response:
•
Negative Response:
•
◦
else without a previous if command will cause an error
Usage:
> else
>
2.7.19
end
The end command is used to terminate a conditional command block after an if command block, or after a 'while'
command.
This command must be entered within the same script as the if or while command, when used within a script.
if command
....
[elif command]
Version 14.08-2
Page 99
....
[elif-command]
...
[else command]
...
end command
while command
....
end command
end command
Command type:
local
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yangcli-pro.yang
Positive Response:
•
Negative Response:
•
◦
else without a previous if command will cause an error
Usage:
> end
>
2.7.20
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.
Version 14.08-2
Page 100
eval command
Command type:
local
Default parameter:
expr
Min parameters:
1
Max parameters:
2
Return type:
data
YANG file:
yangcli-pro.yang
Command Parameters:
•
•
expr
◦
◦
usage: mandatory
◦
default: none
◦
docroot
◦
type: anyxml
◦
◦
default: none
◦
any path nodes.
Positive Response:
•
Negative Response:
•
◦
elif without a previous if command will cause an error
◦
elif following an 'else' command 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'
Version 14.08-2
Page 101
session1> $sysname = eval '//sysName' docroot=$backup
2.7.21
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.
eventlog command
Command type:
local
Default parameter:
show
Min parameters:
0
Max parameters:
3
Return type:
status
YANG file:
yangcli-pro.yang
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')
◦
Version 14.08-2
brief
▪
type: empty
▪
usage: optional
Page 102
◦
◦
•
•
▪
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:
Version 14.08-2
Page 103
> eventlog show=5 start=3
[3]
[4]
[5]
[6]
[7]
[2009-07-10T02:21:10Z]
[2009-07-10T02:23:14Z]
[2009-07-10T02:23:23Z]
[2009-07-10T02:24:52Z]
[2009-07-10T02:24:57Z]
(4)
(5)
(6)
(7)
(8)
<sysSessionStart>
<sysSessionEnd>
<sysSessionStart>
<sysConfigChange>
<sysSessionEnd>
>
2.7.22
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.
exit command
Command type:
local
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
none (prompt is changed)
YANG file:
yangcli-pro.yang
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:
•
Usage:
andy@myserver# exit
Version 14.08-2
Page 104
andy@myserver>
2.7.23
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.
fill command
Command type:
local
Default parameter:
target
Min parameters:
2
Max parameters:
3
Return type:
data
YANG file:
yangcli-pro.yang
Command Parameters:
•
•
•
optional
◦
type: empty
◦
usage: optional
◦
◦
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:schemainstance 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.
Version 14.08-2
Page 105
▪
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
◦
Positive Response:
•
OK
Negative Response:
•
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
>
2.7.24
get
The get command is used to retrieve data from the server.
get command
Version 14.08-2
Command type:
remote
Default parameter:
none
Page 106
Min parameters:
0
Max parameters:
2
Return type:
data
YANG file:
yuma-netconf.yang
Command Parameters:
•
•
filter
◦
type: anyxml
◦
usage: optional
◦
default: none
◦
This parameter specifies a boolean filter that should be applied to the stream. Any data in the <running>
database (or non-config data) that does not match the filter will be left out of the <rpc-reply> response.
▪
If no filter is used, the server will return the entire <running> database and all non-config data as well.
This could be a lot of data, depending on the server.
▪
If the result is empty after the filter is applied to the available data, then the server will send an empty
<data> element in the <rpc-reply>
▪
It is possible that access control will cause the <rpc-reply> to be pruned. The netconfd-pro server
will silently prune any unauthorized payload from the
<rpc-reply>.
with-defaults
◦
◦
usage: optional
◦
default: none
◦
◦
This parameter controls how nodes containing only default values are returned in the <rpc-reply>.
Positive Response:
•
the server returns <data>
Negative Response:
•
•
Output:
•
data
◦
type: anyxml
◦
This element will contain the requested data from the <running> database, or non-config data from the
server instrumentation.
Usage:
session1> get
RPC Data Reply 20 for session 10:
Version 14.08-2
Page 107
rpc-reply {
data {
…. data returned by the server
}
}
session1> get filter=@myfilter.xml
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:
•
2.7.25
get-config
The get-config command is used to retrieve configuration data from the server.
get-config command
Command type:
remote
Default parameter:
none
Min parameters:
1
Max parameters:
3
Return type:
data
YANG file:
yuma-netconf.yang
Command Parameters:
•
filter
◦
type: anyxml
◦
usage: optional
◦
default: none
◦
This parameter specifies a boolean filter that should be applied to the stream. Any data in the <running>
database (or non-config data) that does not match the filter will be left out of the <rpc-reply> response.
▪
Version 14.08-2
If no filter is used, the server will return the entire <running> database and all non-config data as well.
This could be a lot of data, depending on the server.
Page 108
•
▪
If the result is empty after the filter is applied to the available data, then the server will send an empty
<data> element in the <rpc-reply>
▪
It is possible that access control will cause the <rpc-reply> to be pruned. The netconfd-pro server
will silently prune any unauthorized payload from the
<rpc-reply>.
source
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the source database for the retrieval operation.
◦
▪
▪
▪
▪
•
candidate
•
type: empty
•
running
•
type: empty
•
startup
•
type: empty
•
url
•
type: yang:uri
•
'schemes' parameter
•
with-defaults
◦
◦
usage: optional
◦
default: none
◦
◦
Positive Response:
•
Negative Response:
•
•
Output:
Version 14.08-2
Page 109
•
data
◦
type: anyxml
◦
This element will contain the requested data from the source database.
Usage:
session1>
$my-config = get-config target=running
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:
•
2.7.26
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.
get-locks command
Version 14.08-2
Command type:
remote
Default parameter:
none
Min parameters:
0
Page 110
Max parameters:
3
Return type:
status
YANG file:
yangcli-pro.yang
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:
•
Negative Response:
•
•
Usage:
session1> get-locks lock-timeout=0
Sending <lock> operations for get-locks...
get-locks finished OK
session1>
Version 14.08-2
Page 111
2.7.27
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. This command is provided by the NETCONF server, not yangcli-pro.
The session indent amount, session line size, and default behavior for the with-defaults parameter can be controlled
at this time.
get-my-session command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
data
YANG file:
mysession.yang
none
Command Parameters:
•
none
Positive Response:
•
the server returns <indent>, <linesize>, and <with-defaults> elements
Negative Response:
•
•
Output:
•
indent
◦
type: uint32 (range 0 to 9)
◦
•
•
linesize
◦
type: uint32
◦
This parameter specifies the desired line length for the session.
with-defaults
◦
type: enumeration (none report-all trim explicit)
◦
This parameter specifies the desired default with-defaults filtering behavior for the session.
◦
session1> get-my-session
rpc-reply {
data {
indent 3
Version 14.08-2
Page 112
linesize 72
with-defaults report-all
}
}
session1>
2.7.28
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.
session1> sget /netconf-state/schemas
The preceding command will return a <schemas> container with several <schema> child nodes. One example entry
is shown below:
schemas {
schema system 2009-06-04 YANG {
identifier system
version 2009-06-04
format YANG
namespace http://netconfcentral.org/ns/yuma-system
location NETCONF
}
}
The <identifier>, <version> and <format> leafs can be used as the corresponding parameter values for the getschema command. See the example below for more details.
get-schema command
Version 14.08-2
Command type:
remote
Default parameter:
none
Min parameters:
3
Max parameters:
3
Return type:
data
Page 113
YANG file:
ietf-netconf-monitoring.yang
:schema-retrieval
Command Parameters:
•
•
•
identifier
◦
type: string
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the module to retrieve.
▪
Do not use any path specification of file extension; just the module name is entered.
▪
The name is case-sensitive, and must be specified exactly as defined.
version
◦
type: string
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the version of the module to retrieve.
▪
For YANG modules, this will be the most recent revision date string defined in a module revision
statement.
▪
If any version is acceptable, or if the specific version is not known, then use the empty string.
format
◦
type: enumeration (XSD YANG YIN RNG)
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the format of the module to be retrieved.
▪
XSD: W3C REC REC-xmlschema-1-20041028
▪
YANG: RFC 6020
▪
YIN: RFC 6020
▪
RNG: ISO/IEC 19757-2
▪
netconfd-pro only supports the YANG and YIN formats
Positive Response:
•
Negative Response:
•
•
Output:
•
data
◦
type: anyxml
Version 14.08-2
Page 114
yangcli-pro will strip off this XML container if the command result is being saved to a text file. Only the
YANG contents will be saved instead.
◦
Usage:
session1> @notifications.yang = get-schema \
identifier=notifications \
version=2009-06-04 \
format=YANG
rpc-reply {
data {
…. entire notifications.yang contents
}
}
(after retrieval, the module can be loaded locally
with the mgrload command)
session1> mgrload notificications.yang
OK
session1>
Reference:
•
draft-ietf-netconf-monitoring-06.txt
2.7.29
group
The group command is used to manage the session groups. Refer to the 'Using Group Configuration' section for
details on the format of this file.
There are 7 sub-commands:
•
create
•
add
•
delete
•
remove
•
list
•
show
•
connect
Refer to the section on “Netconf Group Configuration” for more details on using group configuration.
group command
Version 14.08-2
Page 115
Command type:
local
Default parameter:
none
Min parameters:
1
Max parameters:
6
Return type:
status
YANG file:
yangcli-pro.yang
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
◦
◦
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
◦
◦
An active group cannot be deleted.
remove
◦
◦
This parameter specifies the name of the session to delete from the group in memory. An active session
cannot be deleted.
show
◦
◦
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
Version 14.08-2
Page 116
◦
•
•
•
•
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
bomes 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.
> group list
No groups found
> group create=AB session-A
> group list
Group 'AB'
missing-ok: false
lost-ok: false
reconnect-tries: 5
connected_cnt: 0
Session 'session-A' connected:false >
> group add=AB session-B
> group list
Group 'AB'
missing-ok: false
Version 14.08-2
Page 117
missing-connect-ok:
lost-ok: false
reconnect-interval:
reconnect-tries: 5
connected_cnt: 0
number_of_sessions:
Session 'session-A'
Session 'session-B'
false
30
2
connected:false
connected:false
> group remove=AB session=session-A
> group list
Group 'AB'
missing-ok: false
lost-ok: false
reconnect-tries: 5
connected_cnt: 0
> 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'
missing-ok: false
lost-ok: false
reconnect-tries: 5
connected_cnt: 0
Session 'session-A' 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
base:1.0
candidate:1.0
------
Version 14.08-2
Page 118
-----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
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>
2.7.30
help
Version 14.08-2
Page 119
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.
help command
Command type:
local
Default parameter:
command
Min parameters:
3
Max parameters:
3
Return type:
data
YANG file:
ietf-netconf-monitoring.yang
:schema-retrieval
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
Version 14.08-2
Page 120
◦
◦
•
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
◦
◦
◦
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:
•
Version 14.08-2
Page 121
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>
2.7.31
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.
Version 14.08-2
Page 122
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.
The history clear command is used to delete the entire command line history buffer.
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.
history command
Command type:
local
Default parameter:
show
Min parameters:
0
Max parameters:
2
Return type:
data
YANG file:
yangcli-pro.yang
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
▪
Version 14.08-2
type: string
Page 123
▪
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.
choice help-mode (not entered)
This parameter is ignored unless the history show command is entered.
◦
◦
◦
brief
▪
type: empty
▪
usage: optional
▪
default: none
▪
normal
▪
type: empty
▪
usage: optional
▪
default: none
▪
full
▪
type: empty
▪
usage: optional
▪
default: none
Version 14.08-2
Page 124
▪
Positive Response:
•
the requested history entries will be printed for the history show command
•
all other commands will return OK
Negative Response:
•
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
>
2.7.32
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
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 command
if command
Command type:
Version 14.08-2
local
Page 125
Default parameter:
expr
Min parameters:
1
Max parameters:
2
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
•
expr
◦
◦
usage: mandatory
◦
default: none
◦
docroot
◦
type: anyxml
◦
◦
default: none
◦
any path nodes.
Positive Response:
•
Negative Response:
•
◦
Usage:
andy@myserver> if "$sysname = 'localhost'"
andy@myserver>
2.7.33
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.
insert command
Version 14.08-2
Page 126
Command type:
remote
Default parameter:
target
Min parameters:
2
Max parameters:
7
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the where yangcli-pro should get the data from, for the insert operation. It is
▪
▪
varref
•
type: string
•
usage: mandatory
•
default: none
•
This parameter specifies the name of the user variable to use for the target of the insert
will be printed.
•
•
•
Version 14.08-2
target
◦
type: string
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the database target node of the insert operation. This is an
optional
◦
type: empty
◦
usage: optional
◦
◦
value
◦
type: anyxml
◦
usage: mandatory
◦
default: none
Page 127
◦
•
•
•
•
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
◦
◦
usage: optional
◦
◦
System Variables:
•
$$default-operation
◦
•
$$error-option
◦
•
$$test-option
Version 14.08-2
Page 128
◦
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> insert varref=myvar order=first
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)
andy@myserver>
Reference:
•
draft-ietf-netmod-yang-13
2.7.34
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 sessionid parameter in this command, to terminate the session will the lock.
Note: this is an extreme measure, which should be used with caution.
kill-session command
Version 14.08-2
Command type:
remote
Default parameter:
target
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yuma-netconf.yang
Page 129
Command Parameters:
•
session-id
◦
type: uint32 (range: 1.. max)
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the session number of the currently active NETCONF session that should be
terminated.
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver>
kill-session session-id=11
andy@myserver>
Reference:
•
2.7.35
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.
list command
Version 14.08-2
Page 130
Command type:
local
Default parameter:
none
Min parameters:
1
Max parameters:
6
Return type:
data
YANG file:
yangcli-pro.yang
Command Parameters:
•
choice help-mode (not entered)
◦
◦
◦
•
brief
▪
type: empty
▪
usage: optional
▪
default: none
▪
normal
▪
type: empty
▪
usage: optional
▪
default: none
▪
full
▪
type: empty
▪
usage: optional
▪
default: none
▪
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.
Version 14.08-2
•
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.
Page 131
◦
◦
◦
◦
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
Version 14.08-2
Page 132
Negative Response:
•
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>
2.7.36
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.
Refer to the netconfd-pro configuration section for more details on adding new YANG modules into the server.
Version 14.08-2
Page 133
After using this command, the mgrload command may also be needed to keep the current session synchronized with
the server.
Use the revision parameter to load a specific revision of a module.
The server will return the revision date of the module that was loaded (or already present).
load command
Command type:
remote
Default parameter:
module
Min parameters:
1
Max parameters:
3
Return type:
data
YANG file:
yuma-system.yang
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:
•
the server returns <mod-revision>
Negative Response:
•
•
Usage:
Version 14.08-2
Page 134
andy@myserver>
load toaster revision=2009-06-23
rpc-reply {
mod-revision 2009-06-23
}
andy@myserver>
2.7.37
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.
lock command
Version 14.08-2
Command type:
remote
Default parameter:
none
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yuma-netconf.yang
none
:candidate
:startup
:url
Page 135
Command Parameters:
•
target
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the target database to be locked.
◦
▪
▪
▪
▪
candidate
•
type: empty
•
running
•
type: empty
•
startup
•
type: empty
•
url
•
type: yang:uri
•
•
Positive Response:
•
Negative Response:
•
•
◦
If the <error-tag> is 'lock-denied' then the <error-info> will contain a <session-id> leaf. This identifies the
session number of the current lock holder.
Usage:
andy@myserver>
lock target=candidate
andy@myserver>
2.7.38
log-debug
Version 14.08-2
Page 136
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.
log-debug command
Command type:
local
Default parameter:
msg
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
msg
◦
type: string
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the string to print to the program log.
Positive Response:
•
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>
2.7.39
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').
log-error command
Version 14.08-2
Page 137
Command type:
Version 14.08-2
local
Page 138
Default parameter:
msg
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
msg
◦
type: string
◦
usage: mandatory
◦
default: none
◦
Positive Response:
•
Negative Response:
•
Usage:
andy@myserver> log-error 'sysName not correct'
Error: sysName not correct
andy@myserver>
2.7.40
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').
log-info command
Version 14.08-2
Command type:
local
Default parameter:
msg
Min parameters:
1
Max parameters:
1
Return type:
status
Page 139
YANG file:
yangcli-pro.yang
Command Parameters:
•
msg
◦
type: string
◦
usage: mandatory
◦
default: none
◦
Positive Response:
•
Negative Response:
•
Usage:
andy@myserver> log-info 'sysName is correct'
Info: sysName is correct
andy@myserver>
2.7.41
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').
log-warn command
Command type:
local
Default parameter:
msg
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
msg
◦
type: string
Version 14.08-2
Page 140
◦
usage: mandatory
◦
default: none
◦
Positive Response:
•
Negative Response:
•
Usage:
andy@myserver> log-warn 'sysName object not found'
Warning: sysName object not found
andy@myserver>
2.7.42
merge
The merge command is a high-level <edit-config> operation. It is used to merge some new nodes into the default
target database.
merge command
Command type:
remote
Default parameter:
target
Min parameters:
1
Max parameters:
5
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
◦
◦
usage: mandatory
◦
default: none
Version 14.08-2
Page 141
◦
This parameter specifies the where yangcli-pro should get the data from, for the merge operation. It is
▪
▪
varref
•
type: string
•
usage: mandatory
•
default: none
•
This parameter specifies the name of the user variable to use for the target of the merge
will be printed.
•
•
•
•
•
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
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
◦
◦
value
◦
type: anyxml
◦
usage: mandatory
◦
default: none
◦
timeout
◦
Version 14.08-2
Page 142
◦
usage: optional
◦
◦
System Variables:
•
$$default-operation
◦
•
$$error-option
◦
•
$$test-option
◦
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> merge \
target=/nacm/rules/moduleRule[moduleName='netconf']\
[allowed-rights='read write']/allowed-group \
value=ncx:guest
andy@myserver>
Reference:
•
2.7.43
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.
mgrload command
Version 14.08-2
Command type:
local
Default parameter:
module
Page 143
Min parameters:
1
Max parameters:
3
Return type:
status
YANG file:
yangcli-pro.yang
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:
•
Usage:
> mgrload toaster
Load module toaster OK
>
2.7.44
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.
Version 14.08-2
Page 144
This command is only supported by the netconfd-pro server. The server will simply respond 'OK', if the request is
well-formed.
no-op command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yuma-system.yang
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver>
no-op
andy@myserver>
2.7.45
pwd
The pwd command is used to print the current working directory.
pwd command
Command type:
local
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yangcli-pro.yang
Positive Response:
Version 14.08-2
Page 145
•
the current working directory is printed to the log or STDOUT
Negative Response:
•
Usage:
> pwd
Current working directory is /home/andy
>
2.7.46
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.
quit command
Command type:
local
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
none
YANG file:
yangcli-pro.yang
Positive Response:
•
The program terminates; no response will be printed.
Negative Response:
•
Usage:
> quit
andy@myworkstation>
2.7.47
recall
The recall command is used to recall a previously entered command line from the command line history buffer.
Version 14.08-2
Page 146
A command is recalled by its command ID number. Use the history show command to see the contents of the
command line history buffer.
recall command
Command type:
local
Default parameter:
index
Min parameters:
1
Max parameters:
1
Return type:
data
YANG file:
yangcli-pro.yang
Positive Response:
•
The specified command line is recalled into the current command line.
Negative Response:
•
Usage:
> recall 7
> sget /system
2.7.48
record-test
The record-test command is used to automatically record commands into a test script that is compatible with the testsuite 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.
record-test command
Version 14.08-2
Command type:
local
Default parameter:
suite-name
Min parameters:
1
Page 147
Max parameters:
3
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
•
choice record-test-action (not entered)
▪
choice usage: mandatory
▪
default: case: none
▪
start-case
•
•
•
▪
▪
▪
Version 14.08-2
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
Page 148
▪
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:
•
Usage:
andy@myserver> record-test start suite1 test-name=test1
Start recording:
suite=suite1 test=test1
andy@myserver>
2.7.49
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.
release-locks command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yangcli-pro.yang
Positive Response:
•
The previously granted locks are released.
Negative Response:
•
•
Usage: (showing 2 locks being released)
Version 14.08-2
Page 149
andy@myserver> release-locks
andy@myserver>
2.7.50
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 new “remove” operation, defined in RFC 6241, This command will only work on NETCONF
servers that support the RFC 6241 (base:1.1) version of the NETCONF protocol. 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.
remove command
Command type:
remote
Default parameter:
target
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
:base:1.1
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:schemainstance string, so any instance identifier, or absolute path expression, or something in between, is
accepted.
System Variables:
•
$$default-operation
◦
•
$$error-option
Version 14.08-2
Page 150
◦
•
$$optional
◦
•
$$test-option
◦
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> remove /nacm/rules/data-rule \
(user will be prompted to fill in the data-rule 'name' key leaf)
andy@myserver> remove \
target=/nacm/rules/data-rule[name='test rule']/comment
andy@myserver>
Reference:
•
2.7.51
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.
replace command
Version 14.08-2
Command type:
remote
Default parameter:
target
Min parameters:
1
Page 151
Max parameters:
5
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the where yangcli-pro should get the data from, for the replace operation. It is
▪
▪
varref
•
type: string
•
usage: mandatory
•
default: none
•
This parameter specifies the name of the user variable to use for the target of the replace
will be printed.
•
•
•
Version 14.08-2
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
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
◦
◦
Page 152
•
•
value
◦
type: anyxml
◦
usage: mandatory
◦
default: none
◦
timeout
◦
◦
usage: optional
◦
◦
System Variables:
•
$$default-operation
◦
•
$$error-option
◦
•
$$test-option
◦
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> replace \
target=/nacm/rules/moduleRule[moduleName='yuma-system']\
[allowed-rights='exec']
(user prompted to fill in specified <moduleRule> element)
andy@myserver>
Reference:
Version 14.08-2
Page 153
•
2.7.52
restart
The restart command is used to restart the NETCONF server.
This command is only supported by the netconfd-pro server. This command is provided by the NETCONF server,
not yangcli-pro.
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 netconfd-pro user manual for details on configuring access control.
restart command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yuma-system.yang
Positive Response:
•
the server will drop all sessions and restart
Negative Response:
•
•
Usage:
andy@myserver> restart
ses: session 10 shut by remote peer
>
2.7.53
run
The run command is used to run 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 at this time.
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.
Version 14.08-2
Page 154
run command
Command type:
local
Default parameter:
script
Min parameters:
1
Max parameters:
10
Return type:
status
YANG file:
yangcli-pro.yang
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 specifis 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 <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)
Version 14.08-2
Page 155
andy@myserver>
2.7.54
save
The save command is used to save NETCONF database edits to non-volatile storage, on the server. It is a pseudocommand, 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 section on
NETCONF sessions for more details.
save command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
none
YANG file:
yangcli-pro.yang
Positive Response:
•
The server returns one or two <ok/> responses.
Negative Response:
•
•
Usage:
andy@myserver> save
RPC OK Reply 34 on session 10
andy@myserver>
2.7.55
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.
Version 14.08-2
Page 156
session command
Command type:
local
Default parameter:
set-current
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
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:
•
andy@myserver>
session set-current session-A
session-A>
2.7.56
session-cfg
The session-cfg command is used to access a named session.
•
delete
•
save
•
show (default)
session-cfg command
Command type:
Version 14.08-2
local
Page 157
Default parameter:
show
Min parameters:
1
Max parameters:
2
Return type:
status
YANG file:
yangcli-pro.yang
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:
•
andy@myserver> session-cfg save session-A
Saving current session as 'session-A'
andy@myserver>
2.7.57
sessions-cfg
The sessions-cfg command is used to access the named session files.
•
clear
•
load
•
save
Version 14.08-2
Page 158
•
show (default)
sessions-cfg command
Command type:
local
Default parameter:
show
Min parameters:
1
Max parameters:
2
Return type:
status
YANG file:
yangcli-pro.yang
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:
•
session-A> sessions-cfg load ~/more-sessions.conf
Version 14.08-2
Page 159
Loading saved sessions from '/home/andy/more-sessions.conf'
Loaded saved sessions OK from '~/more-sessions.conf'
session-A>
2.7.58
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:secure, so only the system super-user can invoke this command by default.
set-log-level command
Command type:
remote
Default parameter:
none
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yuma-system.yang
none
Command Parameters:
•
log-level
◦
type: enumeration (off, error, warn, info, debug, debug2, debug3)
◦
This mandatory parameter specifies the desired server logging verbosity level.
Positive Response:
•
Negative Response:
•
•
An <rpc-error> message will be printed if the server detected an error.]
andy@myserver> set-log-level log-level=debug2
andy@myserver>
2.7.59
set-my-session
Version 14.08-2
Page 160
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.
The session line size and default behavior for the with-defaults parameter can be controlled at this time.
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.
set-my-session command
Command type:
remote
Default parameter:
none
Min parameters:
0
Max parameters:
4
Return type:
status
YANG file:
yuma-mysession.yang
none
Command Parameters:
•
•
•
•
indent
◦
type: uint32 (range: 0 .. 9)
◦
This parameter specifies the desired number of spaces to indent for each new XML nest level, for the
session logging. If missing, then the indent amount is not changed.
linesize
◦
type: uint32 (range: 40 .. 1024)
◦
This parameter specifies the desired line length for the session. If missing, then the current line size is
not changed.
with-defaults
◦
type: enumeration (report-all trim explicit)
◦
This parameter specifies the desired default with-defaults filtering behavior for the session. If missing, the
current with-defaults behavior is not changed.
message-indent
◦
type: int32 (range: -1 .. 9)
◦
This parameter specifies the desired number of spaces to indent for each new XML nest level, for
protocol messages sent to the session. If missing, then the message indent amount is not changed.
Positive Response:
•
Negative Response:
•
•
An <rpc-error> message will be printed if the server detected an error.]
Version 14.08-2
Page 161
andy@myserver>
set-my-session --linesize=64 --with-defaults=trim --message-indent=1
andy@myserver>
2.7.60
sget
The sget command is used to invoke a NETCONF <get> operation with a subtree filter.
in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the nofill
parameter.
sget command
Command type:
remote
Default parameter:
target
Min parameters:
1
Max parameters:
5
Return type:
data
YANG file:
yangcli-pro.yang
none
:with-defaults
Command Parameters:
•
◦
◦
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.
•
target
◦
Version 14.08-2
type: string
Page 162
•
•
•
•
•
◦
◦
default: none
◦
This parameter specifies the database target node of the <get> operation. This is an
▪
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
◦
◦
value
◦
type: anyxml
◦
usage: mandatory
◦
default: none
◦
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
◦
Version 14.08-2
Page 163
◦
usage: optional
◦
default: none
◦
◦
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:
•
Negative Response:
•
•
Output:
•
data
◦
type: anyxml
◦
This element will contain the requested data from the <running> database or non-config data structures.
Usage:
andy@myserver> sget sytem
Filling container /system:
rpc-reply {
data {
system {
sysName myserver.localdomain
sysCurrentDateTime 2009-07-06T02:24:19Z
sysBootDateTime 2009-07-05T19:22:28Z
}
}
}
andy@myserver>
Reference:
•
2.7.61
sget-config
The sget-config command is used to invoke a NETCONF <get-config> operation with a subtree filter.
in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the nofill
parameter.
Version 14.08-2
Page 164
sget-config command
Command type:
remote
Default parameter:
target
Min parameters:
2
Max parameters:
6
Return type:
data
YANG file:
yangcli-pro.yang
none
:candidate
:startup
:url
:with-defaults
Command Parameters:
•
◦
◦
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.
•
target
◦
type: string
◦
◦
default: none
◦
This parameter specifies the database target node of the <get> operation. This is an
▪
Version 14.08-2
The escape command ('?s') can be used in parameter mode to skip a parameter
completely.
Page 165
▪
•
•
•
•
•
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
◦
◦
value
◦
type: anyxml
◦
usage: mandatory
◦
default: none
◦
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
◦
◦
usage: mandatory
◦
default: none
◦
◦
▪
candidate
•
Version 14.08-2
type: empty
Page 166
•
▪
▪
▪
•
running
•
type: empty
•
startup
•
type: empty
•
url
•
type: yang:uri
•
'schemes' parameter
•
with-defaults
◦
◦
usage: optional
◦
default: none
◦
◦
System Variables:
•
$$timeout
◦
•
$$with-defaults
◦
The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.
Positive Response:
•
Negative Response:
•
•
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
Version 14.08-2
Page 167
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>
Reference:
•
2.7.62
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.
Version 14.08-2
Page 168
•
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 system command prints the contents of the yangcli-pro system variables.
•
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
show command
Command type:
local
Default parameter:
none
Min parameters:
1
Max parameters:
2
Return type:
data
YANG file:
yangcli-pro.yang
Command Parameters:
•
◦
◦
◦
•
brief
▪
type: empty
▪
usage: optional
▪
default: none
▪
normal
▪
type: empty
▪
usage: optional
▪
default: none
▪
full
▪
type: empty
▪
usage: optional
▪
default: none
▪
choice showtype (not entered)
◦
mandatory 1 of N choice for the sub-command for the show command
▪
Version 14.08-2
cli
Page 169
•
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.
◦
▪
•
type: empty
•
usage: mandatory
•
default: none
•
The parameter prints the differences between current config and the edits that have not been
applied yet.
▪
Version 14.08-2
The help-mode parameter has no affect on this command.
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.
◦
▪
diff
◦
▪
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
Page 170
•
▪
▪
▪
▪
Version 14.08-2
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.
Page 171
▪
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.
◦
▪
system
•
type: empty
•
usage: mandatory
•
default: none
•
This parameter specifies that information for all system variables 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.
◦
Version 14.08-2
If help-mode is 'brief', then the name, variable object, and type of each variable object will
be printed.
Page 172
◦
▪
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.
◦
The help-mode parameter has no affect in this mode.
Positive Response:
•
the server prints the requested information
Negative Response:
•
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>
2.7.63
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 netconfd-pro user manual for details on configuring access control.
shutdown command
Version 14.08-2
Command type:
remote
Default parameter:
none
Page 173
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yuma-system.yang
Positive Response:
•
the server will drop all sessions and terminate.
Negative Response:
•
•
Usage:
andy@myserver> shutdown
>
2.7.64
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.
This command automatically sets the following variables to temporary values, which are restored when the stop-rpctiming operation is invoked.
•
$$echo-replies = false
•
$$rpc-timing = true
•
$$rpc-timing-stats = true
It is used along with the stop-rpc-timing command.
start-rpc-timing command
Version 14.08-2
Command type:
local
Default parameter:
statfile
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Page 174
none
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:
•
Usage:
session-B> start-rpc-timing
OK
session-B>
2.7.65
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.
start-session command
Command type:
local
Default parameter:
name
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
name
◦
type: session name string
◦
usage: mandatory
Version 14.08-2
Page 175
◦
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:
•
Usage:
session-A> start-session session-B
yangcli: Starting NETCONF session for andy on myserver
NETCONF session established for andy on myserver
base:1.0
candidate: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
Server Module Capabilities
yuma-arp@2012-01-13
yuma-ncx@2012-01-13
yumaworks-app-common@2012-08-16
yumaworks-extensions@2012-06-28
Server Enterprise Capabilities
Version 14.08-2
Page 176
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
Checking Server Modules...
session-B>
2.7.66
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.
start-timer command
Command type:
local
Default parameter:
id
Min parameters:
1
Max parameters:
2
Return type:
status
YANG file:
yangcli-pro.yang
none
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.
◦
Version 14.08-2
Page 177
Positive Response:
•
Negative Response:
•
Usage:
andy@myserver> start-timer 1
OK
andy@myserver>
2.7.67
stop-rpc-timing
The stop-rpc-timing command is used to stop remote operation timing mode.
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
It is used along with the start-rpc-timing command.
stop-rpc-timing command
Command type:
local
Default parameter:
none
Min parameters:
0
Max parameters:
0
Return type:
status
YANG file:
yangcli-pro.yang
none
none
Positive Response:
•
Negative Response:
•
Version 14.08-2
Page 178
Usage:
session-B> stop-rpc-timing
OK
session-B>
2.7.68
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.
stop-session command
Command type:
local
Default parameter:
name
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
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 connect command.
Positive Response:
•
The prompt should change if the current session is stopped
Negative Response:
•
Usage:
session-B> stop-session session-B
RPC OK Reply 4 for session 4 [session-B]:
>
Version 14.08-2
Page 179
2.7.69
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.
stop-timer command
Command type:
local
Default parameter:
id
Min parameters:
1
Max parameters:
2
Return type:
data
YANG file:
yangcli-pro.yang
none
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:
•
Usage:
andy@myserver> $time = stop-timer 1
Elapsed time: 2.003345 seconds
Version 14.08-2
Page 180
andy@myserver>
2.7.70
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
test-suite command
Command type:
local
Default parameter:
show
Min parameters:
0
Max parameters:
2
Return type:
status
YANG file:
yangcli-pro.yang
none
none
Command Parameters:
•
•
•
suite-name:
◦
◦
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:
◦
◦
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
Version 14.08-2
Page 181
▪
◦
◦
◦
◦
◦
◦
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.
Version 14.08-2
Page 182
Negative Response:
•
Usage:
andy@myserver> test-suite start ~/mytests.conf
…. commands from test executed
andy@myserver>
2.7.71
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.
unlock command
Command type:
remote
Default parameter:
none
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yuma-netconf.yang
none
:candidate
:startup
:url
Command Parameters:
•
target
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the target database to be locked.
◦
▪
▪
Version 14.08-2
candidate
•
type: empty
•
running
Page 183
▪
▪
•
type: empty
•
startup
•
type: empty
•
url
•
type: yang:uri
•
•
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> unlock target=candidate
andy@myserver>
2.7.72
unset
The unset command is used to delete a command alias from memory.
unset command
Command type:
local
Default parameter:
name
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
name
◦
type: string
Version 14.08-2
Page 184
◦
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.
•
Usage:
> unset get-running
Deleted alias 'get-running'
>
2.7.73
uservars
The uservars command is used to clear, load, or save the global user variables.
uservars command
Command type:
local
Default parameter:
none
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
uservars-action
◦
type: choice
◦
usage: mandatory
◦
default: none
◦
clear:
▪
◦
Delete all global user variables from memory
load [uservars-filespec]
Version 14.08-2
Page 185
▪
◦
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
>
2.7.74
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.
validate command
Command type:
remote
Default parameter:
none
Min parameters:
1
Max parameters:
1
Return type:
status
YANG file:
yuma-netconf.yang
:validate
:candidate
:startup
:url
Command Parameters:
Version 14.08-2
Page 186
•
target
◦
◦
usage: mandatory
◦
default: none
◦
This parameter specifies the name of the target database to be validated.
◦
▪
▪
▪
▪
▪
candidate
•
type: empty
•
running
•
type: empty
•
startup
•
type: empty
•
url
•
type: yang:uri
•
•
config
•
type: anyxml
•
capabilities
•
This parameter represents an entire database, using the in-line config form, similar to the editconfig command, except this config parameter contains no nc:operation attributes and must be a
complete database, not a subset.
Positive Response:
•
Negative Response:
•
•
Usage:
andy@myserver> validate source=candidate
Version 14.08-2
Page 187
andy@myserver>
2.7.75
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
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
while command
Command type:
local
Default parameter:
expr
Min parameters:
1
Max parameters:
3
Return type:
status
YANG file:
yangcli-pro.yang
Command Parameters:
•
•
expr
◦
◦
usage: mandatory
◦
default: none
◦
docroot
◦
type: anyxml
◦
◦
default: none
◦
any path nodes.
Version 14.08-2
Page 188
•
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:
•
Negative Response:
•
◦
Usage:
andy@myserver> while 1 --maxloops=10
SAME AS:
andy@myserver> while '$x < 10'
andy@myserver>
2.7.76
xget
The xget command is used to invoke a NETCONF <get> operation with an XPath filter.
xget command
Command type:
remote
Default parameter:
select
Min parameters:
1
Max parameters:
3
Return type:
data
YANG file:
yangcli-pro.yang
none
:with-defaults
Command Parameters:
•
Version 14.08-2
Page 189
◦
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
◦
◦
usage: optional
◦
◦
with-defaults
◦
◦
usage: optional
◦
default: none
◦
◦
System Variables:
•
$$timeout
◦
•
$$with-defaults
◦
The <with-defaults> parameter for the <get> operation will be derived from this system variable.
Positive Response:
•
Negative Response:
Version 14.08-2
Page 190
•
•
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-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:
•
Version 14.08-2
Page 191
2.7.77
xget-config
The xget-config command is used to invoke a NETCONF <get-config> operation with an XPath filter.
xget-config command
Command type:
remote
Default parameter:
select
Min parameters:
2
Max parameters:
4
Return type:
data
YANG file:
yangcli-pro.yang
none
:candidate
:startup
:url
:with-defaults
Command Parameters:
•
◦
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
◦
Version 14.08-2
Page 192
◦
usage: mandatory
◦
default: none
◦
◦
▪
▪
▪
▪
•
•
candidate
•
type: empty
•
running
•
type: empty
•
startup
•
type: empty
•
url
•
type: yang:uri
•
'schemes' parameter
•
timeout
◦
◦
usage: optional
◦
◦
with-defaults
◦
◦
usage: optional
◦
default: none
◦
◦
System Variables:
•
$$timeout
◦
•
$$with-defaults
◦
The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.
Positive Response:
Version 14.08-2
Page 193
•
Negative Response:
•
•
Output:
•
data
◦
type: anyxml
◦
This element will contain the requested data from the source database.
Usage:
andy@myserver> xget /nacm/groups source=running
rpc-reply {
data {
nacm {
groups {
group nacm:admin {
groupIdentity nacm:admin
userName andy
userName fred
userName barney
}
group nacm:guest {
groupIdentity nacm:guest
userName guest
}
}
}
}
}
andy@myserver>
Version 14.08-2
Page 194
3 CLI Reference
The YumaPro programs uses command line interface (CLI) parameters to control program behavior.
Many parameters are supported by more than one program, such as --log.
The following sections document all the YumaPro CLI parameters, in alphabetical order.
3.1 --aliases-file
The –aliases-file parameter specifies the yangcli-pro command aliases file specification to use.
--aliases-file parameter
Syntax
string
Default:
$HOME/.yumapro/.yangcli_pro_aliases
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro –aliases-file=~/myalaises
3.2 --alt-names
The –alt-names parameter controls whether alternative names are searched when processing a UrlPath search.
--alt-names parameter
Syntax
boolean (true or false)
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --alt-names=false
3.3 --autoaliases
The --autoaliases parameter controls automatic loading and saving of the command aliases file.
If 'true', then aliases will be loaded and saved automatically.
If 'false', then aliases must be loaded and saved manually with the 'aliases' command.
Version 14.08-2
Page 195
--autoaliases parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autoaliases=false
3.4 --autocomp
The --autocomp parameter controls automatic completion of command and parameter names.
If true, then the program will attempt to find a partial match by comparing only the number of characters entered. For
example '--log-l=debug' is the same as '--log-level=debug'.
If 'false', then command and parameter names must match exactly.
--autocomp parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autocomp=false
3.5 --autoconfig
The --autoconfig parameter controls whether the running configuration will be retrieved automatically for active
sessions. By default, the running config will be retrieved and maintained so it can be compared and used for
command tab completion.
If true, then the program will attempt to retrieve and maintain a shadow configuration for each session, using the <getconfig> NETCONF operation. If 'false', then automatic shadow configuration handling will not be done.
--autoconfig parameter
Version 14.08-2
Syntax
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autoconfig=true
Page 196
3.6 --autohistory
The --autohistory parameter controls automatic loading and saving of the command line history buffer in the yangclipro program..
If true, then when the program starts, the default command line history buffer will be loaded, and the previous set of
commands will be available with the history and recall commands.
If 'false', then the command line history buffer will not be loaded and saved automatically.
The default location for this file is ~/.yumapro/.yangcli_pro_history.
--autohistory parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autohistory=false
3.7 --autoload
The --autoload parameter controls automatic loading of YANG modules, as needed.
If true, then the program will attempt to find a needed YANG module.
If 'false', then YANG modules must be loaded manually.
--autoload parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autoload=false
3.8 --autoload-cache
The --autoload-cache parameter controls the use of YANG modules retrieved with the <get-schema> operation as
needed.
If true, then the YANG modules that are retrieved with the <get-schema> operation will be cached.
If 'false', then YANG modules that are retrieved with the <get-schema> operation will not be cached.
--autoload-cache parameter
Version 14.08-2
Page 197
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autoload-cache=false
3.9 --autoload-get
The --autoload-get parameter controls automatic loading of YANG modules, as needed.
If true, then the program will attempt to find a needed YANG module.
If 'false', then YANG modules must be loaded manually.
--autoload-get parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autoload=false
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autoload-get=false
3.10 --autoload-save-cache
The –autoload-save-cache parameter controls whether the modules held in the YANG module cache, are saved
when yangcli-pro exits, as needed.
If true, then the YANG modules that are cached will be saved when yangcli-pro exit.
If 'false', then the YANG modules that are cached will not be saved when yangcli-pro exit..
--autoload-save-cache parameter
Version 14.08-2
Syntax
Default:
TRUE
Page 198
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
--autoload-save-cache=false
3.11 --autonotif
The --autonotif parameter controls automatic creation of a notification subscription, if the server supports the
:notification and :interleave capabilities.
If 'true', then the program will attempt to start a notification subscription if the server advertises support, using the
<create-subscription> NETCONF operation.
If 'false', then notification subscriptions must be started manually.
--autonotif parameter
Syntax
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autonotif=true
3.12 --autosessions
The --autosessions parameter controls whether the saved sessions will be loaded into memory at startup and saved
to file at exit.
If true, the default session-cfg file will be used (~/.yumapro/.yangcli_pro_sessions.conf) for loading and saving the
configured sessions in memory.
If false, the configured sessions will only be stored and loaded manually with the sessions-cfg command.
--autosessions parameter
Version 14.08-2
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autosessions=false
Page 199
3.13 --autotest
The --autotest parameter controls whether the saved test suites will be loaded into memory at startup and saved to
file at exit.
If true, the default test-suite-cfg file will be used (~/.yumapro/.yangcli_pro_tests.conf) for loading and saving the
configured test-suites in memory.
If false, the configured test-suites will only be stored and loaded manually with the test-suite command.
--autotest parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autotest=false
3.14 --autouservars
The --autouservars parameter controls automatic loading of global user variables.
If 'true', then the global user variables will be automatically loaded and saved.
If 'false', then the global user variables must be loaded and saved manually with the 'uservars' command.
--autouservars parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --autouservars=false
3.15 --bad-data
The --bad-data parameter controls how invalid parameter input is handled by the program.
•
ignore: Use invalid parameter values. Use with caution.
•
warn: Issue a warning message, but use the invalid data anyway.
•
check: Prompt the user interactively, and check if the invalid data should be used, or a new value re-entered.
Version 14.08-2
Page 200
•
error: Do not use invalid parameter values.
--bad-data parameter
Syntax
enumeration:
ignore
warn
check
error
Default:
check
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro ----bad-data=warn
3.16 --batch-mode
The --batch-mode parameter specifies that the interactive CLI will not be used.
Instead, if a script is provided with the 'run-script' parameter, or a command provided with the 'run-command'
parameter, then it will be executed automatically before the program exits. This mode can be used to invoke
NETCONF commands from Unix shell scripts.
--batch-mode parameter
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --batch-mode \
--run-script=~/run-tests
3.17 --check-output
The --check-output parameter specifies whether <rpc> messages about to be sent to a remote server should be
validated against the YANG schema for the specific RPC operation.
If true, then yangcli-pro will validate remote commands against the YANG definition for the rpc/input node. This checks
the operation parameters about to be sent to a server session.
Note that validation of the contents of a <config> element is not done.
This CLI parameter is also the $$check-output global parameter.";
--check-output parameter
Version 14.08-2
Page 201
Syntax
boolean
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --check-output=false
3.18 --check-output-error
The --check-output-error parameter specifies whether validation errors detected in <rpc> messages about to be sent
to a remote server should be treated as warnings or errors.
If 'true', then errors found during the check-output validation tests will be treated as errors, causing the <rpc> about to
be sent to fail. If 'false', then errors found during the check-output validation tests will be treated as warnings.
This CLI parameter is also the $$check-output-error global parameter.";
--check-output-error parameter
Syntax
boolean
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --check-output-error=true
3.19 --check-replies
The --check-replies parameter specifies whether <rpc-reply> messages received from a remote server should be
validated against the YANG schema for the specific RPC operation.
If true, then yangcli-pro will validate remote commands against the YANG definition for the rpc/output node. If the
“output” section is missing or empty, then the <rpc-reply> will be checked to make sure it contains either <ok> or 1 or
more <rpc-error> elements.
This checks the parameters in the <rpc-reply> sent from a server session.
Note that validation of the contents of a <config> element is not done.
This CLI parameter is also the $$check-replies global parameter.
--check-replies parameter
Version 14.08-2
Syntax
boolean
Default:
TRUE
Page 202
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --check-replies=false
3.20 --check-replies-error
The --check-replies-error parameter specifies whether validation errors detected in <rpc-reply> messages received
from a remote server should be treated as warnings or errors.
If 'true', then errors found during the check-replies validation tests will be treated as errors, causing the <rpc-reply>
about to be processed to be rejected instead.
If 'false', then errors found during the check-replies validation tests will be treated as warnings.
This CLI parameter is also the $$check-replies-error global parameter.";
--check-replies-error parameter
Syntax
boolean
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
--check-replies-error=true
3.21 --config
The --config parameter specifies the name of a YumaPro configuration file that contains more parameters to process,
in addition to the CLI parameters.
Refer to the 'Configuration Files' section for details on the format of this file.
--config parameter
Version 14.08-2
Syntax
string: complete file specification of the text
file to parse for more parameters.
Default:
/etc/yumapro/<program-name>.conf
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Page 203
Example:
yangcli-pro testmod \
--config=~/testconf.conf
3.22 --config-edit-mode
The --config-edit-mode parameter controls how edits will be applied in configuration mode.
There are 4 possible editing modes:
•
line: The edit(s) are automatically applied after each line is entered
•
level: The edits(s) are automatically applied when the current level is exited
•
mode: The edit(s) are automatically applied when the configuration mode is exited
•
manual: The edit(s) are only applied manually with the apply command.
The default configuration editing mode is 'level'. Note that the 'apply' command can be used even if the value of this
parameter is not 'manual'.
--config-edit-mode parameter
Syntax
enum:
line
level
mode
manual
Default:
level
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --config-edit-mode=line
3.23 --datapath
The --datapath parameter specifies the directory search path to use while searching for data files. It consists of a
colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.
This parameter overrides the $YUMAPRO_DATAPATH environment variable, if it is present.
--datapath parameter
Version 14.08-2
Syntax
string: list of directory specifications
Default:
$YUMAPRO_DATAPATH environment
variable
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
Page 204
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro \
--datapath=”~/work2:~/data”
3.24 --default-module
The --default-module parameter specifies the module to search for identifiers, after the netconf and ncx modules
have been checked. This allows a specific module to match identifier names first, before all modules are searched at
once. This can avoid a collision if the same identifier value is used in more than one module.
--default-module parameter
Syntax
string: module name without any path or file
extension included.
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --default-module=testmod
3.25 --deviation
The --deviation parameter is a leaf-list of modules that should be loaded automatically when the program starts, as a
deviation module. In this mode, only the deviation statements are parsed and then made available later when the
module that contains the objects being deviated is parsed.
The deviations must be known to the parser before the target module is parsed.
This parameter is used to identify any modules that have deviation statements for the set of modules being parsed
(e.g., --module and --subtree parameters).
A module can be listed with both the --module and --deviation parameters, but that is not needed unless the module
contains external deviations. If the module only contains deviations for objects in the same module, then the
--deviation parameter does not need to be used.
The program will attempt to load each module in deviation parsing mode, in the order the parameters are entered.
For the netconfd-pro program, If any modules have fatal errors then the program will terminate.
For the yangdump-pro and yangcli-pro programs, each module will be processed as requested.
--deviation parameter
Version 14.08-2
Syntax
module name or filespec
Default:
none
Min Allowed:
0
Page 205
Max Allowed:
unlimited
Supported by:
netconfd-pro
yangcli-pro
yangdump-pro
Example:
yangcli-pro \
--module=test1 \
--deviation=test1_deviations
3.26 --display-mode
The --display-mode parameter controls how data is displayed in the program.
The qualified names (identifiers, idenitityref, XPath) within a text configuration can be generated several ways. This is
needed because sibling nodes in different XML namespaces can have the same name.
--display-mode values
enum value
description
example
plain
no prefix, just local-name
sysBootError
prefix
XML prefix and local-name
sys:sysBootError
module
module name and local name
system:sysBootError
xml
XML format
<sysBootError xmlns=”foo”>
xml-nons
XML format without namespace
(xmlns) attributes
<sysBootError>
json
JSON format
{ “sysBootError” : “blah” }
When saving configuration files in non-volatile storage, then it is suggested that only 'module' or 'xml' modes be used,
since these are the only deterministic modes.
The set of XML prefixes in use at any one time is not persistent, and cannot be relied upon, unless the namespace
declarations are saved (xml mode) or the module names are saved (module mode).
display-mode parameter
Version 14.08-2
Syntax
enumeration:
plain
prefix
module
xml
xml-nons
json
Default:
plain
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --display-mode=module
Page 206
3.27 --echo-notif-loglevel
The --echo-notif-loglevel parameter controls how unregistered notifications are echoed when notification messages
are received. If the --echo-notifs parameter is true, then this parameter controls the logging debug level needed for
notifications to be printed, If --echo-notifs is 'false' then this parameter has no affect.
Only notifications other than <sys-config-change> and <sysConfigChange> are echoed. Those notifications are
used to maintain shadow configurations.
If the --log-level is set to the same value or higher as this parameter, then the full notification message will be echoed.
If the --log-level is set to one level lower than this parameter, then a 1 line notification summary message will be
echoed. For example, if --log-level=info and --echo-nofits=true and --echo-notif-loglevel=debug, then a one line
summary will be printed for received notifications.
--echo-notif-loglevel parameter
Syntax
enum: (same as log-level)
Default:
debug
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
--echo-notif-loglevel=info
3.28 --echo-notifs
The --echo-notifs parameter controls whether unregistered notifications are echoed when notification messages are
received.
Only notifications other than <sys-config-change> and <sysConfigChange> are echoed. Those notifications are
used to maintain shadow configurations.
--echo-notifs parameter
Syntax
boolean
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --echo-notifs=false
3.29 --echo-replies
Version 14.08-2
Page 207
The --echo-replies parameter controls whether <rpc-reply> messages are echoed when they are received.
If 'true' then replies with data will be displayed. If 'false' then they will not be displayed. Note that this parameter does
not affect error replies (messages with <rpc-error> elements in them).
--echo-replies parameter
Syntax
boolean
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --echo-replies=false
3.30 --feature-disable
The --feature-disable parameter directs all programs to disable a specific feature.
This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name,
e.g.,
test:feature1
It is an error if a --feature-enable and --feature-disable parameter specify the same feature.
Parameters for unknown features will be ignored.
--feature-disable parameter
Syntax
formatted string (module:feature
Default:
none
Min Allowed:
0
Max Allowed:
unlimited
Supported by:
yangcli-pro
yangdiff-pro
yangdump-pro
netconfd-pro
Example:
yangcli-pro --featuredisable=test:feature1
3.31 --feature-enable
The --feature-enable parameter directs all programs to enable a specific feature.
Version 14.08-2
Page 208
This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name,
e.g.,
test:feature1
It is an error if a --feature-disable and --feature-enable parameter specify the same feature.
Parameters for unknown features will be ignored.
--feature-enable parameter
Syntax
formatted string (module:feature
Default:
none
Min Allowed:
0
Max Allowed:
unlimited
Supported by:
yangcli-pro
yangdiff-pro
yangdump-pro
netconfd-pro
Example:
yangcli-pro--featureenable=test:feature1
3.32 --feature-enable-default
The --feature-enable-default parameter controls how yangdump-pro will generate C code for YANG features by
default.
If 'true', then by default, features will be enabled.
If 'false', then by default, features will be disabled.
If a --feature-enable or --feature-disable parameter is present for a specific feature, then this parameter will be
ignored for that feature.
--feature-enable-default parameter
Version 14.08-2
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
yangdiff-pro
yangdump-pro
netconfd-pro
Example:
yangcli-pro \
--feature-enable-default=false
Page 209
3.33 --fixorder
The --fixorder parameter controls whether PDU parameters will be automatically sent in NETCONF PDUs in the
correct order.
If 'true', the schema-defined, canonical order will be used.
If 'false', the specified order that parameters are entered will be used for the PDU order as well.
--fixorder parameter
Syntax
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --fixorder=false
3.34 --force-target
The --force-target parameter controls whether the candidate or running configuration datastore will be used as the
default edit target, when both are supported by the server.
--force-target parameter
Syntax
enum (candidate or running)
Default:
candidate
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --force-target=running
3.35 --help
The --help parameter causes program help text to be printed, and then the program will exit instead of running as
normal.
This parameter can be combined with the --help-mode parameter to control the verbosity of the help text. Use --brief
for less, and --full for more than the normal verbosity.
Version 14.08-2
Page 210
This parameter can be combined with the --version parameter in all programs. It can also be combined with the
--show-errors parameter in yangdump-pro.
The program configuration parameters will be displayed in alphabetical order, not in schema order.
--help parameter
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --help
3.36 --help-mode
The --help-mode parameter is used to control the amount of detail printed when help text is requested in some
command. It is always used with another command, and makes no sense by itself. It is ignored unless used with the
--help parameter.
--help-mode parameter
Syntax
choice of 3 empty leafs
--brief
--normal
--full
Default:
normal
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --help --help-mode=full
•
default choice: normal
•
choice help-mode
Version 14.08-2
Page 211
◦
◦
◦
brief
▪
type: empty
▪
normal
▪
type: empty
▪
full
▪
type: empty
▪
3.37 --home
The --home parameter over-rides the $HOME environment variable, if it is set. File searches that use the user's
home directory will use this path specification instead.
--home parameter
Syntax
string: pathspec
Default:
$HOME environment value
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --home=~/testmodules
3.38 --ignore-missing-vars
The --ignore-missing-vars parameter specifies how missing variable errors in data templates are handled. This
parameter has no affect unless the 'use-data-templates' parameter is 'true'.
If 'true', then variable expressions that contain references to missing variables will not cause a parsing error. Instead,
an empty string will be used or the value of a missing variable.
If 'false', then variable expressions that contain references to missing variables will cause a parsing error.
--ignore-missing-vars parameter
Version 14.08-2
Syntax
boolean
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Page 212
Supported by:
yangcli-pro
Example:
yangcli-pro \
--ignore-missing-vars=true
3.39 --indent
The --indent parameter specifies the number of spaces that will be used to add to the indentation level, each time a
child node is printed during program operation.
--indent parameter
Syntax
uint32 (0 .. 9)
Default:
2
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --indent=4
3.40 --log
The --log parameter specifies a file name to be used for logging program messages, instead of STDOUT. It can be
used with the optional parameters below to control how the log file is written. (See also -–log-syslog which directs
message output to a syslog daemon, and the –-log-console parameter which duplicates log output via STDOUT.
--log parameter
Syntax
string: log file specification
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
netconfd-pro --log=~/server.log&
3.41 --log-append
The --log-append parameter specifies that the existing log file (if any) should be appended , instead of deleted. It is
ignored unless the --log parameter is present.
Version 14.08-2
Page 213
--log-append parameter
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
netconfd-pro --log-append \
--log=~/server.log&
3.42 --log-backtrace
The --log-backtrace parameter specifies that stack frame trace information be appended to selected log messages.
By default, this information will be included in all enabled output streams (STDOUT, STDERR, log file, and/or syslog).
Such output may be further restricted by inclusion of any of the log-backtrace-xxx commands below.
--log-backtrace parameter
Syntax
Max frame count: 0..200
Default:
0 means use internal default (20)
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro --log-backtrace=0
3.43 --log-backtrace-detail
The --log-backtrace-detail adds compiler/OS dependent information to the output of –-log-backtrace.
--log-backtrace-detail parameter
Version 14.08-2
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro --log-backtrace=0 \
--log-backtrace-detail
Page 214
3.44 --log-backtrace-level
The --log-backtrace-level parameter specifies that stack frame trace information be appended only to selected log
message levels (see --log-level).
--log-backtrace-level parameter
Syntax
Enumeration:
error
warn
info
debug
debug2
debug3
debug4
One of more enumeration(s) may be specified
by enclosing the string in double quotes ('”')
and separating each member with a space.
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro –log-backtrace=0 \
--log-backtrace-level=”error debug”
3.45 --log-backtrace-stream
The --log-backtrace-stream parameter specifies that stack frame trace information will be limited to output streams
specified by the argument list. Possible arguments include logfile, stdout, stderr, syslog, and vendor.
--log-backtrace-stream parameter
Version 14.08-2
Syntax
Enumeration:
logfile
stdout
stderr
syslog
vendor
One or more enumeration(s) may be
specified by enclosing the string in double
quotes ('”') and separating each member with
a space.
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Page 215
Example:
netconfd-pro --log-syslog
\
--log=server.log
\
--log-backtrace=0
\
--log-backtrace-stream=”logfile”
3.46 --log-console
The –log-console parameter directs that log output will be be sent to STDOUT, after being sent to the log file and/or
local syslog daemon. (This assumes that —log and/or –-log-syslog are present).
--log-console parameter
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro –log=file --log-syslog \
--log-console &
3.47 --log-header
The --log-header parameter specifies that additional information (level/date/time) will be included in the log stream
output. Possible arguments to this command include custom (add date/time/level info) and localtime (express
date/time in local terms).
--log-header parameter
Version 14.08-2
Syntax
Enumeration:
custom
localtime
One or more enumeration(s) may be
specified by enclosing the string in double
quotes ('”') and separating each member with
a space.
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro --log-append \
--log=~/server.log
\
--log-header=”custom localtime”&
Page 216
3.48 --log-level
The --log-level parameter controls the verbosity level of messages printed to the log file or STDOUT, if no log file is
specified.
The log levels are incremental, meaning that each higher level includes everything from the previous level, plus
additional messages.
There are 7 settings that can be used:
•
none: All logging is suppressed. Use with extreme caution!
•
error: Error messages are printed, indicating problems that require attention.
•
warn: Warning messages are printed, indicating problems that may require attention.
•
info: Informational messages are printed, that indicate program status changes.
•
debug: Debugging messages are printed that indicate program activity.
•
debug2: Protocol debugging and trace messages are enabled.
•
debug3: Very verbose debugging messages are enabled. This has an impact on resources and
performance, and should be used with caution.
--log-level parameter
Syntax
enumeration:
off
error
warn
info
debug
debug2
debug3
debug4
Default:
--info (--debug for DEBUG builds)
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
netconfd-pro --log-level=debug \
--log=~/server.log&
3.49 --log-mirroring
The --log-mirroring parameter is a synonym for —log-console.
3.50 --log-stderr
Version 14.08-2
Page 217
The --log-stderr parameter directs that error level log output be directed to STDERR rather than STDOUT. (Note
however that if –-log is present, all error level messages will be directed to the specified log file … –-log-stderr has
no effect in this case.)
--log-stderr parameter
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro --log-stderr > logFile&
! All log messages redirected to
logFile except ...
! Error level messages displayed on
console
3.51 --log-suppress-ctrl
The --log-suppress-ctrl parameter causes certain control parameters to br stripped from log messages.
--log-suppress-ctrl parameter
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro --log-suppress-ctrl
3.52 --log-syslog
The --log-syslog parameter directs log output to be sent to the local syslog daemon, rather than to STDOUT. See
the –log-console parameter for information on how log output may also be duplicated via STDOUT.
--log-syslog parameter
Version 14.08-2
Syntax
empty
Default:
none
Min Allowed:
0
Page 218
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
netconfd-pro --log-syslog
3.53 --log-syslog-level
The --log-syslog-level parameter acts as a filter for the message level sent to the syslog or vendor output stream.
The filter level is set by default to “info” if not specified.
The log levels are incremental, meaning that each higher level includes everything from the previous level, plus
additional messages.
There are 7 settings that can be used:
•
none: All logging is suppressed. Use with extreme caution!
•
error: Error messages are printed, indicating problems that require attention.
•
warn: Warning messages are printed, indicating problems that may require attention.
•
info: Informational messages are printed, that indicate program status changes.
•
debug: Debugging messages are printed that indicate program activity.
•
debug2: Protocol debugging and trace messages are enabled.
•
debug3: Very verbose debugging messages are enabled. This has an impact on resources and
performance, and should be used with caution.
--log-syslog-level parameter
Version 14.08-2
Syntax
enumeration:
off
error
warn
info
debug
debug2
debug3
debug4
Default:
--info (--debug for DEBUG builds)
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
Netconfd-pro –log=logfile \
> --log-level=debug \
> --log-syslog \
> --log-syslog-level=info &
Page 219
3.54 --match-names
The --match-names parameter specifies how names are matched when performing UrlPath searches.
The following values are supported::
•
exact
The name must exactly match the node name for all characters in both name strings.
•
exact-nocase
The name must match the node name for all characters in both name strings.
Strings are not case-sensitive.
•
one
The name must exactly match the first N characters of just one node name,
which must be the only partial name match found.
•
one-nocase
The name must exactly match the first N characters of just one node name, which
must be the only partial name match found. Strings are not case-sensitive.
•
first
The name must exactly match the first N characters of any node name. The first one
found will be used.
•
first-nocase
The name must exactly match the first N characters of any node name. The first one
found will be used. Strings are not case-sensitive.
--match-names parameter
Syntax
enum:
exact
exact-nocase
one
one-nocase
first
first-nocase
Default:
one-nocase
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --match-names=exact
3.55 --message-indent
Version 14.08-2
Page 220
The --message-indent parameter specifies the number of spaces that will be used to add to the indentation level,
each time a child node is printed during protocol messages such as NETCONF requests. This does not affect the
indentation for logging messages, which is controlled by the --indent parameter.
The value -1 requests that no newlines or indentation will be used in protocol messages..
--message-indent parameter
Syntax
int32 (-1 .. 9)
Default:
-1
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
yangcli-pro --message-indent=2
3.56 --modpath
The --modpath parameter specifies the YANG module search path to use while searching for YANG files. It consists
of a colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.
This parameter overrides the $YUMAPRO_MODPATH environment variable, if it is present.
--modpath parameter
Syntax
Default:
$YUMAPRO_MODPATH environment
variable
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro \
--modpath=”~/testmodules:~/modules:~/
trunk/netconf/modules”
3.57 --module
The --module parameter is a leaf-list of modules that should be loaded automatically when the program starts.
The program will attempt to load each module in the order the parameters were entered.
For the netconfd-pro program, If any modules have fatal errors then the program will terminate.
For the yangdump-pro program, each module will be processed as requested.
Version 14.08-2
Page 221
--module parameter
Syntax
module name or filespec
Default:
none
Min Allowed:
0
Max Allowed:
unlimited
Supported by:
netconfd-pro
yangcli-pro
yangdump-pro
Example:
yangcli-pro \
--module=test1 \
--module=test2
3.58 --ncport
The --ncport parameter specifies the TCP port number that should be used for NETCONF sessions.
This parameter specifies the TCP port number to use when a NETCONF session is created during the startup of the
program. The parameter can only be entered once.
--ncport parameter
Syntax
uint32
Default:
830
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --server=myserver
--ncport=22 \
--user=fred
--password=mypassword
3.59 --no-config
The --no-config parameter specifies that the default configuration file (/etc/yumapro/yangcli_pro.conf) should not be
loaded, even if it is present.
--no-config parameter
Version 14.08-2
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Page 222
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --no-config
3.60 --password
The --password parameter specifies the password string that should be used when a NETCONF session is
connected during the startup of the program.
--password parameter
Syntax
string
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --server=myserver \
--password=yangrocks \
--user=andy
3.61 --private-key
The --private-key parameter specifies the file path specification for the file containing the client-side private key.
If both 'public-key' and 'private-key' files are present, the client will attempt to connect to the server using these keys.
If this fails, or not done, then password authentication will be attempted.
--private-key parameter
Syntax
string
Default:
$HOME/.ssh/id_rsa
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro –private-key=~/.ssh/mykey
3.62 --prompt-type
The --prompt-type parameter specifies the verbosity of the prompt stroing.
The values allowed are 'brief', 'normal' and 'full'.
Version 14.08-2
Page 223
--prompt-type parameter
Syntax
enum:
brief
normal
full
Default:
normal
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro –-prompt-type=full
3.63 --protocols
The --protocols parameter specifies which protocol versions the program or session will attempt to use. Empty set is
not allowed.
--protocols parameter
Syntax
bits
Default:
“netconf1.0 netconf1.1”
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
Example:
yangcli-pro –protocols=netconf1.0
3.64 --public-key
The --public-key parameter specifies the file path specification for the file containing the client-side public key.
If both 'public-key' and 'private-key' files are present, the client will attempt to connect to the server using these keys.
If this fails, or not done, then password authentication will be attempted.
--public-key parameter
Version 14.08-2
Syntax
string
Default:
$HOME/.ssh/id_rsa.pub
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro –public-
Page 224
key=~/.ssh/mykey.pub
3.65 --runpath
The --runpath parameter specifies the directory search path to use while searching for script files. It consists of a
colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.
This parameter overrides the $YUMAPRO_RUNPATH environment variable, if it is present.
--runpath parameter
Syntax
Default:
$YUMAPRO_RUNPATH environment
variable
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro \
--runpath=”~/testscripts”
3.66 --run-command
The --run-command parameter specifies a command will be invoked upon startup.
In the yangcli-pro program, if the auto-connect parameters are provided, then a session will be established before
running the command.
--run-command parameter
Syntax
string
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
--run-command="history
load=~/test3-history"
3.67 --run-script
Version 14.08-2
Page 225
The --run-script parameter specifies a script will be invoked upon startup.
In the yangcli-pro program, if the auto-connect parameters are provided, then a session will be established before
running the script.
--run-script parameter
Syntax
string (file specification)
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
--run-script="test3-start"
3.68 --save-session-vars
The --save-session-vars parameter specifies if session variables will be saved when the program exits. If usesession-vars is 'false' then this variable is ignored.
If 'true', then session variables will be saved when the program exits, but only if user variables are being saved.
If 'false', then session variables will not be saved when the program exits.
--save-session-vars parameter
Syntax
boolean
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --save-session-vars=false
3.69 --server
The --server parameter specifies the IP address or DNS name of the NETCONF server that should be connected to
automatically, when the program starts.
--server parameter
Version 14.08-2
Syntax
string:IP address or DNS name
Default:
none
Min Allowed:
0
Page 226
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --server=myserver
3.70 --subdirs
The --subdirs parameter controls whether sub-directories should be searched or not, if they are found during a
module search.
If false, the file search paths for modules, scripts, and data files will not include sub-directories if they exist in the
specified path.
--subdirs parameter
Syntax
boolean
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangdump-pro
Example:
yangcli-pro
--subdirs=false
3.71 --test-suite-file
The --test-suite-file parameter contains the file specification of the default test suite configuration file to use.
--test-suite-file parameter
Syntax
string:filespec
Default:
$HOME/.yumapro/.yangcli_pro_tests.conf
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
–test-suite-file=~/mytests.conf
3.72 --time-rpcs
The --time-rpcs parameter is used to measure the round-trip time of each <rpc> request and
<rpc-reply> at the session level. Echo the elapsed time value to screen if in interactive mode, as well as the log if the
log is a file instead of stdout. The $$time-rpcs system variable is derived from this parameter.";
Version 14.08-2
Page 227
--time-rpcs parameter
Syntax
boolean
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --time-rpcs=true
3.73 --time-rpcs-stats
The --time-rpcs-stats parameter is used to control whether the timed rpc statistics should be saved if the time-rpcs
parameter is set to 'true'. If 'true', then timing statistics will be saved.
--time-rpcs-stats parameter
Syntax
boolean
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --time-rpcs-stats=true
3.74 --time-rpc-stats-file
The --time-rpc-stats-file parameter contains the file specification of the default rpc timing data file to use.
--time-rpcs-stats-file parameter
Syntax
string:filespec
Default:
$HOME/yangcli_pro_rpc_stats.txt
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
–time-rpc-stats-file=~/mystats.txt
3.75 --timeout
Version 14.08-2
Page 228
The --timeout parameter specifies the number of seconds that should pass before giving up on a response during a
NETCONF session. The value zero means wait forever (no timeout).
--timeout parameter
Syntax
uint32 (0 for no timeout; otherwise number of
seconds to wait)
Default:
30 seconds
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --timeout=0
3.76 --transport
The --transport parameter specifies the NETCONF transport protocol to use.
This parameter is also supported in the 'connect' command.
There are 3 values supported:
1.
ssh: standard NETCONF SSH transport (RFC 4742 or RFC 6242)
2.
tcp: tail-f NETCONF over TCP transport
Note that netconfd-pro does not support this transport protocol!
3.
tcp-ncx: YumaWorks NETCONF over TCP transport
Note that netconfd-pro does support this transport protocol, if the netconfd-pro --socket-type CLI parameter
is set to 'tcp'.
I
--transport parameter
Syntax
Enum (ssh, tcp, or tpc-ncx)
Default:
ssh
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --transport=tcp-ncx
3.77 --use-data-templates
The --use-data-templates parameter specifies if variable expressions are enabled for data in XML, JSON or .conf
instance documents.
If 'true', then text matching the pattern for variable expressions in these instance documents will be processed as
variable expressions.
Version 14.08-2
Page 229
If 'false', then text matching the pattern for variable expressions in these instance documents will be treated as plain
strings.
--use-data-templates parameter
Syntax
boolean
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
--use-data-templates=false
3.78 --use-rawxml
The --use-rawxml parameter specifies how file result variables will be read for XML files. Controls whether the XML
will be parsed against the target YANG object (the default) or injected into a variable or request message from the raw
XML text in the file.
--use-rawxml parameter
Syntax
boolean
Default:
FALSE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --use-rawxml=true
3.79 --use-session-vars
The --use-session-vars parameter specifies how global variables will be handled when set from the context of a
named session.
If 'true', then an assignment (e.g., $$foo = 'bar') will only affect the session-specific instance of the variable, and only
be visible within the scope of the named session.
If 'false', then assignment statements for global variables will affect the global instance of the variable, and be visible
to all sessions.
If the current session is the default session, and not a named session, then the value of this variable is ignored, and
all global variable assignments will affect the global instance of the variable, and be visible to all sessions.
--use-session-vars parameter
Syntax
Version 14.08-2
boolean
Page 230
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --use-session-vars=false
3.80 --use-xmlheader
The --use-xmlheader parameter specifies how file result variables will be written for XML files.
Controls whether the XML preamble header will be written or not.
--use-xmlheader parameter
Syntax
boolean
Default:
TRUE
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --use-xmlheader=false
3.81 --user
The --user parameter specifies the user name string on the NETCONF server that should be used when establishing
a NETCONF session.
--user parameter
Syntax
string:user name
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro --user=admin \
--server=myserver
3.82 --uservars-file
The --uservars-file parameter contains the file specification of the user global variables XML file to use.
Version 14.08-2
Page 231
--uservars-file parameter
Syntax
string:filespec
Default:
$HOME/.yumapro/yangcli_pro_uservars.xml
Min Allowed:
0
Max Allowed:
1
Supported by:
yangcli-pro
Example:
yangcli-pro \
-–uservars-file=~/myvars.xml
3.83 --version
The --version parameter causes the program version string to be printed, and then the program will exit instead of
running as normal.
All YumaPro version strings use the same format:
DEBUG: <major>.<minor>.<svn-build-version>
or
NON-DEBUG: <major>.<minor>-<release>
An example version number that may be printed:
yangcli-pro 14.08-2
This parameter can be combined with the --help parameter.
--version parameter
Syntax
empty
Default:
none
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --version
3.84 --warn-idlen
The --warn-idlen parameter controls whether identifier length warnings will be generated.
The value zero disables all identifier length checking. If non-zero, then a warning will be generated if an identifier is
defined which has a length is greater than this amount.
--warn-idlen parameter
Version 14.08-2
Page 232
Syntax
uint32: 0 to disable, or 8 .. 1023
Default:
64
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --warn-idlen=50
3.85 --warn-linelen
The --warn-linelen parameter controls whether line length warnings will be generated.
The value zero disables all line length checking. If non-zero, then a warning will be generated if a YANG file line is
entered which has a length is greater than this amount.
Tab characters are counted as 8 spaces.
--warn-linelen parameter
Syntax
uint32: 0 to disable, or 40 .. 4095
Default:
72
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --warn-linelen=79
3.86 --warn-off
The --warn-off parameter suppresses a specific warning number.
The error and warning numbers, and the default messages, can be viewed with the yangdump-pro program by using
the --show-errors configuration parameter.
The specific warning message will be disabled for all modules. No message will be printed and the warning will not
count towards the total for that module.
--warn-off parameter
Version 14.08-2
Syntax
uint32: 400 .. 899
Default:
none
Page 233
Min Allowed:
0
Max Allowed:
499
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro --warn-off=435
# revision order not descending
3.87 --yumapro-home
The --yumapro-home parameter specifies the project directory root to use when searching for files.
If present, this directory location will override the '$YUMAPRO_HOME environment variable, if it is set. If this
parameter is set to a zero-length string, then the $YUMAPRO_HOME environment variable will be ignored.
The following directories are searched when either the $YUMAPRO_HOME environment variable or this parameter is
set:
•
$YUMAPRO_HOME/modules
◦
•
$YUMAPRO_HOME/data
◦
•
This sub-tree is searched for YANG files.
This directory is searched for data files.
$YUMAPRO_HOME/scripts
◦
This directory is searched for yangcli-pro script files.
yuma-home parameter
Version 14.08-2
Syntax
string: directory specification
Default:
$YUMAPRO_HOME environment variable
Min Allowed:
0
Max Allowed:
1
Supported by:
netconfd-pro
yangcli-pro
yangdiff-pro
yangdump-pro
Example:
yangcli-pro \
--yumapro-home=~/sw/netconf \
--log=~/test.log&
Page 234

YumaPro yangcli-pro Manual YANG-Based Unified Modular Automation Tools NETCONF Over SSH Client

Transcription

Similar documents

Lorenz system II - Harvard Mathematics Department

Tutorial of the STRUCTURE software

biography

(June 2012) - D. INOUE (NICT Japan).

Lecture 1 - Biostatistics

Statistics 512 Divisions 1 and 4, Spring 2014 Sample Midterm I

Chapter 7 μ Confidence Intervals and Sample Size

Music / Andy Shauf

How a Sample PL/SQL Block Looks

Kao Kalia Yang