yumapro yangcli-pro manual - yumaworks · yumapro yangcli-pro manual yang-based unified modular...

YumaPro yangcli-pro Manual

YANG-Based Unified Modular Automation Tools

NETCONF Over SSH ClientNETCONF Over TLS Client

RESTCONF Over HTTP(S) ClientNETCONF Over SSH Call Home Server NETCONF Over TLS Call Home Server

Version 19.10-13


Table Of Contents1 Preface..............................................................................................................................................9

1.1 Legal Statements.........................................................................................................................91.2 Additional Resources...................................................................................................................9

1.2.1 WEB Sites......................................................................................................................................91.2.2 Mailing Lists.................................................................................................................................10

1.3 Conventions Used in this Document............................................................................................102 yangcli-pro User Guide.....................................................................................................................11

2.1 Introduction...............................................................................................................................112.1.1 Features........................................................................................................................................122.1.2 Starting yangcli-pro.......................................................................................................................152.1.3 Stopping yangcli-pro......................................................................................................................172.1.4 Statements....................................................................................................................................172.1.5 Commands....................................................................................................................................172.1.6 Variables.......................................................................................................................................222.1.7 Files.............................................................................................................................................272.1.8 Scripts..........................................................................................................................................282.1.9 Configuration Mode Editing...........................................................................................................312.1.10 Configuration Parameter List........................................................................................................34

2.2 Invoking Commands..................................................................................................................402.2.1 Command Prompt..........................................................................................................................412.2.2 Command Name............................................................................................................................442.2.3 ncx:default-parm Extension............................................................................................................452.2.4 Parameter Mode Escape Commands................................................................................................472.2.5 Using Inline XML or JSON Data.....................................................................................................482.2.6 Using External XML......................................................................................................................502.2.7 Using XPath Expressions................................................................................................................522.2.8 Special Parameter Handling............................................................................................................542.2.9 Command Completion...................................................................................................................552.2.10 Command Line Editing................................................................................................................562.2.11 Command History........................................................................................................................572.2.12 Command Responses...................................................................................................................58

2.3 Controlling Terminal Output.......................................................................................................592.3.1 Pipe Commands............................................................................................................................592.3.2 Pagination.....................................................................................................................................632.3.3 Display Mode................................................................................................................................64

2.4 NETCONF Device Configuration...............................................................................................662.4.1 Creating Devices...........................................................................................................................662.4.2 Saving Devices..............................................................................................................................662.4.3 Multiple Devices...........................................................................................................................662.4.4 Saving the Configured Devices.......................................................................................................672.4.5 Loading Additional Configured Devices...........................................................................................672.4.6 Displaying the Configured Devices..................................................................................................672.4.7 Displaying Devices........................................................................................................................682.4.8 Saved Device Configuration File Format..........................................................................................692.4.9 Device Configuration File Example.................................................................................................70

2.5 NETCONF Schema Server Configuration....................................................................................712.5.1 Creating New Schema Servers........................................................................................................712.5.2 Saving Schema Servers..................................................................................................................722.5.3 Multiple Schema Servers................................................................................................................732.5.4 Displaying the Configured Schema Servers......................................................................................73

Version 19.10-13


2.5.5 Displaying A Schema Server...........................................................................................................732.5.6 Saved Schema Server Configuration File Format...............................................................................742.5.7 Schema Server Configuration File Example......................................................................................75

2.6 NETCONF User Configuration...................................................................................................762.6.1 Creating New Users.......................................................................................................................762.6.2 Saving Users.................................................................................................................................762.6.3 Multiple Users...............................................................................................................................772.6.4 Saving the Configured Users...........................................................................................................772.6.5 Loading Additional Configured Users..............................................................................................772.6.6 Displaying the Configured Users.....................................................................................................782.6.7 Displaying Users...........................................................................................................................782.6.8 Saved User Configuration File Format.............................................................................................792.6.9 User Configuration File Example....................................................................................................80

2.7 NETCONF Session Configuration..............................................................................................812.7.1 Saving Sessions.............................................................................................................................812.7.2 Multiple Sessions..........................................................................................................................822.7.3 Changing the Active Session...........................................................................................................822.7.4Saving the Configured Sessions.......................................................................................................832.7.5 Loading Additional Configured Sessions..........................................................................................832.7.6 Displaying the Configured Sessions.................................................................................................842.7.7 Displaying Sessions.......................................................................................................................852.7.8 Terminating a Named Session.........................................................................................................862.7.9 Saved Session Configuration File Format.........................................................................................872.7.10 Session Configuration File Example..............................................................................................89

2.8 NETCONF Group Configuration................................................................................................902.8.1 Create group.................................................................................................................................902.8.2 List group.....................................................................................................................................912.8.3 Delete group.................................................................................................................................912.8.4 Add group.....................................................................................................................................922.8.5 Remove Group..............................................................................................................................922.8.6 Show Group..................................................................................................................................932.8.7 Connect Group..............................................................................................................................942.8.8 Help Group...................................................................................................................................952.8.9 Saving Groups...............................................................................................................................962.8.10 Changing the Active group............................................................................................................96

2.9 Using NETCONF Sessions.........................................................................................................972.9.1 Connection Startup Screen..............................................................................................................972.9.2 Server Tailored Context..................................................................................................................992.9.3 Retrieving Data...........................................................................................................................1002.9.4 Modifying Data...........................................................................................................................1012.9.5 Using Notifications......................................................................................................................1032.9.6 Configuration Parameters That Affect Sessions...............................................................................1042.9.7 Trouble-shooting NETCONF Session Problems..............................................................................105

2.10 Automated Testing.................................................................................................................1072.10.1 Test Templates...........................................................................................................................1082.10.2 YANG File Defining Test Templates............................................................................................1092.10.3 RPC Reply Testing.....................................................................................................................1132.10.4 Using Wildcards in Data Response Testing....................................................................................1142.10.5 Example Test File......................................................................................................................116

2.11 Call Home Server..................................................................................................................1202.11.1 Call Home Configuration............................................................................................................121

Version 19.10-13


2.11.2 Call Home Accept Session Procedure...........................................................................................1212.12 Privilege Mode In YP-Shell Enable Mode................................................................................122

2.12.1 enable.......................................................................................................................................1232.12.2 enable password.........................................................................................................................1242.12.3 enable no-password....................................................................................................................125

2.13 Privilege Mode In YP-Shell Config Mode................................................................................1262.13.1 Enable Privilege Mode...............................................................................................................1272.13.2 Disable Privilege Mode..............................................................................................................128

2.14 Command Reference..............................................................................................................1292.14.1action........................................................................................................................................1292.14.2 alias..........................................................................................................................................1332.14.3 aliases.......................................................................................................................................1352.14.4 auto-test....................................................................................................................................1372.14.5 cache........................................................................................................................................1392.14.6 cd.............................................................................................................................................1422.14.7 clear.........................................................................................................................................1432.14.8 close-session.............................................................................................................................1442.14.9 commit.....................................................................................................................................1452.14.10 config.....................................................................................................................................1472.14.11 config-commit.........................................................................................................................1482.14.12connect....................................................................................................................................1492.14.13 copy-config.............................................................................................................................1532.14.14 create......................................................................................................................................1562.14.15 create-subscription...................................................................................................................1592.14.16 device-cfg...............................................................................................................................1612.14.17 devices-cfg..............................................................................................................................1632.14.18 delete......................................................................................................................................1652.14.19 delete-config...........................................................................................................................1672.14.20 discard-changes.......................................................................................................................1692.14.21 edit-config...............................................................................................................................1702.14.22 elif.........................................................................................................................................1732.14.23 else.........................................................................................................................................1752.14.24 enable.....................................................................................................................................1762.14.25 end.........................................................................................................................................1762.14.26 eval........................................................................................................................................1782.14.27 eventlog..................................................................................................................................1802.14.28 exit.........................................................................................................................................1832.14.29 fill..........................................................................................................................................1842.14.30 get..........................................................................................................................................1862.14.31 get-config................................................................................................................................1882.14.32 get-locks.................................................................................................................................1912.14.33 get-my-session.........................................................................................................................1932.14.34 get-schema..............................................................................................................................1952.14.35 get-walk..................................................................................................................................1982.14.36 group......................................................................................................................................2062.14.37 help........................................................................................................................................2112.14.38 history....................................................................................................................................2142.14.39 if............................................................................................................................................2172.14.40 insert......................................................................................................................................2192.14.41 kill-session..............................................................................................................................2222.14.42 list..........................................................................................................................................2242.14.43 load........................................................................................................................................228

Version 19.10-13


2.14.44 lock........................................................................................................................................2302.14.45 log-debug................................................................................................................................2322.14.46 log-error.................................................................................................................................2332.14.47 log-info...................................................................................................................................2342.14.48 log-warn.................................................................................................................................2352.14.49 merge.....................................................................................................................................2362.14.50 mgrload..................................................................................................................................2392.14.51 no-op......................................................................................................................................2402.14.52 nvsave....................................................................................................................................2412.14.53 pwd........................................................................................................................................2422.14.54 quit.........................................................................................................................................2432.14.55 recall......................................................................................................................................2442.14.56 record-test...............................................................................................................................2452.14.57 release-locks............................................................................................................................2472.14.58 remove...................................................................................................................................2482.14.59 replace....................................................................................................................................2502.14.60 restart.....................................................................................................................................2532.14.61 run.........................................................................................................................................2542.14.62 save........................................................................................................................................2562.14.63 schema-server-cfg....................................................................................................................2572.14.64 schema-servers-cfg...................................................................................................................2592.14.65 session....................................................................................................................................2612.14.66 session-cfg..............................................................................................................................2622.14.67 sessions-cfg.............................................................................................................................2642.14.68 set-log-level............................................................................................................................2662.14.69 set-my-session.........................................................................................................................2672.14.70 sget........................................................................................................................................2692.14.71 sget-config..............................................................................................................................2732.14.72 sget-data.................................................................................................................................2772.14.73 show.......................................................................................................................................2812.14.74 shutdown................................................................................................................................2882.14.75 sleep.......................................................................................................................................2892.14.76 start-rpc-timing........................................................................................................................2902.14.77 start-session.............................................................................................................................2922.14.78 start-timer...............................................................................................................................2942.14.79 stop-rpc-timing........................................................................................................................2962.14.80 stop-session.............................................................................................................................2972.14.81 stop-timer................................................................................................................................2982.14.82 terminal..................................................................................................................................3002.14.83 test-suite.................................................................................................................................3012.14.84 unlock....................................................................................................................................3042.14.85 unset.......................................................................................................................................3062.14.86 user-cfg...................................................................................................................................3072.14.87 users-cfg.................................................................................................................................3092.14.88 uservars..................................................................................................................................3112.14.89 validate...................................................................................................................................3122.14.90 while......................................................................................................................................3142.14.91 xget........................................................................................................................................3162.14.92 xget-config..............................................................................................................................3192.14.93 xget-data.................................................................................................................................323

3 CLI Reference................................................................................................................................3273.1 --aliases-file............................................................................................................................327

Version 19.10-13


3.2 --alt-names..............................................................................................................................3273.3 --ask-password........................................................................................................................3283.4 --auto-discard-changes.............................................................................................................3283.5 --auto-keepalive.......................................................................................................................3293.6 --auto-reconnect.......................................................................................................................3293.7 --auto-reconnect-interval..........................................................................................................3303.8 --auto-reconnect-max...............................................................................................................3303.9 --autoaliases............................................................................................................................3313.10 --autocomp............................................................................................................................3313.11 --autoconfig...........................................................................................................................3323.12 --autoconfig-conf-mode..........................................................................................................3323.13 --autodevices.........................................................................................................................3333.14 --autohistory..........................................................................................................................3333.15 --autoload..............................................................................................................................3343.16 --autoload-cache....................................................................................................................3343.17 --autoload-get........................................................................................................................3353.18 --autoload-save-cache.............................................................................................................3353.19 --autonotif.............................................................................................................................3363.20 --autonvsave..........................................................................................................................3363.21 --autoschemaservers...............................................................................................................3373.22 --autosessions........................................................................................................................3373.23 --autotest...............................................................................................................................3383.24 --autousers............................................................................................................................3383.25 --autouservars........................................................................................................................3393.26 --bad-data..............................................................................................................................3393.27 --batch-mode.........................................................................................................................3403.28 --binary-display-maxlen.........................................................................................................3403.29 --break-key-mode..................................................................................................................3413.30 --callhome-address.................................................................................................................3413.31 --callhome-enabled................................................................................................................3423.32 --callhome-port......................................................................................................................3423.33 --callhome-tls-port.................................................................................................................3433.34 --callhome-user......................................................................................................................3433.35 --check-output.......................................................................................................................3443.36 --check-output-error...............................................................................................................3443.37 --check-replies.......................................................................................................................3453.38 --check-replies-error...............................................................................................................3453.39 --config.................................................................................................................................3463.40 --config-autosave...................................................................................................................3463.41 --config-commit-mode...........................................................................................................3473.42 --config-edit-mode.................................................................................................................3473.43 --datapath..............................................................................................................................3483.44 --default-module....................................................................................................................3483.45 --deviation.............................................................................................................................3493.46 --disable-command................................................................................................................3503.47 --display-mode......................................................................................................................3513.48 --echo-notif-loglevel..............................................................................................................3523.49 --echo-notifs..........................................................................................................................352

Version 19.10-13


3.50 --echo-replies........................................................................................................................3533.51 --encoding.............................................................................................................................3533.52 --entry-point..........................................................................................................................3543.53 --feature-disable.....................................................................................................................3543.54 --feature-enable.....................................................................................................................3553.55 --feature-enable-default..........................................................................................................3563.56 --fill-optional.........................................................................................................................3563.57 --fixorder..............................................................................................................................3573.58 --force-target.........................................................................................................................3573.59 --help....................................................................................................................................3583.60 --help-mode...........................................................................................................................3583.61 --help-width..........................................................................................................................3593.62 --history-file..........................................................................................................................3603.63 --home..................................................................................................................................3603.64 --ignore-missing-vars.............................................................................................................3613.65 --indent.................................................................................................................................3613.66 --insecure-ok.........................................................................................................................3623.67 --keepalive-interval................................................................................................................3623.68 --log......................................................................................................................................3633.69 --log-append..........................................................................................................................3633.70 --log-backtrace......................................................................................................................3643.71 --log-backtrace-detail.............................................................................................................3643.72 --log-backtrace-level..............................................................................................................3653.73 --log-backtrace-stream...........................................................................................................3663.74 --log-console.........................................................................................................................3663.75 --log-header...........................................................................................................................3673.76 --log-level.............................................................................................................................3683.77 --log-mirroring......................................................................................................................3693.78 --log-stderr............................................................................................................................3693.79 --log-suppress-ctrl..................................................................................................................3693.80--log-syslog............................................................................................................................3703.81 --log-syslog-level...................................................................................................................3713.82 --match-names.......................................................................................................................3723.83 --message-indent....................................................................................................................3733.84 --modpath.............................................................................................................................3733.85 --module...............................................................................................................................3743.86 --ncport.................................................................................................................................3743.87 --no-aliases............................................................................................................................3753.88 --no-config............................................................................................................................3753.89 --no-password........................................................................................................................3763.90 --optional..............................................................................................................................3763.91 --password............................................................................................................................3773.92 --private-key..........................................................................................................................3773.93 --prompt................................................................................................................................3783.94 --prompt-name.......................................................................................................................3783.95 --prompt-type........................................................................................................................3793.96 --protocols.............................................................................................................................3793.97 --public-key...........................................................................................................................380

Version 19.10-13


3.98 --restrict-edit-mode................................................................................................................3803.99 --runpath...............................................................................................................................3813.100 --run-command....................................................................................................................3813.101 --run-script..........................................................................................................................3823.102 --save-session-vars...............................................................................................................3823.103 --script-input.......................................................................................................................3833.104 --server...............................................................................................................................3833.105 --server-commands..............................................................................................................3843.106 --ssl-certificate.....................................................................................................................3843.107 --ssl-fallback-ok...................................................................................................................3853.108 --ssl-key..............................................................................................................................3853.109 --ssl-trust-store....................................................................................................................3863.110 --subdirs..............................................................................................................................3863.111 --term-length.......................................................................................................................3873.112 --test-suite-file.....................................................................................................................3873.113 --time-rpcs..........................................................................................................................3883.114 --time-rpcs-stats...................................................................................................................3883.115 --time-rpc-stats-file..............................................................................................................3893.116 --timeout.............................................................................................................................3893.117 --transport...........................................................................................................................3903.118 --use-data-templates.............................................................................................................3903.119 --use-rawxml.......................................................................................................................3913.120 --use-session-vars................................................................................................................3913.121 --use-traceid........................................................................................................................3923.122 --use-xmlheader...................................................................................................................3923.123 --user..................................................................................................................................3933.124 --uservars-file......................................................................................................................3933.125 --version.............................................................................................................................3943.126 --warn-error.........................................................................................................................3953.127 --warn-idlen........................................................................................................................3953.128 --warn-linelen......................................................................................................................3963.129 --warn-off............................................................................................................................3963.130 --warn-up............................................................................................................................3973.131 --wildcard-keys....................................................................................................................3983.132 --with-enable-mode..............................................................................................................3983.133 --with-notif-commands.........................................................................................................3993.134 --with-ocpattern...................................................................................................................3993.135 --with-term-msg...................................................................................................................4003.136 --yangmap...........................................................................................................................4003.137 --yumapro-home..................................................................................................................401

Version 19.10-13


1 Preface

1.1 Legal Statements

Copyright 2009 – 2012, Andy Bierman, All Rights Reserved.

Copyright 2012 - 2020, 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 API Quickstart Guide

YumaPro Quickstart Guide

YumaPro User Manual

YumaPro netconfd-pro Manual

YumaPro yangdiff-pro Manual

YumaPro yangdump-pro Manual

YumaPro Developer Manual

YumaPro ypclient-pro Manual

YumaPro yp-system API Guide

YumaPro yp-show API Guide

YumaPro Yocto Linux Quickstart Guide

YumaPro yp-snmp Manual

To obtain additional support you may contact YumaWorks technical support department:

[email protected]

1.2.1 WEB Sites

• YumaWorks

◦ https://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

Version 19.10-13

http://www.netconfcentral.org/

https://www.yumaworks.com/

mailto:[email protected]


◦ 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

• 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

◦ https://mailarchive.ietf.org/arch/browse/netconf/

◦ Technical issues related to the NETCONF protocol are discussed on the NETCONF WG mailing list. Refer to the instructions on https://www.ietf.org/mailman/listinfo/netconf for joining the mailing list.

• NETMOD Working Group

◦ https://datatracker.ietf.org/wg/netmod/documents/

◦ 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 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

Version 19.10-13

https://datatracker.ietf.org/wg/netmod/documents/

https://www.ietf.org/mailman/listinfo/netconf



https://mailarchive.ietf.org/arch/browse/netconf/

http://www.ibr.cs.tu-bs.de/projects/libsmi/

http://tools.ietf.org/wg/netconf/

http://trac.tools.ietf.org/wg/netconf/trac/wiki

http://www.yang-central.org/


2 yangcli-pro User GuideProgram 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.

Version 19.10-13


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

◦ Command line history, recall

◦ Output filtering with 'pipe' commands

◦ Terminal pagination with –More-- prompt controls

• Supports NETCONF 1.0, NETCONF 1.1, and RESTCONF protocols

• Automated session reconnect for NETCONF and RESTCONF sessions

• Automated shadow configuration monitoring for each session; can be referenced in scripts and tab completion

• Automated notification monitoring for each session; callback framework for event handling

• Automated regression testing support to verify server operation, including

◦ setup and cleanup sections per test-suite

◦ multiple tests per suite

◦ each test step can check for ok, rpc-error, data responses

• Automatic recording of test suites

◦ The record-test command used to automatically record commands in a re-usable test script.

◦ The test-suite command is used to run previously recorded tests and verify the same results are obtained as when the test was recorded.

• Automatic monitoring of server notifications

◦ The <create-subscription> operation is automatically sent if --autonotif=true and the server supports notifications.

◦ Configuration change events are monitored to know when configuration updates are needed for that session

• Automatic shadowing of the running configuration

◦ The <get-config> operation is automatically sent if --autoconfig=true. A shadow of the running configuration is maintained for the session, and updated automatically if notifications are active.

◦ The config command uses the shadow configuration for tab completion and comparison purposes.

• Automatic support for all NETCONF protocol operations, including several 'short-hand' commands for the most common operations:

◦ <edit-config> high level functions:

▪ create

▪ delete

▪ insert

▪ merge

▪ replace

Version 19.10-13


▪ remove

◦ <get> and <get-config> high-level functions:

▪ sget

▪ sget-config

▪ xget

▪ xget-config

◦ NMDA <get-data> high-level functions:

▪ sget-data

▪ xget-data

• Automated database locking, unlocking and error cleanup, using the high-level get-locks and release-locks commands.

• Automatic, standards-based, server schema synchronization, using the YANG module capability URI information in the <hello> PDU, and the <get-schema> operation:

◦ For each session, the exact view of the server schema definition tree is created, based on the module capability:

▪ module namespace

▪ module name

▪ module revision date

▪ enabled features

▪ names of any modules that contain deviations for this module

◦ The help text and parameter validation for each session will be tailored to the capabilities advertised by the server.

◦ Parses each potential matching YANG file to make sure the module name, revision date, and namespace URI value are all exactly the same as the values in the module capability URI.

• Understands all NETCONF protocol capabilities, and complex hard-wired logic simplifies protocol usage, and allows high-level commands to pick appropriate defaults for many RPC operation parameters.

• Load any YANG module at boot-time or run-time and start using it immediately.

• Full concurrent support for multiple revisions of the same module.

• Supports NETCONF notifications, including :interleave capability.

• Full XPath 1.0 and subtree filtering support.

• Automatic support for all YANG language mechanisms, including extensions.

• Any YANG <rpc> operation is automatically available as a yangcli-pro command.

• Uses YANG files directly as input, so no pre-processing or configuration needed to use a new module.

• Can be called from unix scripts in 'batch-mode' to automatically establish a NETCONF session, issue a command or invoke a yangcli-pro script, close the session, and return the results.

• Extensive interactive shell environment, including user variables, file variables, smart parameter set completion, and a simple scripting environment for automatic operation.

• Automatic, context-sensitive (tab key) command-line completion.

• Full support for XPath, instance-identifier, leafref, and identityref parameters.

Version 19.10-13


• Automatic, context-sensitive help system, based completely on YANG files and using the exact modules supported by the current NETCONF session, if connected.

• Full, customizable command line editing, using emacs by default, but vi or a custom set of keystroke bindings are also supported.

• Command line history and command recall.

• Store and recall command line history files for later use.

• Automatic NETCONF session management, including support for all YANG extensions to the <capability> element.

• Automatic recognition and support for all NETCONF 'capability' related operations.

• Automatic support for all YANG additions to the NETCONF protocol, such as the insert operation

• Unlimited nested scripts with up to 10 parameters each can automate testing and other management tasks

• User configurable command aliases that can be saved and restored.

• Differentiate between local and server commands when the <tab> and ?<cr> used. A star '*' will be printed after each server command.

• Configurable NETCONF Call-Home over SSH support

• Support the privileged mode in yp-shell for config mode.

• Support of restricting all editing to the yp-shell config mode.

• Configurable break-key behavior to cancel current command ot exit program

Version 19.10-13


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 yangcli-pro from a work directory, rather than the installation directory or within the module library.

The yangcli-pro program can be invoked several ways:

• To get the current version and exit:

yangcli-pro --version

• To get program help and exit:

yangcli-pro --helpyangcli-pro --help --briefyangcli-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

Version 19.10-13


• 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 \--user=andy --password=yangrocks

• To automatically connect to a server, run a script in non-interactive mode, and then remain connected to the server, add the --run-script parameter to the connection parameters. The --runpath parameter can also be entered, if needed.

yangcli-pro --server=myserver.example.com \--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.

yangcli-pro --server=myserver.example.com \--user=andy --password=yangrocks \--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 remainin the current session (in interactive mode) after the command is invoked.

yangcli-pro --server=myserver.example.com \--user=andy --password=yangrocks \--batch-mode --run-command=”sget /system”

• To automatically connect to a server, and just listen for notifications, and never exit, use the --autonotif=true parameter instead of the --run-command or --run-script parameter. The --batch-mode parameter must be provided in this mode.

yangcli-pro --server=myserver.example.com \--user=andy --password=yangrocks \--batch-mode --autonotif=true

Version 19.10-13


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

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).

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:

Version 19.10-13


• 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 commandavailable on the server.

Local Commands

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

clear Clear the screen

config Enter the configuration mode for the current session

connect Connect to a server and start a NETCONF session

device-cfg Access a named device configuration

devices-cfg Access the named device configuration file

elif Start an 'else-if' conditional block

else Start an 'else' conditional block

enable-password Enable the privileged mode in yp-shell to enter the config mode.

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

nvsave Save the running datastore to the startup datastore

pwd Print the current working directory

quit Exit the program

Version 19.10-13


recall Recall a line from the command history buffer

record-test Record commands and responses for a regression test

run Run a script

schema-server-cfg Access a named schema-server-cfg configuration

schema-servers-cfg Access the named schema-servers-cfg configuration file

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

sleep Sleep for a number of seconds (for use in scripts)

start-rpc-timing Start <rpc> timing mode and save statistics to a file

stop-session Stop a named session

stop-timer Stop a script timer and display the elapsed time

terminal Set the terminal length

test-suite Access a configured unit-test suite for automated testing

user-cfg Access a named user configuration

users-cfg Access the named user configuration file

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

Version 19.10-13


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

action Invoke a YANG 1.1 <action>

create Invoke an <edit-config> create operation

delete Invoke an <edit-config> delete operation

get-locks Lock all the databases with the <lock> operation

get-walk Walk the entries of a YANG list.

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

Version 19.10-13


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

sget-data Invoke a <get-data> 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

xget-data Invoke a <get-data> 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 description

apply Apply any pending edits to the current session

exit Return to the parent mode and apply and pending edits

do Run a command in configuration mode

no Prefix to configuration mode command used to delete a node

return Return to normal mode from Confing mode without applying ny edits

Version 19.10-13


2.1.6 Variables

The yangcli-pro program utilizes several types of user-accessible variables. These variables can be listed with the 'show vars' command and other commands as well.

A variable reference consists of 1 or 2 dollar signs ('$'), followed immediately by a valid identifier string (e.g., $$global-logor $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 ofa 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 yangcli-pro. These variables are set once when the program is started, and cannot be used in the the left hand side of an assignment statement.

Version 19.10-13


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

$$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

$$ask-password the –ask-password configuration parameter

$$auto-discard-changes the --auto-discard-changes parameter

$$auto-keepalive the –auto-keepalive configuration parameter

$$auto-reconnect the –-auto-reconnect configuration parameter

$$auto-reconnect-interval the --auto-reconnect-interval configuration parameter

$$auto-reconnect-max the --auto-reconnect-max configuration parameter

$$autoaliases the --autoaliases configuration parameter

$$autocomp the --autocomp configuration parameter

$$autoconfig the --autoconfig configuration parameter

$$autoconfig-conf-mode the --autoconfig-conf-mode configuration parameter

$$autodevices the --autodevices configuration parameter

$$autohistory the --autohistory configuration parameter

$$autoload the --autoload configuration parameter

$$autoload-cache the --autoload-cache configuration parameter

$$autoload-get the --autoload-get configuration parameter

$$autoload-save-cache the –autoload-save-cache configuration parameter

Version 19.10-13


$$autonotif the --autonotif configuration parameter

$$autonvsave the –autonvsave configuration parameter

$$autoschemaservers the --autoschemaservers configuration parameter

$$autosessions the --autosessions configuration parameter

$$autotest the --autotest configuration parameter

$$autousers the --autousers configuration parameter

$$autouservars the --autouservars configuration parameter

$$bad-data the --bad-data configuration parameter

$$break-key-mode the --break-key-mode configuration parameter

$$callhome-address the --callhome-address configuration parameter

$$callhome-enabled the --callhome-enabled configuration parameter

$$callhome-port the --callhome-port configuration parameter

$$callhome-tls-port the --callhome-tls-port 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-autosave the --config-autosave configuration parameter

$$config-commit-mode the --config-commit-mode 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 <edit-config> operations

$$display-mode the --display-mode configuration parameter

$$echo-notif-loglevel the --echo-notif-loglevel configuration parameter

$$echo-notifs the --echo-notifs configuration parameter

$$echo-replies the --echo-replies configuration parameter

$$encoding the --encoding configuration parameter

$$error-option the <error-option> parameter for <edit-config> operations

$$fill-optional the –fill-optional configuration parameter

$$fixorder the --fixorder configuration parameter

$$help-width the –help-width configuration parameter

$$ignore-missing-vars the –ignore-missing-vars configuration parameter

$$indent the –indent configuration parameter

$$keepalive-interval The -keepalive-interval configuration parameter

$$log-level the --log-level configuration parameter

$$match-names the –match-names configuration parameter

Version 19.10-13


$$message-indent the --message-indent configuration parameter

$$optional the --optional configuration parameter

$$prompt the --prompt configuration parameter (yp-shell only)

$$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

$$ssl-fallback-ok the –ssl-fallback-ok configuration parameter

$$term-length the –term-length 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-session-vars the --use-session-vars configuration parameter

$$use-traceid the --use-traceid 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

$$with-term-msg the –with-term-msg configuration parameter

Read-write global user variables

If a unrecognized global variable (e.g., $$foo) is used in the left-hand side of an assignment statement, then a global user variable will be created with that name. If the global user variable already exists, then its value will be overwritten.

The uservars command can be used to load or store these variables so they are loaded at boot-time. By default, the XML file used to store these variables is $HOME/.yumapro/yangcli-pro_uservars.xml.

Read-write local user variables

If a local variable (e.g., $foo) is used in the left-hand side of an assignment statement, then a local user variable will be created with that name. If the local user variable already exists, then its value will be overwritten. If the variable is created within a script (i.e., run-level greater than zero), then it will be deleted when the script exits.

Version 19.10-13


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.

Version 19.10-13


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 yangcli-pro 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 [email protected] --with-defaults=explicit

It is an error if the file referenced does not exist or cannot be read.

Version 19.10-13

mailto:--filter%[email protected]


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. Scriptsare simply text files, and the extension used does not matter.

There are no formal templates for scripts, like there are for RPC operations, at this time. Instead, positional parameters can be passed to any script.

The parameters named --P1 to --P9 allow up to 9 parameters to be passed to any script. Within each script, the numbered parameters '$1' to '$9' are available, and contain the value that was passed as the corresponding ---Pn” parameter when calling the script.

If a line contains only optional whitespace, followed by the pound sign character '#', then the line is treated as a comment. These lines will be skipped.

If an error occurs during a command within a script, or an <rpc-error> is received from the server during a NETCONF session, then the running script will be canceled, and if this was a nested script, then all parent scripts will also be canceled.

Script Example:

> run connect --P1=andy --P2==localhost --P3=yangrocks

// connect script# start a NETCONF session$user = $1$server = $2$password = $3

> connect --user=$user --server=$server --password=$password

Run Levels

The run command can appear in a script.

When yangcli-pro starts up, either in interactive mode or in batch mode, the script interpreter is at run level zero. Each time a run command is invoked, either at the command line or within a script currently being invoked, a new run level withthe 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,

Version 19.10-13


These command work exactly like an 'if' expression within a program language such as Python. Note that indentation is notsignificant, 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).

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 1

The following script does not do any useful work.

It is provided to demonstrate some simple constructs.

$x = 0while '$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'endif "feature-enabled('test5', 'feature-foo')"

Version 19.10-13


log-info 'feature-foo' run add-foo-parmsend

Sample Script 2

The following script demonstrates how to run multiple edits on ietf-interface.yang data module:

$x = 0 $y = interfaces $z = interface $value = ianaift:l2vlan

while '$x < 5' create /if:$y/if:$z[if:name='vlan$x']/if:type value=$value commit $x = eval '$x + 1'

end

Version 19.10-13


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 similarto a router CLI. This mode can be used to edit YANG datastore nodes with a simplified interface.

Configuration mode can be used if the current session is connected to a server. If not, requests to enter configuration mode will be rejected with an error message.

In configuration mode, data node names can be abbreviated just like RPC operation parameter names.

Enter Configuration Mode

To enter configuration mode, use the 'config' command:

mysession> config term

mysession#

Once configuration mode is active, the prompt will change (notice (c) above), the available top-level configuration data nodes advertised by the server are available as 'commands'. Only a few special commands are available in configuration mode:

• 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.

Version 19.10-13


Any pending edits will be abandoned and not applied to the current session.

mysession(interface)# return

mysession>

Creating or modifying server database parameters

mysession(interface)# mtu 9000

mysession(interface)# exit

Applying 1 edit to session [mysession]

mysession(interfaces)# exit

mysession# exit

mysession>

Since the configuration editing mode is set to 'level' (the default). the 'mtu' edit is not applied until the exit command is given. To force all pending edits to be sent to the current session, the apply command can be used within a given context level.

Commands can be entered in a flexible manner. The same command as above could be entered in 1 command line:

mysession# int int eth0 mtu 9000


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.

Escaping configuration mode

Version 19.10-13


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#

Version 19.10-13


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.

--ask-password Controls whether the 'connect' command will prompt for password parameter (if it is not provided).

--auto-discard-changes Controls automatic sending of <discard-changes> to cleanup edit

--auto-keepalive Controls automatic sending of keepalive messages. NOT IMPLEMENTED - IGNORED

--auto-reconnect Controls automatic reconnecting to dropped sessions

--auto-reconnect-interval Controls how often automatic reconnect is attempted

--auto-reconnect-max Controls maximum number of reconnect attempts

--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.

--autoconfig-conf-mode Controls whether the running configuration will be retrieved automatically for active sessions, while editing in config mode

--autodevices Controls whether saved device configurations are loaded at startup and saved upon exit.

--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> operationare 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 cached YANG modules will be saved upon exit

--autonotif Controls whether notifications will automatically be enabled when a session starts.

--autonvsave Controls whether the 'save' and 'apply' commands will NV-save the configuration changes or not.

--autosessions Controls whether saved session configurations are loaded at startup and saved upon exit.

--autoschemaservers Controls whether the saved schema servers will be loaded into memory

Version 19.10-13


at startup and saved to file at exit.

--autosessions Controls whether the saved sessions will be loaded into memory at startup and saved to file at exit.

--autotest Controls whether the saved test suites will be loaded into memory at startup and saved to file at exit.

--autousers Controls whether saved user configurations are loaded at startup and saved upon exit.

--autouservars Controls automatic loading and saving of the global user variables

--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.

--binary-display-maxlen Maximum number of bytes o display of binary data for a YANG object

--break-key-mode Controls the behavior when the break key (Control C) is pressed

--callhome-address IP address to use to listen for CallHome SSH requests

--callhome-enabled Enable or disable the IETF Call Home protocol

--callhome-port TCP port number to use to listen for NETCONF over SSH CallHome requests

--callhome-tls-port TCP port number to use to listen for NETCONF over TLS CallHome requests

--callhome-user Name of a configured user entry to use for Call Home connections

--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-autosave Controls how edits in config term mode are saved to NV-storage if the server supports the :startup capability.

--config-commit-mode If 'true' then edits done in config mode will be made to the candidate datastore if possible. The edits will not be committed to the running datastore automatically.

--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.`

--disable-command Specifies a top-level command that should be disabled and not visible or available to a user. If the value does not contain a module name prefix, then the command will be disabled in all modules.

--display-mode Specifies how values should be displayed.

Version 19.10-13


--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'

--encoding Controls the desired RESTCONF encoding format.

--entry-point RESTCONF entry point. Use this string instead of retrieving the XRD from the RESTCONF server to discover the entry point

--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

--fill-optional Specifies the default value for the –optional flag for the operations that fill YANG datastore contents

--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 beused 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).

--help-width Width of help text line for '?' help key output

--history-file Specifies the libtecla command line history file to use

--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.

--insecure-ok Specifies if unverified client certificates will be accepted (DEBUG only)

--keepalive-interval Specifies the keepalive message interval. NOT IMPLEMENTED.

--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.

--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.

Version 19.10-13


--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.

--log-syslog-level Sets the syslog debug logging level filter for output to the syslog file

--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-aliases Disables the alias substitution feature.

--no-config Specifies that the default configuration file should not be loaded if it exists. Not a configuration file parameter.

--no-password Specifies that keys will be used instead of a password. Ignored if used as a configuration file parameter.

--optional Specifies the default value of the $$optional variable. THis will affect all input, not just YANG datastore contents. Use with caution!

--password Specifies the password to use in the connect command.

--private-key Contains the file path specification for the file containing the client-side private key.

--prompt Set a complete custom prompt for yp-shell

--prompt-name Customize a prompt name for yp-shell.

--prompt-type Selects the type of prompt string that will be used in interactive mode.

--protocols Controls which NETCONF protocol versions will be enabled. Ignored if used in a configuration file.

--public-key Contains the file path specification for the file containing the client-side public key

--restrict-edit-mode Controls whether an 'restrict edit mode' will be supported for yp-shell.

--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 ininteractive mode.

--server Specifies the server address to use in the connect command.

--server-commands Specifies whether RPC operations learned from server YANG modules

Version 19.10-13


will be added as a command available to the user.

ssl-certificate Contains the file path specification for the file containing the client-side SSL certificate.

ssl-fallback-ok If true then an attempt to establish a plain TCP connection will be made if an SSL connection cannot be made.

ssl-key Contains the file path specification for the file containing the client-side SSL key

ssl-trust-store Contains the file path specification for the file containing the client-side ssl trust-store, or the path specification for the directory to use for findingtrusted certificates

--subdirs Specifies whether child sub-directories should be searched when looking for files.

--term-length Specifies the number of lines that should be printed per page if paginatedoutput is used. The “terminal length” command can also be used for the same purpose.

--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-rpcsvariable is also true.

--time-rpcs-stats-file Save rpc statistics to the specified file if the --time-rpc-stats and time-rpcs 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-traceid Controls whether the 'trace-id' attribute will be set in the RPC calls or not. By default, 'trace-id' attribute is disabled.

--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-error Treat all warnings as errors

--warn-idlen Controls how identifier lengths are checked.

--warn-linelen Controls how line lengths are checked.

--warn-off Suppresses the specified warning number.

Version 19.10-13


--warn-up Elevates the specified warning number to an error

--wildcard-keys Enable wildcards on key leaf values

--with-enable-mode Controls whether an enable mode will be supported for yp-shell.

--with-notif-commands Controls whether notification commands are available in yp-shell

--with-ocpattern Controls whether OpenConfig pattern syntax will be checked

--with-term-msg Controls whether Terminal Diagnostic events are supported

--yangmap Specifies a yangmap XML file that should be loaded into the program

--yumapro-home Specifies the $YUMAPRO_HOME project root to use when searching for files.

Version 19.10-13


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

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.

Version 19.10-13


2.2.1 Command Prompt

The yangcli-pro command prompt changes, depending on the context.

It can also be configured and changed at run-time by the user (yp-shell only.

If the --prompt CLI parameter or $$prompt configuration variable is used to set the prompt to a user-specified value, then that will be the prompt shown in Idle Mode, and also used as the base prompt string in Config Mode. See the --prompt parameter for more details.

Idle Mode:

If the script interpreter is idle and there is no NETCONF session active, then the prompt is simply a 'less than' sign:

>

If the script interpreter is idle and the default NETCONF session active, then the prompt is of the form <user>@<server>', depending on the parameters used in the connect command. Note that the <server> portion of the prompt can be configuredin yp-shell, using the prompt-name CLI parameter.

andy@myserver>

If a named session is active, then the '<user>@<server>' text will not be shown. Instead, the session name will be shown mysession.

mysession>

Configuration Mode:

If configuration mode is entered, the final prompt character will change from '>' to '#'.

Default session:

andy@myserver#

Named session:

mysession#

If the configuration mode context node is changed, then the new datastore target object name will be shown as well:

mysession# interfaces

Version 19.10-13


mysession(interfaces)# interface eth0

mysession(interface)#

Continuation Mode:

If a backslash, end-of-line sequence ended the previous line, the prompt will simply be the word 'more' indented 3 spaces:

andy@myserver> get \ more>

The 'more>' prompt will continue if the new line also ends in with an escaped end-of-line. When a new line is finally terminated, all the fragments are spliced together and delivered as one command line.

Note: context-sensitive command completion is not available in this mode.

Choice mode:

If a partial command has been entered in interactive mode, and the script interpreter needs to prompt for a YANG 'choice' parameter, then a list of numbered cases will be presented, and the prompt will be the same as it was before (depending on whether a NETCONF session is active or not), except a colon character (':'), followed by the command name, will be added at the end. As long as parameters for the same command are being entered (i.e., prompted for child nodes within a selected case, the command name will be appended to the prompt.

andy@myserver> sget

Enter a number of the selected case statement:

1: case varref: leaf varref 2: case from-cli: leaf target leaf optional anyxml value

Enter choice number [1 - 2]: andy@myserver:sget>

Parameter mode:

If a partial command has been entered in interactive mode, and the script interpreter needs to prompt for a leaf or leaf-list, then the parameter name will appear in angle brackets ('<' and '>').

Filling mandatory case /sget/input/from/from-cli: Enter string value for leaf <target> andy@myserver:sget>

Version 19.10-13


If the 'ncx:password' extension is part of the YANG definition for the leaf or leaf-list, then the characters entered at the prompt in this mode will not be echoed, and they will not be saved in the command history buffer. Any default value will not be printed either. Instead, 4 asterisks '****' will be printed, even though the correct value will be used in the command.

If a default value is available, it will appear in square brackets ('[' and ']'). In this case, entering 'return' will not be interpreted as an empty string, but rather the default value that was presented.

> connect

Enter string value for leaf <user> [andy] :connect>

Enter string value for leaf <server> [myserver] :connect>

Enter string value for leaf <password> [****] :connect>

Enter uint16 value for leaf <port> [830] :connect>

Enter uint32 value for leaf <timeout> [30]

[connect sequence text printed, and then prompt changes...)

andy@myserver>

Note: After a NETCONF session is terminated for any reason, the connection parameters will be remembered , and presented as defaults the next time the connect command is entered.

False Conditional Block Mode

If a conditional command (if, elif, else, or while command) is active, but the conditional expression is false, then any commands defined within that conditional block will not be executed. If this occurs in interactive mode instead of a script, the string '[F]' will be added to the command prompt. Note that the 'help' and 'log-info' commands do not get executed in the following example:

> if 0

[F]> help

[F]> log-info 'this will not get printed'

[F]> end

>

Version 19.10-13


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 19.10-13



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 default parameter

action target

alias var

aliases show

cd dir

connect server

create target

elif expr

else expr

if expr

eventlog show

fill target

help command

history show

Version 19.10-13


command default parameter

insert target

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

sget-data target

xget select

xget-config select

xget-data select

while expr

Version 19.10-13


2.2.4 Parameter Mode Escape Commands

There are 4 escape sequence commands that can be used while entering parameters.

They all begin with the question mark character ('?'), and end with the 'Enter' key.

Control key sequences are not used because that would interfere with command line editing keys.

Parameter mode escape sequences

escape sequence description

? Print some help text

?? Get all available help text

?s Skip this parameter

?se Skip to the end of the current parameter set

?c Cancel this commandIf --break-key-mode=command then Control-C can also be used to cancel a command.

Note: If the current parameter is considered hidden (ncx:hidden extension used in the YANG definition), then no help will be available for the parameter, even though it is accessible. This also apples to the help command. Any command or parameter designated as ncx:hidden will be treated as an unknown identifier, and no help will be given.

Note: Skipping mandatory nodes with the '?s' command is affected by the --bad-data configuration parameter and $$bad-data system variable. An error, warning, or confirmation check may occur. Refer to the CLI Reference for more details.

The '?s' command to skip a parameter will allow the current command to be skipped, even if it is a mandatory parameter.

The '?se' command will allow the current command to be skipped, even if it is a mandatory parameter. The rest of the parameters in the same sibling set will also be skipped, but only if they are optional parameters. This mode is only active if the –optional parameter is used in the command that is causing parameters to be entered, or the $$optional global variable isset to 'true'. The sibling set is defined as the nodes in the parent containment node (case, list, or container).

Note: If there are any YANG defined values (e.g., enumeration, bits, default-stmt) available for the current parameter, then pressing the tab key will list the full or partial completions available.

Version 19.10-13


2.2.5 Using Inline XML or JSON Data

It is possible to assign JSON or XML encoded data to a variable or command parameter.

This can be done at the command prompt or within a script.

A special string consisting of 3 double quotes is used to indicate the beginning or end of the inline data.

The syntax is simple:

<start-tag> [wsp] <XML element -or- JSON object> [wsp] <end-tag>

Example <edit-config> command setting the <config> container to an XML value:

sesA> edit-config target=candidate \ config="""<config><int8.1>5</int8.1></config>"""

The end-of-line continuation marker '\' is not needed when entering inline data. The data may appear or multiple lines.

Example script using JSON:

> edit-config target=candidate config="""{"config": { "container.1" : { "uint16.1" : 42, "uint32.1" : 4200, "int32.1" : -4200 } }}"""

Example script using XML:

> edit-config target=candidate config="""<config> <container.1> <uint16.1>42</uint16.1> <uint32.1>4200</uint32.1> <int32.1>-4200</int32.1> </container.1></config>"""

When entering inline data at the command line, the “more>” command prompt mode will be entered automatically if an oddnumber of tags are found on the input line.

Version 19.10-13


When assigning inline data to a variable, there is no object specified, so the YANG “anydata” type is used. In this case any valid XML element or JSON object can be assigned.

Example Variable Assignment

andy@localhost> $foo = """more> <A>more> <leaf1>testing</leaf1>more> </A>more> """

OK

andy@localhost> show var foo

foo [/struct] A { leaf1 testing }

andy@localhost>

Restrictions:

• Only the following YANG data node types are supported:

◦ container

◦ list

◦ anyxml

◦ anydata

◦ input

◦ output

• The maximum length of an input line, including all inline data, is 65535 bytes.

• If a JSON array is entered instead of a JSON object, then only the first instance will be used. Any additional instances will be ignored.

Version 19.10-13


2.2.6 Using External XML

It is possible to specify command parameters and even the entire command with an external XML file. This file needs to be located in the data path, such as the $HOME/data directory.

The CLI parameter --use-rawxml affects the parsing of the external XML file. By default, the XML will be parsed and converted to internal data format. If --use-rawxml=true is used then the file will be used as-is if the XML file is invalid.

If this parameter is ‘false’ then xmlns attributes will be ignored in the external XML file.

External XML Parameters

A parameter can be specified using an external XML file using the @<filename> syntax

> get [email protected]

andy@localhost> get [email protected]

RPC Data Reply 6 for session 3 [default]:

rpc-reply { data { netconf-state { statistics { netconf-start-time 2019-12-03T01:30:04Z in-bad-hellos 0 in-sessions 1 dropped-sessions 0 in-rpcs 5 in-bad-rpcs 0 out-rpc-errors 0 out-notifications 0 } } }}

andy@localhost>

In this example, the contents of the <filter> element will be filled using the contents of the file “myfilter.xml”. The contents will be used as the child nodes of the <filter> element. This is suitable for sending subtree filters.

<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <statistics/> </netconf-state>

The message sent to the server:

Version 19.10-13

mailto:filter%[email protected]


<?xml version="1.0" encoding="UTF-8"?><rpc message-id="5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get> <filter type="subtree"> <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <statistics/> </netconf-state> </filter> </get></rpc>

External XML Commands

It is possible to provide the entire command in the external XML file. In this case the top-level element must match the command, and the contents of this command will be used for the input parameters.

> $$use-rawxml = true

> get @myget.xml

The contents of the myget.xml contain a filter element using an XPath expression. In this case the prefixes need to be defined if any are used in the XPath expression. Note that the <get> operation needs a namespace definition as well or else the namespace will default to “yuma-ncx”.

<get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <filter type="xpath" select="/n:netconf-state/n:statistics" xmlns:n="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring" /></get>

Version 19.10-13


2.2.7 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 anode-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 19.10-13


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=plaindata { interfaces {

interface eth0 { name eth0 ifMtu 1500

} interface eth1 {

name eth1 ifMtu 1518

} }}

Version 19.10-13


2.2.8 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., --help-mode) can be omitted. The accessible child nodes within the case nodes can be entered directly (e.g., sget --target parameter).

# this is not allowed because 'help-mode' is not complete> help --command=help --help-mo=brief

# this is allowed because 'help-mode' is complete,# even though help-mode is a choice and 'brief' is# an empty leaf> help help help-mode=brief

# choice and case names are transparent when# searching for parameter names, so the# following command is the same as above> help help brief

Lists and Leaf-Lists

When filling a data structure and a descendant node is entered, which is a YANG list or leaf-list, then multiple entries can be entered. After the node is filled in, there will be a prompt (Y/N, default no) to add more list or leaf-list entries.

Binary Data Type

The YANG binary data type is supported. Parameters of this type should be entered in plain text and they will be convertedto binary format.

Version 19.10-13


2.2.9 Command Completion

The 'tab' key is used for context-sensitive command completion:

• If no command has been started, a list of available commands is printed

• If a partial command is entered, a list of commands which match the characters entered so far is printed

• If a command is entered, but no parameters, then a list of available parameters is printed

• If a command is entered, and the cursor is within a command name, then a list of parameters which match the characters entered so far is printed

• If a command is entered, and the cursor is after a command name, but not within a value string, then a list of available parameters is printed

• If a command is entered, and the cursor is within a command value, then a list of possible values which match the characters entered so far is printed. Note that not all data types support value completion at this time.

• If no values are available, but a default value is known, that value will be printed

• If a session is active, and whitespace followed by the forward slash '/' character is entered, a list of top-level data node names is printed. Once a top-level name and a trailing slash '/' character is entered, pressing the tab key again will print the names of the child nodes of the current data node. Only schema-node strings are supported at this time. Auto-completion will not work if predicates are present in the absolute path expression.

Command list example: no NETCONF session is active:

> <hit tab key>cd fill history mgrload quit run connect help list pwd recall show

Command list example: NETCONF session is active

[email protected]> <hit tab key>cd get-schema recall close-session help replace commit history restart connect insert run copy-config kill-session save create list sget create-subscription load sget-config delete load-config show delete-config lock shutdown discard-changes merge unlock edit-config mgrload validate fill no-op xget get pwd xget-config get-config quit

Version 19.10-13


2.2.10 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.

The alt key sequence (M-f == alt key and f key at the same time). The letter is not case-sensitive, so M-F and M-f are the same command.

The following table shows the the most common default key bindings:

Common editing key bindings

command description

^C clear screen

^F cursor right

^B cursor-left

Â beginning of line

Ê end of line

Û delete line

M-f forward-word

M-b backward word

Version 19.10-13

http://www.astro.caltech.edu/~mcs/tecla/tecla.html

http://www.astro.caltech.edu/~mcs/tecla/


^P up history

^N down history

2.2.11 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 sub-modes:

• show: show maximum of N history entries (default is 25)

• clear: clear the history buffer

• save: save the history buffer to a file

• load: load the history buffer from a file

By default, the command line history buffer is loaded when the program starts, and saved when the program exits. This behavior can be turned off by setting the --autohistory configuration parameter to 'false'.

If –autohistory is ‘true’, then by default, the command line history buffer is loaded from the file $HOME/.yumapro.yangcli_pro_history This behavior can be changed by setting the –history-file configuration parameter to the file specification to use instead of the default file location. The same parameter needs to be used each time the program is loaded in order to maintain the same history file.

The '!' character is special when editing commands. If the first character is '!', and it is followed by a number or a non-zero character, the line will be interpreted as a recall request:

• > !42 == recall command number 42 (same as recall 42)

• > !get == recall the most recent command line starting with 'get'

Refer to the Command Reference section for more details on the history command.

Version 19.10-13


2.2.12 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 fileand/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.

Version 19.10-13


2.3 Controlling Terminal Output

The yangcli-pro and yp-shell programs support terminal output filtering and paginated output. Pipe commands allow the line-by-line terminal output to be filtered, formatted, or redirected.

• Pipe Commands: filter show command output and server response output

• Pagination: pause output after each page, allowing the user to continue or quit the output

• Display Mode: Specifies the display format (e.g., plain, cli, XML, JSON)

2.3.1 Pipe Commands

Pipe commands are used to control the terminal output

• Pipe Commands: filter show command output and server response output

◦ begin: start output after this pattern matches

◦ include: include lines that match this pattern

◦ exclude: exclude lines that match this pattern

◦ redirect: send output to a text file instead of the screen

◦ display: format the output in XML, JSON, CLI, or plain format

Usage Notes:

• The pipe commands can be combined.

• The “include” and “exclude” commands can be specified multiple times

• The “redirect” filespec is relative to the current working directory

• The “display” parameter is used to over-ride the current $$display-mode variable setting.

Examples:

The “show fan” command is an external command from the example-show.yang module.

It is not a real command within yangcli-pro.

The full output of the command is shown first, without any pipe commands:

> show fan 1 --full

Report for Fan 1 put fan status here... put more fan status here... put even more fan status here...

The “begin” command: this is case-sensitive so the first “fan” matches, not “Fan”

Version 19.10-13


> show fan 1 --full | begin fan

put fan status here... put more fan status here... put even more fan status here...

>

The “include” command:

> show fan 1 --full | include more put more fan status here... put even more fan status here…

>

The “exclude” command:

> show fan 1 --full | exclude more

Report for Fan 1 put fan status here...

>

The “display” command:

andy@localhost> sget /system/uname|display json

Filling container /system/uname:RPC Data Reply 11 for session 3 [default]: { "yuma-netconf:rpc-reply": { "yuma-netconf:data": { "yuma-system:system": { "uname": { "sysname":"Linux", "release":"4.4.0-104-generic", "version":"#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017", "machine":"x86_64", "nodename":"andy-2i7" } } } }}

andy@localhost>

Version 19.10-13


The “display” and “redirect” commands combined:

andy@localhost> sget /system|redirect ~/test1.json display json

Filling container /system:andy@localhost>

YANG Definition

container pipe { ncx:abstract; ncx:hidden;

description "Pipe command sub-commands. The 'begin', 'include', and 'exclude' parameters are used to filter command output. If these parameters contain any pattern meta-characters, then they will be treated as a YANG pattern string. If a plain string is found instead, then this string must be found in the line to be considered a match.

Each output line is processed in the following manner: 1) if begin set and not triggered yet, then test the line. If a match then disable this step for future lines and continue testing output, else skip this line. 2) check each exclude parameter. If any match then skip this line. 3) check each include parameter. If any match then include this line, else skip this line. 4) include the line in the output.

If the 'redirect' parameter is present then the filtered output will be sent to a file instead of the session.

If the 'display'parameter is present then the specifed display format will be used for the output and the filtering format. By default, the current display-mode is used for both filtering and output formats.";

leaf begin { type string; description "Specifies the pipe begin line pattern."; }

leaf-list include { type string; description "Specifies a pipe include line pattern. Multiple parameters are treated as a logical-OR expression."; }

leaf-list exclude { type string; description "Specifies a pipe exclude line pattern.

Version 19.10-13


Multiple parameters are treated as a logical-OR expression."; }

leaf redirect { type string; description "Specifies the pipe output redirect filespec. If this filespec already exists then output will be appended to the file."; }

leaf display { type enumeration { enum xml { description "Display output in XML"; } enum json { description "Display output in JSON"; } enum curmode { description "Display output is the current $$display-mode"; } enum plain { description "Display output in plain format"; } enum cli { description "Display output in CLI format"; } } default "curmode"; description "Specifies the pipe output display format."; } }

Version 19.10-13


2.3.2 Pagination

• Pagination: pause output after each page, allowing the user to continue or quit the output

◦ --More-- prompt displayed at each pause

◦ terminal length command controls number of lines printed per page

◦ $$term-length variable also controls number of lines printed per page

◦ space bar prints next page, return prints next line, ‘q’ to quit output

leaf term-length { description "Specifies the length of the terminal to use for page mode output with the -More- prompt. This parameter is ignored in batch mode. It is only used if the output session is operating in interactive mode.

If the value 0 is used then the 'More' prompt will be disabled. Otherwise this value represents the number of lines to output for each screen in pagination output mode."; type uint16 { range "0 .. 511"; } default 0; }

Example using pagination and pipe commands together:

andy@localhost> term length 10

OK

andy@localhost> sget /system/uname|display json

Filling container /system/uname:RPC Data Reply 12 for session 3 [default]: { "yuma-netconf:rpc-reply": { "yuma-netconf:data": { "yuma-system:system": { "uname": { "sysname":"Linux", "release":"4.4.0-104-generic", "version":"#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017",

--More--

Examples setting terminal length:

> $$term-length = 20> term length 20

Version 19.10-13


2.3.3 Display Mode

The display mode controls the output format used to display YANG data:

• Not all commands use YANG data so the display mode does not affect all commands.

• Some show commands for example use plain text output only.

• Commands that return “OK” or some error message are not affected by the display mode.

• Commands that return server data and display the response support all display modes

• Setting the Display Mode:

◦ $$display-mode variable controls the output display format

◦ The pipe command “display” overrides the $$display-mode setting for the current command

• Displaying the current display mode:

> show var display-mode display-mode cli

YANG Definition:

leaf display-mode { description "Controls how values are displayed during output to STDOUT or a log file."; type enumeration { enum plain { description "Plain identifier without any prefix format."; } enum prefix { description "Plain text with XML prefix added format."; } enum module { description "Plain text with module name as prefix added format."; } enum xml { description "XML format."; } enum xml-nons { description "XML format, but no namespace (xmlns) attributes will be generated."; } enum json { description "JSON format."; } enum cli { description "CLI format."; } }

Version 19.10-13


default plain; }

Plain Mode Example:

andy@localhost> sget /system/uname

Filling container /system/uname:RPC Data Reply 14 for session 3 [default]:

rpc-reply { data { system { uname { sysname Linux release 4.4.0-104-generic version '#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017' machine x86_64 nodename andy-2i7 } } }}

andy@localhost>

CLI Mode example:

andy@localhost> sget /system/uname

Filling container /system/uname:RPC Data Reply 15 for session 3 [default]:

rpc-reply data system uname sysname Linux release 4.4.0-104-generic version '#127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017' machine x86_64 nodename andy-2i7

andy@localhost>

Version 19.10-13


2.4 NETCONF Device Configuration

The yangcli-pro program can be configured to associate a name with a set of device parameters to start a NETCONF device with a server. These named devices are saved in a configuration file. Use the --autodevices to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.

By default, the devices configuration is saved in $HOME/.yumapro/yangcli_pro_devices.conf. To override this file, set --autodevices=false and use the devices-cfg command to load a specific devices configuration file.

2.4.1 Creating Devices

> device-cfg create=device-B server=192.168.0.57 protocols=netconf1.0

A new device is created: device-id=device-B name=device-B server=192.168.0.57

> device-cfg show=device-B

Device 'device-B':

server: 192.168.0.57

connected: false

2.4.2 Saving Devices

To save a device, the text configuration file can be edited or the 'device-cfg save' command can be used.

> connect user=andy server=myserver password=mypassword

... startup screen ...

andy@myserver> device-cfg save device-A

Saved current device as 'device-A'

andy@myserver>

2.4.3 Multiple Devices

Multiple devices can be active at once, however only one command at a time can be sent. This will be improved in a future release. Just use the start-session command to start a different session. Only one instance of each named session with its device can be active at the same time.

Version 19.10-13


2.4.4 Saving the Configured Devices

The device configuration can be saved or loaded at run-time, even if the --autodevices=true parameter is used (the default). The devices-cfg command is used to load and save this file.

session-A> devices-cfg save

Saved 2 sessions OK to '~/.yumapro/yangcli_pro_devices.conf'

session-A>

To save the devices to a different file, simply provide the filespec in the 'devices-cfg save' command:

session-A> devices-cfg save myusers.conf

Saved 2 devices OK to 'mydevices.conf'

session-A>

2.4.5 Loading Additional Configured Devices

Additional devices can be added to the configuration in memory with the 'devices-cfg load' command. The named devices in the file cannot conflict with names already in use or the duplicate devices will be skipped.

session-A> devices-cfg load devices.conf

Loaded 3 sessions OK from 'devices.conf'

session-A>

2.4.6 Displaying the Configured Devices

The devices that are available can be displayed with the 'devices-cfg show' command. The --brief and --full extensions are available for this command.

session-A> devices-cfg show

Saved devices source: '~/.yumapro/.yangcli_pro_devices.conf'

Device 'desktop': server: 10.0.0.7 connected: false

Device 'device-A': server: localhost

connected: false

Version 19.10-13


Device 'device-B': server: 192.168.0.57 connected: false

2.4.7 Displaying Devices

Displaying a Specific Device

To see information about a specific device, use the 'device-cfg show' command:

> device-cfg show device-A

Device 'device-A': server: localhost connected: false

Version 19.10-13


2.4.8 Saved Device Configuration File Format

The saved sessions are stored in a YumaPro configuration file.

The file contents must conform to the following YANG container definition:

container saved-devices { ncx:abstract; description "Represents all the saved devices in the ~/.yumapro/yangcli_pro_devices file. Use the 'devices' command to access this file. Edit by hand only if you follow this YANG definition.";

list device { description "The list of devices to use during this test-suite.";

key name;

leaf name { type nt:NcxName; description "The name of the saved device. The 'device save' command will use the string <user>@<server-address> as the default."; }

leaf devicetype { type string; description "Device type for NETCONF devices."; } leaf server { type inet:host; mandatory true; description "IP address or DNS name of the NETCONF server target.";

}

leaf ncport { type uint16 { range "1..max"; } default 830; description "NETCONF port number to use. If not present, then port 830, followed by port 22, will be tried."; }

uses ncxapp:ProtocolsParm; } }

Version 19.10-13


2.4.9 Device Configuration File Example

The following example file shows a valid device configuration file:

saved-devices device 'desktop' { server '10.0.0.7' ncport 830 protocols "netconf1.0 netconf1.1" } device 'device-A' { server 'localhost' ncport 830 protocols "netconf1.0 netconf1.1" } device 'device-B' { server '192.168.0.57' ncport 830 protocols "netconf1.1" } }

Version 19.10-13


2.5 NETCONF Schema Server Configuration

The yangcli-pro program can be configured to associate a name with a set of schema server parameters to start a NETCONF schema device with a server. These named schema servers are saved in a configuration file. Use the --autoschemaservers to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.

By default, the schema server configuration is saved in $HOME/.Malaprop/yangcli_pro_schema_servers.conf. To override this file, set --autoschemaservers=false and use the schema-servers-cfg command to load a specific schema server configuration file.

If a session that is starting up goes not support get-schema then yangcli will check its get-schema-servers list and do a special side session to that remote server to get the missing YANG modules. Leave the remote session open until all autoload is done then close it.

2.5.1 Creating New Schema Servers

A schema server is created with a saved device id and a saved user id.

Example: Use the saved user id of userA and the saved device id of deviceA to create a new schema-serverA.

> user-cfg show=userA User 'userA': user: admin password: fredlow connected: false

> device-cfg show=deviceA Device 'deviceA': server: 192.168.0.57 connected: false

> schema-server-cfg create=schema-serverA device-id=deviceA user-id=userA

A new schema_server is created: schema_server-id=schema-serverA name=schema-serverA device=deviceA device=userA

Version 19.10-13


2.5.2 Saving Schema Servers

To save schema servers, the text configuration file can be edited or the 'schema-servers-cfg save' command can be used.

> schema-servers-cfg save

Saved 1 schema_servers OK to '~/.yumapro/.yangcli_pro_schema_servers.conf'

> schema-server-cfg show=schema-serverA

Schema Server: schema-serverA Device Id: deviceA User Id: userA Connected: false

To save the schema servers to a different file, simply provide the filespec in the 'schema-servers-cfg save' command:

> schema-servers-cfg save=~/.yumapro/schema-servers.conf

Saved 3 schema_servers OK to '~/.yumapro/schema-servers.conf'

Version 19.10-13


2.5.3 Multiple Schema Servers

Multiple schema servers can be configured, only one schema server can be active. If a session that is starting up does not support get-schema then yangcli will check its get-schema-servers list and do a special side session to that remote server to get the missing YANG modules. Leave the remote session open until all autoload is done then closes it.

2.5.4 Displaying the Configured Schema Servers

The schema servers that are available can be displayed with the 'schema-servers-cfg show' command. The --brief and --full extensions are available for this command.

> schema-servers-cfg

Saved schema_servers source: '~/.yumapro/.yangcli_pro_schema_servers.conf'

Schema Server: schema-serverA

Device Id: deviceA

User Id: userA

Connected: false

Schema Server: schema-server-ACER

Device Id: device-ACER

User Id: user-ACER

Connected: false

Schema Server: schema-server-asus2

Device Id: asus2-device

User Id: asus2

Connected: false

2.5.5 Displaying A Schema Server

Displaying a Specific Schema Server

To see information about a specific device, use the 'schema-server-cfg show' command:

> schema-server-cfg show=schema-serverA

Schema Server: schema-serverA Device Id: deviceA User Id: userA Connected: false

Version 19.10-13


2.5.6 Saved Schema Server Configuration File Format

The saved schema servers are stored in a YumaPro configuration file.


container saved-schema-servers { ncx:abstract; description "Represents all the saved schema-servers in the ~/.yumapro/yangcli_pro_schema_server file. Use the 'schema-server' command to access this file. Edit by hand only if you follow this YANG definition.";

list schema-server-id { description "The list of schema-servers to use."; key name;

leaf name { type nt:NcxName; description "The id of the saved server."; }

leaf user-id { type nt:NcxName; description "The id of the saved user."; }

leaf device-id { type nt:NcxName; description "The id of the saved device."; }

} }

Version 19.10-13


2.5.7 Schema Server Configuration File Example

The following example file shows a valid schema server configuration file:

saved-schema-servers { schema-server-id 'schema-serverA' { user-id 'userA' device-id 'deviceA' } schema-server-id 'schema-server-ACER' { user-id 'user-ACER' device-id 'device-ACER' } schema-server-id 'schema-server-asus2' { user-id 'asus2' device-id 'asus2-device' } }

Version 19.10-13


2.6 NETCONF User Configuration

The yangcli-pro program can be configured to associate a name with a set of user parameters to start a NETCONF user with a server. These named users are saved in a configuration file. Use the --autousers to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.

By default, the users configuration is saved in $HOME/.yumapro/yangcli_pro_users.conf. To override this file, set --autousers=false and use the users-cfg command to load a specific users configuration file.

2.6.1 Creating New Users

To create a new user, use the 'user-cfg create' command.

> user-cfg create=usr1 user-name=admin password=adminA new user is created: user-id=usr1 name=admin password=admin

> user-cfg show usr1 User 'usr1': user: admin password: admin connected: false >

2.6.2 Saving Users

To save a user, the text configuration file can be edited or the 'user-cfg save' command can be used.



andy@myserver> user-cfg save user-A

Saved current user as 'user-A'

andy@myserver>

Version 19.10-13


2.6.3 Multiple Users

Multiple users can be active at once, however only one command at a time can be sent. This will be improved in a future release. Just use the start-session command to start a different session. Only one instance of each named session with its user can be active at the same time.

2.6.4 Saving the Configured Users

The user configuration can be saved or loaded at run-time, even if the --autousers=true parameter is used (the default). Theusers-cfg command is used to load and save this file.

session-A> users-cfg save

Saved 2 sessions OK to '~/.yumapro/yangcli_pro_users.conf'

session-A>

To save the user to a different file, simply provide the filespec in the 'users-cfg save' command:

session-A> users-cfg save myusers.conf

Saved 2 users OK to 'myusers.conf'

session-A>

2.6.5 Loading Additional Configured Users

Additional users can be added to the configuration in memory with the 'users-cfg load' command. The named users in the file cannot conflict with names already in use or the duplicate users will be skipped.

session-A> users-cfg load users.conf

Loaded 3 sessions OK from 'users.conf

Version 19.10-13


2.6.6 Displaying the Configured Users

The users that are available can be displayed with the 'users-cfg show' command. The --brief and --full extensions are available for this command.

session-A> users-cfg show

Saved users source: '~/.yumapro/.yangcli_pro_users.conf' User 'userA': user: userNameA password: password A connected: false

User 'userB': user: userNameB password: password B connected: false

User 'userC': user: userNameC password: password C connected: false

2.6.7 Displaying Users

Displaying a Specific User

To see information about a specific user, use the 'user-cfg show' command:

> user-cfg show userA User 'userA': user: userNameA password: password A connected: false

Version 19.10-13


2.6.8 Saved User Configuration File Format



container saved-users { ncx:abstract; description "Represents all the saved users in the ~/.yumapro/yangcli_pro_users file. Use the 'users' command to access this file. Edit by hand only if you follow this YANG definition.";

list userid { description "The list of users to use.";

key name;

leaf name { type nt:NcxName; description "The id of the saved user."; }

leaf user { type nt:NcxName; mandatory true; description "The user name of the session."; }

choice pass { mandatory true; leaf password { type string; ncx:password; description "User password to use for NETCONF users. If none, then user will be prompted before connecting."; } leaf no-password { type empty; } } uses SshKeyParms; uses SslKeyParms; } }

Version 19.10-13


2.6.9 User Configuration File Example

The following example file shows a valid user configuration file:

saved-users { userid 'userA' { user 'userNameA' password 'passwordA' public-key '$HOME/.ssh/id_rsa.pub' private-key '$HOME/.ssh/id_rsa' ssl-fallback-ok true ssl-trust-store '$HOME/.ssl/trust-store.pem' ssl-key '$HOME/.ssl/yangapi-client.key' ssl-certificate '$HOME/.ssl/yangapi-client.crt' } userid 'userB' { user 'userNameB' password 'passwordB' public-key '$HOME/.ssh/id_rsa.pub' private-key '$HOME/.ssh/id_rsa' ssl-fallback-ok true ssl-trust-store '$HOME/.ssl/trust-store.pem' ssl-key '$HOME/.ssl/yangapi-client.key' ssl-certificate '$HOME/.ssl/yangapi-client.crt' } }

Version 19.10-13


2.7 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 automaticloading of this file. The default is to load this file at start-up and save it upon exit.

By default, the sessions configuration is saved in $HOME/.yumapro/yangcli_pro_sessions.conf. To override this file, set --autosessions=false and use the sessions-cfg command to load a specific sessions configuration file.

The start-session command is used to start a named session:

> start-session session-A


session-A>

2.7.1 Saving Sessions

To save a session, the text configuration file can be edited or the 'session-cfg save' command can be used.



andy@myserver> session-cfg save session-A

Saved current session as 'session-A'

andy@myserver>

Version 19.10-13


2.7.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 canbe 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.7.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.

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>

Version 19.10-13


2.7.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>

2.7.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>

Version 19.10-13


2.7.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

Version 19.10-13


2.7.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


Displaying a Specific Session

To see information about a specific session, use the 'session-cfg show' command:

session-A> session-cfg show session-B


session-A>

Version 19.10-13


2.7.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

>

Version 19.10-13


2.7.9 Saved Session Configuration File Format



container saved-sessions { description "Represents all the saved sessions in the ~/.yumapro/yangcli_pro_sessions file. Use the 'sessions' command to access this file. Edit by hand only if you follow this YANG definition."; list session { description "The list of sessions to use during this test-suite.";

key name;

leaf name { type nt:NcxName; description "The name of the saved session. The 'session save' command will use the string <user>@<server-address> as the default."; }

leaf 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.";

Version 19.10-13


}

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 19.10-13


2.7.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 public-key $HOME/.ssh/id_rsa.pub private-key $HOME/.ssh/id_rsa server localhost ncport 830 protocols "netconf1.0 netconf1.1" } session A { user andy2 password newpassword public-key $HOME/.ssh/id_rsa.pub private-key $HOME/.ssh/id_rsa server localhost ncport 830 protocols "netconf1.0 netconf1.1" }}

Version 19.10-13


2.8 NETCONF Group Configuration

The yangcli-pro program can be configured to manage the session groups. It associates a group name with a set of sessionsto 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 suppress automatic loadingof this file. The default is to load this file at start-up and save it upon exit.

By default, the group configuration is saved in $HOME/.yumapro/yangcli_pro_sessions.conf. To override this file, set --autosessions=false and use the sessions-cfg command to load a specific sessions configuration file.

2.8.1 Create group

The group command is used to create a group. The 'session' parameter must also be present.

Example of 'group create':

> group create=AB session=session-A session=session-B

> group create=a1a2a3 session=a1 session=a2 session=a3

Version 19.10-13


2.8.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' This group is not connected. missing-ok: false missing-connect-ok: false lost-ok: false

reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 0 number_of_sessions: 3 Session 'a1' connected:false Session 'a2' connected:false Session 'a3' connected:false <

2.8.3 Delete group

The group delete command is used to delete a group.

> group delete=AB

> group delete=a1a2a3

> group list

No groups found

>

Version 19.10-13


2.8.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' 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

2.8.5 Remove Group

The group remove command is used to remove the sessions from a name group. The 'session' parameter must also be present.

> group remove=AB session=session-A > group list Group 'AB' This group is not connected. missing-ok: false missing-connect-ok: false lost-ok: false reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 0 number_of_sessions: 1 Session 'session-B' connected:false

Version 19.10-13


2.8.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' This group is not connected. missing-ok: false missing-connect-ok: false lost-ok: false reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 0 number_of_sessions: 1 Session 'session-B' connected:false>

Version 19.10-13


2.8.7 Connect Group

The group connect command is used to start a named group with session group parameters: lost-ok, missing-connect-ok, missing-ok, reconnect-interval, and reconnect-tries.

The default parameters value are false.

> group connect=AB yangcli-pro: Starting NETCONF session for andy on localhost over ssh on port 830 NETCONF session established for xxxxx on localhost ... startup screen ...

AB> Client Session Id: 1 Server Session Id: 1 --------- --------- ---------

NETCONF session established for xxxxx on localhost ... startup screen ...

AB> Client Session Id: 2 Server Session Id: 2 --------- --------- --------- AB> group list Group 'AB' This group is fully connected. missing-ok: false missing-connect-ok: false lost-ok: false reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 2 number_of_sessions: 2 Session 'session-A' connected:true Session 'session-B' connected:true

Version 19.10-13


2.8.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] Indicates the number of seconds yangcli will wait to re-establish a connection i... leaf create [NcxIdentifier] Name of the group to create. The 'session' parameter must also be present

leaf delete [NcxIdentifier] Name of the group to delete

leaf add [NcxIdentifier] Name of the group to add some sessions. The 'session' parameter must also be presen...

leaf remove [NcxIdentifier] Name of the group to remove some sessions. The 'session' parameer must also be pres...

leaf show [NcxIdentifier] Name of the group to show

leaf list [empty] List the names of all the groups saved-sessions { leaf-list session [NcxIdentifier] <Mandatory> Name of a session that is being added to the group. >

Version 19.10-13


2.8.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 protocols "netconf1.0 netconf1.1" } session 'session-B' { user 'andy' password 'xxxxx' public-key '$HOME/.ssh/id_rsa.pub' private-key '$HOME/.ssh/id_rsa' server 'localhost' ncport 830 protocols "netconf1.0 netconf1.1" } group 'AB' { missing-connect-ok false missing-ok false lost-ok false reconnect-interval 30 reconnect-tries 5 session 'session-A' session 'session-B' } }

2.8.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>

Version 19.10-13


2.9 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.

By default, a NETCONF over SSH session will be started.

Use the parameter transport=tls in the “connect” command to start a NETCONF over TLS session.

When a NETCONF session starts up, a <capability> exchange is done, and the server reports exactly what content it supports. This information is used extensively to customize the session, and report errors and warnings for the session.

2.9.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:

NETCONF session established for user on localhost

Client Session Id: 1 Server Session Id: 1

Server Protocol Capabilities base:1.0 candidate:1.0 confirmed-commit:1.0 rollback-on-error:1.0 validate:1.0 url:1.0 xpath:1.0

Version 19.10-13


notification:1.0 interleave:1.0 partial-lock:1.0 with-defaults:1.0 base:1.1 validate:1.1 confirmed-commit:1.1 yang-library:1.0

Server Module Capabilities ietf-netconf@2011-06-01 ietf-inet-types@2013-07-15 ietf-netconf-acm@2012-02-22 ietf-netconf-monitoring@2010-10-04 ietf-netconf-notifications@2012-02-06 ietf-netconf-partial-lock@2009-10-19 ietf-netconf-with-defaults@2011-06-01 ietf-yang-library@2016-06-21 ietf-yang-types@2013-07-15 nc-notifications@2008-07-14 notifications@2013-03-15 yang-attributes@2013-02-18 yuma-app-common@2012-08-16 yuma-arp@2012-01-13 yuma-interfaces@2012-01-13 yuma-mysession@2013-10-05 yuma-ncx@2013-09-23 yuma-proc@2013-07-16 yuma-system@2013-07-15 yuma-time-filter@2012-11-15 yuma-types@2012-06-01 yumaworks-event-filter@2014-02-09 yumaworks-extensions@2014-06-05 yumaworks-ids@2014-07-12 yumaworks-sil-sa@2014-05-15 yumaworks-system@2014-05-27 yumaworks-types@2013-02-11 yumaworks-ycontrol@2014-04-08

Server Enterprise Capabilities urn:yumaworks:params:xml:ns:netconf:config-id?id=7865

Protocol version set to: RFC 6241 (base:1.1) Default target set to: <candidate> Save operation mapped to: commit Default with-defaults behavior: explicit Additional with-defaults behavior: trim,report-all,report-all-taggedYang-Library set to: RFC 7895 module-set-id: 6765

Version 19.10-13


2.9.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.

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.

Version 19.10-13


2.9.3 Retrieving Data

There are 8 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

sget-data high-level subtree filter, using the <get-data> protocol operation

xget high-level XPath filter, using the <get> protocol operation

xget-config high-level XPath filter, using the <get-config> protocol operation

xget-data high-level XPath filter, using the <get-data> protocol operation

All the high-level retrieval operations support the $$with-defaults system variable. The <with-defaults> parameter will be added the the NETCONF PDU if this variable is set to a value other than 'none' (the default). This system variable will be used as the default if not entered directly.

session1> sget /system --with-defaults=$$with-defaults

This parameter can also be specified directly, each time the command is used.

session1> xget-config //ifMtu --with-defaults=trim

The $$bad-data system variable is used to control how invalid operations and data are sent to the server. The xget and xget-config commands are affected by this parameter. If the :xpath capability was not advertised by the server when the session started, an error or warning may occur if these commands are used.

If any data is received that yangcli-pro does not understand, then a warning message will be printed and the data will be treated as if it was defined with the YANG 'anyxml' data type.

Version 19.10-13


2.9.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 theenumeration '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


session1> $newvalue = 1518

session1> replace /interfaces/interface[name='eth0']/ifMtu \--test-option=test-only \--value=$newvalue

Version 19.10-13


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


session1> replace /interfaces/interface[name='eth0']/ifMtu \--error-option=rollback-on-error \--value=1518

The high level save command is mapped to other commands, depending on the capabilities reported by the server.

save command

capabilities real command(s)

:candidate commit

:writable-running <none>

:startup copy-config --source=running \ --target=startup

Version 19.10-13


2.9.5 Using Notifications

The create-subscription command is used to start receiving notifications.

The netconfd-pro server will include a <sequence-id> element in any notification that is saved in the replay buffer. This unsigned integer can be used to help debug notification filters (i.e., if non-consecutive <sequence-id> values are received, then the notification was filtered, or dropped due to access control policy).

If any replay notifications are desired, then the --startTime parameter must be included. At the end of the stored notifications, the server will send the <replayComplete> event. This notification type is not saved, and will not be found in the server replay buffer, if replay is supported by the server. The netconfd-pro server will not include a <sequence-id> element in this notification type.

If the notification subscription should stop at a certain time, then the --stopTime parameter must be included. At the end ofthe 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.

Version 19.10-13


2.9.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 doesnot 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'.

Version 19.10-13


2.9.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

◦ try to 'ping' the server and see if it responds

• make sure the SSH server is responding

◦ try to login in to the server using normal SSH login on port 22

• make sure a firewall is not blocking TCP port 830

◦ try to connect to the NETCONF server using the --port=22 option

• make sure the netconf-subsystem is configured correctly in /etc/ssh/sshd_configthere should be the proper configuration commands for NETCONF to work. For example, the netconfd-pro serverconfiguration might look like this:

Port 22Port 830Subsystem 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

Version 19.10-13


If the NETCONF server is not accepting a certain command:

• make sure the command (or parameters used in the command) is actually supported by the server.

◦ There may be features, when statements, or deviation statements that indicate the server does not support the command or one or more of its parameters.

• make sure that access control configured on the server is not blocking the command. The error-tag should be 'access-denied' in this case.

If the NETCONF server is not returning the expected data in a <get> or <get-config> protocol operation::

• Make sure all the parameters are supported by the server

◦ the :xpath capability must be advertised by the server to use the 'select' attribute in the <get> or <get-config> operations

◦ the :with-defaults capability must be advertised by the server to use the <with-defaults> parameter

• if using a filter, try to retrieve the data without a filter and see if it is there

• make sure that access control configured on the server is not blocking the retrieval. There will not be any error reported in this case. The server will simply skip over any unauthorized data, and leave it out of the <rpc-reply>.

• set the logging level to debug2 or higher, and look closely at the PDUs being sent to the server. Set the display mode to a value other than 'plain' to make sure the correct namespaces are being used in the request.

If an <edit-config> operation is failing unexpectedly:

• make sure that access control configured on the server is not blocking the request. The error-tag should be 'access-denied' in this case.

• make sure an unsupported parameter or parameter value is not used

◦ <test-option> is not supported unless the :validate capability is advertised by the server

◦ <error-option> = 'rollback-on-error' is not supported unless the :rollback-on-error capability is advertised by the server

• if the request contains an edit to a nested data structure, make sure the parent data structure(s) are in place as expected. The <default-operation> parameter is set to 'none' in the high level editing operations, so any data 'above' the edited data must already exist.

• set the logging level to debug2 or higher, and look closely at the PDUs being sent to the server. Set the display mode to a value other than 'plain' to make sure the correct namespaces are being used in the request.

Version 19.10-13


2.10 Automated Testing

Automated regression testing is provided using test-suite templates to describe actions and expected responses and results. The test-suite command is used to access this feature.

Tests rely on named sessions in order to send commands from different sessions. Each test step can be directed at a different session. The “locking” example in a later section shows how test step commands can be either expected to succeed (e.g., first session attempts <lock> command) and fail (e.g., second session attempts <lock> but the datastore is already locked).

A test suite that only needs to send commands to the current session does not need to use named sessions. The session connection and shutdown steps do not need to be done in the test-suite.

The start-session command is usually used within the setup section for each session required in all of the tests within the test-suite. The server must already be running. (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 filesyntax 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.

Version 19.10-13


2.10.1 Test Templates

The test suite file structure is shown below:

• test-suite-file: collection of test-suites in a single file. Multiple files can be loaded. If the --autotest CLI parameter is 'true' (default) then yangcli-pro will look for the default test file, called $HOME/.yumapro/yangcli_pro_tests.conf.

• test-suite: collection of tests. Each test-suite has an optional 'setup' section which is executed once before the tests are run, and an optional 'cleanup' section that is run after all the tests have run

• test: collection of steps to perform a specific test

• step: a command to be executed locally or remotely to a specified session. Each step for a remote command can be configured to check the server response received.

Version 19.10-13


2.10.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 <[email protected]>";

description "This module contains data structures representing 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;

Version 19.10-13


leaf name { type yt:NcxName; description "The test suite name."; }

leaf description { type string; description "Description of this test suite."; }

container setup { ywx:cli-text-block; description "Test suite setup commands"; }

container cleanup { ywx:cli-text-block; description "Test suite cleanup commands"; }

leaf-list run-test { ordered-by user; type yt:NcxName; min-elements 1; description "The ordered list of test names to run in this test suite. At least 1 test must be specified."; } list test { description "The unit-tests that are configured to be run. At least 1 test must be configured."; ordered-by user; min-elements 1; key name;

leaf name { type yt:NcxName; description "The name of this unit test."; }

leaf description { type string; description "Description of this unit test."; }

leaf-list must-pass { type yt:NcxName; description "The names of the tests that have already been run and pased for this test to be attempted, The test will be skipped if any test in the must-pass list has been attempted and the test failed.

If the named test has not been run yet this test will fail and be skipped. If the named test was skipped, then it will not cause this test to be skipped, only if it did not run at all or if it ran and passed."; }

Version 19.10-13


list step { description "A list of test steps to be done in order."; ordered-by user; key name;

leaf name { type string { length "1 .. 64"; } description "The name of this unit test step."; }

leaf description { type string; description "Description of this unit test step."; }

leaf session-name { type yt:NcxName; description "The name of the session to use. Empty if the test session should be used"; }

leaf result-type { type response-type; description "The expected response type. If this leaf is missing then any response type is acceptable."; }

leaf result-error-tag { 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 { must "../result-type = 'error'"; type string; description "The error-app-tag value expected if the result-type is 'error'. If not set, then any error-app-tag value is acceptable."; }

leaf-list result-error-info { must "../result-type = 'error'"; type yt:NcxName; description "The error-info element name expected if the result-type is 'error'."; }

leaf command { type string; mandatory true; description "The yangcli command line string to use";

Version 19.10-13


}

/**** !!!! 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 19.10-13


2.10.3 RPC Reply Testing

Each step has a “response-type” field that specifies what kind of RPC reply testing is expected.

• none: Do not perform any RPC reply testing, or this step does not send an RPC request to a server

• ok: An RPC reply is expected with an <ok> response

• data: An RPC reply is expected with some sort of data response. The expected response is stored in an XML file and compared to the actual RPC reply when the step is exectured

◦ Initial files are created automatically during the “record-test” procedure.

◦ The files are stored in the $HOME/.yumapro/recordtest directory.

◦ Each filename has the form <suite-name>_<test-name>_<step-number>_record.xml

◦ During the test a temporary file will be created for each data file to save the RPC reply. These files will be deleted when the test suite is completed.

◦ Each file contains a single <rpc-reply> element.

◦ These files can be edited, created, by hand, or even deleted.

◦ Wildcard fields can be used in this file to allow any value to match, removing this node from the comparison test.

• error: An RPC reply is expected with an <rpc-error> response

◦ error-tag: The expected error-tag in the <rpc-error> response

◦ error-app-tag: The expected error-app-tag in the <rpc-error> response

◦ result-error-info: A list of names of elements expected in the <error-info> container within the <rpc-error> response

Version 19.10-13


2.10.4 Using Wildcards in Data Response Testing

It is possible simply test for a node within the RPC reply instead of comparing its actual value. Some data such as timestamps and counters may change on every retrieval. Such a node can cause the entire step to fail when comparing the <rpc-reply> contents.

The wildcard string is a sequence of 5 characters (underscore, asterisk, asterisk, asterisk, underscore)

_***_

If this string is used as the value for an element, then that node will be skipped in the comparison.

Example Step:

• Suite: s1

• Test: t1

• Step: 2

• Command: sget /netconf-state/datastores

• File: $HOME/.yumapro/recordtest/s1_t1_2_record.xml

Original Data File Created During record-test:

<?xml version="1.0" encoding="UTF-8"?><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <datastores> <datastore> <name>candidate</name> <last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">2019-12-05T23:21:27Z</last-modified> </datastore> <datastore> <name>running</name> <last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">2019-12-05T23:21:27Z</last-modified> </datastore> </datastores> </netconf-state> </data></rpc-reply>

Altered Data File Wild Wildcard Strings:

Version 19.10-13


<?xml version="1.0" encoding="UTF-8"?><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <datastores> <datastore> <name>candidate</name> <last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">_***_</last-modified> </datastore> <datastore> <name>running</name> <last-modified xmlns="http://netconfcentral.org/ns/yuma-time-filter">_***_</last-modified> </datastore> </datastores> </netconf-state> </data></rpc-reply>

Version 19.10-13


2.10.5 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" session-name session-A result-type ok

Version 19.10-13


command "merge /uint8.1 value=10" }

step 4 { description "session B tries to write to the target config candidate is not locked so this should work" session-name session-B result-type ok command "merge /uint8.1 value=12" }

step 5 { description "session B tries to commit the candidate to running running is locked so this should fail" session-name session-B result-type error result-error-tag in-use command "commit" } step 6 { description "session A tries to lock the candidate config this should fail since the candidate is dirty" session-name session-A result-type error result-error-tag resource-denied command "lock target=candidate" } step 7 { description "session B tries to lock the candidate config this should fail since the candidate is dirty" session-name session-B result-type error result-error-tag resource-denied command "lock target=candidate" }

step 8 { description "session B issues a discard-changes" session-name session-B result-type ok command "discard-changes" } step 9 { description "session A issues a discard-changes" session-name session-A result-type ok command "discard-changes" } step 10 { description "session B locks the candidate config" session-name session-B result-type ok command "lock target=candidate" } step 11 { description "session A tries to lock the candidate config, which should fail because it is already locked" session-name session-A

Version 19.10-13


result-type error result-error-tag lock-denied result-error-info session-id command "lock target=candidate" }

step 12 { description "session A tries to write to the target config, which could fail because candidate is locked" session-name session-A result-type error result-error-tag in-use command "merge /uint8.1 value=10" }

step 13 { description "session B tries to write to the target config" session-name session-B result-type ok command "merge /uint8.1 value=12" }

step 14 { description "session A tries to commit the candidate to running, candidate is locked by B so this should fail" session-name session-A result-type error result-error-tag in-use command "commit" }

step 15 { description "session B tries to commit the candidate to running, running is locked by A so this should fail" session-name session-B result-type error result-error-tag in-use command "commit" }

step 16 { description "session A tries to discard-changes, candidate is locked by B so this should fail" session-name session-A result-type error result-error-tag in-use command "discard-changes" }

step 17 { description "session A tries to unlock candidate, candidate is locked by B so this should fail" session-name session-A result-type error result-error-tag in-use command "unlock target=candidate" }

step 18 { description "session B tries to unlock running, which is locked by A so this should fail" session-name session-B result-type error

Version 19.10-13


result-error-tag in-use command "unlock target=running" }

step 19 { description "session B unlocks candidate" session-name session-B result-type ok command "unlock target=candidate" }

step 20 { description "session A unlocks candidate" session-name session-A result-type ok command "unlock target=running" }

step 21 { description "session A commits nothing due to discard-changes from B" session-name session-A result-type ok command "commit" }

} } }

Version 19.10-13


2.11 Call Home Server

The yangcli-pro program supports the IETF NETCONF Call Home feature defined in RFC 8071.

Call Home for NETCONF over SSH Port Assignment:

Service Name: netconf-ch-sshPort Number: 4334Transport Protocol(s): TCPDescription: NETCONF Call Home (SSH)Assignee: IESG <[email protected]>Contact: IETF Chair <[email protected]>Reference: RFC 8071

Call Home for NETCONF over TLS Port Assignment:

Service Name: netconf-ch-tlsPort Number: 4335Transport Protocol(s): TCPDescription: NETCONF Call Home (TLS)Assignee: IESG <[email protected]>Contact: IETF Chair <[email protected]>Reference: RFC 8071

A server implementing Call Home will initiate the TCP connection for a NETCONF session to a pre-configured manager (e.g., yangcli-pro), which will start a normal SSH session for NETCONF, but using the incoming TCP connection instead ofcreating a new connection.

In Call Home Server mode, yangcli-pro will listen for incoming TCP connections on its Call Home port.

There must be pre-configured user or session entries for yangcli-pro to accept an incoming Call Home session.

Version 19.10-13

https://trac.tools.ietf.org/html/rfc8071

https://tools.ietf.org/html/rfc8071


2.11.1 Call Home Configuration

The following CLI parameters are available to Call Home configuration:

• callhome-address (default 0.0.0.0)

• callhome-enabled (default false)

• callhome-port (default 4334)

• callhome-tls-port (default 4335)

• callhome-user (no default)

1. This feature has to be enabled by setting –callhome-enabled=true in the configuration or command line.

2. If the default listen address (all IPv4 addresses) is not desired, then the –callhome-address parameter must be configured.

3. If the default TCP port number (4334) is not desired for NETCONF over SSH, then the –callhome-port parameter must be set.

4. If the default TCP port number (4335) is not desired for NETCONF over TLS, then the –callhome-tls-port parameter must be set.

5. One or more named sessions may be configured to use address-specific session configuration. The “session-cfg save” command can be used to save a current session. This mode requires the client to be able to connect to the desired server.

6. One named user entry can be be designated the “callhome-user” entry. The “user-cfg save” command can be used to create a suitable user entry. Then the –calhome-user parameter is set to session name. In this mode the client does not need to connect to the desired server first, but the user and credentials need to be pre-configured on the NETCONF server in advance.

2.11.2 Call Home Accept Session Procedure

If --callhome-enabled=true then yangcli-pro will listen for callhome sessions.

When an incoming call home connection is received, yangcli-pro will attempt to start a new NETCONF session in the following manner:

1. The source IP address is checked against the IP address of any named session configurations. If a match is found, that session will be used. If it is already in use then the incoming session will be rejected.

2. If no matching IP address session entry found, then check if a callhome-user entry is configured. If so, then create atemporary session using the user-cfg data and the incoming address information for the server configuration.

3. If no callhome-user entry is configured then the incoming connection is dropped

Version 19.10-13


2.12 Privilege Mode In YP-Shell Enable Mode

The yangcli-pro program supports a privileged mode in the yp-shell enable mode.

If CLI parameter of “with-enable-mode=true” is used, the user must enter the command "enable" and provide the password if configured before they gain a privilege exec mode to change the configuration of the server. The command “config term” will only be present in enable mode. Within enable mode, the 'config term' command is used to enter configuration mode.

Use 'enable' to enter ‘enable mode’, use 'enable password' to create a password, and use ‘enable no-password’ to delete the password.

The command of enable password is used to configure a password and store it in the $HOME/.yumapro/.yangcli_password.pswd file. After a password is configured, the privilege mode will be enabled and the password file will be saved. Any time the user enters the enable mode, the user is prompted for the password instead of just going to the enable mode right away.

The command of enable no-password will delete the configured password and the $HOME/.yumapro/.yangcli_password.pswd file. The privilege mode will be disabled.

If the server does a factory restart then the .yangcli_password.pswd file will be deleted by the server and password will be removed. The privilege mode will be disabled.

The command of enable is only for the yp-shell. The yangcli-pro (client mode) does not have this command.

If CLI parameter of 'with-enable-mode=false', or not used, the command “config term” will be present and the commandof 'enable', ‘enable password’, and 'enable no-password' will not be present.

Version 19.10-13


2.12.1 enable

Use enable command to enter enable mode. The enable command will cause the # prompt. The only commands supportedin this mode will be "exit" and "config term". The config term mode entered from the enable mode will have prompt of (config)# instead of the normal yp-shell config mode prompt.

./yp-shell with-enable-mode=true –restrict-edit-mode=true

abierman@andy-u14> show vars | include with-enable-mode with-enable-mode true

abierman@andy-u14> show vars | include restrict-edit-mode restrict-edit-mode true

abierman@andy-u14>abierman@andy-u14> enable <TAB>no-password passwordabierman@andy-u14> help enable full

enable Use 'enable' to enter enable mode for yp-shell. Use 'enable password' to configure the password. Use 'enable no-password' to remove the password.

If a password has been set, then it will be required to enter enable mode. input choice pass leaf password [string] Configure the password.

leaf no-password [empty] Remove the password.

abierman@andy-u14> enableabierman@andy-u14#<TAB>config exit

abierman@andy-u14#thue@andy-u14# config tabierman@andy-u14(config)#

abierman@andy-u14(config)# int8.1 8

abierman@andy-u14(config)# do show runningnc:rpc-reply { data { t:int8.1 8 }}

abierman@andy-u14(config)# exitabierman@andy-u14#abierman@andy-u14# exitabierman@andy-u14>

Version 19.10-13


2.12.2 enable password

Use enable password to configure a password. After enable password is configured, the user will be prompted for the password instead of just going to enable mode right away.

abierman@andy-u14> enable password=xxxxxxxxxRe-enter password:Enable password entered

abierman@andy-u14> enableEnter password:xxxxxxxxx

abierman@andy-u14# config tabierman@andy-u14(config)# exitabierman@andy-u14# exit

abierman@andy-u14> enableEnter password:xxxxxxxxx

abierman@andy-u14#

Version 19.10-13


2.12.3 enable no-password

Use enable no-password to deleted the configured password. After enable no-password, the user enters enable mode without getting prompted for password.

abierman@andy-u14>enable no-passwordEnable password entered:xxxxxxxxxEnable password removed

abierman@andy-u14> enable

abierman@andy-u14# <TAB>abierman@andy-u14# config exit

Version 19.10-13


2.13 Privilege Mode In YP-Shell Config Mode

The yangcli-pro program supports a privileged mode in the yp-shell config mode.

The CLI command of enable-password is used to configure a password and store it in the $HOME/.yumapro/.yangcli_password.pswd file. After a password is configured, the privilege mode will be enabled and the password file will be saved. Any time the user enters the config mode, the user is prompted for the password instead of just going to the config mode right away.

The “no” form of this command will remove the configured password and the $HOME/.yumapro/.yangcli_password.pswd file. The privilege mode will be disabled.

If the server does a factory restart then the .yangcli_password.pswd file will be deleted by the server and password will be removed. The privilege mode will be disabled.

The command of enable-password is only for the yp-shell. The yangcli-pro (client mode) does not have this command.

Version 19.10-13


2.13.1 Enable Privilege Mode

Use enable-password in the config mode to enable the privilege mode .There is no echo for the password (Example: fredlow2018) typed.After enable-password is set, the user will be prompted for the password instead of just going to config mode right away.

abierman@andy-u14> config tabierman@andy-u14# abierman@andy-u14# enable-passwordEnter string value for leaf <password>abierman@andy-u14:enable-password#Re-enter password: Enable password enteredabierman@andy-u14#

Re-enter config mode after enable-password is set. The user will be prompted for the password instead of just going in to config mode right away. There is no echo for the password typed.

abierman@andy-u14# abierman@andy-u14# exitabierman@andy-u14> config tEnter password:abierman@andy-u14#

Restart yp-shell after enable-password is set.

abierman@andy-u14# exitabierman@andy-u14> qabierman@andy-u14:~/swdev/ypwork/netconf/target/bin$ ./yp-shellabierman@andy-u14> config tEnter password: abierman@andy-u14#

Version 19.10-13


2.13.2 Disable Privilege Mode

Use no enable-password in config mode to disable the privilege mode .After no enable-password, the user enters config mode without getting prompted for password.

abierman@andy-u14# no enable-passwordEnable password removedabierman@andy-u14# exit

abierman@andy-u14> config tabierman@andy-u14#abierman@andy-u14# exit

abierman@andy-u14> qabierman@andy-u14:~/swdev/ypwork/netconf/target/bin$ ./yp-shell

abierman@andy-u14> config tabierman@andy-u14#

Version 19.10-13


2.14 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.14.1 action

The action command is a high-level operation to invoke a YANG 1.1 action. This is essentially an RPC operation that is specific to a data resource. It is defined within a YANG container or list. It is used to invoke data model specific actions that are unrelated to editing.

A target node must be an action, and then any missing key leafs (if any) within the data structure are filled in. If the specified action node has input parameters, they will be filled in.

A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true' or the –optional parameter is provided.

Refer to the fill command for more details on interactive mode data structure completion.

create command

Command type: remote

Default parameter: target

Min parameters: 1

Max parameters: 5

Return type: status

YANG file: yangcli-pro.yang

Capabilities needed: :candidate or :writable-running

Command Parameters:

• choice 'from' (not entered)

◦ type: choice of case 'varref' or case 'from-cli'

◦ usage: mandatory

◦ default: none

Version 19.10-13


◦ This parameter specifies the where yangcli-pro should get the data from, for the action. It is either a user variable or from interactive input at the command line.

▪ varref

• type: string

• usage: mandatory

• default: none

• This parameter specifies the name of the user variable to use for the target of the action. The parameter must exist (e.g., created with the fill command) or an error message will be printed.

▪ case from-cli (not entered)

• target

◦ type: string


◦ default: none

◦ This parameter specifies the database target node of the action. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

• urltarget

◦ type: string

◦ usage: optional

◦ default: none

◦ This parameter specifies the database target node of the action. This is an UrlPath string.

• optional

◦ type: empty

◦ usage: optional

◦ default: controlled by $$optional system variable

◦ This parameter controls whether optional nodes within the target will be filled in. It can be used to override the $$optional system variable, when it is set to 'false'.

• value

◦ type: anyxml


◦ default: none

◦ TBD: THIS PARAMETER IS NOT SUPPORTED YET

▪ This parameter specifies the value that should be used for the contents of the input parametersfor the action. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false').

• timeout

Version 19.10-13


◦ type: uint32 (0 = no timeout, otherwise the number of seconds to wait)

◦ usage: optional

◦ default: set to the $$timeout system variable, default 30 seconds

◦ This parameter specifies the number of seconds to wait for a response from the server before giving up. The session will not be dropped if a remote command times out, but any late response will be dropped. A value of zero means no timeout should be used, and yangcli-pro will wait forever for a response.

Positive Response:

• the server returns <ok/>

Negative Response:

• An error message will be printed if errors are detected locally.

• An <rpc-error> message will be printed if the server detected an error.

Usage:

YANG Module Example:

module act1 { yang-version 1.1; namespace "http://netconfcentral.org/ns/act1"; prefix a; revision "2017-10-14";

container objs { config false; list obj { key "idx"; leaf idx { type int32; } leaf col1 { type string; } action draw { description "Draw this object"; input { leaf i { type uint32; mandatory true; } leaf j { type uint32; } } } } }}

Invoke “draw” action:

andy@localhost> action /objs/obj[idx="10"]/draw

Filling mandatory action /objs/obj/draw:Enter uint32 value for leaf <i>andy@localhost:action> 10

RPC OK Reply 2 for session 3 [default]:

andy@localhost>

Version 19.10-13


XML sent to NETCONF server:

<?xml version="1.0" encoding="UTF-8"?><rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action xmlns="urn:ietf:params:xml:ns:yang:1"> <objs xmlns="http://netconfcentral.org/ns/act1"> <obj> <idx>10</idx> <draw> <i>10</i> </draw> </obj> </objs> </action></rpc>

Reference:

• RFC 7950, section 7.15

Version 19.10-13


2.14.2 alias

The alias command is used to set or display a specific command alias, or display all command aliases if no parameter is given. It is similar to the 'alias' command in unix shells such as 'bash'.

Note: This command can be disabled with the –no-aliases CLI parameter.

There are 3 forms of the alias command:

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


Command Parameters:

• var

◦ type: string

◦ usage: optional

◦ default: none

◦ The 'var' string must contain either a valid alias name or a string setting an alias. There cannot be any whitespace between the '=' and other characters when setting an alias. The alias value must be quoted if it contains whitespace.

▪ A double-quoted string can contain single quotes:

> alias get-eth0=”xget /interfaces/interface[name='eth0']”

▪ A single-quoted string can contain double quotes:

> alias get-eth0='xget /interfaces/interface[name=”eth0”]'

▪ An unquoted string can be used if the <value> does not contain any whitespace:

Version 19.10-13


> alias gc=get-config

Positive Response:

• If no parameter given:

◦ The current list of command aliases is displayed.

• If a <name> parameter given:

◦ The specified alias is displayed.

• If a <name>=<value> parameter is given:

◦ 'Updated alias foo' if alias foo already exists.

◦ 'Added alias foo' if this is a new alias

Negative Response:

• If no parameter given:

◦ Not applicable

• If a <name> parameter given:

◦ Error: alias 'foo' not found

• If a <name>=<value> parameter is given:

◦ Error message printed if value is invalid

Usage:

> alias get-running=”get-config --source=running”

Added alias 'get-running'

>

Version 19.10-13


2.14.3 aliases

The aliases command is used to load, save, or clear the command aliases, or display all command aliases if no parameter is given.

Note: This command can be disabled with the –no-aliases CLI parameter.

There are 4 forms of the aliases command:

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


Command Parameters:

• alias-action

◦ type: choice

◦ usage: optional

◦ default: show

◦ clear

▪ Delete all aliases from memory. This will not affect the aliases file until the 'aliases save' command is used, or the program exits and the –autoaliases parameter is set to 'true'.

◦ load [alias-filespec]

▪ Load an aliases file into memory. If the 'alias-filespec' parameter is not given, then the default aliases file ($HOME/.yumapro/.yangcli_pro_aliases) will be used.

◦ save [alias-filespec]

▪ Save the command aliases into memory to an alias file. If the 'alias-filespec' parameter is not given, then the default aliases file ($HOME/.yumapro/.yangcli_pro_aliases) will be used.

◦ show

▪ Displays all aliases in memory.

Version 19.10-13


Positive Response:

• show:


• clear, load, save:

◦ A status message is displayed.

Negative Response:

• An error message is printed if any error occurs.

Usage:

> aliases save

Saved aliases OK to '~/.yumapro/.yangcli_pro_aliases'

>

Version 19.10-13


2.14.4 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 isan <edit-config> operation, followed by a <commit> operation. If the running database is the server target, then an edit is simply an <edit-config> operation.

If the session-name parameter is present, then that named session will be used, or else the current session will be used. The session must be connected to the server and the session must be active. The user must have read and write access to all the nodes indicated by the target parameter. Access to the <edit-config>, <commit>, and <copy-config> operations is also required.

Note: choice statements are not supported at this time. Only string and numeric simple types are supported at this time.

auto-test command

Command type: local


Min parameters: 1

Max parameters: 3

Return type: status


Command Parameters:

• target

◦ type: schema identifier string


◦ 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

Version 19.10-13


◦ 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>

Version 19.10-13


2.14.5 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: local


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-nameDelete the specified module name from the YANG module cache. All revisions will be deleted from the cache.

3. cache delete=module-name revision=revision-dateDelete the specified module name and revision date from the YANG module cache.

Command Parameters:cache-action

◦ type: choice

◦ usage: optional

◦ default: none

◦ clear

▪ Clear the YANG module cache on disk.

◦ delete [name of module]

▪ delete the specified YANG modules from YANG module cache.

◦ revision [revision-date of module]

▪ deletes the specified YANG modules from YANG module cache.

Positive Response:

• none. Use 'show cache' to verify the result of the action.

Version 19.10-13


Negative Response:

• none. Use 'show cache' to verify the result of the action.

Usage:

> show cache yumaworks-event-filter@2014-02-09 ietf-netconf-notifications@2012-02-06 yuma-ncx@2013-09-23 yuma-types@2012-06-01 yuma-netconf@2013-09-28 t79@2014-06-19 yumaworks-types@2013-02-11 ietf-netconf-partial-lock@2009-10-19 test1a@2011-07-14 ietf-inet-types@2013-07-15 yuma-proc@2013-07-16 yuma-mysession@2013-10-05 test1c@2008-10-12 yumaworks-system@2014-05-27 yang-attributes@2013-02-18 ietf-netconf-with-defaults@2011-06-01 ietf-netconf-monitoring@2010-10-04 yuma-interfaces@2012-01-13 ietf-netconf-acm@2012-02-22 test1@2008-10-12 yuma-system@2013-07-15 ietf-yang-types@2013-07-15 yuma-app-common@2012-08-16 test1b@2008-10-12 <==============test@2009-12-26 yuma-time-filter@2012-11-15

andy@myserver> cache delete=test1bandy@myserver>andy@myserver> show cache

yumaworks-event-filter@2014-02-09 ietf-netconf-notifications@2012-02-06 yuma-ncx@2013-09-23 yuma-types@2012-06-01 yuma-netconf@2013-09-28 t79@2014-06-19 yumaworks-types@2013-02-11 ietf-netconf-partial-lock@2009-10-19 test1a@2011-07-14 ietf-inet-types@2013-07-15 yuma-proc@2013-07-16 yuma-mysession@2013-10-05 test1c@2008-10-12 yumaworks-system@2014-05-27 yang-attributes@2013-02-18 ietf-netconf-with-defaults@2011-06-01 ietf-netconf-monitoring@2010-10-04 yuma-interfaces@2012-01-13 ietf-netconf-acm@2012-02-22 test1@2008-10-12 <==============yuma-system@2013-07-15 ietf-yang-types@2013-07-15 yuma-app-common@2012-08-16

Version 19.10-13


andy@myserver> cache delete=test1 revision=2008-10-12andy@myserver>andy@myserver> show cache

yumaworks-event-filter@2014-02-09 ietf-netconf-notifications@2012-02-06 yuma-ncx@2013-09-23 yuma-types@2012-06-01 yuma-netconf@2013-09-28 t79@2014-06-19 yumaworks-types@2013-02-11 ietf-netconf-partial-lock@2009-10-19 test1a@2011-07-14 ietf-inet-types@2013-07-15 yuma-proc@2013-07-16 yuma-mysession@2013-10-05 test1c@2008-10-12 yumaworks-system@2014-05-27 yang-attributes@2013-02-18 ietf-netconf-with-defaults@2011-06-01 ietf-netconf-monitoring@2010-10-04 yuma-interfaces@2012-01-13 ietf-netconf-acm@2012-02-22test@2009-12-26 yuma-arp@2012-01-13 test@2009-9-26yuma-system@2013-07-15 ietf-yang-types@2013-07-15 yuma-app-common@2012-08-16 yuma-time-filter@2012-11-15 yuma-arp@2012-01-13 ietf-netconf@2011-06-01 nc-notifications@2008-07-14 notifications@2013-03-15 ietf-netconf@2011-06-01 nc-notifications@2008-07-14 notifications@2013-03-15 yuma-time-filter@2012-11-15 yuma-arp@2012-01-13 ietf-netconf@2011-06-01 nc-notifications@2008-07-14 notifications@2013-03-15 ietf-netconf@2011-06-01 nc-notifications@2008-07-14 notifications@2013-03-15

andy@myserver> andy@myserver> cache clear

andy@myserver> andy@myserver> show cache

andy@myserver> cache clear

empty cache: ./yumapro/.yangcli andy@myserver>

Reference:

• yangcli-pro.yang

Version 19.10-13


2.14.6 cd

The cd command is used to change the current working directory.

cd command

Command type: local

Default parameter: dir

Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• dir

◦ type: string


◦ 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

>

Version 19.10-13


2.14.7 clear

The clear command is used to clear the screen and reposition the prompt at the top of the screen.

This command is only applied in interactive mode, and has no affect in batch mode.

clear command

Command type: local

Default parameter: N/A

Min parameters: 0

Max parameters: 0

Return type: none


Command Parameters: none

Positive Response:

• the screen is cleared

Negative Response:

• no change to screen

Usage:

Before command:

> cd ~/modules

Current working directory is /home/andy/modules

> cd --dir=$YUMAPRO_HOME

Current working directory is /home/andy/swdev/yumapro/trunk/netconf

> clear

After command:

>

Version 19.10-13


2.14.8 close-session

The close-session command is used to terminate the current NETCONF session. A NETCONF server should always acceptthis 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



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

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:


Version 19.10-13


2.14.9 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



Min parameters: 0

Max parameters: 2

Return type: status


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

◦ 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

Version 19.10-13


◦ 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:

• RFC 4741, section 8.3.4

Version 19.10-13


2.14.10 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

Command type: local

Default parameter: term

Min parameters: 1

Max parameters: 1

Return type: none (enter configuration mode)


Command Parameters:

• term

◦ type: empty


◦ 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#

Version 19.10-13


2.14.11 config-commit

The config-commit is used to commit the candidate datastore to the running datastore in config mode.

Config-commit command

Command type: local

Default parameter: 0

Min parameters: 0

Max parameters: 0

Return type: none


Command Parameters:

• none.

Positive Response:

• No error message.

Negative Response:

• An error message will be printed

Usage:

andy@myserver> config term

andy@myserver# config-commit

Version 19.10-13


2.14.12 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


Default parameter: server

Min parameters: 1

Max parameters: 10

Return type: status


Command Parameters:

• server

◦ type: inet:ip-address (string containing IP address or DNS name

◦ usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration.

◦ default: previous server used, if any, will be presented as the default, but not used automatically

◦ This parameter specifies the server address for the session.

• password

◦ type: string (ncx:password)

◦ usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration, of if no-password parameter is present.

◦ default: previous password used, if any, will be presented as the default, but not used automatically

◦ This parameter specifies the password string to use to establish the session. It will not be echoed in parameter mode or saved in the command history buffer.

• no-password

◦ type: empty

◦ usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration, of if password parameter is present.

Version 19.10-13


◦ default:not present

◦ This parameter specifies that there is no password needed for this connection

• ncport

◦ type: uint16

◦ usage: optional

◦ default: 830

◦ This parameter specifies the TCP port number that should be used for the session.

• timeout


◦ usage: optional



• user

◦ type: string

◦ usage: mandatory unless session-name parameter is used and refers to a previously saved session configuration.

◦ default: previous user name used, if any, will be presented as the default, but not used automatically

◦ This parameter specifies the user name to use for the session. This must be a valid user name on the NETCONF server.

• protocols

◦ type: bits (netconf1.0 netconf1.1 yang-api restconf)

◦ usage: optional

◦ default: --protocols configuration parameter setting

◦ Specifies which NETCONF protocol versions to enable. Overrides –protocols configuration parameter.

▪ netconf1.0: request RFC 4741 NETCONF

▪ netconf1.1: request RFC 6241 NETCONF

▪ yang-api: request Yuma YANG-API protocol

▪ restconf: request IETF RESTCONF protocol

• private-key

◦ type: string

◦ usage: optional

◦ default: --private-key configuration parameter setting

◦ Specifies the SSH private key file to use. Overrides –private-key configuration parameter.

• public-key

◦ type: string

Version 19.10-13


◦ 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, tcp-ncx, tls)

◦ usage: optional

◦ default: ssh

◦ This parameter specifies the transport protocol to use.

▪ ssh:Selects the standard NETCONF transport (and --ncport specifies the SSH port to use).

▪ tcp:Selects the tail-f NETCONF over TCP protocol. The --ncport value is set to 2023, 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.

▪ tls:Selects the TLS protocol; Supported only if protocols=yang-api or restconf.

• entry-point

◦ type: string

usage: RESTCONF entry point. Use this string instead of retrieving the XRD from the RESTCONF server to discover the entry point.

Positive Response:

• the session is started and the prompt changes to include the 'user@server' string.

Negative Response:

• One or more error messages will be printed. Refer to the section on trouble-shooting NETCONF Session problemsfor more details.

Version 19.10-13

mailto:'user@agent


Usage:

> connect myserver user=andy password=yangrocks

<startup screen printed>

andy@myserver>

Version 19.10-13

http://www.example.com/


2.14.13 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-volatilestorage.

This command is provided by the NETCONF server, not yangcli-pro.

copy-config command



Min parameters: 2

Max parameters: 3

Return type: status


Capabilities needed: none

Capabilities optional: :candidate:startup:url:with-defaults

Command Parameters:

• source

◦ type: container with 1 of N choice of leafs


◦ 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

Version 19.10-13


▪ 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



◦ default: none

◦ This parameter specifies the name of the target database for the copy operation.


▪ candidate

• type: empty


▪ running

• type: empty

• capabilities needed: :writable-running (still optional to implement)

◦ netconfd-pro does not support this mode

▪ startup

• type: empty


▪ 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 (target=url) cannot be used, since this parameter contains a string.

Version 19.10-13


• 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:


Negative Response:



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/urlEnter string value for leaf <url>:andy@myserver:copy-config> file://configs/myconfig.xml

RPC OK Reply 12 for session 10:andy@myserver>

Reference:


Version 19.10-13

smb://configs/myconfig.xml


2.14.14 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'.


create command



Min parameters: 1

Max parameters: 5

Return type: status



Command Parameters:




◦ default: none

◦ This parameter specifies the where yangcli-pro should get the data from, for the create operation. It is either auser variable or from interactive input at the command line.

▪ varref

• type: string


• default: none

• This parameter specifies the name of the user variable to use for the target of the create operation. Theparameter must exist (e.g., created with the fill command) or an error message will be printed.


• target

◦ type: string


◦ default: none

Version 19.10-13


◦ 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



• value

◦ type: anyxml


◦ 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 interactiveprompt 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

• $$test-option

◦ The <test-option> parameter for the <edit-config> operation will be derived from this variable

Positive Response:

Version 19.10-13



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)


Reference:


Version 19.10-13


2.14.15 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



Min parameters: 0

Max parameters: 4

Return type: status

YANG file: notifications.yang

Capabilities needed: :notification

Capabilities optional: :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

Version 19.10-13


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

◦ 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:


Version 19.10-13


2.14.16 device-cfg

The device-cfg command is used to access a named device.

There are 3 sub-commands:

• delete

• save

• show (default)

Refer to the section on “NETCONF Device Configuration” for more details on using saved devices.

device-cfg command

Command type: local

Default parameter: show

Min parameters: 1

Max parameters: 2

Return type: status



Command Parameters:

• delete

◦ type: name string

◦ This parameter specifies the name of the device to delete from the saved devices in memory. An active devicecannot be deleted.

• save


◦ This parameter specifies the name of the device to save in the saved devices in memory.

• show

◦ type: name string; default: empty string == current device

◦ This parameter specifies the name of the device to show. An empty string indicates that the current device should be used.

◦ The --brief, --normal, or --full parameter can be used for this sub-command.

Positive Response:

• A message indicating the save or delete was done will be printed. The show command will generate some formatted output showing information on the requested device.

Negative Response:

Version 19.10-13



andy@myserver> device-cfg save device-A

Saving current device as 'device-A'

andy@myserver>

Version 19.10-13


2.14.17 devices-cfg

The devices-cfg command is used to access the named device files.


• clear

• load

• save

• show (default)

Refer to the section on “NETCONF Device Configuration” for more details on using saved devices.

devices-cfg command

Command type: local


Min parameters: 1

Max parameters: 2

Return type: status



Command Parameters:

• clear

◦ type: empty

◦ This parameter indicates that all saved devices in memory be deleted. This cannot be done if any of the devices are currently active. Use 'device-cfg load' to restore the saved devices.

• load

◦ type: string

◦ This parameter identifies the file specification for the saved devices to load. Any new named devices will be added to the named devices in memory.

• save


◦ This parameter identifies the file specification for the saved devices config file to load. The saved devices in memory will be saved to this file.

• show

◦ type: name string; default: empty string == all devices

◦ This parameter specifies the name of the device to show.


Version 19.10-13


Positive Response:

• A message indicating the load, save or clear was done will be printed. The show command will generate some formatted output showing information on the requested devices.

Negative Response:


session-A> devices-cfg load ~/more-devices.conf

Loading saved devices from '/home/andy/more-devices.conf' Loaded saved devices OK from '~/more-devices.conf'

session-A>

Version 19.10-13


2.14.18 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



Min parameters: 1

Max parameters: 2

Return type: status



Command Parameters:

• target

◦ type: string

◦ usage: optional (urltarget or target must be present)

◦ default: none

◦ This parameter specifies the database target node of the delete operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

• urltarget

◦ type: string

◦ usage: optional

◦ default: none

◦ This parameter specifies the database target node of the delete operation. This is an UrlPath string.

System Variables:



• $$error-option


• $$optional

◦ Controls whether optional descendant nodes will be filled into the target parameter contents

Version 19.10-13


• $$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)


andy@myserver> delete \target=/nacm/rules/data-rule[name='test rule']/comment

(no user prompting; <edit-config> request sent right away)


Reference:


Version 19.10-13


2.14.19 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



Min parameters: 1

Max parameters: 1

Return type: status



Capabilities optional: :candidate:startup:url

Command Parameters:

• target



◦ default: none

◦ This parameter specifies the name of the target database for the delete operation.


▪ startup

• type: empty


• a server may support this target

▪ url

• type: yang:uri



Version 19.10-13


• a server may support this parameter

Positive Response:


Negative Response:



Usage:

andy@myserver> delete-config target=startup


andy@myserver>

Reference:


Version 19.10-13


2.14.20 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 byanother session, then this request will fail with an 'in-use' error.


discard-changes command



Min parameters: 0

Max parameters: 0

Return type: status


Capabilities needed: :candidate


Positive Response:


Negative Response:



Usage:

andy@myserver> discard-changes


andy@myserver>

Reference:

• RFC 6241, section 8.3.4.2

Version 19.10-13


2.14.21 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



Min parameters: 2

Max parameters: 5

Return type: status



Capabilities optional: :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 datafrom 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

Version 19.10-13


◦ 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

▪ 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 (target=url) cannot be used, since this parameter contains a string.

• target



◦ 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

Version 19.10-13


▪ 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 \error-option=stop-on-error \[email protected]


andy@myserver>

Reference:


Version 19.10-13


2.14.22 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 blockwill 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

Command type: local

Default parameter: expr

Min parameters: 1

Max parameters: 2

Return type: status


Command Parameters:

• expr

◦ type: XPath expression string


◦ default: none

Version 19.10-13


◦ 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>

Version 19.10-13


2.14.23 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 beenexecuted in the same if command sequence.

if command

....

[elif command]

....

[elif-command]

...

[else command]

...

end command

else command

Command type: local


Min parameters: 0

Max parameters: 0

Return type: status



Positive Response:


Negative Response:


◦ else without a previous if command will cause an error

Usage:

> else

>

Version 19.10-13

mailto:andy@myagent


2.14.24 enable

The enable command is used to enter enable mode.

enable command

Command type: local


Min parameters: 0

Max parameters: 1

Return type: none


Command Parameters:

• password

◦ type: string (ncx:password)

◦ usage: optional

◦ default: none

◦ This parameter specifies the password string to use to enter the enable mode.

• no-password

◦ type: empty

◦ usage: optional

◦ default: none

◦ This parameter specifies that there is no password needed to enter the enable mode.

2.14.25 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]

....

[elif-command]

...

[else command]

...

end command

Version 19.10-13


while command

....

end command

end command

Command type: local


Min parameters: 0

Max parameters: 0

Return type: status



Positive Response:


Negative Response:


◦ else without a previous if command will cause an error

Usage:

> end

>

Version 19.10-13


2.14.26 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.


eval command

Command type: local


Min parameters: 1

Max parameters: 2

Return type: data


Command Parameters:

• expr



◦ default: none


• docroot

◦ type: anyxml


◦ default: none


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

Version 19.10-13


◦ type: anyxml

◦ This element will contain the result from the XPath expression. A node-set result will produce a complex element return value, and all other XPath result types will produce a string return value.

Usage:

session1> $x = eval '$x + 1'

session1> $sysname = eval '//sysName' docroot=$backup

Version 19.10-13

mailto:andy@myagent


2.14.27 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


Min parameters: 0

Max parameters: 3

Return type: status


Command Parameters:

• choice eventlog-action (not entered):

◦ type: choice of case 'show-case' or leaf 'clear'

◦ usage: optional

◦ default: show=-1 is used as the default if nothing entered

◦ This parameter specifies the event log action that should be performed.

▪ clear

• type: int32 (-1 to clear all entries; 1 to max to delete N entries)

• usage: optional

• default: -1

• This parameter specifies the maximum number of event log entries to be deleted, starting from the oldest entries in the event log. The value -1 means delete all the entries. Otherwise the value must be greater than zero, and up to that many entries will be deleted.

▪ case show-case (not entered)

• choice help-mode (not entered) (default choice is 'normal')

◦ brief

▪ type: empty

▪ usage: optional

▪ default: none

Version 19.10-13


▪ 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 19.10-13


> eventlog show=5 start=3

[3] [2009-07-10T02:21:10Z] (4) <sysSessionStart> [4] [2009-07-10T02:23:14Z] (5) <sysSessionEnd> [5] [2009-07-10T02:23:23Z] (6) <sysSessionStart> [6] [2009-07-10T02:24:52Z] (7) <sysConfigChange> [7] [2009-07-10T02:24:57Z] (8) <sysSessionEnd>

>

Version 19.10-13


2.14.28 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


Min parameters: 0

Max parameters: 0

Return type: none (prompt is changed)


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

andy@myserver>

Version 19.10-13


2.14.29 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


Min parameters: 2

Max parameters: 3

Return type: data


Command Parameters:

• optional

◦ type: empty

◦ usage: optional



• target

◦ type: string


◦ default: none

◦ This parameter specifies the database target node of the create operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

• value

◦ type: anyxml


◦ default: none

◦ This parameter specifies the content to use for the filled variable.

▪ If this parameter is not entered, then the user will be prompted interactively to fill in the target data structure.

Version 19.10-13


▪ 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

>

Version 19.10-13


2.14.30 get

The get command is used to retrieve data from the server. This command is provided by the NETCONF server, not yangcli-pro.

get command



Min parameters: 0

Max parameters: 4

Return type: data


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>.

• depth

◦ type: uint32 or “unbounded”

◦ usage: optional

◦ default: unbounded

◦ capabilities needed: none: netconfd-pro NETCONF extension

Version 19.10-13


◦ This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.

• module-tag:

◦ type: string

◦ default: none

◦ capabilities needed: none

◦ This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.

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:

rpc-reply { data { …. data returned by the server }}

session1> get [email protected]


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:


Version 19.10-13






2.14.31 get-config

The get-config command is used to retrieve configuration data from the server.


get-config command



Min parameters: 1

Max parameters: 7

Return type: data


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>.

• source



◦ default: none

◦ This parameter specifies the name of the source database for the retrieval operation.


▪ candidate

• type: empty


▪ running

Version 19.10-13


• type: empty


▪ startup

• type: empty


▪ url

• type: yang:uri



• with-defaults


◦ usage: optional

◦ default: none



• depth


◦ usage: optional




• if-modified-since

◦ type: date-and-time

◦ usage: optional

◦ default: none


◦ This parameter will cause the retrieval reply to be empty if the configuration datastore has not been modified since the provided timestamp.

• with-owners

◦ type: empty

◦ usage: optional

◦ default: none

◦ This parameter will cause the 'ywx:owner' attribute to be returned within subtrees where the owner has been saved. The netconfd-pro server must be configured with –save-owners=true in order for any owner strings to be returned.

Version 19.10-13


• module-tag:

◦ type: string

◦ default: none



Positive Response:


Negative Response:



Output:

• 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 \[email protected] \target=candidate

rpc-reply { data {

… data requested by the filter }}

session1>

Reference:


Version 19.10-13




2.14.32 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



Min parameters: 0

Max parameters: 3

Return type: status


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

Version 19.10-13


◦ 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 19.10-13



2.14.33 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



Min parameters: 0

Max parameters: 0

Return type: data

YANG file: mysession.yang


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-sessionRPC Data Reply 25 for session 10:rpc-reply { data { indent 3

Version 19.10-13



linesize 72 with-defaults report-all }}

session1>

Version 19.10-13


2.14.34 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 get-schema command. See the example below for more details.

get-schema command



Min parameters: 3

Max parameters: 3

Return type: data

YANG file: ietf-netconf-monitoring.yang

Capabilities needed: :schema-retrieval

Command Parameters:

• identifier

Version 19.10-13


◦ type: string


◦ 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


◦ 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)


◦ 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

◦ 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:

Version 19.10-13


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:

• RFC 6022

Version 19.10-13




2.14.35 get-walk

This command walks the entries of a YANG list using the netconfd-pro <get-bulk> operation. This command will send <get-bulk> requests to the server until the entire list has been retrieved or the user quits the walk.

If the yumaworks-getbulk YANG module is not supported by the server then this command will not be attempted.

If the program is in interactive mode, then after each retrieval, the user will be prompted to continue or quit the walk. In batch mode the entries will be displayed until the walk terminates.

The server will wait the normal 'timeout' period aftereach request. It will display each response and check it for 'last-keys' data. If present, these values will be used for the 'last-keys' parameter in the next request If not present, then the walk will end.

The walk will be done on the YANG list specified by the 'list-target' parameter. Each retrieval will request 1 or more entries,based on the 'count' parameter. The data returned can be filtered according to the 'content', 'depth', 'with-defaults', and 'list-test' parameters, which as passed to the <get-bulk> operation each time.

The list-target parameter is used to specify that YANG list that will be retrieved.

The list-test parameter allows an XPath boolean expression to be used to test each list-target entry. It is used to select only asubset of the list entries to reduce the number of entries returned.

If a portion of the requested data is not available due to access control restrictions, then that data is silently dropped from the <rpc-reply> message. It is implicitly understood that the client is only requesting data for which it is authorized to receive, in the event such data is selected in the request.

get-walk command



Min parameters: 1

Max parameters: 7

Return type: data


Capabilities needed: Yumaworks-getbulk.yang

Mandatory Parameters:

• list-target

◦ type: string (RESTCONF path URI)


◦ This parameter identifies the list object that is being retrieved. This must be a path expression used to representa list data node. It is formated like a RESTCONF path expression, except module names are not mandatory if they are unique.

Optional Parameters:

• datastore

◦ type: enumeration (candidate running startup)

Version 19.10-13


◦ usage: optional

◦ default: running

◦ This parameter specifies the name of the source database for the retrieval operation. It is ignored if the list-target specifies a non-configuration data node.

◦ enum: candidate

▪ capabilities needed: :candidate

◦ enum : running

▪ capabilities needed: none

◦ enum: startup

▪ capabilities needed: :startup

• count

◦ type: unint32

◦ usage: optional

◦ default: 1

◦ The maximum number of list entries to return.

• content

◦ type: enumeration

◦ usage: optional

◦ default: all

◦ This parameter specifies which type of content to include, exactly the same as the RESTCONF “content” query parameter

▪ enum: config

• Include only config=true descendant data nodes

▪ enum: nonconfig

• include only config=false descendant data nodes

▪ enum: all

• include all descendant data nodes

• depth

◦ type: uint32

◦ usage: optional


◦ This parameter is used as defined in the RESTCONF protocol. The value '1' is associated with the list-object node itself. This value can be used to simply test for the existence of any instances of the list-object.

• with-defaults


◦ usage: --default-style configuration parameter used as the default if no value is provided

◦ This parameter controls how default leaf and leaf-list nodes are returned by the server.

Version 19.10-13


• list-test

◦ type: leaf containing an XPath expression

◦ usage: optional

◦ default: return all selected list-target entries

◦ This parameter contains an XPath expression. The document root and the context node are set to the list instance being tested.

Example to continue walk.

andy@server> get-walk count=5 list-target=/modules-state/module \list-test="starts-with(name, 'ietf-netconf')" \content=all datastore=running depth=unbounded

rpc-reply { bulk { data { module { conformance-type implement feature candidate feature confirmed-commit feature rollback-on-error feature validate feature url feature xpath name ietf-netconf namespace urn:ietf:params:xml:ns:netconf:base:1.0 revision 2011-06-01 } module { conformance-type implement name ietf-netconf-acm namespace urn:ietf:params:xml:ns:yang:ietf-netconf-acm revision 2018-02-14 schema http://localhost/restconf/yang/ietf-netconf-acm/2018-02-14 } module { conformance-type implement name ietf-netconf-monitoring namespace urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring revision 2010-10-04 schema http://localhost/restconf/yang/ietf-netconf-monitoring/2010-10-04 } module { conformance-type implement name ietf-netconf-notifications namespace urn:ietf:params:xml:ns:yang:ietf-netconf-notifications revision 2012-02-06 schema http://localhost/restconf/yang/ietf-netconf-notifications/2012-02-06 } module { conformance-type implement name ietf-netconf-partial-lock namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0 revision 2009-10-19 schema http://localhost/restconf/yang/ietf-netconf-partial-lock/2009-10-19 }

Version 19.10-13


} last-keys { name ietf-netconf-partial-lock revision 2009-10-19 } }}

Press Enter to continue, q to quit get-walk:

rpc-reply { bulk { data { module { conformance-type implement name ietf-netconf-with-defaults namespace urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults revision 2011-06-01 schema http://localhost/restconf/yang/ietf-netconf-with-defaults/2011-06-01 } module { conformance-type implement name ietf-restconf namespace urn:ietf:params:xml:ns:yang:ietf-restconf revision 2017-01-26 schema http://localhost/restconf/yang/ietf-restconf/2017-01-26 } module { conformance-type implement name ietf-restconf-monitoring namespace urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring revision 2017-01-26 schema http://localhost/restconf/yang/ietf-restconf-monitoring/2017-01-26 } module { conformance-type implement name ietf-yang-library namespace urn:ietf:params:xml:ns:yang:ietf-yang-library revision 2016-06-21 schema http://localhost/restconf/yang/ietf-yang-library/2016-06-21 } module { conformance-type implement name ietf-yang-patch namespace urn:ietf:params:xml:ns:yang:ietf-yang-patch revision 2017-02-22 schema http://localhost/restconf/yang/ietf-yang-patch/2017-02-22 } } last-keys { name ietf-yang-patch revision 2017-02-22 } }}


rpc-reply { bulk { data {

Version 19.10-13


module { conformance-type import name ietf-yang-types namespace urn:ietf:params:xml:ns:yang:ietf-yang-types revision 2013-07-15 schema http://localhost/restconf/yang/ietf-yang-types/2013-07-15 } module { conformance-type implement name nc-notifications namespace urn:ietf:params:xml:ns:netmod:notification revision 2008-07-14 schema http://localhost/restconf/yang/nc-notifications/2008-07-14 } module { conformance-type implement name notifications namespace urn:ietf:params:xml:ns:netconf:notification:1.0 revision 2013-03-15 schema http://localhost/restconf/yang/notifications/2013-03-15 } module { conformance-type implement name yang-data-ext namespace urn:ietf:params:xml:ns:yang:yang-data-ext revision 2017-07-03 schema http://localhost/restconf/yang/yang-data-ext/2017-07-03 } module { conformance-type import name yuma-app-common namespace http://netconfcentral.org/ns/yuma-app-common revision 2017-07-25 schema http://localhost/restconf/yang/yuma-app-common/2017-07-25 } } last-keys { name yuma-app-common revision 2017-07-25 } }}Press Enter to continue, q to quit get-walk:

rpc-reply { bulk { data { module { conformance-type implement name yuma-ncx namespace http://netconfcentral.org/ns/yuma-ncx revision 2015-10-16 schema http://localhost/restconf/yang/yuma-ncx/2015-10-16 } module { conformance-type implement name yuma-system namespace http://netconfcentral.org/ns/yuma-system revision 2013-07-15 schema http://localhost/restconf/yang/yuma-system/2013-07-15 } module { conformance-type implement

Version 19.10-13


name yuma-time-filter namespace http://netconfcentral.org/ns/yuma-time-filter revision 2012-11-15 schema http://localhost/restconf/yang/yuma-time-filter/2012-11-15 } module { conformance-type import name yuma-types namespace http://netconfcentral.org/ns/yuma-types revision 2015-09-25 schema http://localhost/restconf/yang/yuma-types/2015-09-25 } module { conformance-type import name yumaworks-app-common namespace http://yumaworks.com/ns/yumaworks-app-common revision 2018-06-26 schema http://localhost/restconf/yang/yumaworks-app-common/2018-06-26 } } last-keys { name yumaworks-app-common revision 2018-06-26 }


rpc-reply { bulk { data { module { conformance-type implement name yumaworks-event-filter namespace http://yumaworks.com/ns/yumaworks-event-filter revision 2014-02-09 schema http://localhost/restconf/yang/yumaworks-event-filter/2014-02-09 } module { conformance-type implement name yumaworks-getbulk namespace http://yumaworks.com/ns/yumaworks-getbulk revision 2018-04-06 schema http://localhost/restconf/yang/yumaworks-getbulk/2018-04-06 } module { conformance-type implement name yumaworks-ids namespace http://yumaworks.com/ns/yumaworks-ids revision 2014-07-12 schema http://localhost/restconf/yang/yumaworks-ids/2014-07-12 } module { conformance-type implement name yumaworks-restconf namespace urn:ietf:params:xml:ns:yang:yumaworks-restconf revision 2017-07-03 schema http://localhost/restconf/yang/yumaworks-restconf/2017-07-03 } module { conformance-type implement name yumaworks-support-save

Version 19.10-13


namespace urn:ietf:params:xml:ns:yang:yumaworks-support-save revision 2017-07-27 schema http://localhost/restconf/yang/yumaworks-support-save/2017-07-27 } } last-keys { name yumaworks-support-save revision 2017-07-27 } }}


rpc-reply { bulk { data { module { conformance-type implement name yumaworks-system namespace http://yumaworks.com/ns/yumaworks-system revision 2019-01-22 schema http://localhost/restconf/yang/yumaworks-system/2019-01-22 } module { conformance-type implement name yumaworks-templates namespace http://yumaworks.com/ns/yumaworks-templates revision 2017-02-20 schema http://localhost/restconf/yang/yumaworks-templates/2017-02-20 } module { conformance-type import name yumaworks-types namespace http://yumaworks.com/ns/yumaworks-types revision 2018-05-03 schema http://localhost/restconf/yang/yumaworks-types/2018-05-03 } } last-keys { name yumaworks-types revision 2018-05-03 } }}


rpc-reply { bulk { data }}

get-walk has completed.andy@server>

Example to quit walk.

Version 19.10-13


andy@server> get-walk count=5 list-target=/modules-state/module \list-test="starts-with(name, 'ietf-netconf')" \content=all datastore=running depth=unbounded

rpc-reply { bulk { data { module { conformance-type implement feature candidate feature confirmed-commit feature rollback-on-error feature validate feature url feature xpath name ietf-netconf namespace urn:ietf:params:xml:ns:netconf:base:1.0 revision 2011-06-01 } module { conformance-type implement name ietf-netconf-acm namespace urn:ietf:params:xml:ns:yang:ietf-netconf-acm revision 2018-02-14 schema http://localhost/restconf/yang/ietf-netconf-acm/2018-02-14 } module { conformance-type implement name ietf-netconf-monitoring namespace urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring revision 2010-10-04 schema http://localhost/restconf/yang/ietf-netconf-monitoring/2010- 10-04 } module { conformance-type implement name ietf-netconf-notifications namespace urn:ietf:params:xml:ns:yang:ietf-netconf-notifications revision 2012-02-06 schema http://localhost/restconf/yang/ietf-netconf-notifications/2012-02-06 } module { conformance-type implement name ietf-netconf-partial-lock namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0 revision 2009-10-19 schema http://localhost/restconf/yang/ietf-netconf-partial-lock/2009-10-19 } } last-keys { name ietf-netconf-partial-lock revision 2009-10-19 } }}

Press Enter to continue, q to quit get-walk:q

andy@server>

Version 19.10-13

http://localhost/restconf/yang/ietf-netconf-monitoring/2010-


2.14.36 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.


• create

• add

• delete

• remove

• list

• show

• connect

Refer to the section on “Netconf Group Configuration” for more details on using group configuration.

group command

Command type: local


Min parameters: 1

Max parameters: 6

Return type: status



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 bepresent. The session cannot be currently active.

• delete


◦ An active group cannot be deleted.

Version 19.10-13


• remove


◦ This parameter specifies the name of the session to delete from the group in memory. An active session cannotbe deleted.

• show


◦ This parameter specifies the name of the group to show.

• list

◦ type: empty

◦ List the names of all the groups.

• connect


◦ This parameter specifies the name of the group to connect.

• missing-ok

◦ type: boolean

◦ If true, then it is OK to manage this group if 1 or more sessions identified in the session leaf-list are not found in the session list. The default is to require all session names to exist in the session list for the group to be used.

• missing-connect-ok

◦ type: boolean

◦ If true, then it is OK to manage this group if 1 or more sessions identified in the session leaf-list are not found in the session list. The default is to require all sessions to connect OK for the group to be used.

• lost-ok

◦ type: boolean

◦ If true, then it is OK to manage this group if 1 or more sessions are lost after connection is made. The default isto 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 bomesunreachable. 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.

Version 19.10-13

mailto:'user@agent


> group list No groups found

> group create=AB session-A

> group list

Group 'AB' This group is not connected. missing-ok: false missing-connect-ok: false lost-ok: false reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 0 number_of_sessions: 1 Session 'session-A' connected:false >

> group add=AB session-B

> group list

Group 'AB' This group is not connected. missing-ok: false missing-connect-ok: false lost-ok: false reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 0 number_of_sessions: 2 Session 'session-A' connected:false Session 'session-B' connected:false

> group remove=AB session=session-A

> group list

Group 'AB' This group is not connected. missing-ok: false missing-connect-ok: false lost-ok: false reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 0 number_of_sessions: 1 Session 'session-B' connected:false

> group delete=AB

> group list No groups found

>group connect=AB Error: group 'AB' not found

> group create=AB session=session-A session=session-B

> group list

Version 19.10-13


Group 'AB' This group is not connected. missing-ok: false missing-connect-ok: false lost-ok: false reconnect-interval: 30 reconnect-tries: 5 connected_cnt: 0 number_of_sessions: 2 Session 'session-A' connected:false Session 'session-B' connected:false

> group connect=AB

yangcli-pro: Starting NETCONF session for trshue on localhost over ssh on port 830

NETCONF session established for trshue on localhost

Client Session Id: 1 Server Session Id: 13 Server Protocol Capabilities base:1.0 candidate:1.0 confirmed-commit:1.0 rollback-on-error:1.0 ------------about to send <get>:on Group of 'AB' Session of 'session-A' yangcli-pro: Starting NETCONF session for trshue on localhost over ssh on port 830

NETCONF session established for trshue on localhost Client Session Id: 2Server Session Id: 14 Server Protocol Capabilities base:1.0 candidate:1.0 ------

AB> get-my-session about to send <get-my-session>:on Group of 'AB' Session of 'session-A' about to send <get-my-session>:on Group of 'AB' Session of 'session-B'

RPC Data Reply 3 for session 13 [session-A]: rpc-reply { indent 2 linesize 72 with-defaults explicit message-indent -1}

RPC Data Reply 2 for session 14 [session-B]: rpc-reply { indent 2 linesize 72 with-defaults explicit message-indent -1 } AB>

AB> set-my-session indent=8 linesize=68 with-defaults=report-all message-indent=-1

about to send <set-my-session>:on Group of 'AB' Session of 'session-A'

Version 19.10-13


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>

Version 19.10-13


2.14.37 help

The help command is used to print documentation to STDOUT.

If no session is active, then only help for the local commands and the standard NETCONF commands will be available.

If a NETCONF session is active, then the documentation shown will attempt to exactly match the capabilities of the server.

If additional (i.e., augment generated) parameters are available, then they will be shown in the command output. If the server does not implement some parameters (e.g., feature not supported) then these parameters will not be shown in the command output.

If the server has modified an object with deviation statements, then the altered object will be shown.

The ncx:hidden extension suppresses the help command. If this extension is present in the YANG definition associated with the request, then no help will be available for that object or command.

help command

Command type: local

Default parameter: command

Min parameters: 3

Max parameters: 3

Return type: data

YANG file: ietf-netconf-monitoring.yang

Capabilities needed: :schema-retrieval

Command Parameters:

• choice helptype (not entered)

◦ command

▪ type: string


▪ default: none

▪ This parameter specifies the name of the command for which documentation is requested

◦ commands

▪ type: empty


▪ default: none

▪ This parameter will request documentation for all available commands

◦ notification

▪ type: string


Version 19.10-13


▪ default: none

▪ This parameter specifies the name of the notification for which documentation is requested

◦ object

▪ type: string


▪ 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 forhelp ('?') and full help ('??')

◦ type

▪ type: string


▪ 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

Version 19.10-13


Negative Response:


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>

Version 19.10-13


2.14.38 history

The history command is used to show, clear, load, or save the command line history buffer.

Use the recall command to recall a previously executed command line, after getting the line number from the history show command.

All lines entered will be saved in the history buffer except an ncx:password value entered in parameter mode.

When yangcli-pro starts, the command line history buffer is empty. If a history file was previously stored with the history save command, then it can be recalled into the buffer with the history load command.

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


Min parameters: 0

Max parameters: 2

Return type: data


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'.

Version 19.10-13


> history load same as:> history load=$HOME/.yangcli-pro_history

◦ save

▪ type: string

▪ usage: optional

▪ default: $HOME/.yangcli-pro_history

▪ This parameter specifies a command history file, and causes the current command line history contents to be saved to that file.

▪ Special processing for this command allows the history file to be omitted in idle mode, even though the save parameter is not type 'empty'.

> history save same as:> history save=$HOME/.yangcli-pro_history

◦ show

▪ type: int32 (-1 for all entries; 1..max for N entries)

▪ usage: optional

▪ default: -1

▪ This parameter specifies the maximum number of history entries to show.

• If no case is selected from this choice, then the command 'history show=-1' will be used by default.

• The help-mode choice parameter is only used with the history show command.

◦ If the --brief or --normal modes are selected the the format will include the command number and the command line.

◦ If the --full mode is selected, then the command data and time will also be printed.

• 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

Version 19.10-13



◦ full

▪ type: empty

▪ usage: optional

▪ default: none


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>

Version 19.10-13


2.14.39 if

The if command is used to start a conditional command block.

The expr parameter is used to specify the XPath expression to test if the if conditional block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.


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: local


Min parameters: 1

Max parameters: 2

Return type: status


Command Parameters:

• expr



◦ default: none


• docroot

Version 19.10-13


◦ type: anyxml


◦ default: none


Positive Response:


Negative Response:



Usage:

andy@myserver> if "$sysname = 'localhost'"

andy@myserver>

Version 19.10-13


2.14.40 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



Min parameters: 2

Max parameters: 7

Return type: status


Command Parameters:




◦ default: none

◦ This parameter specifies the where yangcli-pro should get the data from, for the insert operation. It is either a user variable or from interactive input at the command line.

▪ varref

• type: string


• default: none

• This parameter specifies the name of the user variable to use for the target of the insert operation. Theparameter 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 insert operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

• optional

◦ type: empty

◦ usage: optional

Version 19.10-13




• value

◦ type: anyxml


◦ default: none


• 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


Version 19.10-13



System Variables:



• $$error-option


• $$test-option


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

Version 19.10-13


2.14.41 kill-session

The kill-session command is used to terminate a NETCONF session (other than the current session). All NETCONF implementations must support this command. It is needed sometimes to unlock a NETCONF database locked by a session that is idle or stuck.

If the lock command returns a 'lock-denied' <error-tag>, it will also include an <error-info> field called <session-id>. This is the session number that currently holds the requested lock. The same value should be used for the session-id parameter in this command, to terminate the session will the lock.

Note: this is an extreme measure, which should be used with caution.


kill-session command



Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• session-id

◦ type: uint32 (range: 1.. max)


◦ 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>

Version 19.10-13


Reference:


Version 19.10-13


2.14.42 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, orwhich 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

Command type: local


Min parameters: 1

Max parameters: 6

Return type: data


Command Parameters:

• choice help-mode (not entered)

◦ brief

▪ type: empty

▪ usage: optional

▪ default: none


◦ normal

▪ type: empty

▪ usage: optional

▪ default: none


◦ full

Version 19.10-13


▪ type: empty

▪ usage: optional

▪ default: none


• choice 'listtype' (not entered)


◦ default: none

◦ This parameter specifies the what type of data should be listed.

◦ commands

▪ type: empty


▪ default: none

▪ This parameter specifies that the available commands should be listed.

• If the help-mode is set to 'brief', then only the command names will be listed.

• If the help-mode is set to 'normal', then the XML prefix and the command name will be listed.

• If the help-mode is set to 'full', then the module name and the command name will be listed.

◦ files

▪ type: empty


▪ default: none

▪ This parameter specifies that all the data files in the current data search path should be listed.

◦ modules

▪ type: empty


▪ default: none

▪ This parameter specifies that all the YANG files in the current module search path should be listed.

◦ objects

▪ type: empty


▪ 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

Version 19.10-13



▪ 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


▪ 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 willbe displayed.

Positive Response:

• the requested information will be printed

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

Version 19.10-13


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>

Version 19.10-13


2.14.43 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.

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


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)


◦ 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:

Version 19.10-13


• the server returns <mod-revision>

Negative Response:



Usage:

andy@myserver> load toaster revision=2009-06-23


rpc-reply { mod-revision 2009-06-23 }

andy@myserver>

Version 19.10-13


2.14.44 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 andan '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



Min parameters: 1

Max parameters: 1

Return type: status




Command Parameters:

• target



◦ default: none

Version 19.10-13


◦ 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>

Version 19.10-13


2.14.45 log-debug

The log-debug command prints a message to the program log, if the $$log-level system variable is set to 'debug' or a higherenumeration (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


Command Parameters:

• msg

◦ type: string


◦ 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>

Version 19.10-13


2.14.46 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

Command type: local


Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• msg

◦ type: string


◦ default: none


Positive Response:


Negative Response:


Usage:

andy@myserver> log-error 'sysName not correct'

Error: sysName not correct

andy@myserver>

Version 19.10-13


2.14.47 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

Command type: local


Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• msg

◦ type: string


◦ default: none


Positive Response:


Negative Response:


Usage:

andy@myserver> log-info 'sysName is correct'

Info: sysName is correct

andy@myserver>

Version 19.10-13


2.14.48 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


Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• msg

◦ type: string


◦ default: none


Positive Response:


Negative Response:


Usage:

andy@myserver> log-warn 'sysName object not found'

Warning: sysName object not found

andy@myserver>

Version 19.10-13


2.14.49 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



Min parameters: 1

Max parameters: 5

Return type: status



Command Parameters:




◦ default: none

◦ This parameter specifies the where yangcli-pro should get the data from, for the merge operation. It is either auser variable or from interactive input at the command line.

▪ varref

• type: string


• default: none

• This parameter specifies the name of the user variable to use for the target of the merge operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.


• target

◦ type: string

◦ usage: optional (target or urltarget must be entered)

◦ default: none

Version 19.10-13


◦ This parameter specifies the database target node of the merge operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

• urltarget

◦ type: string

◦ usage: optional

◦ default: none

◦ This parameter specifies the database target node of the merge operation. This is an UrlPath string.

• optional

◦ type: empty

◦ usage: optional



• value

◦ type: anyxml


◦ default: none


• timeout


◦ usage: optional



System Variables:



• $$error-option


• $$test-option


Positive Response:

Version 19.10-13



Negative Response:



Usage:

andy@myserver> merge \target=/nacm/rules/moduleRule[moduleName='netconf']\[allowed-rights='read write']/allowed-group \value=ncx:guest



andy@myserver>

Reference:


Version 19.10-13


2.14.50 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

Command type: local

Default parameter: module

Min parameters: 1

Max parameters: 3

Return type: status


Command Parameters:

• module

◦ type: string (length 1 .. 63)


◦ 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

Version 19.10-13


Load module toaster OK

>

2.14.51 no-op

The no-op command is used to test server message processing response times, by providing a baseline response time to do nothing except return <ok/>.

It can also be used as an application-level keep-alive to prevent proxy idle timeout or server idle timeout problems from occurring.

This command is only supported by the netconfd-pro server. The server will simply respond 'OK', if the request is well-formed.


no-op command



Min parameters: 0

Max parameters: 0

Return type: status


Positive Response:


Negative Response:



Usage:

andy@myserver> no-op


andy@myserver>

Version 19.10-13


2.14.52 nvsave

The nvsave command is used to save the running datastore to the startup datastore on the current session.

If the server does not support the :startup capability then this command will fail. It has the save purpose as “copy-config source=running target=startup”.

no-op command

Command type: local


Min parameters: 0

Max parameters: 0

Return type: status


Positive Response:


Negative Response:



Usage:

andy@myserver> nvsave


andy@myserver>

Version 19.10-13


2.14.53 pwd

The pwd command is used to print the current working directory.

pwd command

Command type: local


Min parameters: 0

Max parameters: 0

Return type: status


Positive Response:

• the current working directory is printed to the log or STDOUT

Negative Response:


Usage:

> pwd

Current working directory is /home/andy

>

Version 19.10-13


2.14.54 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


Min parameters: 0

Max parameters: 0

Return type: none


Positive Response:

• The program terminates; no response will be printed.

Negative Response:


Usage:

> quit

andy@myworkstation>

Version 19.10-13


2.14.55 recall

The recall command is used to recall a previously entered command line from the command line history buffer.

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


Positive Response:

• The specified command line is recalled into the current command line.

Negative Response:


Usage:

> recall 7

> sget /system

Version 19.10-13


2.14.56 record-test

The record-test command is used to automatically record commands into a test script that is compatible with the test-suite command.

The start sub-command is used to start recording a test. Once recording starts, all the commands entered are recorded for the test.

The finish sub-command is used to finish recording a test. The recorded commands will be saved in the default or configured test suite file.

The cancel sub-command is used to cancel recording a test. The recorded commands will be discarded.

The pause sub-command is used to pause recording a test. The commands entered after this command will not be recorded.

The resume sub-command is used to resume recording a paused test. The commands entered after this command will be recorded.

record-test command

Command type: local

Default parameter: suite-name

Min parameters: 1

Max parameters: 3

Return type: status


Command Parameters:

•

• choice record-test-action (not entered)

▪ choice usage: mandatory

▪ default: case: none

▪ start-case

• start

◦ type: empty

◦ Start recording a new test or replace an existing test. Only one test can be recorded at a time.

• suite-name

◦ type: NcxIdentifier


◦ default: none

◦ This parameter specifies the name of the test suite to use.

• test-name

◦ type: NcxIdentifier

Version 19.10-13



◦ default: none

◦ This parameter specifies the name of the test to use.

▪ finish

• type: empty

• default: none

• Finish recording of the test in progress

▪ cancel

• type: empty

• default: none

• Cancel recording of the test in progress

▪ pause

• type: empty

• default: none

• Pause recording of the test in progress

▪ resume

• type: empty

• default: none

• Resume recording of the paused test in progress

Positive Response:

• The requested action is performed for the specified test-suite and test.

Negative Response:


Usage:

andy@myserver> record-test start suite1 test-name=test1

Start recording: suite=suite1 test=test1

andy@myserver>

Version 19.10-13


2.14.57 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



Min parameters: 0

Max parameters: 0

Return type: status


Positive Response:

• The previously granted locks are released.

Negative Response:



Usage: (showing 2 locks being released)

andy@myserver> release-locks

RPC OK Reply 8 for session 23: RPC OK Reply 9 for session 23:

andy@myserver>

Version 19.10-13


2.14.58 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



Min parameters: 1

Max parameters: 1

Return type: status


Capabilities needed: :base:1.1:candidate or :writable-running

Command Parameters:

• target

◦ type: string

◦ usage: optional (urltarget or target must be present)

◦ default: none

◦ This parameter specifies the database target node of the delete operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

System Variables:



• $$error-option


• $$optional


• $$test-option


Positive Response:


Version 19.10-13


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:


Version 19.10-13


2.14.59 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



Min parameters: 1

Max parameters: 5

Return type: status



Command Parameters:




◦ default: none

◦ This parameter specifies the where yangcli-pro should get the data from, for the replace operation. It is either a user variable or from interactive input at the command line.

▪ varref

• type: string


• default: none

• This parameter specifies the name of the user variable to use for the target of the replace operation. The parameter must exist (e.g., created with the fill command) or an error message will be printed.


• target

◦ type: string

◦ usage: optional (target or urltarget must be present)

◦ default: none

Version 19.10-13


◦ This parameter specifies the database target node of the replace operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

• urltarget

◦ type: string

◦ usage: optional

◦ default: none

◦ This parameter specifies the database target node of the replace operation. This is an UrlPath string.

• optional

◦ type: empty

◦ usage: optional



• value

◦ type: anyxml


◦ default: none


• timeout


◦ usage: optional



System Variables:



• $$error-option


• $$test-option


Positive Response:

Version 19.10-13



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 19.10-13


2.14.60 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



Min parameters: 0

Max parameters: 0

Return type: status


Positive Response:

• the server will drop all sessions and restart

Negative Response:



Usage:

andy@myserver> restart

ses: session 10 shut by remote peer

>

Version 19.10-13


2.14.61 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 passstring 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.

run command

Command type: local

Default parameter: script

Min parameters: 1

Max parameters: 10

Return type: status


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


◦ 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

Version 19.10-13


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)

andy@myserver>

Version 19.10-13


2.14.62 save

The save command is used to save NETCONF database edits to non-volatile storage, on the server. It is a pseudo-command, mapped to other remote commands depending on which database target is supported by the server (<candidate> or <running>).

The save command usually maps to either the commit or the copy-config command. Refer to the section on NETCONF sessions for more details.

save command



Min parameters: 0

Max parameters: 0

Return type: none


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>

Version 19.10-13


2.14.63 schema-server-cfg

The schema-server-cfg command is used to access a named schema server.


• create

• show

• delete

schema-server-cfg command

Command type: local


Min parameters: 1

Max parameters: 3

Return type: status



Command Parameters:

• create


◦ This parameter specifies a new schema server to create.

• show

◦ type: name string.

◦ This parameter specifies the name of the schema server to show.


• delete


This parameter specifies the name of the schema server to delete from the saved schema server in memory. An active schema server cannot be deleted.

Positive Response

• A message indicating the create or delete was done will be printed. The show command will generate some formatted output showing information on the requested schema server.

Negative Response:


Version 19.10-13


> schema-server-cfg create=schema-server-B user-id=userB device-id=deviceB

A new schema_server is created: schema_server-id=schema-server-B name=schema-server-B device=deviceB user=userB

> schema-server-cfg show=schema-server-B

Schema Server: schema-server-B Device Id: deviceB User Id: userB Connected: false

> schema-server-cfg delete=schema-server-B

Deleting saved schema_server 'schema-server-B'

Version 19.10-13


2.14.64 schema-servers-cfg

The scheam-servers-cfg command is used to access the named schema server files.


• clear

• load

• save

• show (default)

schema-servers-cfg command

Command type: local


Min parameters: 1

Max parameters: 2

Return type: status



Command Parameters:

• clear

◦ type: empty

◦ This parameter indicates that all saved schema servers in memory be deleted. This cannot be done if any of the schema servers are currently active. Use 'schema-servers-cfg load' to restore the saved schema servers.

• load

◦ type: string

◦ This parameter identifies the file specification for the saved chema servers to load. Any new named schema servers will be added to the named schema servers in memory.

• save


◦ This parameter identifies the file specification for the saved schema servers config file to load. The saved chema servers in memory will be saved to this file.

• show

◦ type: name string; default: empty string == all schema servers


Positive Response:

• A message indicating the load, save or clear was done will be printed. The show command will generate some formatted output showing information on the requested schema servers.

Version 19.10-13


Negative Response:


> schema-servers-cfg clear

Deleting 3 saved schema_servers

> schema-servers-cfg load=~/.yumapro/.yangcli_pro_schema_servers.conf-save

Loaded saved schema_servers OK from '~/.yumapro/.yangcli_pro_schema_servers.conf-save'

> schema-servers-cfg save

Saved 3 schema_servers OK to '~/.yumapro/.yangcli_pro_schema_servers.conf'

> schema-servers-cfg show

Saved schema_servers source: '~/.yumapro/.yangcli_pro_schema_servers.conf' Schema Server: schema-serverA

Device Id: deviceB User Id: userA Connected: false

Schema Server: schema-server-ACER Device Id: device-ACER User Id: user-ACER Connected: false

Schema Server: schema-server-asus2 Device Id: asus2-device User Id: asus2 Connected: false

Version 19.10-13


2.14.65 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 tobe 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.

session command

Command type: local

Default parameter: set-current

Min parameters: 1

Max parameters: 1

Return type: status



Command Parameters:

• set-default


◦ 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>

Version 19.10-13


2.14.66 session-cfg

The session-cfg command is used to access a named session.


• delete

• save

• show (default)


session-cfg command

Command type: local


Min parameters: 1

Max parameters: 2

Return type: status



Command Parameters:

• delete


◦ This parameter specifies the name of the session to delete from the saved sessions in memory. An active session cannot be deleted.

• save


◦ 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.


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:

Version 19.10-13



andy@myserver> session-cfg save session-A

Saving current session as 'session-A'

andy@myserver>

Version 19.10-13


2.14.67 sessions-cfg

The sessions-cfg command is used to access the named session files.


• clear

• load

• save

• show (default)


sessions-cfg command

Command type: local


Min parameters: 1

Max parameters: 2

Return type: status



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


◦ 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.

Version 19.10-13



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

Loading saved sessions from '/home/andy/more-sessions.conf' Loaded saved sessions OK from '~/more-sessions.conf'

session-A>

Version 19.10-13


2.14.68 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



Min parameters: 1

Max parameters: 1

Return type: status



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>

Version 19.10-13


2.14.69 set-my-session

The set-my-session command is used to configure the session customization parameters on the server. It is only supported by the netconfd-pro server.

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



Min parameters: 0

Max parameters: 4

Return type: status

YANG file: yuma-mysession.yang


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:


Version 19.10-13


Negative Response:


• An <rpc-error> message will be printed if the server detected an error.]

andy@myserver> set-my-session --linesize=64 --with-defaults=trim --message-indent=1


andy@myserver>

Version 19.10-13


2.14.70 sget

The sget command is used to invoke a NETCONF <get> operation with a subtree filter.

A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the nofill parameter.


sget command



Min parameters: 1

Max parameters: 6

Return type: data



Capabilities optional: :with-defaults

Command Parameters:




◦ 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


• 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

Version 19.10-13


◦ This parameter specifies the database target node of the <get> operation. This is an ncx:schema-instance string, so any instance identifier, or absolute path expression, or something in between, is accepted.

▪ The escape command ('?s') can be used in parameter mode to skip a parameter completely.

▪ Entering the empty string for a parameter will cause a subtree selection node to be created instead of a content match node

• urltarget

◦ type: string

◦ usage: optional

◦ default: none

◦ This parameter specifies the database target node of the get operation. This is an UrlPath string.

• optional

◦ type: empty

◦ usage: optional



• value

◦ type: anyxml


◦ 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


◦ usage: optional

◦ default: none

Version 19.10-13




• depth


◦ usage: optional




• module-tag:

◦ type: string

◦ 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 Data Reply 32 for session 10:

rpc-reply { data { system {

Version 19.10-13


sysName myserver.localdomain sysCurrentDateTime 2009-07-06T02:24:19Z sysBootDateTime 2009-07-05T19:22:28Z } } }

andy@myserver>

Reference:


Version 19.10-13


2.14.71 sget-config

The sget-config command is used to invoke a NETCONF <get-config> operation with a subtree filter.



sget-config command



Min parameters: 2

Max parameters: 7

Return type: data




Command Parameters:




◦ default: none


▪ varref

• type: string


• default: none



• target

◦ type: string


Version 19.10-13


◦ default: none




• 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


◦ default: none


• nofill

◦ type: empty

◦ usage: optional

◦ default: none




• source


Version 19.10-13



◦ default: none



▪ candidate

• type: empty


▪ running

• type: empty


▪ startup

• type: empty


▪ url

• type: yang:uri



• with-defaults


◦ usage: optional

◦ default: none



• depth


◦ usage: optional




• module-tag:

◦ type: string

◦ default: none


Version 19.10-13



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


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:

Version 19.10-13



2.14.72 sget-data

The sget-data command is used to invoke a NETCONF NMDA <get-data> operation with a subtree filter.

This command will not work unless the server supports the <get-data> operation from RFC 8526 ) ietf-netconf-nmda.yang).



sget-data command



Min parameters: 2

Max parameters: 8

Return type: data




Command Parameters:




◦ default: none


▪ varref

• type: string


• default: none

Version 19.10-13




• target

◦ type: string


◦ default: none




• 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


◦ default: none


• nofill

◦ type: empty

◦ usage: optional

◦ default: none

Version 19.10-13





• datastore

◦ type: leaf containing a datastore-ref


◦ This parameter specifies the name of the source NMDA datasotre for the retrieval operation.

◦ enumeration:

▪ candidate


▪ running


▪ startup


▪ operational


• with-defaults


◦ usage: optional

◦ default: none



• depth


◦ usage: optional



◦ This parameter controls how many levels of subtrees should be returned in the <rpc-reply>. This is called the <max-depth> parameter in the <get-data> operations.

• config-filter:

◦ type boolean

◦ Specifies the type of data based on config-stmt. Retrieve all data if this parameter is not present. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

◦ Only relevant if the datastore parameter is ‘operational’.

◦ If set to ‘false’ for any datastore other than ‘operational’ then an empty <data> element will be returned.

Version 19.10-13


• origin-filter:

◦ type: leaf-list of type origin-ref..

◦ This parameter will select data nodes with the specified origin. This is a top-down filter. It will not select nodeswithin a subtree if the ancestor nodes do not match the filter.

◦ Cannot be used if negated-origin-filter present

◦ Can only be used if the datastore parameter is ‘operational’

• negated-origin-filter:


◦ This parameter will select data nodes if they do not have the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

◦ Cannot be used if origin-filter present


• with-origin

◦ type: empty

◦ This parameter will cause the origin attribute to be added to data nodes returned by the server.


System Variables:

• $$timeout


• $$with-defaults


Positive Response:


Negative Response:



Output:

• data

◦ type: anyxml

◦ This element will contain the requested data from the database indicated by the source parameter.

Usage:

Reference:


Version 19.10-13


2.14.73 show

The show command is used to show program status and YANG details that may be needed during management of a NETCONF server.

There are several variants of the show command:

• The show cache command prints the yangcli-pro YANG module cache.

• The show connected command prints the all connected sessions.

• The show cli command prints the contents of the yangcli-pro CLI and config file parameters.

• The show diff command prints the differences between current config and the edits that have not been applied yet.

• The show edit command prints subtree that is the current node which is from the current edit, not the stored config.

• The show connected command prints a summary of the sessions that are currently connected

• The show global command prints the contents of one global user variable.

• The show globals command prints a summary or the contents of all the global user variables.

• The show local command prints the contents of one local user variable.

• The show locals command prints a summary or the contents of all the local user variables.

• The show module command prints meta information or help text for one YANG module.

• The show modules command prints meta information for all the currently available YANG modules. If a session is active, this will be the list of modules the server reported, plus any modules loaded with the mgrload command.

• The show modules-state command prints cached modules-state for each server.

• The show objects command prints the available objects or help text for the available objects.

• The show running command prints the entire config for the current session , error if there is no current session.

• The show session command prints the session startup screen information for the current session.

• The show system command prints the contents of the yangcli-pro system variables.

• The show terminal command prints the terminal length

• The show var command prints the contents of the specified variable.

• The show vars command prints a summary or the contents of all the program variables.

• The show version command prints the yangcli-pro version number

show command

Command type: local


Min parameters: 1

Max parameters: 2

Return type: data

Version 19.10-13



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

▪ cli

• type: empty


• default: none

• This parameter selects the yangcli-pro CLI and configuration variables.

◦ The help-mode parameter has no affect on this command.

▪ Connected

• type: empty


• default: none

• This parameter prints a summary of the currently connected sessions.


▪ diff

• type: empty


Version 19.10-13


• default: none

• The parameter prints the differences between current config and the edits that have not been applied yet.


▪ edit

• type: empty


• default: none

• The parameter prints subtree that is the current node which is from the current edit, not the stored config.


▪ global

• type: string


• 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


• default: none

• This parameter specifies that information for all global variables should be printed.

◦ If help-mode is 'brief', then the name, variable object, and type of each global variable object will be printed.

◦ If help-mode is 'normal' or 'full', then the contents of each global variable will be printed.

▪ local

• type: string


• 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 beprinted.

◦ If help-mode is 'normal' or 'full', then the contents of the specified local variable will be printed.

▪ locals

• type: empty

Version 19.10-13



• 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


• 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


• default: none

• This parameter specifies that information for all available modules should be printed:

◦ If help-mode is 'brief', then the name of each module will be printed.

◦ If help-mode is 'normal', then the XML prefix, name, and revision date of each module will be printed.

◦ If help-mode is 'full', then the name, revision date, prefix, namespace, and source of each module will be printed.

▪ objects

• type: empty


• 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


• default: none

Version 19.10-13


• This parameter prints the entire config for the current session , error if there is no current session.


▪ system

• type: empty


• default: none

• This parameter specifies that information for all system variables should be printed.


▪ terminal

• type: empty


• default: none

• This parameter specifies that information about the terminal settings should be printed.


▪ var

• type: string


• 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


• default: none

• This parameter specifies that information for all variables should be printed. This includes all CLI, read-only system, read-write system, global user, and local user variables.

◦ If help-mode is 'brief', then the name, variable object, and type of each variable object will be printed.

◦ If help-mode is 'normal' or 'full', then the contents of each variable will be printed.

▪ version

• type: empty


• 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.

Version 19.10-13


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>

andy@myserver> show running data { nacm { groups { group aa { name aa user-name a1 user-name a2 } } } }

andy@myserver> sho edit Only available in config mode.

andy@myserver> sho diff Only available in config mode.

andy@myserver> conf t andy@myserver# nacm groups andy@myserver(groups)# group bb andy@myserver(group)# user-name b1 andy@myserver(group)# user-name b2

andy@myserver(group)# do show edit nacm { groups { group bb { name bb user-name b1 user-name b2 }

Version 19.10-13


} }

andy@myserver(group)# do show diff Edited to merge: nacm { groups { group bb { name bb user-name b1 user-name b2 } } }

Configured: nacm { groups { group aa { name aa user-name a1 user-name a2 } } }

andy@myserver(group)# apply Applying 1 edit to session 'default' andy@myserver(group)# do sho running data { nacm { groups { group aa { name aa user-name a1 user-name a2 } group bb { name bb user-name b1 user-name b2 } } } } andy@myserver(group)#

Version 19.10-13


2.14.74 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



Min parameters: 0

Max parameters: 0

Return type: status


Positive Response:

• the server will drop all sessions and terminate.

Negative Response:



Usage:

andy@myserver> shutdown


>

Version 19.10-13


2.14.75 sleep

The sleep command is used to pause for a number of seconds. It is intended to be used within a script.

Example script:

# send 20 get-config requests, 1 per secondwhile 1 maxloops=20get-config source=runningsleep 1end

sleep command

Command type: local

Default parameter: seconds

Min parameters: 1

Max parameters: 1

Return type: none



Capabilities optional: none

Command Parameters:

• seconds

◦ type: uint16 (1 .. 3600)


◦ This parameter specifies the number of seconds to sleep

Positive Response:

• none

Negative Response:


Usage:

session-B> sleep 1

session-B>

Version 19.10-13


2.14.76 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-rpc-timing 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

Command type: local

Default parameter: statfile

Min parameters: 1

Max parameters: 1

Return type: status




Command Parameters:

• statfile

◦ type: file specification


◦ This parameter specifies the file specification for saving the timing statistics.

Positive Response:

• the client prints OK

Negative Response:


Usage:

Version 19.10-13


session-B> start-rpc-timing

OK

session-B>

Version 19.10-13


2.14.77 start-session

The start-session command is used to start a session with a NETCONF server. It is similar to the connect command exceptthe 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


Command Parameters:

• name

◦ type: session name string


◦ 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 user on myserver

NETCONF session established for user on myserver

Client Session Id: 2 Server Session Id: 4

Server Protocol Capabilities base:1.0 candidate:1.0 confirmed-commit:1.0 rollback-on-error:1.0 validate:1.0 url:1.0 xpath:1.0 notification:1.0

Version 19.10-13


interleave:1.0 partial-lock:1.0 with-defaults:1.0 base:1.1 validate:1.1 confirmed-commit:1.1 yang-library:1.0

Server Module Capabilities ietf-inet-types@2010-09-24 ietf-netconf-acm@2012-02-22 ietf-netconf-monitoring@2010-10-04 ietf-netconf-partial-lock@2009-10-19 ietf-netconf-with-defaults@2011-06-01 ietf-yang-library@2016-06-21 ietf-yang-types@2010-09-24 nc-notifications@2008-07-14 notifications@2008-07-14 yuma-app-common@2012-08-16 yuma-arp@2012-01-13 yuma-interfaces@2012-01-13 yuma-mysession@2010-05-10 yuma-ncx@2012-01-13 yuma-proc@2010-06-01 yuma-system@2012-01-15 yuma-time-filter@2011-08-13 yuma-types@2012-06-01 yumaworks-app-common@2012-08-16 yumaworks-extensions@2012-06-28

Server Enterprise Capabilities None Protocol version set to: RFC 6241 (base:1.1) Default target set to: <candidate> Save operation mapped to: commit Default with-defaults behavior: explicit Additional with-defaults behavior: trim,report-all,report-all-tagged Yang-Library set to: RFC 7895 module-set-id: 6765

Checking Server Modules...

session-B>

Version 19.10-13


2.14.78 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




Command Parameters:

• id

◦ type: number


◦ default: 0

◦ This parameter specifies the numeric ID of the timer.It is a number in the range 0 to 15.

• restart-ok

◦ type: boolean

◦ usage: optional

◦ default: true

◦ Indicates whether the timer will be used if it is already running. If 'true', the timer will be restarted if it is already running. If 'false', an error will occur if the timer is already running.

◦

Positive Response:


Negative Response:


Usage:

Version 19.10-13


andy@myserver> start-timer 1

OK

andy@myserver>

Version 19.10-13


2.14.79 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


Min parameters: 0

Max parameters: 0

Return type: status




Positive Response:


Negative Response:


Usage:

session-B> stop-rpc-timing

OK

session-B>

Version 19.10-13


2.14.80 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


Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• name

◦ type: session name string


◦ 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 19.10-13


2.14.81 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




Command Parameters:

• id

◦ type: number


◦ 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 19.10-13


andy@myserver>

Version 19.10-13


2.14.82 terminal

The terminal command is used to change the terminal settings.

It is used along with the “show terminal” command.

terminal command

Command type: local

Default parameter: length

Min parameters: 1

Max parameters: 1

Return type: none




Command Parameters:

• length

◦ type: number


◦ default: 0

◦ This parameter specifies the length of the terminal to use for page mode output with the -More- prompt. This parameter is ignored in batch mode. It is only used if the output session is operating in interactive mode.

If the value 0 is used then the 'More' prompt will be disabled. Otherwise this value represents the number of lines to output for each screen in pagination output mode.

Positive Response:

• OK

Negative Response:


Usage:

andy@myserver> terminal length 20

OK

andy@myserver>

Version 19.10-13


2.14.83 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


Min parameters: 0

Max parameters: 2

Return type: status




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 19.10-13


▪ 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:

Version 19.10-13


• The appropriate data will be shown for a 'show' sub-command.

Negative Response:


Usage:

andy@myserver> test-suite start ~/mytests.conf

... commands from test executed

andy@myserver>

Version 19.10-13


2.14.84 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



Min parameters: 1

Max parameters: 1

Return type: status




Command Parameters:

• target



◦ 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

Version 19.10-13




Positive Response:


Negative Response:



Usage:

andy@myserver> unlock target=candidate


andy@myserver>

Version 19.10-13


2.14.85 unset

The unset command is used to delete a command alias from memory.

unset command

Command type: local


Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• name

◦ type: string


◦ 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'

>

Version 19.10-13


2.14.86 user-cfg

The user-cfg command is used to access a named user.


• delete

• save

• show (default)

• create

Refer to the section on “NETCONF User Configuration” for more details on using saved users.

user-cfg command

Command type: local


Min parameters: 1

Max parameters: 3

Return type: status



Command Parameters:

• delete


◦ This parameter specifies the name of the user to delete from the saved users in memory. An active user cannotbe deleted.

• save


◦ This parameter specifies the name of the user to save in the saved users in memory.

• show

◦ type: name string; default: empty string == current user

◦ This parameter specifies the name of the user to show. An empty string indicates that the current user should be used.


• create


◦ This parameter specifies a new user to create.

Version 19.10-13


Positive Response:

• A message indicating the save or delete was done will be printed. The show command will generate some formatted output showing information on the requested user.

Negative Response:


andy@myserver> user-cfg save user-A

Saving current user as 'user-A'

andy@myserver>

> user-cfg create=usr1 user-name=admin password=password

A new user is created: user-id=usr1 name=admin password=password

Version 19.10-13


2.14.87 users-cfg

The users-cfg command is used to access the named user files.


• clear

• load

• save

• show (default)

Refer to the section on “NETCONF User Configuration” for more details on using saved users.

users-cfg command

Command type: local


Min parameters: 1

Max parameters: 2

Return type: status



Command Parameters:

• clear

◦ type: empty

◦ This parameter indicates that all saved users in memory be deleted. This cannot be done if any of the users arecurrently active. Use 'user-cfg load' to restore the saved users.

• load

◦ type: string

◦ This parameter identifies the file specification for the saved users to load. Any new named users will be added to the named users in memory.

• save


◦ This parameter identifies the file specification for the saved users config file to load. The saved users in memory will be saved to this file.

• show

◦ type: name string; default: empty string == all devices

Version 19.10-13


◦ This parameter specifies the name of the user to show.


Positive Response:

• A message indicating the load, save or clear was done will be printed. The show command will generate some formatted output showing information on the requested users.

Negative Response:


session-A> users-cfg load ~/more-users.conf

Loading saved users from '/home/andy/more-users.conf' Loaded saved users OK from '~/more-users.conf'

Version 19.10-13


2.14.88 uservars

The uservars command is used to clear, load, or save the global user variables.

uservars command

Command type: local


Min parameters: 1

Max parameters: 1

Return type: status


Command Parameters:

• uservars-action

◦ type: choice


◦ default: none

◦ clear:

▪ Delete all global user variables from memory

◦ load [uservars-filespec]

▪ Load global user variables into memory from an XML file.If the 'uservars-filespec' parameter is missing, then the default file($HOME/.yumapro/yangcli_pro_uservars.xml) will be used.

◦ save [uservars-filespec]

▪ Save the global user variables from memory into an XML file.If the 'uservars-filespec' parameter is missing, then the default file($HOME/.yumapro/yangcli_pro_uservars.xml) will be used.

Positive Response:

• A status message is printed.

Negative Response:

• An error message will be printed.

Usage:

> uservars clear

Deleted all global user variables from memory

Version 19.10-13


2.14.89 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



Min parameters: 1

Max parameters: 1

Return type: status


Capabilities needed: :validate


Command Parameters:

• target



◦ 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

Version 19.10-13




▪ config

• type: anyxml

• capabilities

• This parameter represents an entire database, using the in-line config form, similar to the edit-config 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


andy@myserver>

Version 19.10-13


2.14.90 while

The while command is used to start a conditional loop command block.

The expr parameter is used to specify the XPath expression to test if the while conditional loop block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.


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


Min parameters: 1

Max parameters: 3

Return type: status


Command Parameters:

• expr



◦ default: none


• docroot

◦ type: anyxml


◦ default: none


Version 19.10-13


• 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>

Version 19.10-13


2.14.91 xget

The xget command is used to invoke a NETCONF <get> operation with an XPath filter.

xget command


Default parameter: select

Min parameters: 1

Max parameters: 5

Return type: data



Capabilities optional: :with-defaults

Command Parameters:


◦ type: choice of case 'varref' or case 'select'


◦ 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


• default: none

• This parameter specifies the name of the user variable the contains the XPath expression for the XPathfilter 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


• default: none

• This parameter specifies the XPath expression to use for the XPath filter in the <get> operation.

• timeout


◦ usage: optional

Version 19.10-13




• with-defaults


◦ usage: optional

◦ default: none



• depth


◦ usage: optional




• module-tag:

◦ type: string

◦ 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:



Output:

• data

◦ type: anyxml

Version 19.10-13


◦ 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 19.10-13


2.14.92 xget-config

The xget-config command is used to invoke a NETCONF <get-config> operation with an XPath filter.

xget-config command



Min parameters: 2

Max parameters: 6

Return type: data




Command Parameters:




◦ 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


• default: none

• This parameter specifies the name of the user variable the contains the XPath expression for the XPathfilter 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


• default: none

• This parameter specifies the XPath expression to use for the XPath filter in the <get-config> operation.

Version 19.10-13


• source



◦ default: none



▪ candidate

• type: empty


▪ running

• type: empty


▪ startup

• type: empty


▪ url

• type: yang:uri



• timeout


◦ usage: optional



• with-defaults


◦ usage: optional

◦ default: none



• depth


◦ usage: optional

Version 19.10-13





• module-tag:

◦ type: string

◦ default: none



System Variables:

• $$timeout


• $$with-defaults


Positive Response:


Negative Response:



Output:

• data

◦ type: anyxml


Usage:

andy@myserver> xget-config /nacm/rules/data-rule \source=candidate


rpc-reply { data { nacm { rules { data-rule nacm-tree { name nacm-tree path /nacm:nacm allowed-rights {

Version 19.10-13


read write } allowed-group nacm:admin comment 'access to nacm config' } } } } }

andy@myserver>

Version 19.10-13


2.14.93 xget-data

The xget-data command is used to invoke a NETCONF NMDA <get-data> operation with an XPath filter.

This command will not work unless the server supports the <get-data> operation from RFC 8526 ) ietf-netconf-nmda.yang).

xget-data command



Min parameters: 2

Max parameters: 6

Return type: data




Command Parameters:




◦ 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


• default: none

• This parameter specifies the name of the user variable the contains the XPath expression for the XPathfilter 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


• default: none

Version 19.10-13


• This parameter specifies the XPath expression to use for the XPath filter in the <get-config> operation.

• datastore

◦ type: leaf containing a datastore-ref


◦ This parameter specifies the name of the source NMDA datasotre for the retrieval operation.

◦ enumeration:

▪ candidate


▪ running


▪ startup


▪ operational


• timeout


◦ usage: optional



• with-defaults


◦ usage: optional

◦ default: none



• depth


◦ usage: optional



◦ This parameter controls how many levels of subtrees should be returned in the <rpc-reply>. This is called the <max-depth> parameter in the <get-data> operations.

• config-filter:

◦ type boolean

Version 19.10-13


◦ Specifies the type of data based on config-stmt. Retrieve all data if this parameter is not present. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

◦ Only relevant if the datastore parameter is ‘operational’.

◦ If set to ‘false’ for any datastore other than ‘operational’ then an empty <data> element will be returned.

• origin-filter:


◦ This parameter will select data nodes with the specified origin. This is a top-down filter. It will not select nodeswithin a subtree if the ancestor nodes do not match the filter.

◦ Cannot be used if negated-origin-filter present


• negated-origin-filter:


◦ This parameter will select data nodes if they do not have the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

◦ Cannot be used if origin-filter present


• with-origin

◦ type: empty

◦ This parameter will cause the origin attribute to be added to data nodes returned by the server.

• Can only be used if the datastore parameter is ‘operational’

System Variables:

• $$timeout


• $$with-defaults

◦ The <with-defaults> parameter for the <get-data> operation will be derived from this system variable.

Positive Response:


Negative Response:



Output:

• data

◦ type: anyxml


Usage:

Version 19.10-13


Version 19.10-13


3 CLI ReferenceThe 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


Example: yangcli-pro --alt-names=false

Version 19.10-13


3.3 --ask-password

The --ask-password parameter controls whether the user will be prompted for a password for the “connect” command. Thismight be useful if keys are used instead for SSH authentication. If 'true' then the --no-password parameter can still be usedin the connect command instead of providing a password.

--ask-password parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --ask-password=false

3.4 --auto-discard-changes

The --auto-discard-changes parameter controls whether discard-change will be automatically sent on the errors of the edit and save mode.

• If true, discard-change will be automatically sent.

• If false, discard-change will not be automatically sent.

--auto-discard-changes parameter


Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --auto-discard-changes=true

Version 19.10-13


3.5 --auto-keepalive

The --auto-keepalive parameter Controls whether kepalive messages will be automatically sent on a connected session.

If 'true', keepalive message is sent every keepalive-interval.

If 'false', then keepalive message will not be sent..

This parameter is NOT IMPLEMENTED. IT IS IGNORED.

--auto-keepalive parameter


Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --auto-keepalive=true

3.6 --auto-reconnect

The --auto-reconnect parameter controls whether yangcli-pro will try to reconnect to the server If the session gets droppedby the server.

• If 'true', yangcli-pro will try to reconnect to the server.

• If 'false', yangcli-pro will not try to reconnect to the server.

--auto-reconnect parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --auto-reconnect=false

Version 19.10-13


3.7 --auto-reconnect-interval

The --auto-reconnect-interval parameter indicates the number of seconds yangcli-pro will wait to re-establish a connection if a session is dropped and the server becomes unreachable. The default is 10 seconds.

--auto-reconnect-interval parameter

Syntax uint16

Default: 10

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --auto-reconnect-interval=15

3.8 --auto-reconnect-max

The --auto-reconnect-max parameter controls the number of times to retry the connection. Zero means no limit, otherwise re-connect attempts will stop after this number of failures. The default is 5 times.

--auto-reconnect-max parameter

Syntax uint16

Default: 5

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --auto-reconnect-max=3

Version 19.10-13


3.9 --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.

--autoaliases parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autoaliases=false

3.10 --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


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autocomp=false

Version 19.10-13


3.11 --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 <get-config> NETCONF operation. If 'false', then automatic shadow configuration handling will not be done.

--autoconfig parameter


Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autoconfig=true

3.12 --autoconfig-conf-mode

The --autoconfig-conf-mode parameter controls whether the running configuration will be retrieved automatically for active sessions in config-mode.

• If autoconfig == TRUE then autoconfig-conf-mode is ignored and autoconfig will be done for config mode

• If autoconfig == FALSE then autoconfig-conf-mode is checked

• If TRUE, the autoconfig updates after each update will be done. The current config will be available to assist tab completion.

• If FALSE, the autoconfig updates after each update will not be done. The current config will not be available to assist tab completion.

--autoconfig-conf-mode parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --autoconfig-conf-mode=false

Version 19.10-13


3.13 --autodevices

The --autodevices parameter controls whether the saved devices will be loaded into memory at startup and saved to file at exit.

If true, the default device-cfg file will be used (~/.yumapro/.yangcli_pro_devices.conf) for loading and saving the configured devices in memory.

If false, the configured devices will only be stored and loaded manually with the devices-cfg command.

--autodevices parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autodevices=false

3.14 --autohistory

The --autohistory parameter controls automatic loading and saving of the command line history buffer in the yangcli-pro 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. The –history-file parameter specifies which file is usedto load and save the command line history.

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


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autohistory=false

Version 19.10-13


3.15 --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


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autoload=false

3.16 --autoload-cache

The --autoload-cache parameter controls whether the modules retrieved with the <get-schema> operation are cached for use by the running instance of yangcli-pro.

• If TRUE, then the YANG modules that are retrieved with the <get-schema> operation will be cached. A cached module will be used by yangcli-pro instead of calling <get-schema>, if that module revision is requested again.

• If FALSE, then the YANG modules that are retrieved with the <get-schema> operation will not be cached.

--autoload-cache parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1



Version 19.10-13


3.17 --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


Default: TRUE

Min Allowed: 0

Max Allowed: 1



3.18 --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 exits.

If FALSE, then the YANG modules that are cached will not be saved when yangcli-pro exits.

--autoload-save-cache parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --autoload-save-cache=false

Version 19.10-13


3.19 --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


Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autonotif=true

3.20 --autonvsave

The --autonvsave parameter controls whether the 'save' and 'apply' commands will NV-save the configuration changes or not. If the server advertises the :startup capability and this variable is set to 'false', then the final step to save running to startup will not be done. The 'nvsave' command can be used to manually save the running datastore to non-volatile memory (startup datastore). If this parameter is set to 'true' the final step of saving the running datastore to the startup datastore will be done.

--autonvsave parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autonvsave=false

Version 19.10-13


3.21 --autoschemaservers

The --autoschemaservers controls whether the saved schema servers will be loaded into memory at startup and saved to file at exit. If true, the default schemaserver-cfg file will be used (~/.yumapro/.yangcli_pro_schemaservers .conf) for loading and saving the configured schema servers in memory. If false, the configured schema servers will only be stored and loaded manually with the schemaserver-cfg command.

--autoschemaservers parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autoschemaservers=false

3.22 --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


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autosessions=false

Version 19.10-13


3.23 --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


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autotest=false

3.24 --autousers

The --autousers parameter controls whether the saved sessions will be loaded into memory at startup and saved to file at exit.

If true, the default users-cfg file will be used (~/.yumapro/.yangcli_pro_users.conf) for loading and saving the configured users in memory.

If false, the configured sessions will only be stored and loaded manually with the users-cfg command.

--autousers parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autousers=false

Version 19.10-13


3.25 --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


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --autouservars=false

3.26 --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.

• error: Do not use invalid parameter values.

--bad-data parameter

Syntax enumeration: ignore warn check error

Default: check

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --bad-data=warn

Version 19.10-13


3.27 --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


Example: yangcli-pro --batch-mode \ --run-script=~/run-tests

3.28 --binary-display-maxlen

The --binary-display-maxlen parameter specifies the maximum number of bytes to display when dumping the contents of a binary value. Normally a message will be displayed showing the name and length.

If this parameter is set to a value greater than zero then a standard 8-byte per line hex dump of the binary type will also be displayed for a maximum number of bytes set by this parameter.

--binary-display-maxlen parameter

Syntax uint32

Default: 0

Min Allowed: 0

Max Allowed: 1

Supported by: yangcli-pro, netconfd-pro

Example: yangcli-pro \ --binary-display-maxlen=100

Version 19.10-13


3.29 --break-key-mode

The --break-key-mode parameter specifies the bahavior when the break key is pressedduring a command. The default mode is 'program' to maintain backward compatibility.

program

Break key will cause the program to exit no matter what mode or state the program is in at the moment.

command

Break key will cause the current command in the current session to be terminated.

If no command is in progress, or currently in config mode or enable mode, then the break key will have no affect.

--break-key-mode parameter

Syntax enum (program | control)

Default: program

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --break-key-mode=command

3.30 --callhome-address

The --callhome-address parameter specifies the IP address that should be used to listen for callhome connections. Ignored if callhome-enabled is false.

--callhome-address parameter

Syntax Inet:ip-address

Default: 0.0.0.0

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --callhome-address=192.168.0.40

Version 19.10-13


3.31 --callhome-enabled

The --callhome-enabled parameter enables the Call Home protocol. If true, then yangcli-pro will listen for SSH CallHome connections on the socket identified by the callhome-address and callhome-port parameters.

--callhome-enabled parameter

Syntax boolean

Default: false

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --callhome-enabled=true

3.32 --callhome-port

The --callhome-port parameter specifies the TCP port number that should be used to listen for NETCONF over SSH callhome connections. Ignored if callhome-enabled is false.

--callhome-port parameter

Syntax Inet:port-number

Default: 4334

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --callhome-port=8400

Version 19.10-13


3.33 --callhome-tls-port

The --callhome-tls-port parameter specifies the TCP port number that should be used to listen for NETCONF over TLS callhome connections. Ignored if callhome-enabled is false.

--callhome-tls-port parameter

Syntax Inet:port-number

Default: 4335

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --callhome-tls-port=8401

3.34 --callhome-user

The --callhome-user parameter specifies the name of a configured user entry that should be used as the default user for callhome sessions, if no saved session entry is found matching the server IP address. Will be ignored if the user is not currently configured.

--callhome-user parameter

Syntax string

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --callhome-user=chuser1

Note that the user value is the name of a user-cfg entry, which has to be set up in advance for this parameter to have any effect.

Example user-cfg command for user “chuser1”

• username: fred

• password: secret1

Version 19.10-13


> user-cfg create chuser1 user-name=fred password=secret1

3.35 --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 theoperation 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

Syntax boolean

Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --check-output=false

3.36 --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


Example: yangcli-pro --check-output-error=true

Version 19.10-13


3.37 --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

Syntax boolean

Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --check-replies=false

3.38 --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 tobe 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


Example: yangcli-pro \ --check-replies-error=true

Version 19.10-13


3.39 --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

Syntax string: complete file specification of the text fileto parse for more parameters.

Default: /etc/yumapro/<program-name>.conf

Min Allowed: 0

Max Allowed: 1

Supported by: netconfd-proyangcli-proyangdiff-proyangdump-pro

Example: yangcli-pro testmod \ --config=~/testconf.conf

3.40 --config-autosave

The --config-autosave parameter controls how edits in config term mode are saved to NV-storage if the server supports the :startup capability. If 'true', automatically copy running to startup when an edit is applied. If 'false', no automatically copy from running to startup when an edit is applied. The user will enter 'save' or 'copy-config' manually once config term mode is exited.

--config-autosave parameter

Syntax boolean

Default: TRUE

Min Allowed: 0

Max Allowed: 1

Supported by: yancli-pro

Example: yangcli-pro --config-autosave=true

Version 19.10-13


3.41 --config-commit-mode

The --config-commit-mode parameter controls how edits will be commited in configuration mode.

"If 'true' then edits done in config mode will be made to the candidate datastore if possible. The edits will not be committed to the running datastore automatically. Instead, <config-commit> command in config mode, or <commit> operation in normal mode is required to activate the edits in the server. If 'false' then edits done in config mode will be committed to the running datastore after each 'apply' or 'exit' command in config mode.";

The default configuration commit mode is 'false'.

--config-commit-mode parameter

Syntax boolean

Default: false

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --config-commit-mode=true

3.42 --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

• 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 manual

Default: level

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --config-edit-mode=line

Version 19.10-13


3.43 --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

Syntax string: list of directory specifications

Default: $YUMAPRO_DATAPATH environment variable

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --datapath=”~/work2:~/data”

3.44 --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


Example: yangcli-pro --default-module=testmod

Version 19.10-13


3.45 --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

Syntax module name or filespec

Default: none

Min Allowed: 0

Max Allowed: unlimited

Supported by: netconfd-proyangcli-proyangdump-pro

Example: yangcli-pro \ --module=test1 \ --deviation=test1_deviations

Version 19.10-13


3.46 --disable-command

The --disable-command parameter specifies a top-level command that should be disabled and not visible or available to a user. If the value does not contain a module name prefix, then the command will be disabled in all modules.

--disable-command parameter

Syntax nt:NcxIdentifier

Default: none

Min Allowed: 0



Example: yangcli-pro \ --disable-command=nc:delete-config

Version 19.10-13


3.47 --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, sincethese 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

Syntax enumeration: plain prefix module xml xml-nons json

Default: plain

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --display-mode=module

Version 19.10-13


3.48 --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 notificationsto 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


Example: yangcli-pro \ --echo-notif-loglevel=info

3.49 --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


Example: yangcli-pro --echo-notifs=false

Version 19.10-13


3.50 --echo-replies

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


Example: yangcli-pro --echo-replies=false

3.51 --encoding

The --encoding parameter identifies the desired encoding format for RESTCONF request messages.

The supported values are ‘xml’ and ‘json’.

--encoding parameter

Syntax enum (xml | json)

Default: xml

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --encoding=json

Version 19.10-13


3.52 --entry-point

The --entry-point parameter identifies the RESTCONF entry point. Use this string instead of retrieving the XRD from the RESTCONF server to discover the entry point.

--encoding parameter

Syntax string

Default: /restconf

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --entry-point=/api/restconf

3.53 --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:

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


Supported by: yangcli-proyangdiff-proyangdump-pronetconfd-pro

Example: yangcli-pro \ --feature-disable=test:feature1

Version 19.10-13


3.54 --feature-enable

The --feature-enable parameter directs all programs to enable a specific feature.

This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name:

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



Example: yangcli-pro \ --feature-enable=test:feature1

Version 19.10-13


3.55 --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 forthat feature.

--feature-enable-default parameter


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --feature-enable-default=false

3.56 --fill-optional

The --fill-optional parameter controls the default for the --optional parameter that can be passed to many interactive commands such as 'fill' or 'create'.

If 'true' then the user will be prompted to enter optional nodes while filling YANG datastore content.

If 'false' then the user will not be prompted to enter optional nodes while filling YANG datastore content.

--fill-optional parameter


Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: Yangcli-pro --fill-optional=true

Version 19.10-13


3.57 --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


Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --fixorder=false

3.58 --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


Example: yangcli-pro --force-target=running

Version 19.10-13


3.59 --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.

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


Example: yangcli-pro --help

3.60 --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


Example: yangcli-pro --help --help-mode=full

• default choice: normal

Version 19.10-13


• choice help-mode

◦ brief

▪ type: empty


◦ normal

▪ type: empty


◦ full

▪ type: empty


3.61 --help-width

The --help-width parameter specifies the line width to use when displaying help text for the help key '?' within config term mode. This help mode aligns the description to the right of the widest object node name being displayed.

If the 'help' extension is used, then that text is displayed in its entirety. Otherwise the total line width will be limited to this help-width value.

--help-width parameter

Syntax uint16 (80 .. 511)

Default: 80

Min Allowed: 0

Max Allowed: 1


Example: Yangcli-pro --help-width=130

Version 19.10-13


3.62 --history-file

The --history-file parameter specifies the file location for the libtecla command line history file used if --autohistory is 'true'. This file will be created if if does not exist and the --autohistory parameter is 'true'.

--history-file parameter

Syntax string

Default: ~/.yumapro/.yangcli_pro_history

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --history-file=~/my-history.txt

3.63 --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


Example: yangcli-pro --home=~/testmodules

Version 19.10-13


3.64 --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

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --ignore-missing-vars=true

3.65 --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


Default: 2

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --indent=4

Version 19.10-13


3.66 --insecure-ok

The --insecure-ok parameter specifies if insecure NETCONF over TLS should be allowed. If true then X.509 certificates will be accepted even if they cannot be verified. Used for debugging only!

This parameter is only available if the image was built with the DEBUG=1 parameter.

--insecure-ok parameter

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1

Supported by: netconfd-proyangcli-pro

Example: yangcli-pro --insecure-ok=true

3.67 --keepalive-interval

The --keepalive-interval parameter Specifies the time interval, in seconds, between keepalive messages sent from a session. This value is only used if 'auto-keepalive' is true. NOT IMPLEMENTED. IGNORED BY PROGRAM.

-- keepalive-interval parameter


Default: 4

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --keepalive-interval=10

Version 19.10-13


3.68 --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


Example: netconfd-pro --log=~/server.log&

3.69 --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.

--log-append parameter

Syntax empty

Default: none

Min Allowed: 0

Max Allowed: 1


Example: netconfd-pro --log-append \ --log=~/server.log&

Version 19.10-13


3.70 --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


Example: netconfd-pro --log-backtrace=0

3.71 --log-backtrace-detail

The --log-backtrace-detail adds compiler/OS dependent information to the output of --log-backtrace.

--log-backtrace-detail parameter

Syntax empty

Default: none

Min Allowed: 0

Max Allowed: 1


Example: netconfd-pro --log-backtrace=0 \ --log-backtrace-detail

Version 19.10-13


3.72 --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 debug4One of more enumeration(s) may be specified by enclosing the string in double quotes ('”') andseparating each member with a space.

Default: none

Min Allowed: 0

Max Allowed: 1


Example: Netconfd-pro --log-backtrace=0 \ --log-backtrace-level=”error debug”

Version 19.10-13


3.73 --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

Syntax Enumeration:logfilestdoutstderrsyslogvendorOne or more enumeration(s) may be specified by enclosing the string in double quotes ('”') andseparating each member with a space.

Default: none

Min Allowed: 0

Max Allowed: 1


Example: netconfd-pro --log-syslog \ --log=server.log \ --log-backtrace=0 \ --log-backtrace-stream=”logfile”

3.74 --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


Example: Netconfd-pro --log=file \ --log-syslog --log-console &

Version 19.10-13


3.75 --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

Syntax Enumeration:customlocaltimeOne or more enumeration(s) may be specified by enclosing the string in double quotes ('”') andseparating each member with a space.

Default: none

Min Allowed: 0

Max Allowed: 1


Example: netconfd-pro --log-append \ --log=~/server.log \ --log-header=”custom localtime”&

Version 19.10-13


3.76 --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


Example: netconfd-pro --log-level=debug \ --log=~/server.log&

Version 19.10-13


3.77 --log-mirroring

The --log-mirroring parameter is a synonym for --log-console.

3.78 --log-stderr

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


Example: netconfd-pro --log-stderr > logFile&! All log messages redirected to logFile except ...! Error level messages displayed on console

3.79 --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


Example: netconfd-pro --log-suppress-ctrl

Version 19.10-13


3.80 --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

Syntax empty

Default: none

Min Allowed: 0

Max Allowed: 1


Example: netconfd-pro --log-syslog

Version 19.10-13


3.81 --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

Syntax enumeration: off error warn info debug debug2 debug3 debug4

Default: --info (--debug for DEBUG builds)

Min Allowed: 0

Max Allowed: 1


Example: Netconfd-pro --log=logfile \> --log-level=debug \> --log-syslog \> --log-syslog-level=info &

Version 19.10-13


3.82 --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


Example: yangcli-pro --match-names=exact

Version 19.10-13


3.83 --message-indent

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


Example: yangcli-pro --message-indent=2

3.84 --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


Default: $YUMAPRO_MODPATH environment variable

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --modpath=”~/testmodules:~/modules:~/trunk/netconf/modules”

Version 19.10-13


3.85 --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.

--module parameter

Syntax module name or filespec

Default: none

Min Allowed: 0



Example: yangcli-pro \ --module=test1 \ --module=test2

3.86 --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


Example: yangcli-pro --server=myserver --ncport=22 \ --user=fred --password=mypassword

Version 19.10-13


3.87 --no-aliases

The --no-aliases disables the alias substitution feature. The alias file will not be read. The aliases and alias commands will be disabled. The default is not present

--no-aliases parameter

Syntax empty

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro –-no-aliases

3.88 --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

Syntax empty

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --no-config

Version 19.10-13


3.89 --no-password

The --no-password parameter indicates that no user password is needed for the connection. It is used when connecting to a server in batch mode.

--no-password parameter

Syntax empty

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --no-password \ [server connect parms]

3.90 --optional

The --optional parameter specifies the the default for the $$optional global variable.

If 'true' then the user will be prompted to enter optional nodes for all input.

If 'false' then the user will not be prompted to enter optional nodes for all input.

This parameter affects all YANG input and should normally not be used. The fill-optional parameter should be used

instead.

--optional parameter

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --optional=true

Version 19.10-13


3.91 --password

The --password parameter specifies the password string that should be used when a NETCONF session is connected duringthe startup of the program.

--password parameter

Syntax string

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --server=myserver \ --password=yangrocks \ --user=andy

3.92 --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


Example: yangcli-pro \ --private-key=~/.ssh/mykey

Version 19.10-13


3.93 --prompt

The --prompt parameter is used to set the command line prompt to the user defined value.

This parameter is supported only for yp-shell.

The prompt can also be set using the $$prompt variable at any time. If the --prompt CLI parameter is set

then that value will be used as the prompt when yp-shell starts. If prompt is used, prompt-name and prompt-type will be ignored.

--prompt parameter

Syntax String (length "1 .. 512")

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --prompt=session1

3.94 --prompt-name

The --prompt-name parameter customize yumaworks as prompt name for yp-shell.

--prompt-name parameter

Syntax String (length "1 .. 512")

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --prompt-name=yumaworks

Version 19.10-13


3.95 --prompt-type

The --prompt-type parameter specifies the verbosity of the prompt storing.

The values allowed are 'brief', 'normal' and 'full'.

--prompt-type parameter

Syntax enum: brief normal full

Default: normal

Min Allowed: 0

Max Allowed: 1


Example: Yangcli-pro --prompt-type=full

3.96 --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


Example: yangcli-pro –protocols=netconf1.0

Version 19.10-13


3.97 --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

Syntax string

Default: $HOME/.ssh/id_rsa.pub

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro –public-key=~/.ssh/mykey.pub

3.98 --restrict-edit-mode

The --restrict-edit-mode parameter controls whether an 'restrict edit mode' will be supported for yp-shell.

If true then the yp-shell editing commands (create, merge, replace, delete, remove, insert, delete-all, remove-all, nvsave) will not be available to the user. Also, the NETCONF edit-config, copy-config, delete-config, commit, cancel-commit, discard-changes commands will not be available to the user. If true then only the config mode will be available for editing configuration data on the server. This parameter can be used instead of specifying individual disable-command parameters for the editing commands.

-- restrict-edit-mode


Default: FALSE

Min Allowed: 0

Max Allowed: 1

Supported by: yp-shell

Example: yp-shell –restric-edit-mode=true

Version 19.10-13


3.99 --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


Default: $YUMAPRO_RUNPATH environment variable

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --runpath=”~/testscripts”

3.100 --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


Example: yangcli-pro \ --run-command="history load=~/test3-history"

Version 19.10-13


3.101 --run-script

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


Example: yangcli-pro \ --run-script="test3-start"

3.102 --save-session-vars

The --save-session-vars parameter specifies if session variables will be saved when the program exits. If use-session-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


Example: yangcli-pro --save-session-vars=false

Version 19.10-13


3.103 --script-input

The --script-input parameter specifies whether scripts run in interactive mode should attempt to fill in missing command parameters from the CLI command line or not.

If TRUE, then the user will be prompted for input when needed.

If FALSE, then script commands will be attempted with whatever parameters are present in the script.

--script-input parameter

Syntax boolean

Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --script-input=false

3.104 --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

Syntax string:IP address or DNS name

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --server=myserver

Version 19.10-13


3.105 --server-commands

The --server-commands parameter specifies whether RPC operations learned from server YANG modules will be added asa command available to the user. The module ietf-netconf is exempt from this parameter. Use the disable-command parameter to disable individual NETCONF operations.

--server-commands parameter

Syntax boolean

Default: true

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --server-commands=false

3.106 --ssl-certificate

The --ssl-ceriticate parameter contains the file path specification for the file containing the client-side SSL certificate.

If both 'certificate' and 'key' files are present, the client will attempt to setup a secure connection with the server using the certificate and SSL key.

If this fails, and the 'ssl-fallback-ok' leaf is set to true, the client will attempt to setup a raw TCP connection with the server.

--ssl-certificate parameter

Syntax filespec

Default: $HOME/.ssl/yangapi-client.crt

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --ssl-certificate=~/certs/client.crt

Version 19.10-13


3.107 --ssl-fallback-ok

The --ssl-fallback-ok parameter controls SSL connection behavior. If true then an attempt to establish a plain TCP connection will be made if an SSL connection cannot be made. This parameter only applies of the 'transport' is 'ssl'.

--ssl-fallback-ok parameter

Syntax boolean

Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --ssl-fallback-ok=false

3.108 --ssl-key

The --ssl-key parameter contains the file path specification for the file containing the client-side SSL key certificate.

If both 'certificate' and 'key' files are present, the client will attempt to setup a secure connection with the server using the certificate and SSL key.

If this fails, and the 'ssl-fallback-ok' leaf is set to true, the client will attempt to setup a raw TCP connection with the server.

--ssl-key parameter

Syntax filespec

Default: $HOME/.ssl/yangapi-client.key

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --ssl-key=~/certs/client.key

Version 19.10-13


3.109 --ssl-trust-store

The --ssl-strust-store parameter contains the file path specification for the file containing the client-side ssl trust-store, orthe path specification for the directory to use for finding trusted certificates. If the default value is used and the file is not found, then the default directory location '/etc/ssl/certs' will be used.

--ssl-trust-store parameter

Syntax filespec

Default: $HOME/.ssl/trust-store.pem/etc/ssl/certs directory

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --ssl-trust-store=\ $HOME/certs/trust-store.pem

3.110 --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


Example: yangcli-pro --subdirs=false

Version 19.10-13


3.111 --term-length

The --term-length parameter specifies the length of the terminal to use for page mode output with the -More- prompt. This parameter is ignored in batch mode. It is only used if the output session is operating in interactive mode.

If the value 0 is used then the 'More' prompt will be disabled. Otherwise this value represents the number of lines to output for each screen in pagination output mode.

--term-length parameter

Syntax uint16 (0..511)

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --term-length=24

3.112 --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


Example: yangcli-pro \ --test-suite-file=~/mytests.conf

Version 19.10-13


3.113 --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.";

--time-rpcs parameter

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --time-rpcs=true

3.114 --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


Example: yangcli-pro --time-rpcs-stats=true

Version 19.10-13


3.115 --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


Default: $HOME/yangcli_pro_rpc_stats.txt

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --time-rpc-stats-file=~/mystats.txt

3.116 --timeout

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


Example: yangcli-pro --timeout=0

Version 19.10-13


3.117 --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'.

--transport parameter

Syntax Enum (ssh, tcp, or tpc-ncx)

Default: ssh

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --transport=tcp-ncx

3.118 --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.

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


Example: yangcli-pro \ --use-data-templates=false

Version 19.10-13


3.119 --use-rawxml

The --use-rawxml parameter specifies how file result variables will be read for XML files. Controls whether the XML willbe parsed against the target YANG object (the default) or injected into a variable or request message from the raw XML textin the file.

--use-rawxml parameter

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --use-rawxml=true

3.120 --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 globalvariable assignments will affect the global instance of the variable, and be visible to all sessions.

--use-session-vars parameter

Syntax boolean

Default: TRUE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --use-session-vars=false

Version 19.10-13


3.121 --use-traceid

The --use-traceid parameter controls whether the 'trace-id' attribute will be set in the RPC calls or not. By default, 'trace-id' attribute is disabled. If 'true', then the XML RPC will contain 'trace-id' attribute.

--use-traceid parameter

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --use-traceid=true

3.122 --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


Example: yangcli-pro --use-xmlheader=false

Version 19.10-13


3.123 --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


Example: yangcli-pro --user=admin \ --server=myserver

3.124 --uservars-file

The --uservars-file parameter contains the file specification of the user global variables XML file to use.

--uservars-file parameter


Default: $HOME/.yumapro/yangcli_pro_uservars.xml

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ -–uservars-file=~/myvars.xml

Version 19.10-13


3.125 --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 19.10-13

This parameter can be combined with the --help parameter.

--version parameter

Syntax empty

Default: none

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --version

Version 19.10-13


3.126 --warn-error

The --warn-error parameter controls whether all warnings are elevated to errors.

If ‘true’ then warnings that are enabled will be elevated to errors for reporting purporses.

If the –warn-off parameter is entered for a specific error, that warning is considered disabled, and will not be elevated to an error.

--warn-error parameter

Syntax boolean

Default: false

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --warn-error=true

3.127 --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

Syntax uint32: 0 to disable, or 8 .. 1023

Default: 64

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --warn-idlen=50

Version 19.10-13


3.128 --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


Example: yangcli-pro --warn-linelen=79

3.129 --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

Syntax uint32: 1000 .. 1999

Default: none

Min Allowed: 0



Example: yangcli-pro --warn-off=1022

Version 19.10-13


3.130 --warn-up

The --warn-up parameter elevates a specific warning number to an error.

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 elevated for all modules. An error message will be printed and the warning will be counted towards the error total for that module.

--warn-up parameter

Syntax uint32: 1000 .. 1999

Default: none

Min Allowed: 0



Example: yangcli-pro --warn-up=1022

Version 19.10-13


3.131 --wildcard-keys

The --wildcard-keys parameter is used to enable wildcards on key leaf values.

Set to 'true' if UrlPath targets for GET operations are allowed to replace key values with the dash '-' character to indicate that all instances of that key are requested.

Set to false to treat the '-' character as a plain character if entered as a key value in a UrlPath string.

--wildcard-keys parameter

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --wildcard-keys=true

3.132 --with-enable-mode

The –with-enable-mode parameter controls whether an 'enable mode' will be supported for yp-shell.

If set to 'true', the user must enter the 'enable' command to enter enable mode. If the 'enable password' has been configuredthen this password must be provided by the user in order to enter enable mode. Within enable mode, the 'config term' command can be used to enter configuration mode. If set to 'false', then enable mode will not be used and the 'enable', 'enable password', and “enable no-password” will not be present.

--with-enable-mode


Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yp-shell –with-enable-mode=true

Version 19.10-13


3.133 --with-notif-commands

The –with-notif-commands parameter controls whether notifications will be supported for yp-shell.

If ‘true’ then yp-shell should include the create-subscription and cancel-subscription commands.

This parameter does not affect yp-shell echoing of notification messages. The --echo-notifs and --echo-notif-loglevel parameters need to be set appropriately to echo received notification messages.

--with-notif-commands


Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yp-shell –with-notif-commands=true

3.134 --with-ocpattern

The --with-ocpattern parameter controls whether the server will support the OpenConfig usage of the YANG pattern statement.

• If true, then OpenConfig patterns with be checked

◦ If the module name starts with the string 'openconfig-' then all pattern statements within that module are treated as POSIX patterns, not YANG patterns.

◦ Otherwise the module pattern statements will be checked as YANG patterns.

• If false, then the pattern statements in all modules will be checked as YANG patterns.

--with-ocpattern parameter

Syntax boolean

Default: FALSE

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro --with-ocpattern=true

Version 19.10-13


3.135 --with-term-msg

The --with-term-msg parameter controls whether the server will support Terminal Diagnostic messages.

If set to 'true', then the yumaworks-term-msg module will be loaded and enabled. Otherwise, this module will not be loaded.The <term-msg> notification is used by yp-shell for displaying terminal diagnostic messages.

The yp-shell and yangcli-pro programs will automatically display the <term-msg> as a terminal message if the --with-term-msg parameter is set to ‘true’. If no <term-msg> events are sent by the server then this parameter has no effect.

For yp-shell, the --autonotif=true parameter setting must also be used, in order for this parameter to have any affect.

--with-term-msg parameter

Syntax boolean

Default: TRUE

Min Allowed: 0

Max Allowed: 1

Supported by: netconfd-proyangcli-proyp-shell

Example: yangcli-pro --with-term-msg=false

3.136 --yangmap

The --yangmap parameter specifies a yangmap XML file that should be loaded into the program. See yumaworks-yangmap.yang for details on using YANG mappings in config term mode.

--yangmap parameter

Syntax string

Default: none

Min Allowed: 0



Example: yangcli-pro \ --yangmap=~/HOME/maps/map1.xml

Version 19.10-13


3.137 --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 parameteris 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

◦ This sub-tree is searched for YANG files.

• $YUMAPRO_HOME/data

◦ This directory is searched for data files.

• $YUMAPRO_HOME/scripts

◦ This directory is searched for yangcli-pro script files.

yuma-home parameter

Syntax string: directory specification

Default: $YUMAPRO_HOME environment variable

Min Allowed: 0

Max Allowed: 1


Example: yangcli-pro \ --yumapro-home=~/sw/netconf \ --log=~/test.log&

Version 19.10-13

yumapro yangcli-pro manual - yumaworks · yumapro yangcli-pro manual yang-based unified modular...

Documents