../_images/logo.png

YumaPro yangcli-pro Manual

  • YANG-Based Unified Modular Automation Tools

  • NETCONF Over SSH Client

  • NETCONF Over TLS Client

  • RESTCONF Over HTTP(S) Client

  • NETCONF Over SSH Call Home Server

  • NETCONF Over TLS Call Home Server

Program Components

../_images/yangcli-pro_featured_img_081417.png

yangcli-pro Introduction

The yangcli-pro program is a NETCONF over SSH client application. It is driven directly by YANG modules, and provides a simple but powerful application interface that can utilize any YANG file to drive the user interface. Full server management features and server testing features are supported. There is no configuration required at all to use any YANG file, since the yangdump-pro YANG compiler is built into the application.

yangcli-pro Features

The yangcli-pro client has the following features:

  • Support for multiple sessions to multiple servers at once

  • Support for configured named sessions saved in a secure configuration file

  • Easy to use configuration mode for editing; provides an IOS CLI-like user interface to edit server configurations

    • Command line history, recall

    • Output filtering with 'pipe' commands

    • Terminal pagination with –More-- prompt controls

  • Supports NETCONF 1.0, NETCONF 1.1, and RESTCONF protocols

  • Automated session reconnect for NETCONF and RESTCONF sessions

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

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

  • Automated regression testing support to verify server operation, including

    • setup and cleanup sections per test-suite

    • multiple tests per suite

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

  • Automatic recording of test suites

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

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

  • Automatic monitoring of server notifications

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

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

  • Automatic shadowing of the running configuration

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

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

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

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

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

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

      • module namespace

      • module name

      • module revision date

      • enabled features

      • names of any modules that contain deviations for this module

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

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

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

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

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

  • Supports NETCONF notifications, including :interleave capability.

  • Full XPath 1.0 and subtree filtering support.

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

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

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

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

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

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

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

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

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

  • Command line history and command recall.

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

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

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

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

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

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

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

  • Configurable NETCONF Call-Home over SSH support (RFC 8071)

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

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

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

  • Ability to invoke yangcli or shell scripts to automate command processing

  • Supports the Event Condition Action (ECA) to allow the user to run shell scripts based on a notification.

Starting yangcli-pro

The current working directory in use when yangcli-pro is invoked is important. It is most convenient to run yangcli-pro from a work directory, rather than the installation directory or within the module library.

The yangcli-pro program can be invoked several ways:

  • To get the current version and exit:

    yangcli-pro --version
    
  • To get program help and exit:

    yangcli-pro --help
    
    yangcli-pro --help --brief
    
    yangcli-pro --help --full
    
  • To start an interactive session with the default parameters:

    yangcli-pro
    
  • To start an interactive session with a new log file:

    yangcli-pro --log=mylogfile
    
  • To start an interactive session and append to an existing log file:

    yangcli-pro --log=mylogfile --log-append
    
  • To get parameters from a configuration file:

    yangcli-pro --config=~/yangcli-pro.conf
    
  • To begin to connect to a server upon startup, provide the --server parameter. The connect command will be started upon startup and the user will be prompted to enter the rest of the mandatory parameters to the connect command.

    yangcli-pro server=myserver.example.com
    
  • To connect to a server and automatically connect without any interactive interruption, enter the --server, --user, and --password parameters. A session startup will be attempted right away, using these parameters. Any optional parameters for the connect command (e.g., --port or --timeout) may be entered as well. All parameters can be entered from a config file, and/or the command line.

    yangcli-pro --server=myserver.example.com --user=andy --password=yangrocks
    
  • To automatically connect to a server, run a script in non-interactive mode, and then remain connected to the server, add the --run-script parameter to the connection parameters. The --runpath parameter can also be entered, if needed.

    yangcli-pro --run-script=mytestscript --server=myserver.example.com --user=andy --password=yangrocks
    
  • To automatically connect to a server, run a script in non-interactive mode, and then exit the program, add the --batch-mode and --run-script parameters to the connection parameters. The --runpath parameter can also be entered, if needed.

    yangcli-pro --run-script=mytestscript --batch-mode --server=myserver.example.com --user=andy --password=yangrocks
    
  • To automatically connect to a server, and run a single command instead of a script, and then exit, use the --run-command parameter instead of the --run-script parameter. The --batch-mode parameter can be left out to remain in the current session (in interactive mode) after the command is invoked.

    yangcli-pro --run-command=”sget /system”  --batch-mode --server=myserver.example.com --user=andy --password=yangrocks
    
  • To automatically connect to a server, and just listen for notifications, and never exit, use the --autonotif=true** parameter instead of the --run-command or --run-script parameter. The --batch-mode parameter must be provided in this mode.

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

Stopping yangcli-pro

To terminate the yangcli-pro program, use the quit command.

The control-C character sequence will also cause the program to be terminated.

Statements

The yangcli-pro script interpreter accepts several types of statements:

yangcli-pro Statements

type

description

example

command

invoke a local command and/or send an <rpc> to the server

sget /system

variable assignment

set a user variable to some value

$system = sget /system

file assignment

set the contents of a file to some value

@save.txt = $system

variable deletion

delete a user variable or clear a system variable

$system =

A command can be as simple like 'get' or complex, like 'edit-config'.

A variable assignment sets the specified user or system variable to the right hand side of the expression. An expression has many forms, including the result from a local command or a remote NETCONF operation.

If a string that matches a command is used as the assignment value, then it must be entered in quotes (single or double). For example, the $$default-operation system configuration variable accepts enumeration values which also match RPC commands:

> $$default-operation = 'merge'

A file assignment is essentially the same as a variable assignment, except the right hand side of the expression is saved in the specified file, instead of a user variable.

To delete a user variable, leave the right hand side of the expression empty (or just whitespace).

Commands

The yangcli-pro program has several built-in commands, defined in yangcli-pro.yang, yuma-netconf.yang, and notifications.yang.

The YANG 'rpc' statement is used to define the syntax and behavior of each command.

There are 3 types of yangcli-pro commands:

  • local: the command is executed within the yangcli-pro application, and can be invoked at any time.

  • remote: the command is executed on the remote server, and is only available when a NETCONF session is active. Any YANG rpc statement that yangcli-pro does not recognize as a local command is treated as a remote command available on the server.

  • config mode: the command is executed within the yangcli-pro application, in config mode. This is only available while a session is established.

Local Commands

Command

Description

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

event-handler-cfg

Access an event handler mapping configuration.

event-handlers-cfg

Controls access to the saved event-handlers file.

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

recall

Recall a line from the command history buffer

record-test

Record commands and responses for a regression test

refresh-library

Refresh the module version list used to determine the 'best-match' for imports.

run

Run a script

run-shell

Run a shell script. The allow-shell parameter must be ‘true’

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

Standard NETCONF Commands

The following table shows the standard NETCONF protocol operations that are directly available for use, depending on the capabilities of the server.

Command

Description

cancel-commit

Cancel the current confirmed commit procedure

cancel-subscription

Stop receiving NETCONF notifications (RFC 5277 subscription)

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 (RFC 5277 subscription)

delete-config

Delete an entire NETCONF database

delete-subscription

Terminate a NETCONF notification subscription for the current session

discard-changes

Discard any edits in the candidate database

edit-config

Alteration of the target database

establish-subscription

Start receiving NETCONF notifications (RFC 8639 subscription)

get

Filtered retrieval of state data and running config

get-config

Filtered retrieval of any NETCONF database

get-data

Filtered retrieval of a NETCONF NMDA database

get-schema

Get a data model definition file from the server

kill-session

Force close another NETCONF session

kill-subscription

Force close a notification subscription for another NETCONF session

lock

Lock a NETCONF database that is currently unlocked

modify-subscription

Modify the NETCONF notification subscription parameters

resync-subscription

Re-synchronize a YANG Push datastore subscription

unlock

Unlock a NETCONF database that is currently locked

validate

Validate the contents of a NETCONF database

Custom NETCONF Commands

The following yangcli-pro commands are available for simplified access to standard NETCONF operations

Command

Description

action

Invoke a YANG 1.1 <action>

create

Invoke an <edit-config> create operation

delete

Invoke an <edit-config> delete operation

delete-all

Invoke an <edit-config> delete operation using the netconfd-pro "delete-all" nc:operation value.

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

remove-all

Invoke an <edit-config> remove operation using the netconfd-pro "remove-all" nc:operation value.

replace

Invoke an <edit-config> replace operation

save

Save the current edits on the server in NV-storage

sget

Invoke a <get> operation with a subtree filter

sget-config

Invoke a <get-config> operation with a subtree filter

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

Extended netconfd-pro Commands

The following table shows the extended NETCONF protocol operations that are available on the netconfd-pro server only.

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.

Configuration Mode Commands

The following table shows the special configuration mode commands and keywords. They are only allowed in configuration mode.

Command

Description

apply

Apply any pending edits to the current session

config-commit

Use commit operation to apply any pending edits in 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

Variables

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

A variable reference consists of 1 or 2 dollar signs ('$'), followed immediately by a valid identifier string (e.g., $$global-log or $local-log).

Variables can be 1 or more characters in length, and follow the YANG rules for identifier names.

  • The first character must be a letter, 'A' to 'Z', or 'a' to 'z'.

  • The 2nd to last characters can be a letter 'A' to 'Z', or 'a' to 'z', number ('0' to '9'), an underscore ('_'), a dash ('-'), or a period ('.') character.

There are 4 categories of parameters supported:

  1. Read-only system variables

  2. Read-write system variables

  3. Read-write global user variables (saved in $HOME/.yuma directory)

  4. Read-write local user variables

It is an error if a variable is referenced (in the right-hand-side of a statement) that does not exist.

The first 3 types are global variables, which means that they are available to all run-levels of all scripts. The last type, called a local variable, is only visible to the current run-level of the current script (or interactive shell). Refer to the following section for more details on run levels.

Variable Syntax

Syntax

Description

Example

$$<variable-name>

Left hand side: set the global variable to some value

$$saved_get = get

$$<variable-name>

Right hand side: access the value of a global variable

fill --target=$$mytarget

$<variable-name>

Left hand side: set the local variable to some value

$myloglevel = $$log-level

$<variable-name>

Right hand side: access the value of any variable with this name

$myuser = $user

Read-only System Variables

The following table shows the unix environment variables that are available as read-only global variables in yangcli-pro. These variables are set once when the program is started, and cannot be used in the the left hand side of an assignment statement.

Variable

Description

$$HOME

$HOME environment variable

$$HOSTNAME

$HOST or $HOSTNAME environment variable

$$LANG

$LANG environment variable

$$PWD

$PWD environment variable, when yangcli-pro was invoked

$$SHELL

$SHELL environment variable

$$USER

$USER environment variable

$$YUMAPRO_DATAPATH

$YUMAPRO_DATAPATH environment variable

$$YUMAPRO_HOME

$YUMAPRO_HOME environment variable

$$YUMAPRO_MODPATH

$YUMAPRO_MODPATH environment variable

$$YUMAPRO_RUNPATH

$YUMAPRO_RUNPATH environment variable

Read-write System Variables

The following table shows the CLI configuration parameters that can be read or changed (but not deleted). If a particular parameter was not set during program invocation, then the associated variable will contain the empty string.

Variable

Description

$$aliases-file

--aliases-file configuration parameter

$$allow-shell

--allow-shell configuration parameter

$$alt-names

--alt-names configuration parameter

$$ask-password

--ask-password configuration parameter

$$auto-discard-changes

--auto-discard-changes parameter

$$auto-keepalive

--auto-keepalive configuration parameter

$$auto-reconnect

--auto-reconnect configuration parameter

$$auto-reconnect-interval

--auto-reconnect-interval configuration parameter

$$auto-reconnect-max

--auto-reconnect-max configuration parameter

$$autoaliases

--autoaliases configuration parameter

$$autocomp

--autocomp configuration parameter

$$autoconfig

--autoconfig configuration parameter

$$autoconfig-conf-mode

--autoconfig-conf-mode configuration parameter

$$autodevices

--autodevices configuration parameter

$$autoeventhandlers

--autoeventhandlers configuration parameter

$$autohistory

--autohistory configuration parameter

$$autoload

--autoload configuration parameter

$$autoload-cache

--autoload-cache configuration parameter

$$autoload-get

--autoload-get configuration parameter

$$autoload-save-cache

--autoload-save-cache configuration parameter

$$autonotif

--autonotif configuration parameter

$$autonvsave

--autonvsave configuration parameter

$$autoschemaservers

--autoschemaservers configuration parameter

$$autosessions

--autosessions configuration parameter

$$autotest

--autotest configuration parameter

$$autousers

--autousers configuration parameter

$$autouservars

--autouservars configuration parameter

$$bad-data

--bad-data configuration parameter

$$break-key-mode

--break-key-mode configuration parameter

$$callhome-address

--callhome-address configuration parameter

$$callhome-enabled

--callhome-enabled configuration parameter

$$callhome-port

--callhome-port configuration parameter

$$callhome-tls-port

--callhome-tls-port configuration parameter

$$check-output

--check-output configuration parameter

$$check-output-error

--check-output-error configuration parameter

$$check-replies

--check-replies configuration parameter

$$check-replies-error

--check-replies-error configuration parameter

$$config-autosave

--config-autosave configuration parameter

$$config-commit-mode

--config-commit-mode configuration parameter

$$config-edit-mode

--config-edit-mode configuration parameter

$$default-module

--default-module configuration parameter

$$default-operation

<default-operation> parameter for <edit-config> operations

$$display-mode

--display-mode configuration parameter

$$echo-notif-loglevel

--echo-notif-loglevel configuration parameter

$$echo-notifs

--echo-notifs configuration parameter

$$echo-replies

--echo-replies configuration parameter

$$encoding

--encoding configuration parameter

$$error-option

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

$$fill-optional

--fill-optional configuration parameter

$$fixorder

--fixorder configuration parameter

$$help-width

--help-width configuration parameter

$$ignore-missing-vars

--ignore-missing-vars configuration parameter

$$indent

--indent configuration parameter

$$keepalive-interval

--keepalive-interval configuration parameter

$$leaflist-multi-line

--leaflist-multi-line configuration parameter

$$log-level

--log-level configuration parameter

$$match-names

--match-names configuration parameter

$$message-indent

--message-indent configuration parameter

$$optional

--optional configuration parameter

$$prompt

--prompt configuration parameter (yp-shell only)

$$prompt-type

--prompt-type configuration parameter

$$save-session-vars

--save-session-vars configuration parameter

$$script-input

--script-input configuration parameter

$$server

--server configuration parameter

$$shell-command

--shell-command configuration parameter

$$ssl-fallback-ok

--ssl-fallback-ok configuration parameter

$$term-length

--term-length configuration parameter

$$test-option

<test-option> parameter for the <edit-config> operation

$$test-suite-file

--test-suite-file configuration parameter

$$time-rpcs

--time-rpcs configuration parameter

$$time-rpcs-stats

--time-rpcs-stats configuration parameter

$$time-rpcs-stats-file

--time-rpcs-stats-file configuration parameter

$$timeout

--timeout configuration parameter

$$use-data-templates

--use-data-templates configuration parameter

$$use-rawxml

--use-rawxml configuration parameter

$$use-session-vars

--use-session-vars configuration parameter

$$use-traceid

--use-traceid configuration parameter

$$use-xmlheader

--use-xmlheader configuration parameter

$$user

--user configuration parameter

$$uservars-file

--uservars-file configuration parameter

$$with-defaults

<with-defaults> retrieval parameter

$$with-term-msg

--with-term-msg configuration parameter

Read-write Global User Variables

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

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

Read-write Local User Variables

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

Read-write Session User Variables

If the $$use-sessionvars variable is true, then global variables will be treated as session-specific variables, while the active session is a named session. In this case, if a unrecognized global variable (e.g., $$foo) is used in the left-hand side of an assignment statement, then a session user variable will be created with that name. If the session user variable already exists, then its value will be overwritten.

If data templates are used, then the session-specific variables will be used to replace a variable reference within the template, instead of the global variable.

Files

File contents can be used in yangcli-pro statements, similar to user variables.

A file reference consist of the 'at-sign' character ('@') followed immediately by a valid file specification.

session1> @foo.yang = get-schema --identifier=foo --format=YANG

session1> mgrload --module=foo
  • If the file extension is “.yang”, “.log”, “.txt”, or “.text”, then the value (or command output) will be saved, and yangcli-pro will strip off the outermost XML (if needed) to save the requested file as a pure text file.

  • If the file extension is ".json", the file will be saved in JSON format.

  • Otherwise, the file will be saved in XML format. The display mode set by the user can affect XML output.

    • If the display mode i s'xml-nons' then XML without namespace (xmlns) attributes will be generated instead of normal XML.

Files may also be used as parameter replacements, within a command.

session1> $saved_get = get --filter=@filter.xml --with-defaults=explicit

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

Scripts

Any command can be entered at the interactive shell, or stored in a script file, and invoked with the run command. Scripts are simply text files, and the extension used does not matter.

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

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

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

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

Script Example:

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

// connect script

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

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

Run Levels

The run command can appear in a script.

When yangcli-pro starts up, either in interactive mode or in batch mode, the script interpreter is at run level zero. Each time a run command is invoked, either at the command line or within a script currently being invoked, a new run level with the next higher value is assigned. Local variables are only visible within the current run level.

A maximum of 512 run levels are supported in yangcli-pro.

Scripts can be called recursively, but a stop condition needs to be used to break the recursion (e.g., call the script from within a conditional code block.

Conditional Command Blocks

The if, elif, else, and end commands are used to create an 'if command sequence'.

Any other commands that appear between these commands are part of a conditional command block.

These blocks can be nested. The current conditional state is inherited, so an if command sequence within a false conditional block will not be executed. A block can contain zero or more command lines,

These command work exactly like an 'if' expression within a program language such as Python. Note that indentation is not significant, but it may be used to make scripts more readable.

The if command starts a new if-command sequence. It is followed by a conditional command block. This block ends when an elif, else, or end command within the same if command block is encountered.

At most, only one conditional code block within the if command sequence will be executed. Once a conditional command block has been executed, any remaining blocks will be skipped.

All user and system variables that are available to the current script run level can be used within the XPath expressions for determining the conditional block state (true or false).

Conditional Command Loop Blocks

The while and end commands are used to create an 'while loop sequence'.

Any other commands that appear between these commands are part of a conditional command loop block.

These blocks can be nested. The current conditional state is inherited, so a while loop sequence within a false conditional block will not be executed. A block can contain zero or more command lines,

The loop condition can be a constant expression. The maxloops parameter will prevent infinite looping, and can be utilized to use the while loop sequence as a simple 'for' loop, iterating a specific number of times.

All user and system variables that are available to the current script run level can be used within the XPath expressions for determining the conditional block state (continue or terminate loop).

The following script does not do any useful work. It is provided to demonstrate some simple script constructs.

# Sample Script 1

$x = 0
while '$x < 2'
  # this is a comment
  log-info 'start 1'
  $x = eval '$x + 1'
  $y = 0
  while '$y < 4'
    log-info 'start 2'
    $y = eval '$y + 1'
    if "module-loaded('test')"
      log-info 'module test loaded'
    elif '$x > 1'
      log-info 'x>1'
    elif "feature-enabled('test3', 'feature1')"
      log-info 'feature1'
    else
      log-info 'else'
    end
    log-info 'end 2'

  end
  log-info 'end 1'
end
if "feature-enabled('test5', 'feature-foo')"
  log-info 'feature-foo'
  run add-foo-parms
end

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

# Sample Script 2

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

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

Configuration Mode Editing

In addition to the normal NETCONF low-level and high-level editing commands, there is also a configuration mode similar to a router CLI. This mode can be used to edit YANG datastore nodes with a simplified interface.

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

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

Enter Configuration Mode

To enter configuration mode, use the config command:

mysession> config term

mysession#

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

  • apply: Use this command to force all pending edits to be applied to the current session

  • exit: Use this command to exit the current configuration sub-mode to its parent mode. If already at the top level, then this command will cause configuration mode to be terminated

Enter Configuration Sub-Mode

The configuration context node can be changed to simplify editing. Conceptually, the context node represents a YANG container or list node within the server database.

mysession# interfaces

mysession(interfaces)# int eth0

mysession(interface)#

Exit Configuration Sub-Mode

The exit command is used to exit the current configuration level and return to the parent level.

If the config-edit-mode parameter is set to 'level' then any pending edits at the current level will be applied to the server.

mysession(interface)# exit
mysession(interfaces)#

Return from Configuration Editing Mode

The return command is used to exit all configuration levels and leave configuration mode.

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

mysession(interface)# return

mysession>

Creating or Modifying Server Database Parameters

mysession(interface)# mtu 9000

mysession(interface)# exit

Applying 1 edit to session [mysession]

mysession(interfaces)# exit

mysession# exit

mysession>

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

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

mysession# int int eth0 mtu 9000

Applying 1 edit to session [mysession]

mysession#

Deleting Server Database Parameters

To delete a database node, or return it to its default value, the 'no' prefix is used:

mysession# no int int eth0 mtu

Applying 1 edit to session [mysession]

mysession#

Note that to delete leaf nodes no value is given. A value is only required for YANG list and leaf-list data nodes, to identity the keys for the instance that should be deleted.

Escaping Configuration Mode

In order to enter normal yangcli-pro commands while in configuration mode, the 'do' prefix is used. Only a limited set of commands can be accessed from configuration mode in this manner.

mysession# do show session

[session info shown]

mysession#

yangcli-pro Configuration Parameter List

The following configuration parameters are used by yangcli-pro. Refer to the YumaPro CLI Reference for more details.

Parameter

Description

--aliases-file

Specifies the command aliases file to use.

--allow-shell

Enable or disable the run-shell command.

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

--autoeventhandlers

Controls whether the saved event_handlers will be loaded into memory at startup and saved to file at 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> operation are cached for use by the running instance of yangcli-pro.

--autoload-get

Controls whether the <get> operation will be used to retrieve the /netconf-state/schemas sub-tree.

--autoload-save-cache

Controls whether the 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 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

One or more name of a configured user entries 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.

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

--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 be used as the default edit target, when both are supported by the server.

--handle-bad-reply

Controls the behavior of the XML parser and dictates how a bad RPC reply will be handled.

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

--leaflist-multi-line

Specifies if multiple leaf-lists allowed in 1 line in config mode

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

--log-header

Include additional information (level/date/time) with log message.

--log-level

Specifies verbosity level of log message output

--log-mirroring

Synonym for log-console.

--log-stderr

Specifies that error level log messages will be sent to STDERR.

--log-suppress-ctrl

If present, strip certain control characters from output in order to modify log formatting.

--log-syslog

Send log message output to the syslog daemon.

--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 in interactive mode.

--server

Specifies the server address to use in the connect command.

--server-commands

Specifies whether RPC operations learned from server YANG modules will be added as a command available to the user.

--shell-command

The shell program to invoke for the run-shell command.

--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 finding trusted 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 paginated output is used.

--test-suite-file

Specifies the name of the test suite file to load if --autotest=true.

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

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

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

Invoking yangcli-pro Commands

Commands can be entered with parameters:

  • in one continuous line

    session1> merge target=/toaster/toastControl --value=”down”
    
  • in several lines (using line continuation)

    session1> merge target=/toaster/toastControl \
    more>  --value=”down”
    
  • interactively prompted for each parameter

    session1> merge
    
    (will be prompted for target and value)
    
  • a combination of the above

    session1> merge target=/toaster/toastControl
    
    (will be prompted for value)
    

When a command is entered, and the yangcli-pro script interpreter is running in interactive mode (--batch-mode not active), then the user will be prompted for any missing mandatory parameters.

If the --optional parameter is present (or the $$optional system variable is set to 'true'), then the user will be prompted for any optional parameters that are missing.

A command has the basic form:

<name (QName)> <parameter (any YANG type)>\*

The command name is a qualified name matching the name used in the YANG rpc statement. This is followed by zero or more parameters (in any order).

A command parameter has the same syntax as a CLI configuration parameter.

The command name syntax is described below.

An un-escaped end-of-line character ('enter key') terminates command line input.

Command Prompt

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

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

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

Idle Mode

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

>

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

andy@myserver>

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

mysession>

Configuration Mode

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

Default session:

andy@myserver#

Named session:

mysession#

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

mysession# interfaces
mysession(interfaces)# interface eth0
mysession(interface)#

Continuation Mode

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

andy@myserver> get \

more>

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

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

Choice Mode

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

andy@myserver> sget

Enter a number of the selected case statement:

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

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

Parameter Mode

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

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

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

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

> connect

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

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

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

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

Enter uint32 value for leaf <timeout> [30]

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

andy@myserver>

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

False Conditional Block Mode

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

> if 0

[F]> help

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

[F]> end

>

Command Name

The command name can be entered with or without an XML prefix:

session1> nc:get

session1> get

If there is a prefix (e.g., 'nc:get'), then it needs to be one of the XML prefixes in use at the time. Use the 'show modules' command to see the modules and prefixes in use. The YANG prefix will usually be the same as the XML prefix, but not always.

XML prefixes are required to be unique, so if any 2 YANG modules pick the same prefix, then 1 of them has to be changed for XML encoding purposes.

If the --default-module configuration parameter (or $$default-module system variable) is set, it will be used to resolve a command name without any prefix, if it is not a NETCONF or yangcli-pro command.

An error message will be printed if the command entered cannot be found in any YANG module, or if there are multiple commands that match the same string.

Using the ncx:default-parm Extension

Each command may define a default parameter, by placing an ncx:default-parm extension in the rpc input section in the YANG rpc statement. This extension allows less typing in yangcli-pro to accomplish the same thing.

If the script interpreter encounters a string in the command line that is not a recognized parameter for that command, and there is a default parameter defined, then the string will be used as a value for the default parameter.

For example, the 'show' parameter is the default parameter for the 'history' command, so both of these commands will be interpreted to mean the same thing:

> history --show=10

> history 10

Note: the default parameter does not allow the wrong form of a parameter type to be entered, to accept the default for that parameter. For example, the 'show' parameter above has a default value of '25':

# this is the same as history show=25

> history

# this is an error, not the same as the above

> history show

The following table shows most of the default parameters that are available. If a command has only 1 parameter then it is made the default parameter automatically.

Default Parameters

Command

Default Parameter

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

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

Parameter Mode Escape Commands

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

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

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

Parameter mode escape sequences

Escape Sequence

Description

?

Print some help text

??

Get all available help text

?s

Skip this parameter

?se

Skip to the end of the current parameter set

?c

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

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

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

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

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

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

Using Inline XML or JSON Data

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

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

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

The syntax is simple:

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

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

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

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

Example script using JSON:

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

Example script using XML:

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

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

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

Example Variable Assignment:

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

OK

andy@localhost> show var foo

   foo [/struct]

    A {
      leaf1 testing
    }

andy@localhost>

Restrictions:

  • Only the following YANG data node types are supported:

    • container

    • list

    • anyxml

    • anydata

    • input

    • output

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

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

Using External XML

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

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

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

External XML Parameters

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

> get filter=@myfilter.xml


andy@localhost> get filter=@myfilter.xml

RPC Data Reply 6 for session 3 [default]:

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

andy@localhost>

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

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

The message sent to the server:

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

External XML Commands

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

> $$use-rawxml = true

> get @myget.xml

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

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

Using XPath Expressions

There are some command parameters, such as the --target parameter for the create command, that accept XPath absolute path expressions.

If prefixes are present, then they must match the set of XML prefixes in use at the time. Use the show modules command to see the current set of prefixes.

If prefixes are not used, then the first available matching XML namespace will be used instead.

If the starting forward slash character ('/') is missing, then it will be added.

# these are all the same value (entered in 'fill' command)

# these are all the same value (entered in 'fill' command)
:fill> system
:fill> /system
:fill> /sys:system

It is important to remember 2 simple rules to avoid common errors in XPath expressions:

  1. String constants must be quoted with single quote characters. The expression [name=fred] is not the same as [foo='fred']. The former compares the 'name' node value to the 'fred' node value. The latter compares the 'name' node value to the string 'fred'.

  2. The double quote character ('”') is not allowed in XPath --select parameter expressions because the expression will be sent to the server inside a double-quoted string.

If an incomplete XPath absolute path expression is entered, and the script interpreter is in interactive mode, then the user will be prompted to fill in any missing mandatory nodes or key leafs.

# complete form of ifMtu leaf

:fill> /interfaces/interface[name='eth0']/ifMtu

# incomplete form of ifMtu leaf

:fill> /interfaces/interface/ifMtu

Filling key leaf <name>:

Enter string value:

The 'select' parameter for the xget and xget-config commands accepts full XPath expressions. The expression must yield a node-set result in order to be used as a filter in NETCONF get and get-config operations.

When interface (or any list) entries are returned by netconfd-pro, they will contain the the entire path back to the root of the YANG module, not just the specified node. Also, any key leafs within a list are added. This is only done if the XPath expression is missing any predicates for key leafs.

This is different than XPath 1.0 as used in XSLT. Since NETCONF get and get-config operations return complete XML instance documents, not node-sets, the ancestor nodes and naming nodes need to be added.

# reply shown with --display-mode=plain
data {
   interfaces {
     interface eth0 {
            name eth0
            ifMtu 1500
      }
     interface eth1 {
            name eth1
            ifMtu 1518
      }
   }
}

Special Parameter Handling

Some special handling of YANG data structures is done by the script interpreter. This special handling only apples to command mode.

Containers

Mandatory containers will be filled (in interactive mode) by default. The '$$optional' variable should be set to 'true' to cause optional containers to be filled as well.

Container DataStore Selection

Some parameters, such as the 'source' and 'target' parameters in many commands, are actually represented as a container with a single child -- a choice of several leaf nodes. In this situation, just the name of the desired leaf node can be entered as the 'contents' of the container parameter.

andy@myserver> sget-config /system source=candidate

This behavior is only supported for the following basic structure:

  • container with 1 child that is a choice

  • child choice has 1 or more cases

  • each child case contains one leaf with type 'empty'

Example: The special handling is supported for these commands for the source' parameter:

Container Child Node Selection

A leaf or leaf-list child node within a container can be set from the command line, without requiring interactive editing, inline XML, or external XML files.

A container name can be followed by a forward slash '/', followed by a leaf or leaf-list name. The syntax for setting a simple value is allowed after the leaf or leaf-list name.

Example: start a YANG Push periodic subscription of the running datastore:

> establish-subscription datastore=running periodic/period=3000

There are some restrictions at this time:

  • Only top-level containers or containers within top-level choices are supported

  • Tab completion for this mode is not supported

Choices and Cases

If a parameter name exact-match is not found, and a partial match is attempted, then choice and case node names will be ignored, and not cause a match.

Since these nodes never appear in the XML PDUs they are treated as transparent nodes (wrt/ parameter searches) unless they are specified with their full name.

Parameters that are a choice of several nodes, similar to above, except without a parent container node, (e.g., --help-mode) can be omitted. The accessible child nodes within the case nodes can be entered directly (e.g., sget target parameter).

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

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

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

Lists and Leaf-Lists

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

Binary Data Type

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

Command Completion

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

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

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

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

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

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

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

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

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

Command list example: no NETCONF session is active:

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

Command list example: NETCONF session is active

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

Command Line Editing

The command line parser is based on libtecla, a freely available library.

  • Refer to the complete user guide for information on configuring libtecla.

  • If the file $HOME/.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

^A

beginning of line

^E

end of line

^U

delete line

M-f

forward-word

M-b

backward word

^P

up history

^N

down history

Command History

Each command line is saved in the command history buffer, unless a password is being entered in parameter mode. A command line can be recalled using the recall command.

By default, the previous history line (if any) will be shown if the ^P key is pressed.

By default, the next history line (if any) will be shown if the ^N key is pressed.

In addition, the history command can be used to control the command line buffer further. This command has 4 sub-modes:

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

  • clear: clear the history buffer

  • save: save the history buffer to a file

  • load: load the history buffer from a file

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

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

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

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

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

Refer to the history command section for more details on this command.

Command Responses

The command output and debugging messages within yangcli-pro is controlled by the current log level (error, warn, info, debug, debug2, debug3).

If a command is executed by the script interpreter, then a response will be printed, depending on the log level value.

If the log level is 'info' or higher, and there were no errors and no response, then the string 'OK' is printed.

> $foo = 7

OK

>

If the log-level is set to 'error' or 'warn', then the 'OK' messages will be suppressed.

If the log level is set to 'debug' or higher, then responses from the server will be echoed to the log stream (STDOUT, log file and/or syslog). The current display mode will be used when printing data structures such as <rpc-error> and <notification> element contents.

If an error response is received from the server, it will always be printed to the log.

andy@myserver> create /system

Filling container /system:
RPC Error Reply 5 for session 8:

rpc-reply {
   rpc-error {
      error-type application
      error-tag access-denied
      error-severity error
      error-app-tag limit-reached
      error-path /nc:rpc/nc:edit-config/nc:config/sys:system
      error-message 'max-access exceeded'
   }
}

andy@myserver>

Refer to the --log-level section for more details. Logging capabilities are also discussed in more detail in the YumaPro User Manual.

Controlling Terminal Output

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

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

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

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

Pipe Commands

Pipe commands are used to control the terminal output

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

    • begin: start output after this pattern matches

    • include: include lines that match this pattern

    • exclude: exclude lines that match this pattern

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

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

Usage Notes:

  • The pipe commands can be combined.

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

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

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

Examples:

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

It is not a real command within yangcli-pro.

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

> show fan 1 --full

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

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

> show fan 1 --full | begin fan

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

>

The “include” command:

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

>

The “exclude” command:

> show fan 1 --full | exclude more

Report for Fan 1
  put fan status here...

>

The “display” command:

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

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

andy@localhost>

The “display” and “redirect” commands combined:

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

Filling container /system:
andy@localhost>

pipe YANG Definition

container pipe {
  ncx:abstract;
  ncx:hidden;

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

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

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

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

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

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

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

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

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

Pagination

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

    • --More-- prompt displayed at each pause

    • terminal length command controls number of lines printed per page

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

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

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

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

Example using pagination and pipe commands together:

andy@localhost> term length 10

OK

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

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

  --More--

Examples setting terminal length:

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

Display Mode

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

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

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

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

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

  • Setting the Display Mode:

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

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

  • Displaying the current display mode:

> show var display-mode
display-mode cli

Display Mode YANG Definition

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

Plain Mode Example:

andy@localhost> sget /system/uname

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

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

andy@localhost>

CLI Mode example:

andy@localhost> sget /system/uname

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

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

andy@localhost>

NETCONF Device Configuration

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

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

Creating Devices

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

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

> device-cfg show=device-B

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

Saving Devices

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

> connect user=andy server=myserver password=mypassword

    ... startup screen ...

andy@myserver> device-cfg save device-A

Saved current device as 'device-A'

andy@myserver>

Multiple Devices

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

Saving the Configured Devices

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

session-A> devices-cfg save

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

session-A>

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

session-A> devices-cfg save myusers.conf

Saved 2 devices OK to 'mydevices.conf'

session-A>

Loading Additional Configured Devices

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

session-A> devices-cfg load devices.conf

Loaded 3 sessions OK from 'devices.conf'

session-A>

Displaying the Configured Devices

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

session-A> devices-cfg show

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

Device 'desktop':
  server: 10.0.0.7
  connected: false

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

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

Displaying Devices

Displaying a Specific Device

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

> device-cfg show device-A

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

Saved Device Configuration File Format

The saved sessions are stored in a YumaPro configuration file.

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

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

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

     key name;

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

    leaf devicetype {
          type string;
          description
            "Device type for NETCONF devices.";
    }

   leaf server {
      type inet:host;
      mandatory true;
      description
         "IP address or DNS name of the NETCONF server target.";

    }

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

    uses EntryPointParm;

    uses ncxapp:ProtocolsParm;

    leaf transport {
      description
        "Identifies the transport protocol that should be used.";
      type ywt:transport-type;
      default ssh;
    }

    uses CommentParm;
   }
}

Device Configuration File Example

The following example file shows a valid device configuration file:

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

NETCONF Schema Server Configuration

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

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

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

Creating New Schema Servers

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

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

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

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

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

A new schema_server is created:

schema_server-id=schema-serverA name=schema-serverA device=deviceA user=userA

Saving Schema Servers

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

> schema-servers-cfg save

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

> schema-server-cfg show=schema-serverA

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

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

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

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

Multiple Schema Servers

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

Displaying the Configured Schema Servers

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

> schema-servers-cfg

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

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

Schema Server: schema-server-ACER
  Device Id: device-ACER
  User Id: user-ACER
  Connected: false

Schema Server: schema-server-asus2
  Device Id: asus2-device
  User Id: asus2
  Connected: false

Displaying A Schema Server

Displaying a Specific Schema Server

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

> schema-server-cfg show=schema-serverA

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

Saved Schema Server Configuration File Format

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

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

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

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

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

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

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

Schema Server Configuration File Example

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

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

NETCONF User Configuration

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

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

Creating New Users

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

> user-cfg create=usr1 user-name=admin password=admin

A new user is created: user-id=usr1 name=admin password=admin

> user-cfg show usr1

User 'usr1':
  user: admin
  password: admin
  connected: false

>

Saving Users

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

> connect user=andy server=myserver password=mypassword

   ... startup screen ...

andy@myserver> user-cfg save user-A

Saved current user as 'user-A'

andy@myserver>

Multiple Users

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

Saving the Configured Users

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

session-A> users-cfg save

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

session-A>

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

session-A> users-cfg save myusers.conf

Saved 2 users OK to '**myusers.conf**'

session-A>

Loading Additional Configured Users

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

session-A> users-cfg load users.conf

Loaded 3 sessions OK from 'users.conf'

session-A>

Displaying the Configured Users

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

session-A> users-cfg show

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

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

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

Displaying Users

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

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

Saved User Configuration File Format

The saved sessions are stored in a YumaPro configuration file.

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

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

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

     key name;

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

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

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

User Configuration File Example

The following example file shows a valid user configuration file:

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

NETCONF Session Configuration

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

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

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

> start-session session-A

  ... startup screen ...

session-A>

Saving Sessions

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

> connect user=andy server=myserver password=mypassword

   ... startup screen ...

andy@myserver> session-cfg save session-A

Saved current session as 'session-A'

andy@myserver>

Session use-event-handler

The configured event-handler does not actually cause any event scripts to be invoked because there has to be a session-cfg mapping. The session-cfg has parameter ‘use-event-handler’ to do the mapping.

leaf-list use-event-handler {
  type nt:NcxIdentifier;
  description
    "Name of an event-handler to use within this session.
     When notification delivery for this session is started
     the event handler will be installed. A warning will be
     printed if no event-handler with this name is found.";
}

The event-handler has to be mapped to the session-cfg:

session-A> session-cfg use-event-handler=handler-ses-change
session-A> session-cfg use-event-handler=handler-ses-end
session-A> session-cfg use-event-handler=handler-ses-start

session-A>
session-A> sessions-cfg full
Saved sessions source: '~/.yumapro/.yangcli_pro_sessions.conf'
Session 'session-A':
  user: username
  password: password:
  server: 192.168.0.11
  connected: true
  port: 830
  protocols: netconf1.1
  public-key: $HOME/.ssh/id_rsa.pub
  private-key: $HOME/.ssh/id_rsa
  ssl-fallback-ok: true
  ssl-certificate:
  ssl-key:
  ssl-trust-store:
  transport: netconf-ssh
  Event Handler 'handler-ses-change'
    module-name=ietf-netconf-notifications
    event-name=netconf-config-change
    shell-script=ses-change.sh
  Event Handler 'handler-ses-start'
    module-name=ietf-netconf-notifications
    event-name=netconf-session-start
    shell-script=ses-start.sh
  Event Handler 'handler-ses-end'
    module-name=ietf-netconf-notifications
    event-name=netconf-session-end
    shell-script=ses-end.sh

Multiple Sessions

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

> start-session session-A

   ... startup screen ...

session-A> start-session session-B

   ... startup screen ...

session-B>

Note that when a session is started, the active session is set to that session.

Changing the Active Session

To change the active session and issue commands to a different server, use the session 'set-current' command. This command will cause all subsequent remote commands to be sent to the server associated with the named session.

session-A> session set-current session-B

session-B>

Since the “set-current” parameter is the default parameter, this command can be simplified:

session-A> session session-B

session-B>

To switch to the default session, use the session name “default”. If the default session is connected, then the user and host name will be shown. If not, a simple '>' prompt will be shown instead.

session-A> session default

andy@myserver>

Saving the Configured Sessions

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

session-A> sessions-cfg save

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

session-A>

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

session-A> sessions-cfg save mysessions.conf

Saved 2 sessions OK to 'mysessions.conf'

session-A>

Loading Additional Configured Sessions

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

session-A> sessions-cfg load sessions.conf

Loaded 3 sessions OK from 'sessions.conf'

session-A>

Displaying the Configured Sessions

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

session-A> sessions-cfg show

Saved sessions source: 'mysessions.conf'
Session 'session-A':
   user: andy
   server: localhost
   connected: true

Session 'session-B':
   user: andy
   server: eval.yumaworks.com
   connected: false

Displaying Sessions

Displaying the Active Session

To see information about the active session, use the session-cfg command:

session-A> session-cfg

Session 'session-A':
   user: andy
   server: localhost
   connected: true

Session 'session-B':
   user: andy
   server: eval.yumaworks.com
   connected: false

Displaying a Specific Session

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

session-A> session-cfg show session-B

Session 'session-B':
   user: andy
   server: eval.yumaworks.com
   connected: false

session-A>

Terminating a Named Session

The stop-session command is used to terminate a specific session. The <close-session> operation will be sent on the specified session and the connection gracefully terminated.

session-A> stop-session session-B

session-A>

The active session can also be terminated although no new session will be selected automatically:

session-A> stop-session session-A

>

Saved Session Configuration File Format

The saved sessions are stored in a YumaPro configuration file.

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

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

  list session {
    description
      "The list of sessions to use during this test-suite.";

    key name;

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

    leaf-list use-event-handler {
       type nt:NcxIdentifier;
       description
         "Name of an event-handler to use within this session.
          When notification delivery for this session is started
          the event handler will be installed. A warning will be
          printed if no event-handler with this name is found.";
    }

    leaf device {
      type nt:NcxDeviceName;
      mandatory true;
      description
         "Device name of the NETCONF server target.";
    }

    leaf userid {
      type nt:NcxName;
      mandatory true;
      description
         "User Id of the NETCONF user.";
    }

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


    choice pass {
      mandatory true;

      leaf password {
        type string;
        ncx:password;
        description
          "User password to use for NETCONF sessions.
           If none, then user will be prompted before connecting.";
      }
      leaf no-password { type empty; }
    }

    uses ywapp:SshKeyParms;

    uses ywapp:SslKeyParms;

    leaf server {
      type inet:host;
      mandatory true;
      description
         "IP address or DNS name of the NETCONF server target.";

    }

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

    uses EntryPointParm;

    uses ncxapp:ProtocolsParm;

    leaf transport {
      description
        "Identifies the transport protocol that should be used.";
      type ywt:transport-type;
      default ssh;
    }

    container start-commands {
      ywx:cli-text-block;
      description
        "An optional block of yangcli commands to run
         after the session is successfully started.";
    }

    uses VarsContainer;

    uses CommentParm;
  }

Session Configuration File Example

The following example file shows a valid session configuration file:

saved-sessions {
  session session-A {
    user andy
    password mypassword
    public-key $HOME/.ssh/id_rsa.pub
    private-key $HOME/.ssh/id_rsa
    server localhost
    ncport 830
    protocols "netconf1.0 netconf1.1"
  }
  session session-B {
    user andy
    password mypassword
    public-key $HOME/.ssh/id_rsa.pub
    private-key $HOME/.ssh/id_rsa
    server localhost
    ncport 830
    protocols "netconf1.0 netconf1.1"
  }
  session A {
    user andy2
    password newpassword
    public-key $HOME/.ssh/id_rsa.pub
    private-key $HOME/.ssh/id_rsa
    server localhost
    ncport 830
    protocols "netconf1.0 netconf1.1"
  }
}

Event Handlers Configuration

The yangcli-pro program can access an event handler mapping configuration. An event-handler is a mapping between notification (or set of notifications) and an event handler script. A session-cfg can specify event-handlers to install when the session starts. The event-handler command can also be run in session mode to apply to the current session. These named event handler mapping configuration are saved in a configuration file. Use the --autoeventhandlers to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.

By default, the event handlers configuration is saved in $HOME/.yumapro/yangcli_pro_event_handlers.conf. To override this file, set --autoeventhandlers=false and use the event-handler-cfg command to load a specific event-handlers configuration file.

Creating New Event Handlers

Use event-handler-cfg 'create' command to create a new event handler. The created event handler does not actually cause any event scripts to be invoked because there has to be a session-cfg mapping. The session-cfg command has a parameter ‘use-event-handler’.

> event-handler-cfg ?

brief          Show brief help text
create         An event-handler name to use to create a new event handler.
delete         Delete the specified event-handler from the saved event hand...
event-name     The event name for the event handler.
full           Show full help text
module-name    The module name for the event handler.
normal         Show normal help text
save           Save the specified event handler to the saved event handlers...
script         The yangcli script name to use for the event handler.
shell-script   The shell script name to use for the event handler.
show           Show the specified event-handler or the current event-handle…

> event-handler-cfg create=handler-ses-change module-name=ietf-netconf-notifications event-name=netconf-config-change shell-script=ses-change.sh.

A new event_handler is created: event_handler-id=handler-ses-change

Event Handler 'handler-ses-change'
   module-name=ietf-netconf-notifications
   event-name=netconf-config-change
   shell-script=ses-change.sh

> event-handler-cfg show=handler-ses-change
   Event Handler 'handler-ses-change'
   module-name=ietf-netconf-notifications
   event-name=netconf-config-change
   shell-script=ses-change.sh

> event-handler-cfg delete=handler-ses-change
Deleted saved event_handler 'handler-ses-change'

>

Multiple Event Handlers

Multiple event handlers can be active at once, however only one event script at a time can be invoked. This will be improved in a future release.

Saving the Configured Event Handlers

The event handlers configuration can be saved or loaded at run-time, if the --autoeventhandlers=true parameter is used (the default). The event-handlers-cfg save command is used to save this file.

> event-handlers-cfg save

Saved 3 event_handlers OK to '~/.yumapro/.yangcli_pro_event_handlers.conf'

>

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

> event-handlers-cfg save myeventhandlers.conf

Saved 2 eventhandlers OK to 'myeventhandlers.conf'

>

Loading Additional Configured Event Handlers

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

session-A> event-handlers-cfg load myeventhandlers.conf

Loaded saved event_handlers OK from 'myeventhandlers.conf'

session-A>

Displaying the Configured Event Handlers

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

> event-handlers-cfg show

Saved event_handlers source: '~/.yumapro/.yangcli_pro_event_handlers.conf'

   Event Handler 'handler-ses-change'
      module-name=ietf-netconf-notification
      event-name=netconf-config-change
      shell-script=ses-change.sh
   Event Handler 'handler-ses-start'
      module-name=ietf-netconf-notification
      event-name=netconf-config-start
      shell-script=ses-start.sh
   Event Handler 'handler-ses-end'
      module-name=ietf-netconf-notification
      event-name=netconf-config-end
      shell-script=ses-end.sh

Event Handlers Variables

The event handler is passed 8 variables in the dollar parameters for the script

Parameter

Description

Example

$0

script name

test1.sh

$1

handler name being invoked

my-handler1

$2

module name of the event

ietf-netconf-notifications

$3

Event name

netconf-config-change

$4

eventTime field from the notification

2021-08-29T22:57:43Z

$5

XML file of the <notification> element

/tmp/yangcli-event-s2012.e32.xml

$6

session-name that received the event

my-session1

$7

IP address of the server that sent the event

192.168.0.204

The raw event filespec to XML file that contains the complete <notification> element for this event. This file will be deleted after the script is invoked.

Example XML File:

<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2021-08-29T22:57:43Z</eventTime>
  <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
    <changed-by>
      <username>andy</username>
      <session-id>3</session-id>
      <source-host>127.0.0.1</source-host>
    </changed-by>
    <datastore>running</datastore>
    <edit>
      <target xmlns:nacm="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">/nacm:nacm</target>
      <operation>create</operation>
    </edit>
  </netconf-config-change>
</notification>

NETCONF Group Configuration

The yangcli-pro program can be configured to manage the session groups. It associates a group name with a set of sessions to start NETCONF sessions with servers.

A group name is not allowed to have the same name as any session name. This allows the 'session set-current' command to select a group or an individual session.

The named groups and their sessions are saved in a configuration file. Use the --autosessions parameter to suppress automatic loading of this file. The default is to load this file at start-up and save it upon exit.

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

Create group

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

Example of 'group create':

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

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

List group

The group 'list' command is used to list the names of all the groups.

> group list
Group 'AB'
   This group is not connected.
   missing-ok: false
   missing-connect-ok: false
   lost-ok: false
   reconnect-interval: 30
   reconnect-tries: 5
   connected_cnt: 0
   number_of_sessions: 2
   Session 'session-A' connected:false
   Session 'session-B' connected:false
Group 'a1a2a3'
   This group is not connected.
   missing-ok: false
   missing-connect-ok: false
   lost-ok: false
           reconnect-interval: 30
   reconnect-tries: 5
   connected_cnt: 0
   number_of_sessions: 3
   Session 'a1' connected:false
   Session 'a2' connected:false
   Session 'a3' connected:false
>

Delete group

The group 'delete' command is used to delete a group.

> group delete=AB

> group delete=a1a2a3

> group list

No groups found

>

Add group

The group 'add' command is used to add sessions to a named group. The 'session' parameter must also be present.

> group add=AB session=session-B

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

Remove Group

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

> group remove=AB session=session-A

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

Show Group

The group 'show' command is used to show the name of the group to show.

Example of 'group show':

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

Connect Group

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

The default parameters value are false.

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

    ... startup screen ...

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

NETCONF session established for xxxxx on localhost

    ... startup screen ...

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

Help Group

Use command of help 'group' to print all the group help text.

> help group
group
  Manage the yangcli-pro session groups.
  A group name is not allowed to have the same name as any
...
  input
    default parameter: session
    choice groupcmd <Mandatory>
      case connect
        leaf connect [NcxIdentifier]
          Connect to all sessions in the specified group.

        leaf missing-ok [boolean] [d:false]
          If truew, then it is OK to manage this group if 1 or
          more sessions identified in...

        leaf missing-connect-ok [boolean] [d:false]
          If true, then it is OK to manage this group if 1 or
          more sessions identified in ...

        leaf lost-ok [boolean] [d:false]
          If true, then it is OK to manage this group if 1 or
          more sessions are lost after...

        leaf reconnect-tries [uint32] [d:5]
          Indicates the number of times yangcli will attempt
          to reconnect to a session if ...

        leaf reconnect-interval [uint32] [d:10]
          Indicates the number of seconds yangcli will wait to
          re-establish a connection i...
      leaf create [NcxIdentifier]
        Name of the group to create.  The 'session' parameter
        must also be present

      leaf delete [NcxIdentifier]
        Name of the group to delete

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

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

      leaf show [NcxIdentifier]
        Name of the group to show

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

Saving Groups

To save a group, the text configuration file can be edited or the sessions-cfg 'save' command can be used. The session configuration can be saved or loaded at run-time, even if the --autosessions=true parameter is used (the default). The sessions-cfg command is used to load and save this file.

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

Changing the Active Group

To change the active group and issue commands to a different server, use the session 'set-current' command. This command will cause all subsequent remote commands to be sent to the servers associated with the named group.

a1a2a3> session set-current AB

Group 'AB' is now active

AB>

Using NETCONF Sessions

The yangcli-pro program can be connected to up to 1000 NETCONF servers at a time.

Use the connect or start-session command to start a NETCONF session.

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

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

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

Connection Startup Screen

If the --log-level is set to 'info' or higher, then a startup screen will be displayed when a NETCONF session is started. It contains:

NETCONF session established for user on localhost

Client Session Id: 1
Server Session Id: 1

Server Protocol Capabilities
   base:1.0
   candidate:1.0
   confirmed-commit:1.0
   rollback-on-error:1.0
   validate:1.0
   url:1.0
   xpath:1.0
   notification:1.0
   interleave:1.0
   partial-lock:1.0
   with-defaults:1.0
   base:1.1
   validate:1.1
   confirmed-commit:1.1
   yang-library:1.0

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

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

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

Server Tailored Context

While a NETCONF session is active, the set of available YANG modules will be set to the modules that the server is using, if the --autoload configuration parameter is enabled.

If the schema-retrieval capability is also available on the server, then the <get-schema> operation will be attempted for any YANG module specified in the <hello> message capabilities, but not available to the yangcli-pro program.

When the server module capabilities are analyzed by the yangcli-pro client, the entire YANG module search path is checked for the specific module advertised in the capability. All the modules are partially parsed to check the actual namespace and revision date values. The following fields must exactly match in order for yangcli-pro to use a local YANG module, if --autoload=true.

  • module name

  • module revision date (if any)

  • module namespace

If the namespace URI value is different, it indicates that there is either a bug in one of the conflicting YANG modules, or that two different naming authorities picked the same module name. In this case, a warning will be generated during session initialization.

Any data returned from the server for YANG modules not currently available will be treated as a YANG 'anyxml' node, instead of the (unknown) YANG data type.

If the module contains YANG features that are not advertised in the <capabilities> exchange, then those data definitions will not be available (by default) for use in yangcli-pro commands.

If the module contains an object with a 'when' statement, and the 'when' XPath expression evaluates to 'false', then that data definition will not be available (by default) for use in yangcli-pro commands.

The help command will be tailored to the modules, capabilities, features, and module deviations reported by the server in <capability> exchange.

If --autoload-get is true, the <sget /netconf-state/schemas> operation will retrieve the /netconf-state/schemas sub-tree and the YANG sub-modules not known to yangcli-pro will be loaded correctly. If --autoload-get is false, then just the <hello> message module list will be used to retrieve YANG modules.

If --autoload-cache is true:

  • the YANG modules that are retrieved with the sget /netconf-state/schemas operation results will be cached. module can be used by yangcli-pro.

  • the modules held in the YANG module cache are normally saved when yangcli-pro exits. If --autoload-save-cache is false, then the YANG modules that are cached will be not saved when yangcli-pro exits.

Retrieving Data

There are 8 commands available to retrieve generic data (i.e., an arbitrary subset of an entire NETCONF database):

Command

Description

get

raw NETCONF <get> operation

get-config

raw NETCONF <get-config> operation

get-data

raw NETCONF <get-data> 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, xget-data, and xget-config commands are affected by this parameter.

If the :xpath capability was not advertised by the server when the session started, an error or warning may occur if these commands are used.

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

Modifying Data

The following commands are available to modify generic data (i.e., an arbitrary subset of an entire NETCONF database):

Command

Description

commit

raw NETCONF <commit> operation

create

high-level <edit-config> operation, with nc:operation='create'

delete

high-level <edit-config> operation, with nc:operation='delete'

delete-config

raw NETCONF <delete-config> operation

discard-changes

raw NETCONF <discard-changes> operation

edit-config

raw NETCONF <edit-config> operation

fill

fill a variable for re-use in other operations

insert

high-level <edit-config> operation, with YANG insert operation extensions

lock

lock a NETCONF database

merge

high-level <edit-config> operation, with nc:operation='merge'

replace

high-level <edit-config> operation, with nc:operation='replace'

save

High level save operation, depending on the default target (candidate or running)

unlock

unlock a NETCONF database

All the high-level editing operations use the --target parameter reported by the server when the session started up. If the server did not report the :candidate or :writable-running capabilities, then there will be no writable target, and an error will occur if these commands are entered.

All the high-level editing operations support the $$default-operation system variable. The <default-operation> parameter will be added the the NETCONF <edit-config> PDU if this variable is set to a value other than 'not-used'. The default is the enumeration 'none', which means do not use any default operation, and only use the explicit 'nc:operation' attribute.

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

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

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

session1> $newvalue = 1518

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

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

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

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

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

The high level save command is mapped to other commands, depending on the capabilities reported by the server. This command can be used instead of the multiple server variants of an "NV-save" operation.

save command

Capabilities

Real Command(s)

:candidate

commit

:writable-running

<none>

:startup

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

Using Notifications

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

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

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

If the notification subscription should stop at a certain time, then the 'stopTime' parameter must be included. At the end of the stored notifications, the server will send the <replayComplete> Event, followed by the <notificationComplete> Event. This notification type is not saved, and will not be found in the server replay buffer, if replay is supported by the server. The netconfd-pro server will not include a <sequence-id> element in this notification type.

Notifications are printed to the log, using the current $$display-mode system variable setting, when and if they are received.

Notifications are also logged. Use the eventlog command to access the notifications stored in the event log.

Configuration Parameters That Affect Sessions

The --server, --user, and --password configuration parameters can be used to start a NETCONF session automatically at startup time. The connect command will only be attempted at startup time if the --server parameter is present.

If all 3 of these parameters are present at startup time, then no interactive prompting for additional optional parameters will be done. Instead the connect command will be invoked right away.

During normal operation, the --optional configuration parameter, or the $$optional system variable, can be used to control interactive prompting for optional parameters.

The --server parameter is saved in the $$server system variable, which can be overwritten at any time. If set, this will be used as the initial default value for this parameter in the connect command.

The --user parameter is saved in the $$user system variable, which can be overwritten at any time. If set, this will be used as the initial default value for this parameter in the connect command.

The $$with-defaults system variable can be used to set the default value for the 'with-defaults' parameter extension for these NETCONF operations:

The $$error-option system parameter, can be used to set the default value for the 'error-option' parameter for the NETCONF <edit-config> protocol operation. The default is 'none'.

The $$test-option system parameter can be used to set the default value for the 'test-option' parameter for the NETCONF <edit-config> protocol operation. The default is 'none'.

The --bad-data configuration parameter, or the $$bad-data system variable, can be used to control how yangcli-pro handles parameter values that are known to be invalid, or usage of optional protocol operations that the current session does not support.

The default value is 'check'. To use yangcli-pro in a testing mode to send the server incorrect data on purpose, set this parameter to 'warn' or 'ignore'.

Trouble-shooting NETCONF Session Problems

If the NETCONF session does not start for any reason, one or more error messages will be printed, and the prompt will indicate 'idle' mode. This section assumes that the server is netconfd-pro, and these debugging steps may not apply to all NETCONF agents.

If the NETCONF session does not start:

  • make sure the server is reachable

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

  • make sure the SSH server is responding

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

  • make sure a firewall is not blocking TCP port 830

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

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

    Port 22
    Port 830
    Subsystemnetconf/usr/sbin/netconf-subsystem
    
  • make sure the netconfd-pro server is running. Use the unix 'ps' command, or check the netconfd-pro log file, to make sure it is running.

    ps -alx | grep netconf
    
    (look for 1 'netconfd-pro' and N 'netconf-subsystem' -- 1 for each active session)
    
  • make sure the user name is correct

    • This must be a valid user name on the system

  • make sure the password is correct

    • This must be the valid password (in /etc/passwd or /etc/shadow) for the specified user name

If the NETCONF session stops responding:

  • make sure the server is still reachable

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

  • make sure the SSH server is still responding

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

If the NETCONF server is not accepting a certain command:

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

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

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

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

  • Make sure all the parameters are supported by the server

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

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

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

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

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

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

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

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

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

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

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

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

Automated Testing

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

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

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

The start-session command is usually used within the 'setup' section for each session required in all of the tests within the test-suite. The server must already be running.

The 'setup' and 'cleanup' sections defined within a test suite are called 'CLI text blocks'. They use a special configuration file syntax which allows maximum flexibility for the test designer. These sections begin and and with square brackets ('[' and ']') instead of angle brackets ('{' and '}'). There are no leafs within these containers. Instead they contain plain command lines exactly like a script.

Test Templates

The test suite file structure is shown below:

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

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

  • test: collection of steps to perform a specific test

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

YANG File Defining Test Templates

module yumaworks-test {

  namespace "http://yumaworks.com/ns/yumaworks-test";

  prefix "ywtest";
  
  import yuma-types { prefix yt; }
  import yumaworks-extensions { prefix ywx; }

  organization "YumaWorks, Inc.";

  contact
    "Support <support@yumaworks.com>";

  description
    "This module contains data structures representing 
     replayable test suites for specific use cases and YANG modules

        +---------------------+ 
      +-+------------------+  |
      |                    |  |
      |     Test Suite     |  |
      |                    |--+ 
      +--------------------+
       |          |
       |          |
       |          V
       |    +---------------------+ 
       |  +-+------------------+  |
       |  |                    |  |
       |  |        Test        |  |
       |  |                    |--+ 
       |  +--------------------+
       |          |
       |          |
       |          V
       |      +---------------------+ 
       |    +-+------------------+  |
       |    |                    |  |
       |    |        Step        |  |
       |    |                    |--+ 
       |    +--------------------+
       |
       V
      +---------------------+ 
    +-+------------------+  |
    |                    |  |
    |      Servers       |  |
    |                    |--+ 
    +--------------------+
              |
              |
              V
        +---------------------+ 
      +-+------------------+  |
      |                    |  |
      |      Sessions      |  |
      |                    |--+ 
      +--------------------+


     Copyright (c) 2013 - 2014 YumaWorks, Inc. All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the BSD 3-Clause License
     http://opensource.org/licenses/BSD-3-Clause";

  revision 2013-03-31 {
    description 
       "Rename to yumaworks-test";
  }

  revision 2013-01-21 {
    description 
       "Initial version";
  }

  typedef response-type {
    type enumeration {
      enum none {
        description "Local command, no <rpc-reply> expected.";
      }
      enum ok {
        description "Expecting the <ok> reply.";
      }
      enum data {
        description "Expecting a data reply.";
      }
      enum error {
        description "Expecting an rpc-error reply.";
      }
    }
    description 
      "The type of response expected from the server
       for this request.";
  }

  container test-suites {

     list test-suite {

      key name;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

          leaf result-error-tag {
            when "../result-type = 'error'";
            type string;
            description 
              "The error-tag value expected if the result-type
               is 'error'.  If not set, then any error-tag
               value is acceptable.";
          }

          leaf result-error-apptag {
            when "../result-type = 'error'";
            type string;
            description 
              "The error-app-tag value expected if the result-type
               is 'error'.  If not set, then any error-app-tag
               value is acceptable.";
          }

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

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

          anyxml rpc-reply-data {
            when "../result-type = 'data'";
            description
              "The contents of <rpc-reply> element that are
                expected to be returned in the reply.
                This element itself represents <rpc-reply>
                and any child nodes are the nodes returned
                by the server.";
           }

         }  // list step
      }     // list test
    } // list test-suite
  } // container test-suites


}

RPC Reply Testing

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

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

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

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

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

    • The files are stored in the $HOME/.yumapro/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

Using Wildcards in Data Response Testing

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

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

_***_

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

Example Step:

  • Suite: s1

  • Test: t1

  • Step: 2

  • Command: sget /netconf-state/datastores

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

Original Data File Created During record-test:

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

Altered Data File Wild Wildcard Strings:

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

Example Test File

test-suites {
   test-suite first-test {
     description "A set of tests to validate NETCONF locking is working
          correctly."

     setup [
      # example variables
       $$server ="test1"
       $$admin = "andy"
       $$user1 = "andy"
       $$pass1 = "fredlow"
       $$user2 = "andy2"
       $$pass2 = "fredlow"
       $$testlog = "$HOME/tests/first-test.log"
       $$testmod = "test"

       # 2 sessions used in this test; server must already be running
       start-session session-A
       start-session session-B
     ]

     cleanup [
       stop-session session-A
       stop-session session-B
     ]

     run-test locks

     test locks {

       description "Use 2 sessions to test global locks on the
          candidate and running datastores. Expects the server
          to already be started with --module=test
          and --access-control=off."

       step 1 {
         description "session A locks the running config;
           needs to lock candidate too, but does not!"
         session-name session-A
         result-type ok
         command "lock target=running"
       }

       step 2 {
         description "session B tries to lock the running config"
         session-name session-B
         result-type error
         result-error-tag lock-denied
         result-error-info session-id
         command "lock target=running"
       }

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

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

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

       step 6 {
         description "session A tries to lock the candidate config
           this should fail since the candidate is dirty"
         session-name session-A
         result-type error
         result-error-tag resource-denied
         command "lock target=candidate"
       }

       step 7 {
         description "session B tries to lock the candidate config
           this should fail since the candidate is dirty"
         session-name session-B
         result-type error
         result-error-tag resource-denied
         command "lock target=candidate"
       }

       step 8 {
         description "session B issues a discard-changes"
         session-name session-B
         result-type ok
         command "discard-changes"
       }

       step 9 {
         description "session A issues a discard-changes"
         session-name session-A
         result-type ok
         command "discard-changes"
       }

       step 10 {
         description "session B locks the candidate config"
         session-name session-B
         result-type ok
         command "lock target=candidate"
       }

       step 11 {
         description "session A tries to lock the candidate config,
           which should fail because it is already locked"
         session-name session-A
         result-type error
         result-error-tag lock-denied
         result-error-info session-id
         command "lock target=candidate"
       }

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

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

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

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

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

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

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

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

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

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

     }
   }
}

Call Home Server

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

Call Home for NETCONF over SSH Port Assignment:

Service Name:           netconf-ch-ssh
Port Number:            4334
Transport Protocol(s):  TCP
Description:            NETCONF Call Home (SSH)
Assignee:               IESG <iesg@ietf.org>
Contact:                IETF Chair <chair@ietf.org>
Reference:              RFC 8071

Call Home for NETCONF over TLS Port Assignment:

Service Name:           netconf-ch-tls
Port Number:            4335
Transport Protocol(s):  TCP
Description:            NETCONF Call Home (TLS)
Assignee:               IESG <iesg@ietf.org>
Contact:                IETF Chair <chair@ietf.org>
Reference:              RFC 8071

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

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

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

Call Home Configuration

The following CLI parameters are available to Call Home configuration:

  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. Zero or more named user entries can be be designated a “callhome-user” entry. The “user-cfg save” command can be used to create a suitable user entry. Then the --callhome-user parameter is set to the user-cfg name. In this mode the client does not need to connect to the desired server first, but the user and credentials need to be pre-configured on the NETCONF server in advance.

    1. The success of a callhome-user entry is tracked for each server address attempting a connection.

    2. If the first callhome-user entry has failed when a server attempts to reconnect, then that entry will be skipped and the next entry will be attempted.

    3. The failed server list cannot be cleared at this time. The program must be restarted to clear the failed server mappings for each callhome-user.

    4. Refer to the --callhome-user CLI parameter section for more details

It is not possible to attempt multiple users or connection attempts on the same TCP connection. This is a security feature built into the transport protocols.

Call Home Accept Session Procedure

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

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

  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. For yp-client applications, it is possible that a callhome user-select callback has been registered. If so, then the callback will be invoked with the server address. The callback will do 1 of 3 things

    1. Reject the session so it will be dropped without a connection attempt

    2. Return the callhome-user entry to use for a connection attempt

    3. Return no callhome-user so proceed to step 3 as if no callback was invoked

  3. If no matching IP address session entry found, then check if any callhome-user entries are configured. If so, find the first entry that has not failed for this address, then create a temporary session using the user-cfg data and the incoming address information for the server configuration.

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

Privilege Mode In Enable Mode

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

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

  • Use the enable command to enter ‘enable mode’.

  • Use 'enable password' to create a password.

  • Use 'enable no-password' to delete the password.

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

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

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

The 'enable' command is only available in the yp-shell program. The yangcli-pro program does not have this command.

If --with-enable-mode=false, or not used, the 'config term' command will be present and the 'enable', 'enable password', and 'enable no-password' commands will not be present.

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

enable (config mode)

Use the enable command to enter enable mode. This command will cause the '#' prompt to be used. Only config mode commands such as "apply" and "exit" are allowed in this mode.

user1> show vars | include with-enable-mode
  with-enable-mode true

user1> show vars | include restrict-edit-mode
  restrict-edit-mode true

user1>
user1> enable <TAB>
no-password  password
user1> help enable full

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

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

      leaf no-password [empty]
        Remove the password.


user1> enable
user1#<TAB>
config  exit

user1#
thue@andy-u14# config t
user1(config)#

user1(config)# int8.1 8

user1(config)# do show running
nc:rpc-reply {
  data {
    t:int8.1 8
  }
}

user1(config)# exit
user1#
user1# exit
user1>

enable password

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

user1> enable password=xxxxxxxxx
Re-enter password:
Enable password entered

user1> enable
Enter password:xxxxxxxxx

user1# config t
user1(config)# exit
user1# exit

user1> enable
Enter password:xxxxxxxxx

user1#

enable no-password

Use the 'enable no-password' to delete the configured password. After this command, the user will enter enable mode without getting prompted for password.

..code-block:: bash

user1>enable no-password Enable password entered: xxxxxxxxx Enable password removed

user1> enable

user1# <TAB> user1# config exit

Privilege Mode In Config Mode

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

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

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

Enable Privilege Mode

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

user1> config t
user1#
user1# enable-password
Enter string value for leaf <password>
user1:enable-password#
Re-enter password:
Enable password entered
user1#

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

user1#
user1# exit
user1> config t
Enter password:
user1#

Restart yp-shell after enable-password is set.

user1# exit
user1> q
user1:~/swdev/ypwork/netconf/target/bin$ ./yp-shell
user1> config t
Enter password:
user1#

Disable Privilege Mode

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

user1# no enable-password
Enable password removed
user1# exit

user1> config t
user1#
user1# exit

user1> q
user1:~/swdev/ypwork/netconf/target/bin$ ./yp-shell

user1> config t
user1#

Use leaflist-multi-line to Configure leaf-list

The --leaflist-multi-line parameter controls how the leaf-list can be edited in config-mode

  • If set to 'true', then multiple leaf-lists can be configured at the same line.

  • If set to 'false', then only one leaf-list can be configured and it must be configured at the end of the line.

  • The default value is 'false'.

Example YANG:

container top {
  leaf foo { type string; }
  leaf-list test { type string; }
  leaf-list test2 { type string; }
}

leaflist-multi-line is FALSE

andy@myserver> show var leaflist-multi-line
  leaflist-multi-line false

andy@myserver> config term
andy@myserver# no top

andy@myserver# top <TAB>
foo    test   test2
andy@myserver# top foo f1 test a1 a2 a3 test2 b1 b2 b3
Applying 1 edit

andy@myserver# do show run
nc:rpc-reply {
  data {
    ypshell-test4:top {
      foo f1
      test a1
      test a2
      test a3
      test test2
      test b1
      test b2
      test b3
    }
  }
}

leaflist-multi-line is TRUE

andy@myserver> $$leaflist-multi-line=true
System variable set
OK

andy@myserver> sho var leaflist-multi-line
  leaflist-multi-line true

andy@myserver> conf t
andy@myserver# no top
andy@myserver# top foo f1 test a1 a2 a3 test2 b1 b2 b3
Applying 1 edit

andy@myserver# do sho run
nc:rpc-reply {
  data {
    ypshell-test4:top {
      foo f1
      test a1
      test a2
      test a3
      test2 b1
      test2 b2
      test2 b3
    }
  }
}

Customizing the Keyboard

The command line editing and history is provided by the libtecla library. This library is configurable.

  • Editing mode can be changed: (emacs or vi) [default: emacs]

  • Keyboard character sequence to command bindings

The libtecla configuration file for yangcli-pro and yp-shell is called $HOME/.teclarc. If this file is found then the settings will be applied when the program starts. Any number of key binding lines can be present in this file.

Changing the Editing Mode

Key bindings for the "emacs" or "vi" editor can be selected. The default mode is "emacs". To change the mode to "vi", use the following line in the .teclarc file:

edit-mode vi

Changing Key Bindings

The key bindings within an edit mode (emacs or vi) can be changed with the 'bind' command.

Example .teclarc:

bind C-w backward-delete-word

This command would change the function bound to the Control-w key sequence. The default mapping is 'kill-region' and this 'bind' command will change the binding for Control-w to 'backward-delete-word'.

Refer to the tecla documentation for details on all the key bindings available and default key bindings.

The following sections are from the libtecla documentation, and describe the key bindings available, and the default key bindings used in yangcli-pro.

Available Key Bindings

user-interrupt           -  Send a SIGINT signal to the
                            parent process.
abort                    -  Send a SIGABRT signal to the
                            parent process.
suspend                  -  Suspend the parent process.
stop-output              -  Pause terminal output.
start-output             -  Resume paused terminal output.
literal-next             -  Arrange for the next character
                            to be treated as a normal
                            character. This allows control
                            characters to be entered.
cursor-right             -  Move the cursor one character
                            right.
cursor-left              -  Move the cursor one character
                            left.
insert-mode              -  Toggle between insert mode and
                            overwrite mode.
beginning-of-line        -  Move the cursor to the
                            beginning of the line.
end-of-line              -  Move the cursor to the end of
                            the line.
delete-line              -  Delete the contents of the
                            current line.
kill-line                -  Delete everything that follows
                            the cursor.
backward-kill-line       -  Delete all characters between
                            the cursor and the start of the
                            line.
forward-word             -  Move to the end of the word
                            which follows the cursor.
forward-to-word          -  Move the cursor to the start of
                            the word that follows the
                            cursor.
backward-word            -  Move to the start of the word
                            which precedes the cursor.
goto-column              -  Move the cursor to the
                            1-relative column in the line
                            specified by any preceding
                            digit-argument sequences (see
                            ENTERING REPEAT COUNTS below).
find-parenthesis         -  If the cursor is currently
                            over a parenthesis character,
                            move it to the matching
                            parenthesis character. If not
                            over a parenthesis character
                            move right to the next close
                            parenthesis.
forward-delete-char      -  Delete the character under the
                            cursor.
backward-delete-char     -  Delete the character which
                            precedes the cursor.
list-or-eof              -  This is intended for binding
                            to ^D. When invoked when the
                            cursor is within the line it
                            displays all possible
                            completions then redisplays
                            the line unchanged. When
                            invoked on an empty line, it
                            signals end-of-input (EOF) to
                            the caller of gl_get_line().
del-char-or-list-or-eof  -  This is intended for binding
                            to ^D. When invoked when the
                            cursor is within the line it
                            invokes forward-delete-char.
                            When invoked at the end of the
                            line it displays all possible
                            completions then redisplays
                            the line unchanged. When
                            invoked on an empty line, it
                            signals end-of-input (EOF) to
                            the caller of gl_get_line().
forward-delete-word      -  Delete the word which follows
                            the cursor.
backward-delete-word     -  Delete the word which precedes
                            the cursor.
upcase-word              -  Convert all of the characters
                            of the word which follows the
                            cursor, to upper case.
downcase-word            -  Convert all of the characters
                            of the word which follows the
                            cursor, to lower case.
capitalize-word          -  Capitalize the word which
                            follows the cursor.
change-case              -  If the next character is upper
                            case, toggle it to lower case
                            and vice versa.
redisplay                -  Redisplay the line.
clear-screen             -  Clear the terminal, then
                            redisplay the current line.
transpose-chars          -  Swap the character under the
                            cursor with the character just
                            before the cursor.
set-mark                 -  Set a mark at the position of
                            the cursor.
exchange-point-and-mark  -  Move the cursor to the last
                            mark that was set, and move
                            the mark to where the cursor
                            used to be.
kill-region              -  Delete the characters that lie
                            between the last mark that was
                            set, and the cursor.
copy-region-as-kill      -  Copy the text between the mark
                            and the cursor to the cut
                            buffer, without deleting the
                            original text.
yank                     -  Insert the text that was last
                            deleted, just before the
                            current position of the cursor.
append-yank              -  Paste the current contents of
                            the cut buffer, after the
                            cursor.
up-history               -  Recall the next oldest line
                            that was entered. Note that
                            in vi mode you are left in
                            command mode.
down-history             -  Recall the next most recent
                            line that was entered. If no
                            history recall session is
                            currently active, the next
                            line from a previous recall
                            session is recalled. Note that
                            in vi mode you are left in
                            command mode.
history-search-backward  -  Recall the next oldest line
                            who's prefix matches the string
                            which currently precedes the
                            cursor (in vi command-mode the
                            character under the cursor is
                            also included in the search
                            string).  Note that in vi mode
                            you are left in command mode.
history-search-forward   -  Recall the next newest line
                            who's prefix matches the string
                            which currently precedes the
                            cursor (in vi command-mode the
                            character under the cursor is
                            also included in the search
                            string).  Note that in vi mode
                            you are left in command mode.
history-re-search-backward -Recall the next oldest line
                            who's prefix matches that
                            established by the last
                            invocation of either
                            history-search-forward or
                            history-search-backward.
history-re-search-forward - Recall the next newest line
                            who's prefix matches that
                            established by the last
                            invocation of either
                            history-search-forward or
                            history-search-backward.
complete-word            -  Attempt to complete the
                            incomplete word which
                            precedes the cursor. Unless
                            the host program has customized
                            word completion, filename
                            completion is attempted. In vi
                            commmand mode the character
                            under the cursor is also
                            included in the word being
                            completed, and you are left in
                            vi insert mode.
expand-filename          -  Within the command line, expand
                            wild cards, tilde expressions
                            and dollar expressions in the
                            filename which immediately
                            precedes the cursor. In vi
                            commmand mode the character
                            under the cursor is also
                            included in the filename being
                            expanded, and you are left in
                            vi insert mode.
list-glob                -  List any filenames which match
                            the wild-card, tilde and dollar
                            expressions in the filename
                            which immediately precedes the
                            cursor, then redraw the input
                            line unchanged.
list-history             -  Display the contents of the
                            history list for the current
                            history group. If a repeat
                            count of > 1 is specified,
                            only that many of the most
                            recent lines are displayed.
                            See the "ENTERING REPEAT
                            COUNTS" section.
read-from-file           -  Temporarily switch to reading
                            input from the file who's
                            name precedes the cursor.
read-init-files          -  Re-read teclarc configuration
                            files.
beginning-of-history     -  Move to the oldest line in the
                            history list. Note that in vi
                            mode you are left in command
                            mode.
end-of-history           -  Move to the newest line in the
                            history list (ie. the current
                            line). Note that in vi mode
                            this leaves you in command
                            mode.
digit-argument           -  Enter a repeat count for the
                            next key-binding function.
                            For details, see the ENTERING
                            REPEAT COUNTS section.
newline                  -  Terminate and return the
                            current contents of the
                            line, after appending a
                            newline character. The newline
                            character is normally '\n',
                            but will be the first
                            character of the key-sequence
                            that invoked the newline
                            action, if this happens to be
                            a printable character. If the
                            action was invoked by the
                            '\n' newline character or the
                            '\r' carriage return
                            character, the line is
                            appended to the history
                            buffer.
repeat-history           -  Return the line that is being
                            edited, then arrange for the
                            next most recent entry in the
                            history buffer to be recalled
                            when Tecla is next called.
                            Repeatedly invoking this
                            action causes successive
                            historical input lines to be
                            re-executed. Note that this
                            action is equivalent to the
                            'Operate' action in ksh.
ring-bell                -  Ring the terminal bell, unless
                            the bell has been silenced via
                            the nobeep configuration
                            option (see the THE TECLA
                            CONFIGURATION FILE section).
forward-copy-char        -  Copy the next character into
                            the cut buffer (NB. use repeat
                            counts to copy more than one).
backward-copy-char       -  Copy the previous character
                            into the cut buffer.
forward-copy-word        -  Copy the next word into the cut
                            buffer.
backward-copy-word       -  Copy the previous word into the
                            cut buffer.
forward-find-char        -  Move the cursor to the next
                            occurrence of the next
                            character that you type.
backward-find-char       -  Move the cursor to the last
                            occurrence of the next
                            character that you type.
forward-to-char          -  Move the cursor to the
                            character just before the next
                            occurrence of the next
                            character that the user types.
backward-to-char         -  Move the cursor to the
                            character just after the last
                            occurrence before the cursor
                            of the next character that the
                            user types.
repeat-find-char         -  Repeat the last
                            backward-find-char,
                            forward-find-char,
                            backward-to-char or
                            forward-to-char.
invert-refind-char       -  Repeat the last
                            backward-find-char,
                            forward-find-char,
                            backward-to-char, or
                            forward-to-char in the
                            opposite direction.
delete-to-column         -  Delete the characters from the
                            cursor up to the column that
                            is specified by the repeat
                            count.
delete-to-parenthesis    -  Delete the characters from the
                            cursor up to and including
                            the matching parenthesis, or
                            next close parenthesis.
forward-delete-find      -  Delete the characters from the
                            cursor up to and including the
                            following occurence of the
                            next character typed.
backward-delete-find     -  Delete the characters from the
                            cursor up to and including the
                            preceding occurence of the
                            next character typed.
forward-delete-to        -  Delete the characters from the
                            cursor up to, but not
                            including, the following
                            occurence of the next
                            character typed.
backward-delete-to       -  Delete the characters from the
                            cursor up to, but not
                            including, the preceding
                            occurence of the next
                            character typed.
delete-refind            -  Repeat the last *-delete-find
                            or *-delete-to action.
delete-invert-refind     -  Repeat the last *-delete-find
                            or *-delete-to action, in the
                            opposite direction.
copy-to-column           -  Copy the characters from the
                            cursor up to the column that
                            is specified by the repeat
                            count, into the cut buffer.
copy-to-parenthesis      -  Copy the characters from the
                            cursor up to and including
                            the matching parenthesis, or
                            next close parenthesis, into
                            the cut buffer.
forward-copy-find        -  Copy the characters from the
                            cursor up to and including the
                            following occurence of the
                            next character typed, into the
                            cut buffer.
backward-copy-find       -  Copy the characters from the
                            cursor up to and including the
                            preceding occurence of the
                            next character typed, into the
                            cut buffer.
forward-copy-to          -  Copy the characters from the
                            cursor up to, but not
                            including, the following
                            occurence of the next
                            character typed, into the cut
                            buffer.
backward-copy-to         -  Copy the characters from the
                            cursor up to, but not
                            including, the preceding
                            occurence of the next
                            character typed, into the cut
                            buffer.
copy-refind              -  Repeat the last *-copy-find
                            or *-copy-to action.
copy-invert-refind       -  Repeat the last *-copy-find
                            or *-copy-to action, in the
                            opposite direction.
vi-mode                  -  Switch to vi mode from emacs
                            mode.
emacs-mode               -  Switch to emacs mode from vi
                            mode.
vi-insert                -  From vi command mode, switch to
                            insert mode.
vi-overwrite             -  From vi command mode, switch to
                            overwrite mode.
vi-insert-at-bol         -  From vi command mode, move the
                            cursor to the start of the line
                            and switch to insert mode.
vi-append-at-eol         -  From vi command mode, move the
                            cursor to the end of the line
                            and switch to append mode.
vi-append                -  From vi command mode, move the
                            cursor one position right, and
                            switch to insert mode.
vi-replace-char          -  From vi command mode, replace
                            the character under the cursor
                            with the the next character
                            entered.
vi-forward-change-char   -  From vi command mode, delete
                            the next character then enter
                            insert mode.
vi-backward-change-char  -  From vi command mode, delete
                            the preceding character then
                            enter insert mode.
vi-forward-change-word   -  From vi command mode, delete
                            the next word then enter
                            insert mode.
vi-backward-change-word  -  From vi command mode, delete
                            the preceding word then
                            enter insert mode.
vi-change-rest-of-line   -  From vi command mode, delete
                            from the cursor to the end of
                            the line, then enter insert
                            mode.
vi-change-line           -  From vi command mode, delete
                            the current line, then enter
                            insert mode.
vi-change-to-bol         -  From vi command mode, delete
                            all characters between the
                            cursor and the beginning of
                            the line, then enter insert
                            mode.
vi-change-to-column      -  From vi command mode, delete
                            the characters from the cursor
                            up to the column that is
                            specified by the repeat count,
                            then enter insert mode.
vi-change-to-parenthesis -  Delete the characters from the
                            cursor up to and including
                            the matching parenthesis, or
                            next close parenthesis, then
                            enter vi insert mode.
vi-forward-change-find   -  From vi command mode, delete
                            the characters from the
                            cursor up to and including the
                            following occurence of the
                            next character typed, then
                            enter insert mode.
vi-backward-change-find  -  From vi command mode, delete
                            the characters from the
                            cursor up to and including the
                            preceding occurence of the
                            next character typed, then
                            enter insert mode.
vi-forward-change-to     -  From vi command mode, delete
                            the characters from the
                            cursor up to, but not
                            including, the following
                            occurence of the next
                            character typed, then enter
                            insert mode.
vi-backward-change-to    -  From vi command mode, delete
                            the characters from the
                            cursor up to, but not
                            including, the preceding
                            occurence of the next
                            character typed, then enter
                            insert mode.
vi-change-refind         -  Repeat the last
                            vi-*-change-find or
                            vi-*-change-to action.
vi-change-invert-refind  -  Repeat the last
                            vi-*-change-find or
                            vi-*-change-to action, in the
                            opposite direction.
vi-undo                  -  In vi mode, undo the last
                            editing operation.
vi-repeat-change         -  In vi command mode, repeat the
                            last command that modified the
                            line.

Default Key Bindings for Emacs

The cursor keys are refered to by name, as follows. This is necessary because different types of terminals generate different key sequences when their cursor keys are pressed.

right  ->   cursor-right
left   ->   cursor-left
up     ->   up-history
down   ->   down-history

The remaining bindings don't depend on the terminal setttings.

^F     ->   cursor-right
^B     ->   cursor-left
M-i    ->   insert-mode
^A     ->   beginning-of-line
^E     ->   end-of-line
^U     ->   delete-line
^K     ->   kill-line
M-f    ->   forward-word
M-b    ->   backward-word
^D     ->   del-char-or-list-or-eof
^H     ->   backward-delete-char
^?     ->   backward-delete-char
M-d    ->   forward-delete-word
M-^H   ->   backward-delete-word
M-^?   ->   backward-delete-word
M-u    ->   upcase-word
M-l    ->   downcase-word
M-c    ->   capitalize-word
^R     ->   redisplay
^L     ->   clear-screen
^T     ->   transpose-chars
^@     ->   set-mark
^X^X   ->   exchange-point-and-mark
^W     ->   kill-region
M-w    ->   copy-region-as-kill
^Y     ->   yank
^P     ->   up-history
^N     ->   down-history
M-p    ->   history-search-backward
M-n    ->   history-search-forward
^I     ->   complete-word
^X*    ->   expand-filename
^X^F   ->   read-from-file
^X^R   ->   read-init-files
^Xg    ->   list-glob
^Xh    ->   list-history
M-<    ->   beginning-of-history
M->    ->   end-of-history
\n     ->   newline
\r     ->   newline
M-o    ->   repeat-history
M-^V   ->   vi-mode
M-0, M-1, ... M-9  ->  digit-argument

yangcli-pro Command Reference

This section describes all the yangcli-pro local and remote commands built-in when using the netconfd-pro server.

There may be more or less commands available, depending on the YANG modules actually loaded at the time.

The specific NETCONF capabilities needed are listed for each remote command. No capabilities are ever needed for a local command.

It is possible that other servers will support protocol operations that netconfd-pro does not support. If yangcli-pro has the YANG file available for the module, then it can be managed with the high level commands. Low-level commands can still be used with external data (e.g., @mydatafile.xml).

Any YANG 'rpc' statement can be used as a remote yangcli-pro command. Refer to the server vendor documentation for details on the protocol operations, database contents, and notification definitions that they support.

action

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

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

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

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

+---x action
   +---w input
      +---w (from)
      |  +--:(varref)
      |  |  +---w varref?                string
      |  +--:(from-cli)
      |     +---w (target-parm)?
      |     |  +--:(target)
      |     |  |  +---w target           yang:xpath1.0
      |     |  +--:(urltarget-case)
      |     |     +---w urltarget        ywt:UrlPath
      |     |     +---w match-names?     ywt:NameMatchMode
      |     |     +---w alt-names?       ywt:AltNameMode
      |     |     +---w wildcard-keys?   boolean
      |     +---w optional?              empty
      |     +---w value?                 <anyxml>
      +---w timeout?                     nt:Timeout

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

5

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • choice 'from' (not entered)

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

    • usage: mandatory

    • default: none

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

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: mandatory

          • default: none

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

        • urltarget

          • type: string

          • usage: optional

          • default: none

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

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • TBD: THIS PARAMETER IS NOT SUPPORTED YET

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

  • timeout

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

    • usage: optional

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

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

YANG Module Example:

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

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

Invoke “draw” action:

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

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

RPC OK Reply 2 for session 3 [default]:

andy@localhost>

XML sent to NETCONF server:

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

Reference:

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.

+---x alias
    +---w input
       +---w var?   string

Command type:

local

Default parameter:

var

Min parameters:

0

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • var

    • type: string

    • usage: optional

    • default: none

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

      • A double-quoted string can contain single quotes:

        > alias get-eth0=”xget /interfaces/interface[name='eth0']
      • A single-quoted string can contain double quotes:

        alias get-eth0='xget /interfaces/interface[name=”eth0”]'
        
      • An unquoted string can be used if the <value> does not contain any whitespace:

        > alias gc=get-config
        

Positive Response:

  • If no parameter given:

    • The current list of command aliases is displayed.

  • If a <name> parameter given:

    • The specified alias is displayed.

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

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

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

Negative Response:

  • If no parameter given:

    • Not applicable

  • If a <name> parameter given:

    • Error: alias 'foo' not found

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

    • Error message printed if value is invalid

Usage:

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

Added alias 'get-running'

>

apply

The 'apply' command is available in config mode to apply pending edits to the server configuration.

+---x apply

Command type:

config mode

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

none

Command Parameters:

  • none

Positive Response:

  • A message indicated action performed will be printed if --log-level is info or above.

Negative Response:

  • An error message will be printed

Usage:

Example with --config-commit-mode=false (default):

server1# nacm groups group mygroup

server1(group)# !us

server1(group)# user-name fred

server1(group)# user-name barney

server1(group)# apply

Applying 1 edit

server1(group)#

Example with --config-commit-mode=true:

server1# nacm groups group mygroup

server1(group)# user-name fred

server1(group)# user-name barney

server1(group)# apply

Applying 1 edit

Warning:edits have been made to candidate, but no commit done.
Use config-commit to commit the current configuration to the running datastore.

server1(group)#

aliases

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

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

There are 4 forms of the aliases command:

  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.

+---x aliases
   +---w input
      +---w (alias-action)?
         +--:(show)
         |  +---w show?    empty
         +--:(clear)
         |  +---w clear?   empty
         +--:(load)
         |  +---w load?    string
         +--:(save)
            +---w save?    string

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • alias-action

    • type: choice

    • usage: optional

    • default: show

    • clear

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

    • load [alias-filespec]

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

    • save [alias-filespec]

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

    • show

      • Displays all aliases in memory.

Positive Response:

  • show:

    • The current list of command aliases is displayed.

  • clear, load, save:

    • A status message is displayed.

Negative Response:

  • An error message is printed if any error occurs.

Usage:

> aliases save

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

>

auto-test

The 'auto-test' command is used to test edit operations and performance on a NETCONF server.

It can be used to generate pseudo-random <edit-config> operations for a specified data node. All configuration descendant nodes will be created. Each time an edit is done the NETCONF “replace” operation is used.

If the :startup capability is not present then the edit will be saved to non-volatile storage by the server after each edit is completed. Otherwise the auto-test command will automatically save all edits at the end of the test.

The 'target' parameter is used to specify the database configuration node to use for the test. This is a schema identifier string. No key value predicates are allowed, just object names.

The 'iterations' parameter specifies how many edits to complete. If the candidate database is the server target, then an edit is an <edit-config> operation, followed by a <commit> operation. If the running database is the server target, then an edit is simply an <edit-config> operation.

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

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

+---x auto-test
   +---w input
      +---w target          string
      +---w session-name?   nt:NcxIdentifier
      +---w iterations?     uint32

Command type:

local

Default parameter:

target

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • target

    • type: schema identifier string

    • usage: mandatory

    • default: none

    • This parameter specifies the data node to test.

  • session-name

    • type: identifier string

    • usage: optional

    • default: current session

    • This parameter specifies the session name to use for the test

  • iterations

    • type: uint32

    • usage: optional

    • default: 1

    • This parameter specifies the number of edits to perform for the test.

Positive Response:

  • show:

    • The current list of command aliases is displayed.

  • clear, load, save:

    • A status message is displayed.

Negative Response:

  • An error message is printed if any error occurs.

Usage:

andy@myserver> auto-test target=/ptest1 iterations=100

[edits done on current session]

andy@myserver>

cache

The 'cache' command is used to clear 1 or all entries from the YANG module cache.

There are 3 forms of the cache command:

  1. cache clear: Clear the YANG module cache on disk.

  2. cache delete= module-name Delete the specified module name from the YANG module cache. All revisions will be deleted from the cache.

  3. cache delete= module-name [revision=revision-date] Delete the specified module name and revision date from the YANG module cache.

+---x cache
   +---w input
      +---w (cache-input)
         +--:(clear)
         |  +---w clear?      empty
         +--:(delete-cache)
            +---w delete      nt:NcxIdentifier
            +---w revision?   nt:Date

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

2

Return type:

none

YANG file:

yangcli-pro.yang

Command Parameters:

  • cache-action

    • type: choice

    • usage: optional

    • default: none

    • clear

      • Clear the YANG module cache on disk.

    • delete [name of module]

      • delete the specified YANG modules from YANG module cache.

    • revision [revision-date of module]

      • deletes the specified YANG modules from YANG module cache.

Positive Response:

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

Negative Response:

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

Usage:

Example: show the cache

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

Example: delete all revisions of one module in the cache

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

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

Example: delete one revision of one module in the cache

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

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

Example: clear the cache

andy@myserver> cache clear

empty cache: ./yumapro/.yangcli

andy@myserver>

Reference:

cancel-commit

The 'cancel-commit' command is used to stop a confirmed commit procedure on the server. A commit operation must be done before this command is relevant.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <cancel-commit> operation for parameter details.

Usage:

server1> commit confirmed

RPC OK Reply 3 for session 3 [default]:

server1> cancel-commit

RPC OK Reply 4 for session 3 [default]:

server1>

cancel-subscription

The cancel-subscription command is used to stop receiving notifications from the server, from a previous create-subscription command.

The :notification capability must be supported by the server to use this command.

Unless the :interleave capability is also supported by the server, then only the close-session command can be used while notifications are being delivered.

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

Refer to the <cancel-subscription> operation for parameter details.

Usage:

andy@myserver> cancel-subscription

RPC OK Reply 13 for session 10:

OR

andy@myserver>

Reference:

  • none

cd

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

+---x cd
   +---w input
      +---w dir    string

Command type:

local

Default parameter:

dir

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • dir

    • type: string

    • usage: mandatory

    • default: none

    • The 'dir' string must contain a valid directory specification

Positive Response:

  • the new current working directory is printed

Negative Response:

  • an error message will be printed describing the error

Usage:

> cd ~/modules

Current working directory is /home/andy/modules

> cd --dir=$YUMAPRO_HOME

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

>

clear

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

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

+---x clear

Command type:

local

Default parameter:

N/A

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

yangcli-pro.yang

Command Parameters: none

Positive Response:

  • the screen is cleared

Negative Response:

  • no change to screen

Usage:

> clear

After the command the screen is cleared and a new prompt is printed in on the first line.

close-session

The 'close-session' command is used to terminate the current NETCONF session. A NETCONF server should always accept this command if it is valid, and not reject it due to access control enforcement or if the server is in notification delivery mode. This command is provided by the NETCONF server, not yangcli-pro.

This is a server command. Refer to the <close-session> operation for parameter details.

Usage:

andy@myserver> close-session

RPC OK Reply 2 for session 10:

>

Reference:

commit

The 'commit' command is used to save the edits in the <candidate> database into the <running> database. If there are no edits it will have no effect.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <commit> operation for parameter details.

Usage:

andy@myserver> commit

RPC OK Reply 5 for session 10:

andy@myserver>

Reference:

config

The 'config' command is used to enter configuration mode. It can only be used if the current session is connected to a NETCONF or RESTCONF server.

  • The configuration source is given as the only parameter

  • The value 'terminal' is the only supported configuration source at this time.

  • The max command line length is 4095 character.

+---x config
    +---w input
       +---w (config-source)?
          +--:(term)
             +---w term?   empty

Command type:

local

Default parameter:

term

Min parameters:

1

Max parameters:

1

Return type:

none (enter configuration mode)

YANG file:

yangcli-pro.yang

Command Parameters:

  • term

    • type: empty

    • usage: mandatory

    • default: present

    • This parameter specifies that the terminal is the configuration source

Positive Response:

  • the prompt will change indicating configuration mode is active

Negative Response:

  • An error message will be printed

Usage:

andy@myserver> config term

andy@myserver#

config-commit

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

This command is only used in config mode when --config-commit-mode=true.

+---x config-commit

Command type:

config

Default parameter:

0

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

none

Command Parameters:

  • none.

Positive Response:

  • No error message.

Negative Response:

  • An error message will be printed

Usage:

andy@myserver> config term

andy@myserver# config-commit

connect

The 'connect' command is used to start a session with a NETCONF server.

This command can be used in 3 forms:

  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 is used for all connection parameters.

  3. Modified Named Session: The 'session-name' parameter is used and additional parameters are also specified, which will cause the session-cfg template to be updated if the connection is successful.

If there already is a NETCONF session active, then an error message will be printed and the command will not be executed.

+---x connect
   +---w input
      +---w user                 nt:NcxUserName
      +---w server               inet:host
      +---w (pass)
      |  +--:(password)
      |  |  +---w password?      string
      |  +--:(no-password)
      |     +---w no-password?   empty
      +---w ncport?              uint16
      +---w timeout?             nt:Timeout
      +---w public-key?          string
      +---w private-key?         string
      +---w ssl-fallback-ok?     boolean
      +---w ssl-certificate?     string
      +---w ssl-key?             string
      +---w ssl-trust-store?     string
      +---w protocols?           bits
      +---w entry-point?         string
      +---w transport?           ywt:transport-type
      +---w encoding?            ywt:encoding-type
      +---w session-name?        nt:NcxIdentifier

Command type:

remote

Default parameter:

server

Min parameters:

1

Max parameters:

10

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • server

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

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

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

    • This parameter specifies the server address for the session.

  • password

    • type: string (ncx:password)

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

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

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

  • no-password

    • type: empty

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

    • default:not present

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

  • ncport

    • type: uint16

    • usage: optional

    • default: 830

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

  • timeout

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

    • usage: optional

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

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

  • user

    • type: string

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

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

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

  • protocols

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

    • usage: optional

    • default: --protocols configuration parameter setting

    • Specifies which NETCONF protocol versions to enable. Overrides --protocols configuration parameter.

      • netconf1.0: request RFC 4741 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

    • usage: optional

    • default: --public-key configuration parameter setting

    • Specifies the SSH public key file to use. Overrides the --public-key configuration parameter.

  • session-name

    • type: identifier string

    • usage: optional

    • default: none

    • Specifies the named session configuration entry to use for the connection information. Sessions can be saved while active with the 'session-cfg save' command.

      • If this parameter is used and the named session configuration is found, then that session will be used for connection parameters. Any additional parameters will be used to update the existing named session entry.

      • If this parameter is used and the named session configuration is not found, then other parameters will be checked, and a connection attempt will be made. If successful, the session parameters will be saved as a new saved session.

  • transport

    • type: enumeration (ssh, tcp, tcp-ncx, tls)

    • usage: optional

    • default: ssh

    • This parameter specifies the transport protocol to use.

      • ssh:

        Selects the standard NETCONF transport (and 'ncport' specifies the SSH port to use).

      • tcp:

        Selects the tail-f NETCONF over TCP protocol.

        • The 'ncport' value is set to 2023.

        • The 'protocols' value is set to netconf1.0.

        • The 'password' value will be ignored if present.

        • A direct TCP connection will be used instead of SSH, using the tail-f structured connection string protocol.

      • tcp-ncx:

        Selects the YumaWorks NETCONF over TCP protocol.

        • The 'ncport' value is set to 2023.

        • The 'protocols' value is set to netconf1.0.

        • The 'password' value will be ignored if present.

        • A direct TCP connection will be used instead of SSH, using the YumaWorks <ncx-connect> protocol.

      • tls:

        Selects the TLS protocol

  • entry-point

    • type: string

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

Positive Response:

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

Negative Response:

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

Usage:

> connect myserver user=andy password=yangrocks

<startup screen printed>

andy@myserver>

copy-config

The 'copy-config' command is used to copy one entire NETCONF database to another location.

Not all possible parameter combinations will be supported by every server. In fact, the NETCONF protocol does not require any parameters to be supported unless the :startup or :url capabilities is supported by the server.

If the server supports the :startup capability, then it must support the following operation:

andy@myserver> copy-config source=running target=startup

This is the standard way to save a snapshot of the current running configuration in non-volatile storage, if the server has a separate startup database. If not, the server will automatically save any changes to the running configuration to non-volatile storage.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <copy-config> operation for parameter details.

Usage:

andy@myserver> copy-config source=candidate

Enter a number of the selected case statement:

  1: case candidate:
       leaf candidate
  2: case running:
       leaf running
  3: case startup:
       leaf startup
  4: case url:
       leaf url

Enter choice number [1 - 4]:
andy@myserver:copy-config> 4

Enter string value for leaf <url>:
andy@myserver:copy-config> file:///myconfig.xml

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

Reference:

create

The 'create' command is a high-level <edit-config> operation. It is used to create some new nodes in the default target database.

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

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

+---x create
   +---w input
      +---w (from)
      |  +--:(varref)
      |  |  +---w varref?                string
      |  +--:(from-cli)
      |     +---w (target-parm)?
      |     |  +--:(target)
      |     |  |  +---w target           yang:xpath1.0
      |     |  +--:(urltarget-case)
      |     |     +---w urltarget        ywt:UrlPath
      |     |     +---w match-names?     ywt:NameMatchMode
      |     |     +---w alt-names?       ywt:AltNameMode
      |     |     +---w wildcard-keys?   boolean
      |     +---w optional?              empty
      |     +---w value?                 <anyxml>
      +---w timeout?                     nt:Timeout

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

5

Return type:

status

YANG file:

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

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

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: mandatory

          • default: none

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

        • urltarget

          • type: string

          • usage: optional

          • default: none

          • This parameter specifies the database target node of the create operation. This is an UrlPath string.

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.

  • timeout

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

    • usage: optional

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

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

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver> create varref=myvar

RPC OK Reply 10 for session 10:

andy@myserver> create /nacm/rules/data-rule

(user will be prompted to fill in the data-rule contents)

RPC OK Reply 11 for session 10:

andy@myserver> create target=/nacm/rules/data-rule[name='test rule']/comment value=”this test rule is temporary. Do not remove!”

(no user prompting; <edit-config> request sent right away)

RPC OK Reply 12 for session 10:

andy@myserver>

Reference:

create-subscription

The 'create-subscription' command is used to start receiving notifications from the server.

The :notification capability must be supported by the server to use this command.

Unless the :interleave capability is also supported by the server, then only the close-session command can be used while notifications are being delivered.

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

Refer to the <create-subscription> operation for parameter details.

Usage:

andy@myserver> create-subscription

RPC OK Reply 13 for session 10:

OR

andy@myserver> create-subscription startTime=2009-01-01T00:00:00Z

RPC OK Reply 14 for session 10:

andy@myserver>

Reference:

device-cfg

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

There are 3 sub-commands:

  • delete

  • save

  • show (default)

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

+---x device-cfg
   +---w input
      +---w (device-action)?
         +--:(show-case)
         |  +---w show?           IdentifierOrZero
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?    empty
         |     +--:(normal)
         |     |  +---w normal?   empty
         |     +--:(full)
         |        +---w full?     empty
         +--:(delete)
         |  +---w delete?         nt:NcxIdentifier
         +--:(save)
         |  +---w save?           nt:NcxIdentifier
         +--:(create)
            +---w create          nt:NcxName
            +---w server          inet:host
            +---w ncport?         uint16
            +---w entry-point?    string
            +---w protocols?      bits

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • delete

    • type: name string

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

  • save

    • type: name string

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

  • show

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

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

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

Positive Response:

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

Negative Response:

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

andy@myserver> device-cfg save device-A

Saving current device as 'device-A'

andy@myserver>

devices-cfg

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

There are 4 sub-commands:

  • clear

  • load

  • save

  • show (default)

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

+---x devices-cfg
   +---w input
      +---w (devices-action)?
         +--:(show-case)
         |  +---w show?           empty
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?    empty
         |     +--:(normal)
         |     |  +---w normal?   empty
         |     +--:(full)
         |        +---w full?     empty
         +--:(clear)
         |  +---w clear?          empty
         +--:(load)
         |  +---w load?           string
         +--:(save)
            +---w save?           string

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • clear

    • type: empty

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

  • load

    • type: string

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

  • save

    • type: name string

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

  • show

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

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

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

Positive Response:

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

Negative Response:

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

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

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

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

session-A>

delete

The 'delete' command is a high-level <edit-config> operation. It is used to delete an existing subtree in the default target database.

A target node is specified, and then any missing key leafs (if any) within the data structure are filled in. If the target is a leaf-list, then the user will be prompted for the value of the leaf-list node to be deleted.

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

+---x delete
   +---w input
      +---w (delete-target)
      |  +--:(target)
      |  |  +---w target?      string
      |  +--:(urltarget)
      |     +---w urltarget?   ywt:UrlPath
      +---w value?             <anyxml>

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

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

  • urltarget

    • type: string

    • usage: optional

    • default: none

    • This parameter specifies the database target node of the delete operation. This is an UrlPath string.

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$optional

    • Controls whether optional descendant nodes will be filled into the target parameter contents

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver> delete /nacm/rules/data-rule

(user will be prompted to fill in the data-rule 'name' key leaf)

RPC OK Reply 15 for session 10:

andy@myserver> delete target=/nacm/rules/data-rule[name='test rule']/comment

(no user prompting; <edit-config> request sent right away)

RPC OK Reply 16 for session 10:

andy@myserver>

Reference:

delete-all

The 'delete-all' command is a high-level <edit-config> operation. It is used to delete all instances of a list or leaf-list in the default target database.

A target node is specified, and then any missing key leafs (if any) within the data structure are filled in. If the target is a leaf-list, then the user will be prompted for the value of the leaf-list node to be deleted.

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

+---x delete-all
   +---w input
      +---w (delete-target)
         +--:(target)
         |  +---w target?      string
         +--:(urltarget)
            +---w urltarget?   ywt:UrlPath

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

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

  • urltarget

    • type: string

    • usage: optional

    • default: none

    • This parameter specifies the database target node of the delete operation. This is an UrlPath string.

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$optional

    • Controls whether optional descendant nodes will be filled into the target parameter contents

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver> delete-all /nacm/rules/data-rule

(user will be prompted to fill in the data-rule 'name' key leaf)

RPC OK Reply 15 for session 10:

andy@myserver>

Reference:

  • none

delete-config

The 'delete-config' command is used to delete an entire NETCONF database.

Not all possible 'target' parameter values will be supported by every server. In fact, the NETCONF protocol does not require that any database be supported by this operation.

If the server supports the :url capability, then it may support deletion of local file databases in this manner.:

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <delete-config> operation for parameter details.

Usage:

andy@myserver> delete-config target=startup

RPC OK Reply 17 for session 10:

andy@myserver>

Reference:

delete-subscription

The 'delete-subscription' command is used to terminate your own notification subscription on the connected NETCONF server. The netconfd-pro server must have the yang-push bundle enabled for this operation to be available.

The subscription-id returned in the establish-subscription command must be used as the parameter, since a session can have multiple subscriptions active at once.

The server should also send a <subscription-terminated> Event notification as a result of the operation.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <delete-subscription> operation for parameter details.

Usage:

server1> delete-subscription id=1

Incoming notification for session 2 [default]:
notification {
  eventTime 2022-01-13T02:56:35Z
  subscription-terminated {
    id 1
    reason sn:no-such-subscription
  }
}

RPC OK Reply 5 for session 3 [default]:

server1>

discard-changes

The 'discard-changes' command is used to delete any edits that exist in the <candidate> database, on the NETCONF server. The server will only accept this command if the :candidate capability is supported. If the <candidate> database is locked by another session, then this request will fail with an 'in-use' error.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <discard-changes> operation for parameter details.

Usage:

andy@myserver> discard-changes

RPC OK Reply 18 for session 10:

andy@myserver>

Reference:

do

The 'do' command is available in config mode to invoke a non-config mode command, such as show.

Only 3 sub-commands are supported:

Command type:

config mode

Default parameter:

none

Min parameters:

1

Max parameters:

1

Return type:

none

YANG file:

none

Command Parameters:

  • 1 parameter expected, which is start of 1 of the 3 supported commands

Positive Response:

  • No error message.

Negative Response:

  • An error message will be printed

Usage:

server1# do show var optional

optional false

server1#

edit-config

The 'edit-config' command allows a subset of a NETCONF database on the server to be changed.

If the server supports the :url capability, then it may support editing of local file databases.

If the server supports the :candidate capability, then it will allow edits to the <candidate> database.

If the server supports the :writable-running capability, it will support edits to the <running> database.

It is not likely that a server will support the <candidate> and <running> database as targets at the same time, since changes to the <running> configuration would not be reflected in the <candidate> database, while it was being edited by a different session.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <edit-config> operation for parameter details.

Usage:

andy@myserver> edit-config target=candidate default-operation=merge test-option=test error-option=stop-on-error config=@myconfig.xml

RPC OK Reply 19 for session 10:

andy@myserver>

Reference:

elif

The 'elif' command is used to define a conditional command block after an if command.

This command must be entered within the same script as the if command, when used within a script. It can be used zero or more times within an if command sequence.

The 'expr' parameter is used to specify the XPath expression to test if the elif conditional block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.

The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.

Even if the 'expr' expression is true, the conditional block will only be executed if no conditional block in the if command sequence has already been executed.

if command

  ....

[elif command]

  ....

[elif-command]

  ...

[else command]

  ...

end

The 'elif' command must be paired with a matching end command. It can also be continued with consecutive 'elif' statements.

+---x elif
   +---w input
      +---w expr       yang:xpath1.0
      +---w docroot?   <anyxml>

Command type:

local

Default parameter:

expr

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • expr

    • type: XPath expression string

    • usage: mandatory

    • default: none

    • This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.

  • docroot

    • type: anyxml

    • usage: optional (typically a variable reference is used)

    • default: none

    • This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.

Positive Response:

  • the server returns <ok/>

Negative Response:

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

    • elif without a previous if command will cause an error

    • elif following an 'else' command will cause an error

    • invalid XPath expression or invalid docroot reference will cause an error

Usage:

andy@myserver> elif expr='$x > 4'

andy@myserver>

else

The 'else' command is used to define a final conditional command block after an if command. It must eventually be terminated by a end command.

This command must be entered within the same script as the if command, when used within a script. It can be used zero or one time within an if command sequence.

if command

  ....

[elif command]

  ....

[elif-command]

  ...

[else command]

  ...

end

The conditional command block following the else command will only be executed if no conditional block has already been executed in the same if command sequence.

+---x else

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters: none

Positive Response:

  • the server returns <ok/>

Negative Response:

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

    • else without a previous if command will cause an error

Usage:

> else

enable

The 'enable' command is used to enter enable mode.

This command is available in yp-shell and only if yp-shell is started with the --with-enable-mode parameter set to true.

+---x enable
   +---w input
      +---w (pass)?
         +--:(password)
         |  +---w password?      string
         +--:(no-password)
            +---w no-password?   empty

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

1

Return type:

none

YANG file:

yangcli-pro.yang

Command Parameters:

  • password

    • type: string (ncx:password)

    • usage: optional

    • default: none

    • This parameter specifies the password string to use to enter the enable mode.

  • no-password

    • type: empty

    • usage: optional

    • default: none

    • This parameter specifies that there is no password needed to enter the enable mode.

Usage:

server1> enable

server1# enable

enable-password

The 'enable-password' command is used to configure the password in config mode for yp-shell.

This command is available in yp-shell and only if yp-shell is started with the --with-enable-mode parameter set to true.

+---x enable-password
   +---w input
      +---w password    string

Command type:

config-mode

Default parameter:

password

Min parameters:

1

Max parameters:

1

Return type:

none

YANG file:

yangcli-pro.yang

Command Parameters:

  • password

    • type: string (ncx:password)

    • usage: optional

    • default: none

    • This parameter specifies the password string to use to enter the enable mode.

Usage:

server1> enable-password my-password

end

The 'end' command is used to terminate a conditional command block after an 'if' command block, or after a 'while' command block.

This command must be entered within the same script as the if or while command that started the conditional block.

if command

  ....

[elif command]

  ....

[elif-command]

  ...

[else command]

  ...

end


while command

   ...

end command
+---x end

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters: none

Positive Response:

  • the server returns <ok/>

Negative Response:

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

    • else without a previous if command will cause an error

Usage:

> end

>

establish-subscription

The 'establish-subscription' command is used to start a notification subscription on the connected NETCONF server. The netconfd-pro server must have the yang-push bundle enabled for this operation to be available.

The server is expected to return the subscription-id if the operation succeeds.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <establish-subscription> operation for parameter details.

Usage:

session1> establish-subscription stream=mystream

RPC Data Reply 1 for session 3 [default]:

rpc-reply {
  id 1
}

server1>

eval

The 'eval' command is used to evaluate an XPath expression..

The 'expr' parameter is used to specify the XPath expression to evaluate. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.

The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.

+---x eval
   +---w input
   |  +---w expr       yang:xpath1.0
   |  +---w docroot?   <anyxml>
   +--ro output
      +--ro data    <anyxml>

Command type:

local

Default parameter:

expr

Min parameters:

1

Max parameters:

2

Return type:

data

YANG file:

yangcli-pro.yang

Command Parameters:

  • expr

    • type: XPath expression string

    • usage: mandatory

    • default: none

    • This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.

  • docroot

    • type: anyxml

    • usage: optional (typically a variable reference is used)

    • default: none

    • This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.

Positive Response:

  • the server returns <ok/>

Negative Response:

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

    • elif without a previous if command will cause an error

    • elif following an 'else' command will cause an error

    • invalid XPath expression or invalid docroot reference will cause an error

Output:

  • data

    • type: anyxml

    • This element will contain the result from the XPath expression. A node-set result will produce a complex element return value, and all other XPath result types will produce a string return value.

Usage:

session1> $x = eval '$x + 1'

session1> $sysname = eval '//sysName' docroot=$backup

event-handler-cfg

The 'event-handler-cfg' command is used to access a named event-handler.

There are 4 sub-commands:

  • delete

  • save

  • show (default)

  • create

+---x event-handler-cfg
    +---w input
       +---w (user-action)?
          +--:(show-case)
          |  +---w show?                 IdentifierOrZero
          |  +---w (help-mode)?
          |     +--:(brief)
          |     |  +---w brief?          empty
          |     +--:(normal)
          |     |  +---w normal?         empty
          |     +--:(full)
          |        +---w full?           empty
          +--:(delete)
          |  +---w delete?               nt:NcxIdentifier
          +--:(save)
          |  +---w save?                 nt:NcxIdentifier
          +--:(create)
             +---w create                nt:NcxName
             +---w module-name?          nt:NcxName
             +---w event-name?           nt:NcxName
             +---w (script-type)
                +--:(script)
                |  +---w script?         string
                +--:(shell-script)
                   +---w shell-script?   string

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • delete

    • type: name string

    • This parameter specifies the name of the event-handler to delete from the saved event-handlers in memory.

  • save

    • type: name string

    • This parameter specifies the name of the event-handler to save in the saved event-handlers in memory.

  • show

    • This parameter specifies the name of the event-handler to show.

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

  • create

    • type: name string

    • This parameter specifies a new event-handler to create.

Positive Response:

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

Negative Response:

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

event-handlers-cfg

The 'event-handlers-cfg' command is used to access the named event-handlers files.

There are 4 sub-commands:

  • clear

  • load

  • save

  • show (default)

+---x event-handlers-cfg
    +---w input
       +---w (event-handlers-action)?
          +--:(show-case)
          |  +---w show?           empty
          |  +---w (help-mode)?
          |     +--:(brief)
          |     |  +---w brief?    empty
          |     +--:(normal)
          |     |  +---w normal?   empty
          |     +--:(full)
          |        +---w full?     empty
          +--:(clear)
          |  +---w clear?          empty
          +--:(load)
          |  +---w load?           string
          +--:(save)
             +---w save?           string

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • clear

    • type: empty

    • This parameter indicates that all saved event-handlers in memory be deleted. This cannot be done if any of the event-handlers are currently active. Use 'event-handlers-cfg load' to restore the saved users.

  • load

    • type: string

    • This parameter identifies the file specification for the saved event-handlers to load. Any new named event-handlers will be added to the named users in memory.

  • save

    • type: name string

    • This parameter identifies the file specification for the saved event-handlers config file to load. The saved event-handlers in memory will be saved to this file.

  • show

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

eventlog

The 'eventlog' command is used to view or clear all or part of the notification event log. This log will be empty if no well-formed notifications have been received from any server.

The 'eventlog show' command is used to display some event log entries.

The 'eventlog clear' command is used to delete some event log entries.

If no parameters are entered, it is the same as entering eventlog show=-1.

The event log is not automatically emptied when a session terminates, in case the session was dropped unexpectedly. New entries will be appended to the event log as new sessions and/or subscriptions are started.

+---x eventlog
    +---w input
       +---w (eventlog-action)?
          +--:(show-case)
          |  +---w show?           LogCount
          |  +---w start?          LogIndex
          |  +---w (help-mode)?
          |     +--:(brief)
          |     |  +---w brief?    empty
          |     +--:(normal)
          |     |  +---w normal?   empty
          |     +--:(full)
          |        +---w full?     empty
          +--:(clear)
             +---w clear?          LogCount

Command type:

local

Default parameter:

show

Min parameters:

0

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • choice eventlog-action (not entered):

    • type: choice of case 'show-case' or leaf 'clear'

    • usage: optional

    • default: show=-1 is used as the default if nothing entered

    • This parameter specifies the event log action that should be performed.

      • clear

        • type: int32 (-1 to clear all entries; 1 to max to delete N entries)

        • usage: optional

        • default: -1

        • This parameter specifies the maximum number of event log entries to be deleted, starting from the oldest entries in the event log. The value -1 means delete all the entries. Otherwise the value must be greater than zero, and up to that many entries will be deleted.

      • case show-case (not entered)

        • choice help-mode (not entered) (default choice is 'normal')

          • brief

            • type: empty

            • usage: optional

            • default: none

            • This parameter specifies that brief documentation mode should be used. The event log index, sequence ID, and <eventType> will be displayed in this mode.

          • normal

            • type: empty

            • usage: optional

            • default: none

            • This parameter specifies that normal documentation mode should be used. The event log index, <eventTime>, sequence ID, and <eventType> will be displayed in this mode.

          • full

            • type: empty

            • usage: optional

            • default: none

            • This parameter specifies that full documentation mode should be used. The event log index, <eventTime>, sequence ID, and <eventType> will be displayed in this mode. In addition, the entire contents of the notification PDU will be displayed, using the current $$display-mode setting.

        • show

          • type: int32 (-1 for all, 1 to max for N entries)

          • usage: optional

          • default: -1

          • This parameter specifies the number of event log entries that should be displayed. The value '-1' indicates all the entries should be displayed. Otherwise, the value must be greater than zero, indicating the number of entries to display.

        • start

          • type: uint32

          • usage: optional

          • default: 0

          • This parameter specifies the start position in the event log to start displaying entries. The first entry is number zero. Each time the event log is cleared, the numbering restarts.

System Variables:

  • $$display-mode

    • The log entries printed when help-mode='full' are formatted according to the current value of this system variable.

Positive Response:

  • the event log entries are printed or cleared as requested

Negative Response:

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

Usage:

> eventlog show=5 start=3

 [3]     [2009-07-10T02:21:10Z] (4)     <sysSessionStart>
 [4]     [2009-07-10T02:23:14Z] (5)     <sysSessionEnd>
 [5]     [2009-07-10T02:23:23Z] (6)     <sysSessionStart>
 [6]     [2009-07-10T02:24:52Z] (7)     <sysConfigChange>
 [7]     [2009-07-10T02:24:57Z] (8)     <sysSessionEnd>

>

exit

The 'exit' command is used to exit configuration editing mode or exit the current editing sub-mode if the configuration context node is not the root.

If the $$config-edit-mode system parameter is set to 'level', then exiting from a sub-mode to the top-level configuration mode will cause any pending edits to be applied to the current session.

If the $$config-edit-mode system parameter is set to 'mode', then exiting from the top-level configuration mode will cause any pending edits to be applied to the current session.

There are no parameters for this command.

+---x exit

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

none (prompt is changed)

YANG file:

yangcli-pro.yang

Command Parameters:

  • none

System Variables:

  • none

Positive Response:

  • the prompt is changed to indicate the new level. If edits are applied a message will be displayed indicating edits were applied to the session.

Negative Response:

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

Usage:

andy@myserver# exit

andy@myserver>

fill

The 'fill' command is used to create a user variable for reuse in other commands.

It is used in an assignment statement to create a variable from various sources.

If it is not used in an assignment statement, then the result will not be saved, so the command will have no effect in this case.

The value contents will mirror the subtree within the NETCONF database indicated by the target parameter. If not completely provided, then missing descendant nodes will be filled in interactively, by prompting for each missing node.

+---x fill
   +---w input
   |  +---w (target-parm)?
   |  |  +--:(target)
   |  |  |  +---w target           yang:xpath1.0
   |  |  +--:(urltarget-case)
   |  |     +---w urltarget        ywt:UrlPath
   |  |     +---w match-names?     ywt:NameMatchMode
   |  |     +---w alt-names?       ywt:AltNameMode
   |  |     +---w wildcard-keys?   boolean
   |  +---w optional?              empty
   |  +---w value?                 <anyxml>
   +--ro output
      +--ro data?   <anyxml>

Command type:

local

Default parameter:

target

Min parameters:

2

Max parameters:

3

Return type:

data

YANG file:

yangcli-pro.yang

Command Parameters:

  • optional

    • type: empty

    • usage: optional

    • default: controlled by $$optional system variable

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

  • target

    • type: string

    • usage: mandatory

    • default: none

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

  • value

    • type: anyxml

    • usage: mandatory

    • default: none

    • This parameter specifies the content to use for the filled variable.

      • If this parameter is not entered, then the user will be prompted interactively to fill in the 'target' data structure.

      • If a string is entered, then the target value being filled must be a leaf or leaf-list.

      • If a variable reference is entered, then it will be used as the content, if the target value being filled is a leaf or a leaf-list.

      • If the target value is a complex object, then the referenced variable must also be a complex object of the same type.

      • An error will be reported if the global or local variable does not reference the same object type as the target parameter.

System Variables:

  • $$optional

    • Controls whether optional descendant nodes will be filled into the 'target' parameter contents

Positive Response:

  • OK

Negative Response:

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

Output:

  • data

    • type: anyxml

    • The data structure will mirror the requested target object.

    • The variable (if any) will retain the target object name and namespace so it can be used in other operations more easily. In the example below, the '$my_interface' local variable will have the module name 'interfaces' and name 'interface', when used in other commands such as create or merge.

Usage:

> $my-interface = fill target=/interfaces/interface optional

(user will be prompted to fill in all fields of the <interface> element)

OK

>

get

The 'get' command is used to retrieve data from the server. This command is provided by the NETCONF server, not yangcli-pro.

The 'module-tag' parameter is only supported if netconfd-pro is the server used.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get> operation for parameter details.

Usage:

session1> get

RPC Data Reply 20 for session 10:

rpc-reply {
    data {
       …. data returned by the server
    }
}

session1> get filter=@myfilter.xml

RPC Data Reply 21 for session 10:

rpc-reply {
    data {
    }
}

(the previous response will occur if the filter did not
 match anything or the server access control filtered the
 entire response)

session1>

Reference:

get-bulk

The 'get-bulk' command is used to retrieve YANG list data one or more entries at a time.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-bulk> operation for parameter details.

Usage:

Reference:

  • none

get-config

The 'get-config' command is used to retrieve configuration data from the server.

The 'module-tag' parameter is only supported if netconfd-pro is the server used.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-config> operation for parameter details.

Usage:

session1>  $my-config = get-config target=running

RPC Data Reply 22 for session 10:

rpc-reply {
    data {
       …. entire database returned by the server
    }
}

yangcli-pro andy@myserver[d]> @saved-config.xml = get-config \
        filter=@myfilter.xml  \
        target=candidate

rpc-reply {
    data {
        … data requested by the filter
    }
}

session1>

Reference:

get-data

The get-data command is used to retrieve configuration or operational NMDA datastores from the server. The server must have NMDA enabled for this operation to be present.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-data> operation for parameter details.

Usage:

Reference:

get-locks

The 'get-locks' command is a high-level wrapper for the <lock> operation. It is used to lock all the databases (<running> plus <candidate> and/or <startup> if they exist). If all the locks cannot be obtained, then release all the locks that were obtained (all-or-nothing).

The entire time to wait for a lock in use is set with the lock-timeout parameter.

The retry-interval parameter is used when the <lock> operation fails with a 'lock-denied' error-tag, because some other session has the lock.

If the <candidate> cannot be locked for another reason, a <discard-changes> operation will be attempted to clear any leftover edits.

Normally, the errors received while attempting to acquire locks are not printed to the log, like normal commands. Instead, if $$log-level system parameter is set to 'debug2' or 'debug3', then these messages will be printed.

+---x get-locks
    +---w input
       +---w lock-timeout?     nt:Timeout
       +---w retry-interval?   uint32
       +---w cleanup?          boolean

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • lock-timeout

    • type: uint32 (seconds)

    • usage: optional

    • default: 120 seconds (2 minutes)

    • This parameter specifies how long to wait for a lock that is in use by another session.

  • retry-interval

    • type: uint32 (seconds)

    • usage: optional

    • default: 2 seconds

    • This parameter specifies how long to wait to retry for a lock.

  • cleanup

    • type:boolean

    • usage: optional

    • default: true

    • This parameter controls whether the 'release-locks' command will be called automatically if the entire set of required locks cannot be granted.

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

session1> get-locks lock-timeout=0

Sending <lock> operations for get-locks...

RPC OK Reply 6 for session 23:

RPC OK Reply 7 for session 23:

get-locks finished OK

session1>

get-my-session

The 'get-my-session' command is used to retrieve the session customization parameters from the server. It is only supported by the netconfd-pro server.

The session indent amount, session line size, and default behavior for the with-defaults parameter can be controlled at this time.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-my-session> operation for parameter details.

get-schema

The 'get-schema' command is used to retrieve data model definition files from the server. This is part of the NETCONF monitoring draft. The server must support the :schema-retrieval capability to use this command.

If the server reports a module or module version that yangcli-pro cannot find in its local module library, then an error message will be printed. The get-schema command can then be used to retrieve the missing module from the server.

The ietf-netconf-monitoring.yang module includes a list of the schema supported by the server, which can be retrieved from a server that supports this module, such as netconfd-pro.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <get-schema> operation for parameter details.

Usage:

session1> @notifications.yang = get-schema \
        identifier=notifications \
        version=2009-06-04 \
        format=YANG

RPC Data Reply 24 for session 10:

rpc-reply {
    data {
       …. entire notifications.yang contents
    }
}

(after retrieval, the module can be loaded locally
 with the mgrload command)

session1> mgrload notifications.yang

   OK

session1>

Reference:

get-walk

This command walks the entries of a YANG list using the netconfd-pro <get-bulk> operation. This command will send <get-bulk> requests to the server until the entire list has been retrieved or the user quits the walk.

If the yumaworks-getbulk.yang module is not supported by the server then this command will not be attempted.

If the program is in interactive mode, then after each retrieval, the user will be prompted to continue or quit the walk. In batch mode the entries will be displayed until the walk terminates.

The server will wait the normal 'timeout' period after each request. It will display each response and check it for 'last-keys' data. If present, these values will be used for the 'last-keys' parameter in the next request If not present, then the walk will end.

The walk will be done on the YANG list specified by the 'list-target' parameter. Each retrieval will request 1 or more entries, based on the 'count' parameter. The data returned can be filtered according to the 'content', 'depth', 'with-defaults', and 'list-test' parameters, which as passed to the <get-bulk> operation each time.

The 'list-target' parameter is used to specify that YANG list that will be retrieved.

The 'list-test' parameter allows an XPath boolean expression to be used to test each list-target entry. It is used to select only a subset of the list entries to reduce the number of entries returned.

If a portion of the requested data is not available due to access control restrictions, then that data is silently dropped from the <rpc-reply> message. It is implicitly understood that the client is only requesting data for which it is authorized to receive, in the event such data is selected in the request.

+---x get-walk
   +---w input
      +---w datastore?       enumeration
      +---w list-target      string
      +---w count?           uint32
      +---w content?         enumeration
      +---w depth?           union
      +---w with-defaults?   with-defaults-mode
      +---w list-test?       yang:xpath1.0
      +---w fixed-keys?      <anydata>

Command type:

remote

Default parameter:

none

Min parameters:

1

Max parameters:

7

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Mandatory Parameters:

  • list-target

    • type: string (RESTCONF path URI)

    • usage: mandatory

    • This parameter identifies the list object that is being retrieved. This must be a path expression used to represent a list data node. It is formatted like a RESTCONF path expression, except module names are not mandatory if they are unique.

Optional Parameters:

  • datastore

    • type: enumeration (candidate running startup)

    • usage: optional

    • default: running

    • This parameter specifies the name of the source database for the retrieval operation. It is ignored if the 'list-target' specifies a non-configuration data node.

    • enum: candidate

    • enum : running

      • capabilities needed: none

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

    • default: unbounded

    • This parameter is used as defined in the RESTCONF protocol. The value '1' is associated with the list-object node itself. This value can be used to simply test for the existence of any instances of the list-object.

  • with-defaults

    • type: enumeration (none report-all report-all-tagged trim explicit)

    • usage: --default-style configuration parameter used as the default if no value is provided

    • This parameter controls how default leaf and leaf-list nodes are returned by the server.

  • list-test

    • type: leaf containing an XPath expression

    • usage: optional

    • default: return all selected list-target entries

    • This parameter contains an XPath expression. The document root and the context node are set to the list instance being tested.

Example to continue walk.

andy@server> get-walk count=5 list-target=/modules-state/module \
        list-test="starts-with(name, 'ietf-netconf')" \
        content=all datastore=running depth=unbounded

rpc-reply {
  bulk {
    data {
      module {
        conformance-type implement
        feature candidate
        feature confirmed-commit
        feature rollback-on-error
        feature validate
        feature url
        feature xpath
        name ietf-netconf
        namespace urn:ietf:params:xml:ns:netconf:base:1.0
        revision 2011-06-01
      }
      module {
        conformance-type implement
        name ietf-netconf-acm
        namespace urn:ietf:params:xml:ns:yang:ietf-netconf-acm
        revision 2018-02-14
        schema http://localhost/restconf/yang/ietf-netconf-acm/2018-02-14
      }
      module {
        conformance-type implement
        name ietf-netconf-monitoring
        namespace urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
        revision 2010-10-04
        schema http://localhost/restconf/yang/ietf-netconf-monitoring/2010-10-04
      }
      module {
        conformance-type implement
        name ietf-netconf-notifications
        namespace urn:ietf:params:xml:ns:yang:ietf-netconf-notifications
        revision 2012-02-06
        schema http://localhost/restconf/yang/ietf-netconf-notifications/2012-02-06
      }
      module {
        conformance-type implement
        name ietf-netconf-partial-lock
        namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0
        revision 2009-10-19
        schema http://localhost/restconf/yang/ietf-netconf-partial-lock/2009-10-19
      }
    }
    last-keys {
      name ietf-netconf-partial-lock
      revision 2009-10-19
    }
  }
}

Press Enter to continue, q to quit get-walk:

rpc-reply {
  bulk {
    data {
      module {
        conformance-type implement
        name ietf-netconf-with-defaults
        namespace urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults
        revision 2011-06-01
        schema http://localhost/restconf/yang/ietf-netconf-with-defaults/2011-06-01
      }
      module {
        conformance-type implement
        name ietf-restconf
        namespace urn:ietf:params:xml:ns:yang:ietf-restconf
        revision 2017-01-26
        schema http://localhost/restconf/yang/ietf-restconf/2017-01-26
      }
      module {
        conformance-type implement
        name ietf-restconf-monitoring
        namespace urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring
        revision 2017-01-26
        schema http://localhost/restconf/yang/ietf-restconf-monitoring/2017-01-26
      }
      module {
        conformance-type implement
        name ietf-yang-library
        namespace urn:ietf:params:xml:ns:yang:ietf-yang-library
        revision 2016-06-21
        schema http://localhost/restconf/yang/ietf-yang-library/2016-06-21
      }
      module {
        conformance-type implement
        name ietf-yang-patch
        namespace urn:ietf:params:xml:ns:yang:ietf-yang-patch
        revision 2017-02-22
        schema http://localhost/restconf/yang/ietf-yang-patch/2017-02-22
      }
    }
    last-keys {
      name ietf-yang-patch
      revision 2017-02-22
    }
  }
}

Press Enter to continue, q to quit get-walk:

rpc-reply {
  bulk {
    data {
      module {
        conformance-type import
        name ietf-yang-types
        namespace urn:ietf:params:xml:ns:yang:ietf-yang-types
        revision 2013-07-15
        schema http://localhost/restconf/yang/ietf-yang-types/2013-07-15
      }
      module {
        conformance-type implement
        name nc-notifications
        namespace urn:ietf:params:xml:ns:netmod:notification
        revision 2008-07-14
        schema http://localhost/restconf/yang/nc-notifications/2008-07-14
      }
      module {
        conformance-type implement
        name notifications
        namespace urn:ietf:params:xml:ns:netconf:notification:1.0
        revision 2013-03-15
        schema http://localhost/restconf/yang/notifications/2013-03-15
      }
      module {
        conformance-type implement
        name yang-data-ext
        namespace urn:ietf:params:xml:ns:yang:yang-data-ext
        revision 2017-07-03
        schema http://localhost/restconf/yang/yang-data-ext/2017-07-03
      }
      module {
        conformance-type import
        name yuma-app-common
        namespace http://netconfcentral.org/ns/yuma-app-common
        revision 2017-07-25
        schema http://localhost/restconf/yang/yuma-app-common/2017-07-25
      }
    }
    last-keys {
      name yuma-app-common
      revision 2017-07-25
    }
  }
}
Press Enter to continue, q to quit get-walk:

rpc-reply {
  bulk {
    data {
      module {
        conformance-type implement
        name yuma-ncx
        namespace http://netconfcentral.org/ns/yuma-ncx
        revision 2015-10-16
        schema http://localhost/restconf/yang/yuma-ncx/2015-10-16
      }
      module {
        conformance-type implement
        name yuma-system
        namespace http://netconfcentral.org/ns/yuma-system
        revision 2013-07-15
        schema http://localhost/restconf/yang/yuma-system/2013-07-15
      }
      module {
        conformance-type implement
        name yuma-time-filter
        namespace http://netconfcentral.org/ns/yuma-time-filter
        revision 2012-11-15
        schema http://localhost/restconf/yang/yuma-time-filter/2012-11-15
      }
      module {
        conformance-type import
        name yuma-types
        namespace http://netconfcentral.org/ns/yuma-types
        revision 2015-09-25
        schema http://localhost/restconf/yang/yuma-types/2015-09-25
      }
      module {
        conformance-type import
        name yumaworks-app-common
        namespace http://yumaworks.com/ns/yumaworks-app-common
        revision 2018-06-26
        schema http://localhost/restconf/yang/yumaworks-app-common/2018-06-26
      }
    }
    last-keys {
      name yumaworks-app-common
      revision 2018-06-26
    }

Press Enter to continue, q to quit get-walk:

rpc-reply {
  bulk {
    data {
      module {
        conformance-type implement
        name yumaworks-event-filter
        namespace http://yumaworks.com/ns/yumaworks-event-filter
        revision 2014-02-09
        schema http://localhost/restconf/yang/yumaworks-event-filter/2014-02-09
      }
      module {
        conformance-type implement
        name yumaworks-getbulk
        namespace http://yumaworks.com/ns/yumaworks-getbulk
        revision 2018-04-06
        schema http://localhost/restconf/yang/yumaworks-getbulk/2018-04-06
      }
      module {
        conformance-type implement
        name yumaworks-ids
        namespace http://yumaworks.com/ns/yumaworks-ids
        revision 2014-07-12
        schema http://localhost/restconf/yang/yumaworks-ids/2014-07-12
      }
      module {
        conformance-type implement
        name yumaworks-restconf
        namespace urn:ietf:params:xml:ns:yang:yumaworks-restconf
        revision 2017-07-03
        schema http://localhost/restconf/yang/yumaworks-restconf/2017-07-03
      }
      module {
        conformance-type implement
        name yumaworks-support-save
        namespace urn:ietf:params:xml:ns:yang:yumaworks-support-save
        revision 2017-07-27
        schema http://localhost/restconf/yang/yumaworks-support-save/2017-07-27
      }
    }
    last-keys {
      name yumaworks-support-save
      revision 2017-07-27
    }
  }
}

Press Enter to continue, q to quit get-walk:

rpc-reply {
  bulk {
    data {
      module {
        conformance-type implement
        name yumaworks-system
        namespace http://yumaworks.com/ns/yumaworks-system
        revision 2019-01-22
        schema http://localhost/restconf/yang/yumaworks-system/2019-01-22
      }
      module {
        conformance-type implement
        name yumaworks-templates
        namespace http://yumaworks.com/ns/yumaworks-templates
        revision 2017-02-20
        schema http://localhost/restconf/yang/yumaworks-templates/2017-02-20
      }
      module {
        conformance-type import
        name yumaworks-types
        namespace http://yumaworks.com/ns/yumaworks-types
        revision 2018-05-03
        schema http://localhost/restconf/yang/yumaworks-types/2018-05-03
      }
    }
    last-keys {
      name yumaworks-types
      revision 2018-05-03
    }
  }
}

Press Enter to continue, q to quit get-walk:

rpc-reply {
  bulk {
    data
  }
}

get-walk has completed.
andy@server>

Example to quit walk.

andy@server> get-walk count=5 list-target=/modules-state/module \
        list-test="starts-with(name, 'ietf-netconf')" \
        content=all datastore=running   depth=unbounded

rpc-reply {
  bulk {
    data {
      module {
        conformance-type implement
        feature candidate
        feature confirmed-commit
        feature rollback-on-error
        feature validate
        feature url
        feature xpath
        name ietf-netconf
        namespace urn:ietf:params:xml:ns:netconf:base:1.0
        revision 2011-06-01
      }
      module {
        conformance-type implement
        name ietf-netconf-acm
        namespace urn:ietf:params:xml:ns:yang:ietf-netconf-acm
        revision 2018-02-14
        schema http://localhost/restconf/yang/ietf-netconf-acm/2018-02-14
      }
      module {
        conformance-type implement
        name ietf-netconf-monitoring
        namespace urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
        revision 2010-10-04
        schema http://localhost/restconf/yang/ietf-netconf-monitoring/2010-10-04
      }
      module {
        conformance-type implement
        name ietf-netconf-notifications
        namespace urn:ietf:params:xml:ns:yang:ietf-netconf-notifications
        revision 2012-02-06
        schema http://localhost/restconf/yang/ietf-netconf-notifications/2012-02-06
      }
      module {
        conformance-type implement
        name ietf-netconf-partial-lock
        namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0
        revision 2009-10-19
        schema http://localhost/restconf/yang/ietf-netconf-partial-lock/2009-10-19
      }
    }
    last-keys {
      name ietf-netconf-partial-lock
      revision 2009-10-19
    }
  }
}

Press Enter to continue, q to quit get-walk:q

andy@server>

group

The 'group' command is used to manage the session groups. Refer to the NETCONF Group Configuration section for details on the format of this file.

There are 7 sub-commands:

  • create

  • add

  • delete

  • remove

  • list

  • show

  • connect

+---x group
   +---w input
      +---w (groupcmd)
      |  +--:(connect)
      |  |  +---w connect?              nt:NcxIdentifier
      |  |  +---w missing-ok?           boolean
      |  |  +---w missing-connect-ok?   boolean
      |  |  +---w lost-ok?              boolean
      |  |  +---w reconnect-tries?      uint32
      |  |  +---w reconnect-interval?   uint32
      |  +--:(create-case)
      |  |  +---w create?               nt:NcxIdentifier
      |  +--:(delete-case)
      |  |  +---w delete?               nt:NcxIdentifier
      |  +--:(add-case)
      |  |  +---w add?                  nt:NcxIdentifier
      |  +--:(remove-case)
      |  |  +---w remove?               nt:NcxIdentifier
      |  +--:(show-case)
      |  |  +---w show?                 nt:NcxIdentifier
      |  +--:(list-case)
      |     +---w list?                 empty
      +---w session*                    nt:NcxIdentifier

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

6

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • create

    • type: group name string

    • This parameter indicates the name of the group to create. The 'session' parameter must also be present. The session cannot be currently active.

  • add

    • type: group name string

    • This parameter indicates the name of the group to add specified sessions. The 'session' parameter must also be present. The session cannot be currently active.

  • delete

    • type: group name string

    • An active group cannot be deleted.

  • remove

    • type: group name string

    • This parameter specifies the name of the session to delete from the group in memory. An active session cannot be deleted.

  • show

    • type: group name string

    • This parameter specifies the name of the group to show.

  • list

    • type: empty

    • List the names of all the groups.

  • connect

    • type: name string

    • This parameter specifies the name of the group to connect.

  • missing-ok

    • type: boolean

    • If true, then it is OK to manage this group if 1 or more sessions identified in the session leaf-list are not found in the session list. The default is to require all session names to exist in the session list for the group to be used.

  • missing-connect-ok

    • type: boolean

    • If true, then it is OK to manage this group if 1 or more sessions identified in the session leaf-list are not found in the session list. The default is to require all sessions to connect OK for the group to be used.

  • lost-ok

    • type: boolean

    • If true, then it is OK to manage this group if 1 or more sessions are lost after connection is made. The default is to require all sessions to remain connected for the group to be used.

  • reconnect-tries

    • type: uint32

    • This parameter Indicates the number of times yangcli will attempt to reconnect to a session if the server becomes unreachable. The default is 5 tries.

  • reconnect-interval

    • type: uint32

    • This parameter indicates the number of seconds yangcli will wait to re-establish a connection if a session is dropped and the server becomes unreachable. The default is 10 seconds. units: seconds

Positive Response:

  • An group is started and the prompt changes to >AB

Negative Response:

  • One or more error messages will be printed.

Example 'group' commands:

> group list
No groups found

> group create=AB session-A

> group list

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

> group add=AB session-B

> group list

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

> group remove=AB session=session-A

> group list

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

> group delete=AB

> group list
No groups found

>group connect=AB
Error: group 'AB' not found

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

> group list

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

> group connect=AB

yangcli-pro: Starting NETCONF session for trshue on localhost over ssh on port 830

NETCONF session established for trshue on localhost

Client Session Id: 1
Server Session Id: 13
Server Protocol Capabilities
   base:1.0
   candidate:1.0
   confirmed-commit:1.0
   rollback-on-error:1.0
------
------
about to send <get>:on Group of 'AB' Session of 'session-A'
yangcli-pro: Starting NETCONF session for trshue on localhost over ssh on port 830

NETCONF session established for trshue on localhost
Client Session Id: 2
Server Session Id: 14
Server Protocol Capabilities
base:1.0
candidate:1.0
------

AB> get-my-session
about to send <get-my-session>:on Group of 'AB' Session of 'session-A'
about to send <get-my-session>:on Group of 'AB' Session of 'session-B'

RPC Data Reply 3 for session 13 [session-A]:
rpc-reply {
  indent 2
  linesize 72
  with-defaults explicit
  message-indent -1
}

RPC Data Reply 2 for session 14 [session-B]:
rpc-reply {
  indent 2
  linesize 72
  with-defaults explicit
  message-indent -1
}
AB>

AB> set-my-session indent=8 linesize=68 with-defaults=report-all message-indent=-1

about to send <set-my-session>:on Group of 'AB' Session of 'session-A'
about to send <set-my-session>:on Group of 'AB' Session of 'session-B'
RPC OK Reply 4 for session 13 [session-A]:
RPC OK Reply 5 for session 14 [session-B]:

AB> get-my-session
about to send <get-my-session>:on Group of 'AB' Session of 'session-A'
about to send <get-my-session>:on Group of 'AB' Session of 'session-B'

RPC Data Reply 3 for session 13 [session-A]:
rpc-reply {
  indent 8
  linesize 68
  with-defaults repo
  message-indent -1
}

RPC Data Reply 2 for session 14 [session-B]:
rpc-reply {
  indent 8
  linesize 68
  with-defaults repo
  message-indent -1
}

AB>

help

The help command is used to print documentation to STDOUT.

If no session is active, then only help for the local commands and the standard NETCONF commands will be available.

If a NETCONF session is active, then the documentation shown will attempt to exactly match the capabilities of the server.

If additional (i.e., augment generated) parameters are available, then they will be shown in the command output. If the server does not implement some parameters (e.g., feature not supported) then these parameters will not be shown in the command output.

If the server has modified an object with deviation statements, then the altered object will be shown.

The ncx:hidden extension suppresses the 'help' command. If this extension is present in the YANG definition associated with the request, then no help will be available for that object or command.

+---x help
    +---w input
       +---w (helptype)?
       |  +--:(command)
       |  |  +---w command?        nt:NcxIdentifier
       |  +--:(commands)
       |  |  +---w commands?       empty
       |  +--:(notification)
       |  |  +---w notification?   nt:NcxIdentifier
       |  +--:(object)
       |  |  +---w object?         union
       |  +--:(type)
       |     +---w type?           nt:NcxIdentifier
       +---w (help-mode)?
          +--:(brief)
          |  +---w brief?          empty
          +--:(normal)
          |  +---w normal?         empty
          +--:(full)
             +---w full?           empty

Command type:

local

Default parameter:

command

Min parameters:

3

Max parameters:

3

Return type:

data

YANG file:

ietf-netconf-monitoring.yang

Capabilities needed:

:schema-retrieval

Command Parameters:

  • choice helptype (not entered)

    • command

      • type: string

      • usage: mandatory

      • default: none

      • This parameter specifies the name of the command for which documentation is requested

    • commands

      • type: empty

      • usage: mandatory

      • default: none

      • This parameter will request documentation for all available commands

    • notification

      • type: string

      • usage: mandatory

      • default: none

      • This parameter specifies the name of the notification for which documentation is requested

    • object

      • type: string

      • usage: mandatory

      • Only top-level typedefs are supported by this command. Local typedefs within groupings, containers, or lists are not exportable in YANG.

      • default: none

      • This parameter specifies the name of the NETCONF database object for which documentation is requested.

        • Only top level objects are supported by this command.

        • Documentation for the entire object subtree will be printed, if the object is a container, choice, or list.

        • Documentation for nested objects is only available in parameter mode, using the escape commands for help ('?') and full help ('??')

    • type

      • type: string

      • usage: mandatory

      • default: none

      • This parameter specifies the name of the YANG typedef for which documentation is requested

  • choice help-mode (not entered) (default choice is 'normal')

    • brief

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that brief documentation mode should be used.

    • normal

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that normal documentation mode should be used.

    • full

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that full documentation mode should be used.

Positive Response:

  • the server prints the requested help text

Negative Response:

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

Usage:

> help help full

help
   Print the yangcli-pro help text
   input
      default parameter: command
      choice helptype
         leaf command [NcxIdentifier]
            Show help for the specified command,
            also called an RPC method

         leaf commands [empty]
            Show info for all local commands

         leaf notification [NcxIdentifier]
            Show help for the specified notification

         leaf object [NcxIdentifier]
            Show help for the specified object

         leaf type [NcxIdentifier]
            Show help for the specified type

      choice help-mode
         leaf brief [empty]
            Show brief help text

         leaf normal [empty]
            Show normal help text

         leaf full [empty]
            Show full help text

andy@myserver> help notification sysConfigChange

notification sysConfigChange
   Generated when the <running> configuration is changed.
   leaf userName [string]

   leaf sessionId [SessionId]
      range: 1..max

   leaf remoteHost [ip-address]

   leaf target [string]

   leaf operation [EditOperationType] [d:merge]
      enum values: merge replace create delete

andy@svnserver>

history

The 'history' command is used to show, clear, load, or save the command line history buffer.

Use the recall command to recall a previously executed command line, after getting the line number from the 'history show' command.

All lines entered will be saved in the history buffer except an ncx:password value entered in parameter mode.

When yangcli-pro starts, the command line history buffer is empty. If a history file was previously stored with the 'history save' command, then it can be recalled into the buffer with the 'history load' command. This is done automatically if the --autohistory parameter is set to 'true'.

The 'history clear' command is used to delete the entire command line history buffer.

The 'history save' command is used to save the history to the history file. This is done automatically when yangcli-pro exits, if the --autohistory parameter is set to 'true'.

The numbering sequence for commands, starts from zero and keeps incremented until the program exits. If the history buffer is cleared, then the number sequence will continue, not start over at zero.

+---x history
   +---w input
      +---w (history-action)?
         +--:(show-case)
         |  +---w show?           LogCount
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?    empty
         |     +--:(normal)
         |     |  +---w normal?   empty
         |     +--:(full)
         |        +---w full?     empty
         +--:(clear)
         |  +---w clear?          empty
         +--:(load)
         |  +---w load?           string
         +--:(save)
            +---w save?           string

Command type:

local

Default parameter:

show

Min parameters:

0

Max parameters:

2

Return type:

data

YANG file:

yangcli-pro.yang

Command Parameters:

  • choice history-action (not entered)

    • clear

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that the history buffer should be cleared. Unless the contents have been saved with the history save command, there is no way to recover the cleared buffer contents after this command is executed.

    • load

      • type: string

      • usage: optional

      • default: $HOME/.yangcli-pro_history

      • This parameter specifies a command history file, and causes the current command line history contents to be loaded from that file.

      • Special processing for this command allows the history file to be omitted in idle mode, even though the load parameter is not type 'empty'.

        > history load
        
        same as:
        
        > history load=$HOME/.yangcli-pro_history
        
    • save

      • type: string

      • usage: optional

      • default: $HOME/.yangcli-pro_history

      • This parameter specifies a command history file, and causes the current command line history contents to be saved to that file.

      • Special processing for this command allows the history file to be omitted in idle mode, even though the save parameter is not type 'empty'.

        > history save
        
        same as:
        
        > history save=$HOME/.yangcli-pro_history
        
    • show

      • type: int32 (-1 for all entries; 1..max for N entries)

      • usage: optional

      • default: -1

      • This parameter specifies the maximum number of history entries to show.

        • If no case is selected from this choice, then the command 'history show=-1' will be used by default.

        • The help-mode choice parameter is only used with the 'history show' command.

          • If the --brief or --normal modes are selected the the format will include the command number and the command line.

          • If the --full mode is selected, then the command data and time will also be printed.

Positive Response:

  • the requested history entries will be printed for the 'history show' command

  • all other commands will return OK

Negative Response:

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

Usage:

> history show=3 full
  [27]  2009-07-04 09:25:34 sget /system --nofill
  [28]  2009-07-04 09:34:17 @myconfig = get-config source=running
  [29]  2009-07-04 09:43:54 history show=3 full

> history save=~/my-temp-history-file
   OK
>

if

The 'if' command is used to start a conditional command block.

The 'expr' parameter is used to specify the XPath expression to test if the if conditional block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.

The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.

If the 'expr' expression is true, the conditional block will be executed, and no further conditional blocks within the same if command sequence will be executed.

if command

  ....

[elif command]

  ....

[elif-command]

  ...

[else command]

  ...

end

The 'if' command must be paired with a matching end command. It can also be continued with consecutive elif statements or one else statement.

+---x if
   +---w input
      +---w expr       yang:xpath1.0
      +---w docroot?   <anyxml>

Command type:

local

Default parameter:

expr

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • expr

    • type: XPath expression string

    • usage: mandatory

    • default: none

    • This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.

  • docroot

    • type: anyxml

    • usage: optional (typically a variable reference is used)

    • default: none

    • This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.

Positive Response:

  • the server returns <ok/>

Negative Response:

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

    • invalid XPath expression or invalid docroot reference will cause an error

Usage:

andy@myserver> if "$sysname = 'localhost'"

andy@myserver>

insert

The 'insert' command is used to insert or move YANG list or leaf-list data into a NETCONF database. It is a high level command with utilizes the YANG 'insert' extensions to the NETCONF <edit-config> operation.

+---x insert
   +---w input
      +---w (from)
      |  +--:(varref)
      |  |  +---w varref?                string
      |  +--:(from-cli)
      |     +---w (target-parm)?
      |     |  +--:(target)
      |     |  |  +---w target           yang:xpath1.0
      |     |  +--:(urltarget-case)
      |     |     +---w urltarget        ywt:UrlPath
      |     |     +---w match-names?     ywt:NameMatchMode
      |     |     +---w alt-names?       ywt:AltNameMode
      |     |     +---w wildcard-keys?   boolean
      |     +---w optional?              empty
      |     +---w value?                 <anyxml>
      +---w timeout?                     nt:Timeout
      +---w order?                       enumeration
      +---w operation?                   enumeration
      +---w edit-target?                 string

Command type:

remote

Default parameter:

target

Min parameters:

2

Max parameters:

7

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • choice 'from' (not entered)

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

    • usage: mandatory

    • default: none

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

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: mandatory

          • default: none

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

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.

  • edit-target

    • type: string

    • usage: optional (must be present if the order parameter is set to 'before' or 'after').

    • default: none

    • This parameter specifies the value or key clause that should be used, as the list or leaf-list insertion point. It identifies the existing entry that the new entry will be inserted before or after, depending on the 'order' parameter.

      • For a leaf-list, the edit-target contains the value of the target leaf-list node within the configuration being edited. E.g., edit-target='fred'.

      • For a list, the edit-target contains the key values of the target list node within the configuration being edited. E.g., edit-target=[name='fred'][zipcode=90210].

  • order

    • type: enumeration (first last before after)

    • usage: optional

    • default: last

    • The insert order that should be used. If the value 'before' or 'after' is selected, then the 'edit-target' parameter must also be present.

  • operation

    • type: enumeration (create merge replace)

    • usage: optional

    • default: merge

    • This parameter specifies the 'nc:operation' attribute value for the NETCONF <edit-config> operation. The insert operation is secondary to the NETCONF operation attribute.

  • timeout

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

    • usage: optional

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

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

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver> insert varref=myvar order=first

RPC OK Reply 25 for session 10:

andy@myserver> insert /nacm/rules/data-rule order=after edit-target=[name='test-rule'](user will be prompted to fill in the data-rule contents)

RPC OK Reply 26 for session 10:

andy@myserver>

Reference:

kill-session

The 'kill-session' command is used to terminate a NETCONF session (other than the current session). All NETCONF implementations must support this command. It is needed sometimes to unlock a NETCONF database locked by a session that is idle or stuck.

If the lock command returns a 'lock-denied' <error-tag>, it will also include an <error-info> field called <session-id>. This is the session number that currently holds the requested lock. The same value should be used for the 'session-id' parameter in this command, to terminate the session will the lock.

Note

Use of the kill-session operation is an extreme measure, which should be used with caution.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <kill-session> operation for parameter details.

Usage:

andy@myserver>  kill-session session-id=11

RPC OK Reply 27 for session 10:

andy@myserver>

Reference:

kill-subscription

The 'kill-subscription' command is used to terminate the notification subscription for another session on the connected NETCONF server. The netconfd-pro server must have the yang-push bundle enabled for this operation to be available.

The subscription-id returned in the establish-subscription command must be used as the parameter, since a session can have multiple subscriptions active at once.

The server should also send a "subscription-terminated" notification as a result of the operation.

Note

The nacm:default-deny-all access restriction applies to this operation.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <kill-subscription> operation for parameter details.

Usage:

fred@server1> kill-subscription id=2

RPC OK Reply 3 for session 4 [default]:

fred@server1>

The session that has the subscription (possibly on another client) will get the "subscription-terminated" event.

andy@server1>

Incoming notification for session 2 [default]:
notification {
  eventTime 2022-01-13T03:04:48Z
  subscription-terminated {
    id 2
    reason sn:no-such-subscription
  }
}

andy@server1>

list

This 'list' command is used to display the commands, objects, and oids (object identifiers) that are available at the time.

  • The 'list commands' command will display the local commands and the remote commands that are available in the current NETCONF session, or which have been loaded with the mgrload command.

  • The 'list files command will display the data files that are in the current data search path. The module parameter has no affect in this mode.

  • The 'list modules' command will display the YANG files that are in the current YANG module search path. The module parameter has no affect in this mode.

  • The 'list objects' command will display the top-level objects that are currently available in the current NETCONF session, or which have been loaded with the mgrload command.

  • The 'list oids' command will display the object identifiers of the top-level objects that are currently available in the current NETCONF session, or which have been loaded with the mgrload command.

  • The 'list scripts' command will display the script files that are in the current script search path. The module parameter has no affect in this mode.

+---x list
   +---w input
      +---w (listtype)
      |  +--:(commands)
      |  |  +---w commands?   empty
      |  +--:(files)
      |  |  +---w files?      empty
      |  +--:(objects)
      |  |  +---w objects?    empty
      |  +--:(oids)
      |  |  +---w oids?       empty
      |  +--:(modules)
      |  |  +---w modules?    empty
      |  +--:(scripts)
      |     +---w scripts?    empty
      +---w module?           nt:NcxIdentifier
      +---w (help-mode)?
         +--:(brief)
         |  +---w brief?      empty
         +--:(normal)
         |  +---w normal?     empty
         +--:(full)
            +---w full?       empty

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

6

Return type:

data

YANG file:

yangcli-pro.yang

Command Parameters:

  • choice help-mode (not entered)

    • brief

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that brief documentation mode should be used.

    • normal

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that normal documentation mode should be used.

    • full

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that full documentation mode should be used.

  • choice 'listtype' (not entered)

    • usage: mandatory

    • default: none

    • This parameter specifies the what type of data should be listed.

    • commands

      • type: empty

      • usage: mandatory

      • default: none

      • This parameter specifies that the available commands should be listed.

        • If the help-mode is set to 'brief', then only the command names will be listed.

        • If the help-mode is set to 'normal', then the XML prefix and the command name will be listed.

        • If the help-mode is set to 'full', then the module name and the command name will be listed.

    • files

      • type: empty

      • usage: mandatory

      • default: none

      • This parameter specifies that all the data files in the current data search path should be listed.

    • modules

      • type: empty

      • usage: mandatory

      • default: none

      • This parameter specifies that all the YANG files in the current module search path should be listed.

    • objects

      • type: empty

      • usage: mandatory

      • default: none

      • This parameter specifies that the available top-level objects should be listed.

        • If the help-mode is set to 'brief', then only the object names will be listed.

        • If the help-mode is set to 'normal', then the XML prefix and the object name will be listed.

        • If the help-mode is set to 'full', then the module name and the object name will be listed.

    • oids

      • type: empty

      • usage: mandatory

      • default: none

      • This parameter specifies that the available top-level object identifiers should be listed.

      • The help-mode parameter has no effect

    • scripts

      • type: empty

      • usage: mandatory

      • default: none

      • This parameter specifies that all the script files in the current script search path should be listed.

  • module

    • type: string

    • usage: optional

    • default: none

    • This parameter specifies a module name. If present then only information for the specified YANG module will be displayed.

Positive Response:

  • the requested information will be printed

Negative Response:

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

Usage:

andy@myserver>  list objects full module=test

   test:instance1
   test:instance2
   test:leafref1
   test:leafref2
   test:test1
   test:test2
   test:test3
   test:idtest
   test:musttest
   test:anyxml.1
   test:binary.1
   test:bits.1
   test:boolean.1
   test:empty.1
   test:enumeration.1
   test:identityref.1
   test:instance-identifier.1
   test:instance-identifier.2
   test:int8.1
   test:int16.1
   test:int32.1
   test:int64.1
   test:leafref.1
   test:leafref.2
   test:string.1
   test:uint8.1
   test:uint16.1
   test:uint32.1
   test:uint64.1
   test:dec64.1
   test:dec64.2
   test:dec64.3
   test:union.1
   test:container.1
   test:container.2
   test:list.1
   test:choice.1
   test:xpath.1

andy@myserver>

load

The load command is used to load a YANG module into the server.

This command is only supported by the netconfd-pro server.

The YANG files must be available in the module search path for the server.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <load> operation for parameter details.

Usage:

andy@myserver> load toaster revision=2009-06-23

RPC Data Reply 27 for session 10:

rpc-reply {
  mod-revision 2009-06-23
}

andy@myserver>

lock

The 'lock' command is used to request a global lock on a NETCONF database. It is used, along with the unlock command, to obtain exclusive write access to the NETCONF server.

The scope of a lock command is the lifetime of the session that requested the lock. This means that if the session that owns the lock is dropped for any reason, all the locks it holds will be released immediately by the server.

The use of database locks is optional in NETCONF, but it must be implemented by every server. It is strongly suggested that locks be used if multiple managers are likely to log into the particular NETCONF server.

One or more locks may be needed to execute a transaction safely:

  • If the :writable-running capability is supported, then a lock on the <running> database is needed. This database can be locked at any time.

  • If the :startup capability is supported, then a lock on the <startup> database is needed. This database can be locked at any time.

  • If the :candidate capability is supported, then a lock on the <candidate> database is needed. A lock on the <running> database is also needed.

    • The <candidate> database can only be locked if there are no active edits in it.

    • The discard-changes command may be needed to clear a <candidate> database that has been left edited by a session that terminated unexpectedly.

    • Note: There is no way in NETCONF to tell the difference between an actively edited <candidate> database and an 'abandoned' <candidate> database. The server will almost never clear the <candidate> database. It will only clear any locks held. Use the discard-changes command (for other session's edits) with extreme caution.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <lock> operation for parameter details.

Usage:

andy@myserver> lock target=candidate

RPC OK Reply 29 for session 10:

andy@myserver>

log-debug

The 'log-debug' command prints a message to the program log, if the $$log-level system variable is set to 'debug' or a higher enumeration (e.g., 'debug2').

The 'msg' parameter is used to provide the message string to print.

+---x log-debug
   +---w input
      +---w msg    string

Command type:

local

Default parameter:

msg

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • msg

    • type: string

    • usage: mandatory

    • default: none

    • This parameter specifies the string to print to the program log.

Positive Response:

  • the server returns <ok/>

Negative Response:

  • An error message will be printed if the 'msg' parameter contains errors.

Usage:

andy@myserver> log-debug 'starting strict foo'

Debug: starting script foo

andy@myserver>

log-error

The 'log-error' command prints a message to the program log, if the $$log-level system variable is set to 'error' or a higher enumeration (e.g., 'info').

The 'msg' parameter is used to provide the message string to print.

+---x log-error
   +---w input
      +---w msg    string

Command type:

local

Default parameter:

msg

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • msg

    • type: string

    • usage: mandatory

    • default: none

    • This parameter specifies the string to print to the program log.

Positive Response:

  • the server returns <ok/>

Negative Response:

  • An error message will be printed if the 'msg' parameter contains errors.

Usage:

andy@myserver> log-error 'sysName not correct'

Error: sysName not correct

andy@myserver>

log-info

The 'log-info' command prints a message to the program log, if the $$log-level system variable is set to 'info' or a higher enumeration (e.g., 'debug').

The 'msg' parameter is used to provide the message string to print.

+---x log-info
   +---w input
      +---w msg    string

Command type:

local

Default parameter:

msg

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • msg

    • type: string

    • usage: mandatory

    • default: none

    • This parameter specifies the string to print to the program log.

Positive Response:

  • the server returns <ok/>

Negative Response:

  • An error message will be printed if the 'msg' parameter contains errors.

Usage:

andy@myserver> log-info 'sysName is correct'

Info: sysName is correct

andy@myserver>

log-warn

The 'log-warn' command prints a message to the program log, if the $$log-level system variable is set to 'warn' or a higher enumeration (e.g., 'debug').

The 'msg' parameter is used to provide the message string to print.

+---x log-warn
   +---w input
      +---w msg    string

Command type:

local

Default parameter:

msg

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • msg

    • type: string

    • usage: mandatory

    • default: none

    • This parameter specifies the string to print to the program log.

Positive Response:

  • the server returns <ok/>

Negative Response:

  • An error message will be printed if the 'msg' parameter contains errors.

Usage:

andy@myserver> log-warn 'sysName object not found'

Warning: sysName object not found

andy@myserver>

merge

The 'merge' command is a high-level <edit-config> operation. It is used to merge some new nodes into the default target database.

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

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

+---x merge
   +---w input
      +---w (from)
      |  +--:(varref)
      |  |  +---w varref?                string
      |  +--:(from-cli)
      |     +---w (target-parm)?
      |     |  +--:(target)
      |     |  |  +---w target           yang:xpath1.0
      |     |  +--:(urltarget-case)
      |     |     +---w urltarget        ywt:UrlPath
      |     |     +---w match-names?     ywt:NameMatchMode
      |     |     +---w alt-names?       ywt:AltNameMode
      |     |     +---w wildcard-keys?   boolean
      |     +---w optional?              empty
      |     +---w value?                 <anyxml>
      +---w timeout?                     nt:Timeout

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

5

Return type:

status

YANG file:

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

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

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: optional (target or urltarget must be entered)

          • default: none

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

        • urltarget

          • type: string

          • usage: optional

          • default: none

          • This parameter specifies the database target node of the merge operation. This is an UrlPath string.

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.

  • timeout

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

    • usage: optional

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

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

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver>  merge \
        target=/nacm/rules/moduleRule[moduleName='netconf']\
        [allowed-rights='read write']/allowed-group \
        value=ncx:guest

Reference:

modify-subscription

The 'modify-subscription' command is used to modify a notification subscription on the connected NETCONF server. The netconfd-pro server must have the yang-push bundle enabled for this operation to be available.

The subscription-id that was returned in the establish-subscription operation must be used in this operation.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <modify-subscription> operation for parameter details.

Usage:

session1> modify-subscription id=2 stream-filter-name=alarms-stream

RPC OK Reply 37 for session 10:

session1>

mgrload

The 'mgrload' command is used to load a YANG module into yangcli-pro. The YANG files must be available in the module search path for yangcli-pro.

+---x mgrload
   +---w input
      +---w module       nt:NcxName
      +---w revision?    nt:Date
      +---w deviation*   yt:NcModuleSpec

Command type:

local

Default parameter:

module

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • module

    • type: string (length 1 .. 63)

    • usage: mandatory

    • default: none

    • This parameter specifies the name of the module to load.

  • revision

    • type: date string (YYYY-MM-DD)

    • usage: optional

    • default: none

    • This parameter specifies the revision date of the module to load.

  • deviation:

    • type: leaf-list of deviation module names

    • usage: optional (0 or more instances)

    • default: none

    • This parameter specifies a deviation module to load prior to loading the requested module.

Positive Response:

  • OK

Negative Response:

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

Usage:

> mgrload toaster

Load module toaster OK

>

no

The 'no' command is available in config mode to start a delete operation.

  • A normal config-mode command line is expected.

  • The specified node is deleted

  • A sub-mode is not-expected and not entered if the 'no' keyword is used

  • A complete node specification to deleted is expected

Command type:

config mode

Default parameter:

none

Min parameters:

1

Max parameters:

1

Return type:

none

YANG file:

none

Command Parameters:

  • A complete command specifying the node to delete is expected

Positive Response:

  • A message indicated action performed will be printed if --log-level is info or above.

Negative Response:

  • An error message will be printed

Usage:

session1> conf t

session1# no nacm groups group mygroup

Applying 1 edit

session1#

no-op

The 'no-op' command is used to test server message processing response times, by providing a baseline response time to do nothing except return <ok/>.

  • It can also be used as an application-level keep-alive to prevent proxy idle timeout or server idle timeout problems from occurring.

  • This command is only supported by the netconfd-pro server. The server will simply respond 'OK', if the request is well-formed.

  • This command is only available if the yuma-system.yang module is loaded in the server.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <no-op> operation for parameter details.

Usage:

andy@myserver> no-op

RPC OK Reply 31 for session 10:

andy@myserver>

nvsave

The 'nvsave' command is used to save the running datastore to the startup datastore on the current session.

If the server does not support the :startup capability then this command will fail. It has the save purpose as “copy-config source=running target=startup”.

+---x nvsave

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver> nvsave

RPC OK Reply 32 for session 10:

andy@myserver>

pwd

The 'pwd' command is used to print the current working directory.

+---x pwd

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

Positive Response:

  • the current working directory is printed to the log or STDOUT

Negative Response:

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

Usage:

> pwd

Current working directory is /home/andy

>

quit

The 'quit' command is used to terminate the yangcli-pro program.

If a NETCONF session is in progress, it will be dropped without sending a close-session command first. This should be taken into account if the server reports dropped TCP connections as an error.

+---x quit

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

yangcli-pro.yang

Positive Response:

  • The program terminates; no response will be printed.

Negative Response:

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

Usage:

> quit

andy@myworkstation>

recall

The 'recall' command is used to recall a previously entered command line from the command line history buffer. It is used together with the history command.

  • A command is recalled by its command ID number. Use the 'history show` command to see the contents of the command line history buffer.

  • The command is not executed (like in bash). Instead the command is available for editing.

  • The 'bang' command character '!' can be used instead of this command to recall a command by searching the most recent commands for a match.

    Example: search for most recent 'sget' command

    server1> !sget
    
    server1> sget /proc
    
+---x recall
   +---w input
      +---w index    LogIndex

Command type:

local

Default parameter:

index

Min parameters:

1

Max parameters:

1

Return type:

data

YANG file:

yangcli-pro.yang

Positive Response:

  • The specified command line is recalled into the current command line.

Negative Response:

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

Usage:

> recall 7

> sget /system

record-test

The 'record-test' command is used to automatically record commands into a test script that is compatible with the test-suite command.

  • The 'start' sub-command is used to start recording a test. Once recording starts, all the commands entered are recorded for the test.

  • The 'finish' sub-command is used to finish recording a test. The recorded commands will be saved in the default or configured test suite file.

  • The 'cancel' sub-command is used to cancel recording a test. The recorded commands will be discarded.

  • The 'pause' sub-command is used to pause recording a test. The commands entered after this command will not be recorded.

  • The 'resume' sub-command is used to resume recording a paused test. The commands entered after this command will be recorded.

+---x record-test
    +---w input
       +---w (record-test-action)
          +--:(cancel)
          |  +---w cancel?       empty
          +--:(start-case)
          |  +---w start         empty
          |  +---w suite-name    nt:NcxIdentifier
          |  +---w test-name     nt:NcxIdentifier
          +--:(finish)
          |  +---w finish?       empty
          +--:(pause)
          |  +---w pause?        empty
          +--:(resume)
             +---w resume?       empty

Command type:

local

Default parameter:

suite-name

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • choice record-test-action (not entered)

    • choice usage: mandatory

    • default: case: none

    • start-case

      • start

        • type: empty

        • Start recording a new test or replace an existing test. Only one test can be recorded at a time.

      • suite-name

        • type: NcxIdentifier

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the test suite to use.

      • test-name

        • type: NcxIdentifier

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the test to use.

    • finish

      • type: empty

      • default: none

      • Finish recording of the test in progress

    • cancel

      • type: empty

      • default: none

      • Cancel recording of the test in progress

    • pause

      • type: empty

      • default: none

      • Pause recording of the test in progress

    • resume

      • type: empty

      • default: none

      • Resume recording of the paused test in progress

Positive Response:

  • The requested action is performed for the specified test-suite and test.

Negative Response:

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

Usage:

andy@myserver> record-test start suite1 test-name=test1

Start recording:  suite=suite1 test=test1

andy@myserver>

refresh-library

The 'refresh-library' is used to force yangcli-pro to re-scan for YANG modules.

If the YANG modules available on disk changes while the program is running, then this command can be used to refresh the module version list used to determine the 'best-match' for imports.

+---x refresh-library

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

Positive Response:

  • The specified command refreshes the module version list available for “best-match” imports revision tracking.

Negative Response:

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

Usage:

> help refresh-library

rpc refresh-library
  If the YANG modules available on disk changes while
  the program is running, then this command can be
  used to refresh the module version list used
  to determine the 'best-match' for imports.

> refresh-library

   OK

> show search-path-module

YANG Module Search Path

Current dir only: /home/username/swdev/ypwork/netconf/target/bin
HOME/modules: /home/username/modules
Default YUMAPRO_INSTALL: /usr/share/yumapro/modules
Start Dir: /home/username/swdev/ypwork/netconf/target/bin/modules
yangcli Cache: /home/username/.yumapro/.yangcli_cache

release-locks

The 'release-locks' command is used to release all the locks that were previously granted with the get-locks command.

If the get-locks command was not used, then this command will fail with an error message that no locks are active to unlock.

+---x release-locks

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

Positive Response:

  • The previously granted locks are released.

Negative Response:

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

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

Usage: (showing 2 locks being released)

andy@myserver> release-locks

RPC OK Reply 8 for session 23:
RPC OK Reply 9 for session 23:

andy@myserver>

remove

The 'remove' command is a high-level <edit-config> operation. It is used to remove an existing subtree in the default target database, using the remove” operation, defined in RFC 6241,

  • This command will only work on NETCONF servers that support the RFC 6241 :base:1.1 capability

  • This command does not generate an error if the entry to delete does not exist.

  • A target node is specified, and then any missing key leafs (if any) within the data structure are filled in. If the target is a leaf-list, then the user will be prompted for the value of the leaf-list node to be removed.

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

+---x remove
   +---w input
      +---w target    string
      +---w value?    <anyxml>

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

:base:1.1 :candidate or :writable-running

Command Parameters:

  • target

    • type: string

    • usage: optional (urltarget or target must be present)

    • default: none

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

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$optional

    • Controls whether optional descendant nodes will be filled into the target parameter contents

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver>  remove /nacm/rules/data-rule
(user will be prompted to fill in the data-rule 'name' key leaf)

RPC OK Reply 15 for session 10:

andy@myserver> remove target=/nacm/rules/data-rule[name='test rule']/comment
(no user prompting; <edit-config> request sent right away)

RPC OK Reply 16 for session 10:

andy@myserver>

Reference:

remove-all

The 'remove-all' command is a high-level <edit-config> operation. It is used to remove all instances of a list or leaf-list.

  • This is only supported for the netconfd-pro server.

  • The --allow-leaflist-delete-all parameter must be set to 'true' to use this operation on a leaf-list.

  • The --allow-list-delete-all parameter must be set to 'true' to use this operation on a list.

  • This command does not generate an error if the entry to delete does not exist.

  • The same restrictions as the remove command apply to this command.

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

+---x remove-all
   +---w input
      +---w (delete-target)
         +--:(target)
         |  +---w target?      string
         +--:(urltarget)
            +---w urltarget?   ywt:UrlPath

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

:base:1.1 :candidate or :writable-running

Command Parameters:

Choice of:

  • target

    • type: string

    • usage: optional (urltarget or target must be present)

    • default: none

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

  • urltarget

    • type: string

    • usage: optional

    • default: none

    • This parameter specifies the database target node of the replace operation. This is an UrlPath string.

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$optional

    • Controls whether optional descendant nodes will be filled into the target parameter contents

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver>  remove-all /nacm/rules/data-rule
(user will be prompted to fill in the data-rule 'name' key leaf)

RPC OK Reply 15 for session 10:

andy@myserver>

Reference:

  • none

replace

The 'replace' command is a high-level <edit-config> operation. It is used to replace an existing subtree with some new nodes, in the default target database.

Only the subtree indicated by the 'target' or 'varref' parameter will be replaced.

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

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

+---x replace
    +---w input
       +---w (from)
       |  +--:(varref)
       |  |  +---w varref?                string
       |  +--:(from-cli)
       |     +---w (target-parm)?
       |     |  +--:(target)
       |     |  |  +---w target           yang:xpath1.0
       |     |  +--:(urltarget-case)
       |     |     +---w urltarget        ywt:UrlPath
       |     |     +---w match-names?     ywt:NameMatchMode
       |     |     +---w alt-names?       ywt:AltNameMode
       |     |     +---w wildcard-keys?   boolean
       |     +---w optional?              empty
       |     +---w value?                 <anyxml>
       +---w timeout?                     nt:Timeout

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

5

Return type:

status

YANG file:

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

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

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: optional (target or urltarget must be present)

          • default: none

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

        • urltarget

          • type: string

          • usage: optional

          • default: none

          • This parameter specifies the database target node of the replace operation. This is an UrlPath string.

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.

  • timeout

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

    • usage: optional

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

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

System Variables:

  • $$default-operation

    • The <default-operation> parameter for the <edit-config> operation will be derived from this variable.

  • $$error-option

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

  • $$test-option

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

Positive Response:

  • the server returns <ok/>

Negative Response:

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

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

Usage:

andy@myserver> replace \
        target=/nacm/rules/moduleRule[moduleName='yuma-system']\
        [allowed-rights='exec']

(user prompted to fill in specified <moduleRule> element)

RPC OK Reply 31 for session 10:

andy@myserver>

Reference:

return

The 'return' command is available in config mode to cancel and discard all edits and exit config mode.

Command type:

config mode

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

none

Command Parameters:

  • none

Positive Response:

  • The command prompt will change back to a normal session prompt

Negative Response:

  • An error message will be printed (e.g. invoked outside config mode)

Usage:

session1> conf t

session1# nacm groups group mygroup

session1(group)# user-name fred

session1(group)# user-name barney

session1(group)# return

session1>

restart

The 'restart' command is used to restart the NETCONF server.

  • This command is only supported by the netconfd-pro server.

  • The default access control configuration for netconfd-pro will not allow any user except the designated 'superuser' account to invoke this command.

  • The yuma-system.yang module must be loaded in the server for this command to be available.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <restart> operation for parameter details.

Usage:

andy@myserver> restart

ses: session 10 shut by remote peer

>

run

The 'run' command is used to invoke a yangcli-pro script.

Refer to the section on Scripts for details on how to write a script.

  • The script name is the only mandatory parameter.

  • There are 9 generic parameters (named P1 to P9) that can be used to pass string parameters to scripts.

  • Within a script, these are referenced with local variables ($1 to $9).

  • The run command can be used within a script.

  • Scripts do not return any status or data.

  • The run command can appear inside a script, starting a new run level. An error will occur if a loop occurs or too many nest levels are used. Up to 64 run levels are supported in yangcli-pro.

+---x run
    +---w input
       +---w script    string
       +---w P1?       string
       +---w P2?       string
       +---w P3?       string
       +---w P4?       string
       +---w P5?       string
       +---w P6?       string
       +---w P7?       string
       +---w P8?       string
       +---w P9?       string

Command type:

local

Default parameter:

script

Min parameters:

1

Max parameters:

10

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • P1, P2, P3, P4, P5, P6, P7, P8, P9

    • type: string

    • usage: optional

    • default: none

    • These parameters provide a generic string parameter passing mechanism for each script invocation, similar to unix shell scripts. Within the script, the parameters $1, $2, $3, $4, $5, $6, $7, $8 and $9 will be non-NULL only if the corresponding 'Pn' parameter was set in the script invocation.

  • script

    • type: string

    • usage: mandatory

    • default: none

    • This parameter specifies the name of the script to be run. If a path specification is included, then it will be used. Otherwise the current script search path will be used to find the script.

System Variables:

  • $$runpath

    • Controls where yangcli-pro will look for files specified in the 'script' parameter.

Positive Response:

  • the specified script will be executed

Negative Response:

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

  • An <rpc-error> message will be printed if the server detected an error, if any remote commands are contained in the script.

Usage:

> run connect P1=yangrocks

(commands and responses are printed as if they were typed)

andy@myserver>

resync-subscription

The 'resync-subscription' command is used to request a full Push Update from the server. The netconfd-pro server must have the yang-push bundle enabled for this operation to be available.

The subscription-id that was returned in the establish-subscription operation must be used in this operation.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <resync-subscription> operation for parameter details.

Usage:

session1> resync-subscription id=2

RPC OK Reply 37 for session 10:

session1>

run-shell

The 'run-shell' command is an internal command to run a shell script The --allow-shell parameter must be set to 'true' for this command to be present.

  • The script name is the only mandatory parameter.

  • There are 9 generic parameters (named P1 to P9) that can be used to pass string parameters to scripts.

  • Within a script, these are referenced with local variables ($1 to $9).

  • Scripts do not return any status or data at this time.

  • The parameters P1 .. P9 will be converted to dollar parameters $0 to $N, where N is the number of 'Pn' parameters provided.

  • The parameters will be added to the command line in named order P1 through P9.

  • Environment variables are not used for script parameters since they could have naming conflicts, especially for recursive scripts.

Example:

server1> run-script test1.sh P3=foo P6=bar P1=baz

This script will be invoked with parameters $1=baz $2=foo $3=bar

+---x run-shell
   +---w input
      +---w script    string
      +---w P1?       string
      +---w P2?       string
      +---w P3?       string
      +---w P4?       string
      +---w P5?       string
      +---w P6?       string
      +---w P7?       string
      +---w P8?       string
      +---w P9?       string

Command type:

local

Default parameter:

script

Min parameters:

1

Max parameters:

10

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • P1, P2, P3, P4, P5, P6, P7, P8, P9

    • type: string

    • usage: optional

    • default: none

    • These parameters provide a generic string parameter passing mechanism for each script invocation, similar to unix shell scripts. Within the script, the parameters $1, $2, $3, $4, $5, $6, $7, $8 and $9 will be non-NULL only if the corresponding 'Pn' parameter was set in the script invocation.

  • script

    • type: string

    • usage: mandatory

    • default: none

    • This parameter specifies the name of the script to be run. If a path specification is included, then it will be used. Otherwise the current script search path will be used to find the script.

System Variables:

  • $$runpath

    • Controls where yangcli-pro will look for files specified in the 'script' parameter.

Positive Response:

  • the specified script will be executed

Negative Response:

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

Usage:

> run-script test1.sh P3=foo P6=bar P1=baz

andy@myserver>

save

The 'save' command is used to save NETCONF database edits to non-volatile storage, on the server. It is a pseudo-command, mapped to other remote commands depending on which database target is supported by the server (<candidate> or <running>).

The 'save' command usually maps to either the commit or the copy-config command. Refer to the Using NETCONF Sessions section for more details.

+---x save

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

yangcli-pro.yang

Positive Response:

  • The server returns one or two <ok/> responses.

Negative Response:

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

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

Usage:

andy@myserver> save

RPC OK Reply 34 on session 10

andy@myserver>

schema-server-cfg

The 'schema-server-cfg' command is used to access a named schema server.

There are 3 sub-commands:

  • create

  • show

  • delete

+---x schema-server-cfg
   +---w input
      +---w (schema-server-action)?
         +--:(show-case)
         |  +---w show?           IdentifierOrZero
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?    empty
         |     +--:(normal)
         |     |  +---w normal?   empty
         |     +--:(full)
         |        +---w full?     empty
         +--:(delete)
         |  +---w delete?         nt:NcxIdentifier
         +--:(create)
            +---w create          nt:NcxName
            +---w user-id         nt:NcxName
            +---w device-id?      nt:NcxName

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • create

    • type: name string

    • This parameter specifies a new schema server to create.

  • show

    • type: name string.

    • This parameter specifies the name of the schema server to show.

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

  • delete

    • type: name string

      This parameter specifies the name of the schema server to delete from the saved schema server in memory. An active schema server cannot be deleted.

Positive Response

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

Negative Response:

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

Usage:

> schema-server-cfg create=schema-server-B user-id=userB device-id=deviceB

A new schema_server is created:
schema_server-id=schema-server-B name=schema-server-B device=deviceB user=userB

> schema-server-cfg show=schema-server-B

Schema Server: schema-server-B
Device Id: deviceB
User Id: userB
Connected: false

> schema-server-cfg delete=schema-server-B

Deleting saved schema_server 'schema-server-B'

schema-servers-cfg

The 'schema-servers-cfg' command is used to access the named schema server files.

There are 4 sub-commands:

  • clear

  • load

  • save

  • show (default)

+---x schema-servers-cfg
   +---w input
      +---w (schema-servers-action)?
         +--:(show-case)
         |  +---w show?           empty
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?    empty
         |     +--:(normal)
         |     |  +---w normal?   empty
         |     +--:(full)
         |        +---w full?     empty
         +--:(clear)
         |  +---w clear?          empty
         +--:(load)
         |  +---w load?           string
         +--:(save)
            +---w save?           string

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • clear

    • type: empty

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

  • load

    • type: string

    • This parameter identifies the file specification for the saved chema servers to load. Any new named schema servers will be added to the named schema servers in memory.

  • save

    • type: name string

    • This parameter identifies the file specification for the saved schema servers config file to load. The saved chema servers in memory will be saved to this file.

  • show

    • type: name string; default: empty string == all schema servers

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

Positive Response:

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

Negative Response:

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

Usage:

 > schema-servers-cfg clear

 Deleting 3 saved schema_servers


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

 Loaded saved schema_servers OK from '~/.yumapro/.yangcli_pro_schema_servers.conf-save'

 > schema-servers-cfg save

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


 > schema-servers-cfg show

 Saved schema_servers source: '~/.yumapro/.yangcli_pro_schema_servers.conf'
 Schema Server: schema-serverA
Device Id: deviceB
User Id: userA
Connected: false
 Schema Server: schema-server-ACER
Device Id: device-ACER
User Id: user-ACER
Connected: false
 Schema Server: schema-server-asus2
Device Id: asus2-device
User Id: asus2
Connected: false

session

The 'session' command is used to set the current named session, if named sessions are used. The current session is used by yangcli-pro to decide where to send remote commands. Changing the current session allows commands typed at the CLI to be sent to the desired server session.

The only sub-command at this time is 'set-current', and the name of the session to be used as the new current session is the only parameter.

Refer to the section on “NETCONF Session Configuration” for more details on using saved sessions.

+---x session
   +---w input
      +---w set-current    nt:NcxIdentifier

Command type:

local

Default parameter:

set-current

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • set-default

    • type: name string

    • This mandatory parameter specifies the name of the session to set as the current session. The special session name 'default' is reserved for the session that can be activated with the 'connect' command.

Positive Response:

  • The session prompt should change to indicate the new current session.

Negative Response:

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

andy@myserver>  session set-current session-A

session-A>

session-cfg

The 'session-cfg' command is used to access a named session.

There are 3 sub-commands:

  • delete

  • save

  • show (default)

Refer to the NETCONF Session Configuration section for more details on using saved sessions.

+---x session-cfg
   +---w input
      +---w (session-action)?
         +--:(show-case)
         |  +---w show?                IdentifierOrZero
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?         empty
         |     +--:(normal)
         |     |  +---w normal?        empty
         |     +--:(full)
         |        +---w full?          empty
         +--:(delete)
         |  +---w delete?              nt:NcxIdentifier
         +--:(save)
         |  +---w save?                nt:NcxIdentifier
         +--:(use-event-handler)
            +---w use-event-handler*   nt:NcxIdentifier

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • delete

    • type: name string

    • This parameter specifies the name of the session to delete from the saved sessions in memory. An active session cannot be deleted.

  • save

    • type: name string

    • This parameter specifies the name of the session to save in the saved sessions in memory.

  • show

    • type: name string; default: empty string == current session

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

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

Positive Response:

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

Negative Response:

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

Usage:

andy@myserver> session-cfg save session-A

Saving current session as 'session-A'

andy@myserver>

sessions-cfg

The 'sessions-cfg' command is used to access the named session files.

There are 4 sub-commands:

  • clear

  • load

  • save

  • show (default)

Refer to the NETCONF Session Configuration section for more details on using saved sessions.

+---x sessions-cfg
    +---w input
       +---w (sessions-action)?
          +--:(show-case)
          |  +---w show?           empty
          |  +---w (help-mode)?
          |     +--:(brief)
          |     |  +---w brief?    empty
          |     +--:(normal)
          |     |  +---w normal?   empty
          |     +--:(full)
          |        +---w full?     empty
          +--:(clear)
          |  +---w clear?          empty
          +--:(load)
          |  +---w load?           string
          +--:(save)
             +---w save?           string

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • clear

    • type: empty

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

  • load

    • type: string

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

  • save

    • type: name string

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

  • show

    • type: name string; default: empty string == all sessions

    • This parameter specifies the name of the session to show.

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

Positive Response:

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

Negative Response:

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

Usage:

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

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

session-A>

set-log-level

The 'set-log-level' command is used to configure the server logging verbosity level. It is only supported by the netconfd-pro server.

This operation is defined as nacm:default-deny-all, so only a system superuser account can invoke this command by default.

This operation is defined in the yuma-system.yang and yumaworks-system.yang module so a prefix may be needed to use this command, depending on the server configuration. Both commands are the same.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <set-log-level> operation for parameter details.

Usage:

andy@myserver> set-log-level log-level=debug2

RPC OK Reply 29 for session 10:

andy@myserver>

set-my-session

The 'set-my-session' command is used to configure the session customization parameters on the server. It is only supported by the netconfd-pro server.

Since all parameters are optional, they need to be entered in the same command line as the command name. Otherwise the $$optional system variable needs to be set to 'true'. If not, then no parameters will be sent to the server, and no session parameters will be changed.

The yuma-mysession.yang module must be loaded in the server for this command to be available.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <set-my-session> operation for parameter details.

Usage:

andy@myserver>  set-my-session --linesize=64 --with-defaults=trim --message-indent=1

RPC OK Reply 25 for session 10:

andy@myserver>

sget

The 'sget' command is used to invoke a NETCONF <get> operation with a subtree filter.

A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the 'nofill' parameter.

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

+---x sget
    +---w input
    |  +---w (from)
    |  |  +--:(varref)
    |  |  |  +---w varref?                string
    |  |  +--:(from-cli)
    |  |     +---w (target-parm)?
    |  |     |  +--:(target)
    |  |     |  |  +---w target           yang:xpath1.0
    |  |     |  +--:(urltarget-case)
    |  |     |     +---w urltarget        ywt:UrlPath
    |  |     |     +---w match-names?     ywt:NameMatchMode
    |  |     |     +---w alt-names?       ywt:AltNameMode
    |  |     |     +---w wildcard-keys?   boolean
    |  |     +---w optional?              empty
    |  |     +---w value?                 <anyxml>
    |  +---w nofill?                      empty
    |  +---w with-defaults?               CliWithDefaultsType
    |  +---w depth?                       union
    |  +---w module-tag*                  string
    +--ro output
       +--ro data?   <anyxml>

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

6

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

:with-defaults

Command Parameters:

  • choice 'from' (not entered)

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

    • usage: mandatory

    • default: none

    • This parameter specifies the where yangcli-pro should get the data from, for the subtree filter target of the <get> operation. It is either a user variable or from interactive input at the command line.

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: optional (target or urltarget must be present)

          • default: none

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

            • The escape command ('?s') can be used in parameter mode to skip a parameter completely.

            • Entering the empty string for a parameter will cause a subtree selection node to be created instead of a content match node

        • urltarget

          • type: string

          • usage: optional

          • default: none

          • This parameter specifies the database target node of the get operation. This is an UrlPath string.

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.

  • nofill

    • type: empty

    • usage: optional

    • default: none

    • This parameter specifies the that no interactive prompting to fill in the contents of the specified subtree filter target will be done.

      • This causes the entire selected subtree to be requested in the filter.

      • yangcli-pro will attempt to figure out if there can be multiple instances of the requested subtree. If not, then 'nofill' will be the default for that target parameter.

  • with-defaults

    • type: enumeration (none report-all report-all-tagged trim explicit)

    • usage: optional

    • default: none

    • capabilities needed: with-defaults

    • This parameter controls how nodes containing only default values are returned in the <rpc-reply>.

  • depth

    • type: uint32 or “unbounded”

    • usage: optional

    • default: unbounded

    • capabilities needed: none: netconfd-pro NETCONF extension

    • This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.

  • module-tag:

    • type: string

    • default: none

    • capabilities needed: none

    • This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.

System Variables:

  • $$timeout

    • The response timeout interval will be derived from this system variable.

  • $$with-defaults

    • The <with-defaults> parameter for the <get> operation will be derived from this system variable.

Positive Response:

  • the server returns <data>

Negative Response:

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

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

Output:

  • data

    • type: anyxml

    • This element will contain the requested data from the <running> database or non-config data structures.

Usage:

andy@myserver> sget system

Filling container /system:
RPC Data Reply 32 for session 10:

rpc-reply {
   data {
      system {
         sysName myserver.localdomain
         sysCurrentDateTime 2009-07-06T02:24:19Z
         sysBootDateTime 2009-07-05T19:22:28Z
      }
   }
}

andy@myserver>

Reference:

sget-config

The 'sget-config' command is used to invoke a NETCONF <get-config> operation with a subtree filter.

A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the 'nofill' parameter.

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

+---x sget-config
   +---w input
   |  +---w (from)
   |  |  +--:(varref)
   |  |  |  +---w varref?                string
   |  |  +--:(from-cli)
   |  |     +---w (target-parm)?
   |  |     |  +--:(target)
   |  |     |  |  +---w target           yang:xpath1.0
   |  |     |  +--:(urltarget-case)
   |  |     |     +---w urltarget        ywt:UrlPath
   |  |     |     +---w match-names?     ywt:NameMatchMode
   |  |     |     +---w alt-names?       ywt:AltNameMode
   |  |     |     +---w wildcard-keys?   boolean
   |  |     +---w optional?              empty
   |  |     +---w value?                 <anyxml>
   |  +---w nofill?                      empty
   |  +---w with-defaults?               CliWithDefaultsType
   |  +---w depth?                       union
   |  +---w module-tag*                  string
   |  +---w source
   |     +---w (config-source)
   |        +--:(candidate)
   |        |  +---w candidate?   empty {nc:candidate}?
   |        +--:(running)
   |        |  +---w running?     empty
   |        +--:(startup)
   |        |  +---w startup?     empty {nc:startup}?
   |        +--:(url)
   |           +---w url?         nc:ConfigURIType {nc:url}?
   +--ro output
      +--ro data?   <anyxml>

Command type:

remote

Default parameter:

target

Min parameters:

2

Max parameters:

7

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

:candidate :startup :url :with-defaults

Command Parameters:

  • choice 'from' (not entered)

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

    • usage: mandatory

    • default: none

    • This parameter specifies the where yangcli-pro should get the data from, for the subtree filter target of the <get> operation. It is either a user variable or from interactive input at the command line.

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: optional (target or urltarget must be present)

          • default: none

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

            • The escape command ('?s') can be used in parameter mode to skip a parameter completely.

            • Entering the empty string for a parameter will cause a subtree selection node to be created instead of a content match node

        • urltarget

          • type: string

          • usage: optional

          • default: none

          • This parameter specifies the database target node of the get-config operation. This is an UrlPath string.

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.

  • nofill

    • type: empty

    • usage: optional

    • default: none

    • This parameter specifies the that no interactive prompting to fill in the contents of the specified subtree filter target will be done.

      • This causes the entire selected subtree to be requested in the filter.

      • yangcli-pro will attempt to figure out if there can be multiple instances of the requested subtree. If not, then nofill will be the default for that target parameter.

  • source

    • type: container with 1 of N choice of leafs

    • usage: mandatory

    • default: none

    • This parameter specifies the name of the source database for the retrieval operation.

    • container contents: 1 of N:

      • candidate

      • running

        • type: empty

        • capabilities needed: none

      • startup

        • type: empty

        • capabilities needed: startup

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

  • with-defaults

    • type: enumeration (none report-all report-all-tagged trim explicit)

    • usage: optional

    • default: none

    • capabilities needed: with-defaults

    • This parameter controls how nodes containing only default values are returned in the <rpc-reply>.

  • depth

    • type: uint32 or “unbounded”

    • usage: optional

    • default: unbounded

    • capabilities needed: none: netconfd-pro NETCONF extension

    • This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.

  • module-tag:

    • type: string

    • default: none

    • capabilities needed: none

    • This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.

System Variables:

  • $$timeout

    • The response timeout interval will be derived from this system variable.

  • $$with-defaults

    • The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.

Positive Response:

  • the server returns <data>

Negative Response:

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

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

Output:

  • data

    • type: anyxml

    • This element will contain the requested data from the database indicated by the 'source' parameter.

Usage:

andy@myserver> sget-config /nacm/rules/data-rule \
        source=candidate \
        nofill

RPC Data Reply 35 for session 10:

rpc-reply {
   data {
     nacm {
         rules {
            data-rule nacm-tree {
               name nacm-tree
               path /nacm:nacm
               allowed-rights {
                  read
                  write
               }
               allowed-group nacm:admin
               comment 'access to nacm config'
            }
         }
      }
   }
}

andy@myserver>

sget-data

The 'sget-data' command is used to invoke a NETCONF NMDA <get-data> operation with a subtree filter.

  • This command will not work unless the server supports the <get-data> operation from RFC 8526, in ietf-netconf-nmda.yang.

  • A target node is specified (in 1 of 2 ways), and then the data structure is filled in. Only mandatory nodes will be filled in unless the $$optional system variable is set to 'true'. This step can be skipped completely with the 'nofill' parameter.

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

  • The ietf-netconf-nmda.yang module must be loaded in the server for this command to be available.

+---x sget-data
   +---w input
   |  +---w datastore?                     enumeration
   |  +---w (from)
   |  |  +--:(varref)
   |  |  |  +---w varref?                  string
   |  |  +--:(from-cli)
   |  |     +---w (target-parm)?
   |  |     |  +--:(target)
   |  |     |  |  +---w target             yang:xpath1.0
   |  |     |  +--:(urltarget-case)
   |  |     |     +---w urltarget          ywt:UrlPath
   |  |     |     +---w match-names?       ywt:NameMatchMode
   |  |     |     +---w alt-names?         ywt:AltNameMode
   |  |     |     +---w wildcard-keys?     boolean
   |  |     +---w optional?                empty
   |  |     +---w value?                   <anyxml>
   |  +---w nofill?                        empty
   |  +---w with-defaults?                 CliWithDefaultsType
   |  +---w depth?                         union
   |  +---w module-tag*                    string
   |  +---w config-filter?                 boolean
   |  +---w (origin-filters)?
   |  |  +--:(origin-filter)
   |  |  |  +---w origin-filter*           or:origin-ref
   |  |  +--:(negated-origin-filter)
   |  |     +---w negated-origin-filter*   or:origin-ref
   |  +---w with-origin?                   empty
   +--ro output
      +--ro data?   <anyxml>

Command type:

remote

Default parameter:

target

Min parameters:

2

Max parameters:

8

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

:candidate :startup :url :with-defaults

Command Parameters:

  • choice 'from' (not entered)

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

    • usage: mandatory

    • default: none

    • This parameter specifies the where yangcli-pro should get the data from, for the subtree filter target of the <get> operation. It is either a user variable or from interactive input at the command line.

      • varref

        • type: string

        • usage: mandatory

        • default: none

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

      • case from-cli (not entered)

        • target

          • type: string

          • usage: optional (target or urltarget must be present)

          • default: none

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

            • The escape command ('?s') can be used in parameter mode to skip a parameter completely.

            • Entering the empty string for a parameter will cause a subtree selection node to be created instead of a content match node

        • urltarget

          • type: string

          • usage: optional

          • default: none

          • This parameter specifies the database target node of the get-config operation. This is an UrlPath string.

        • optional

          • type: empty

          • usage: optional

          • default: controlled by $$optional system variable

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

        • value

          • type: anyxml

          • usage: mandatory

          • default: none

          • This parameter specifies the value that should be used for the contents of the 'target' parameter. If it is entered, then the interactive mode prompting for missing parameters will be skipped, if this parameter is complete (or all mandatory nodes present if the $$optional system variable is 'false'). For example, if the target is a leaf, then specifying this parameter will always cause the interactive prompt mode to be skipped.

  • nofill

    • type: empty

    • usage: optional

    • default: none

    • This parameter specifies the that no interactive prompting to fill in the contents of the specified subtree filter target will be done.

      • This causes the entire selected subtree to be requested in the filter.

      • yangcli-pro will attempt to figure out if there can be multiple instances of the requested subtree. If not, then nofill will be the default for that target parameter.

  • datastore

    • type: leaf containing a datastore-ref

    • usage: mandatory

    • This parameter specifies the name of the source NMDA datastore for the retrieval operation.

    • enumeration:

      • candidate

      • running

        • capabilities needed: none

      • startup

        • capabilities needed: startup

      • operational

        • capabilities needed: none

  • with-defaults

    • type: enumeration (none report-all report-all-tagged trim explicit)

    • usage: optional

    • default: none

    • capabilities needed: with-defaults

    • This parameter controls how nodes containing only default values are returned in the <rpc-reply>.

  • depth

    • type: uint32 or “unbounded”

    • usage: optional

    • default: unbounded

    • capabilities needed: none

    • This parameter controls how many levels of subtrees should be returned in the <rpc-reply>. This is called the <max-depth> parameter in the <get-data> operations.

  • config-filter:

    • type boolean

    • Specifies the type of data based on config-stmt. Retrieve all data if this parameter is not present. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

    • Only relevant if the datastore parameter is ‘operational’.

    • If set to ‘false’ for any datastore other than ‘operational’ then an empty <data> element will be returned.

  • origin-filter:

    • type: leaf-list of type origin-ref..

    • This parameter will select data nodes with the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

    • Cannot be used if negated-origin-filter present

    • Can only be used if the datastore parameter is ‘operational’

  • negated-origin-filter:

    • type: leaf-list of type origin-ref..

    • This parameter will select data nodes if they do not have the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

    • Cannot be used if origin-filter present

    • Can only be used if the datastore parameter is ‘operational’

  • with-origin

    • type: empty

    • This parameter will cause the origin attribute to be added to data nodes returned by the server.

    • Can only be used if the datastore parameter is ‘operational’

System Variables:

  • $$timeout

    • The response timeout interval will be derived from this system variable.

  • $$with-defaults

    • The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.

Positive Response:

  • the server returns <data>

Negative Response:

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

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

Output:

  • data

    • type: anyxml

    • This element will contain the requested data from the database indicated by the 'source' parameter.

Usage:

Reference:

show

The 'show' command is used to show program status and YANG details that may be needed during management of a NETCONF server.

There are several variants of the 'show' command:

  • The show cache command prints the yangcli-pro YANG module cache.

  • The show connected command prints the all connected sessions.

  • The show cli command prints the contents of the yangcli-pro CLI and config file parameters.

  • The show diff command prints the differences between current config and the edits that have not been applied yet.

  • The show edit command prints subtree that is the current node which is from the current edit, not the stored config.

  • The show connected command prints a summary of the sessions that are currently connected

  • The show global command prints the contents of one global user variable.

  • The show globals command prints a summary or the contents of all the global user variables.

  • The show local command prints the contents of one local user variable.

  • The show locals command prints a summary or the contents of all the local user variables.

  • The show module command prints meta information or help text for one YANG module.

  • The show modules command prints meta information for all the currently available YANG modules. If a session is active, this will be the list of modules the server reported, plus any modules loaded with the mgrload command.

  • The show modules-state command prints cached modules-state for each server.

  • The show objects command prints the available objects or help text for the available objects.

  • The show running command prints the entire config for the current session , error if there is no current session.

  • The show session command prints the session startup screen information for the current session.

  • The show search-path-module command prints the YANG module search path in use.

  • The server-commands prints the server commands (not in config mode). It is top-level only and only relevant if session is connected.

  • The show system command prints the contents of the yangcli-pro system variables.

  • The show terminal command prints the terminal length

  • The show var command prints the contents of the specified variable.

  • The show vars command prints a summary or the contents of all the program variables.

  • The show version command prints the yangcli-pro version number

+---x show
   +---w input
      +---w (showtype)
      |  +--:(cache)
      |  |  +---w cache?                empty
      |  +--:(cli)
      |  |  +---w cli?                  empty
      |  +--:(diff)
      |  |  +---w diff?                 empty
      |  +--:(edit)
      |  |  +---w edit?                 empty
      |  +--:(connected)
      |  |  +---w connected?            empty
      |  +--:(module)
      |  |  +---w module?               nt:NcxIdentifier
      |  +--:(modules)
      |  |  +---w modules?              empty
      |  +--:(modules-state)
      |  |  +---w modules-state?        empty
      |  +--:(local)
      |  |  +---w local?                nt:NcxName
      |  +--:(locals)
      |  |  +---w locals?               empty
      |  +--:(global)
      |  |  +---w global?               nt:NcxName
      |  +--:(globals)
      |  |  +---w globals?              empty
      |  +--:(group-vars)
      |  |  +---w group-vars?           IdentifierOrZero
      |  +--:(objects)
      |  |  +---w objects?              empty
      |  +--:(running)
      |  |  +---w running               empty
      |  |  +---w select?               string
      |  +--:(search-path-module)
      |  |  +---w search-path-module?   empty
      |  +--:(server-commands)
      |  |  +---w server-commands?      empty
      |  +--:(session)
      |  |  +---w session?              empty
      |  +--:(session-vars)
      |  |  +---w session-vars?         IdentifierOrZero
      |  +--:(system)
      |  |  +---w system?               empty
      |  +--:(terminal)
      |  |  +---w terminal?             empty
      |  +--:(var)
      |  |  +---w var?                  nt:NcxName
      |  +--:(vars)
      |  |  +---w vars?                 empty
      |  +--:(version)
      |     +---w version?              empty
      +---w (help-mode)?
         +--:(brief)
         |  +---w brief?                empty
         +--:(normal)
         |  +---w normal?               empty
         +--:(full)
            +---w full?                 empty

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

2

Return type:

data

YANG file:

yangcli-pro.yang

Command Parameters:

  • choice help-mode (not entered) (default choice is 'normal')

    • brief

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that brief documentation mode should be used.

    • normal

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that normal documentation mode should be used.

    • full

      • type: empty

      • usage: optional

      • default: none

      • This parameter specifies that full documentation mode should be used.

  • choice showtype (not entered)

    • mandatory 1 of N choice for the sub-command for the 'show' command

      • cli

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter selects the yangcli-pro CLI and configuration variables.

      • Connected

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter prints a summary of the currently connected sessions.

      • diff

        • type: empty

        • usage: mandatory

        • default: none

        • The parameter prints the differences between current config and the edits that have not been applied yet.

      • edit

        • type: empty

        • usage: mandatory

        • default: none

        • The parameter prints subtree that is the current node which is from the current edit, not the stored config.

      • global

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the global variable to show information for.

        • If help-mode is 'brief', then the name, variable object, and type of the global variable object will be printed.

        • If help-mode is 'normal' or 'full', then the contents of the specified global variable will be printed.

      • globals

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that information for all global variables should be printed.

        • If help-mode is 'brief', then the name, variable object, and type of each global variable object will be printed.

        • If help-mode is 'normal' or 'full', then the contents of each global variable will be printed.

      • local

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the local variable to show information for.

        • If help-mode is 'brief', then the name, variable object, and type of the local variable object will be printed.

        • If help-mode is 'normal' or 'full', then the contents of the specified local variable will be printed.

      • locals

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that information for all local variables should be printed.

        • If help-mode is 'brief', then the name, variable object, and type of each local variable object will be printed.

        • If help-mode is 'normal' or 'full', then the contents of each local variable will be printed.

      • module

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the module to show information for.

        • If help-mode is 'brief' or 'normal', then the name, version, namespace, and source of the module will be printed.

        • If help-mode is 'full', then the module level help text for the specified module will be printed.

      • modules

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that information for all available modules should be printed:

        • If help-mode is 'brief', then the name of each module will be printed.

        • If help-mode is 'normal', then the XML prefix, name, and revision date of each module will be printed.

        • If help-mode is 'full', then the name, revision date, prefix, namespace, and source of each module will be printed.

      • objects

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that information for all available database objects should be printed:

        • If help-mode is 'brief', then the module name and name of each object will be printed.

        • If help-mode is 'normal', then the YANG object type, object name, and YANG base type will be printed.

        • If help-mode is 'full', then brief help text will be printed for every object.

      • running

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter prints the entire config for the current session , error if there is no current session.

      • Search-path-module

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that the YANG module search path should be printed.

      • Server-commands

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter display server commands (not in config mode).

      • System

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that information for all system variables should be printed.

      • terminal

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that information about the terminal settings should be printed.

      • var

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the name of any variable to show information for.

        • If help-mode is 'brief', then the name, variable object, and type of the variable object will be printed.

        • If help-mode is 'normal' or 'full', then the contents of the specified variable will be printed.

      • vars

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that information for all variables should be printed. This includes all CLI, read-only system, read-write system, global user, and local user variables.

        • If help-mode is 'brief', then the name, variable object, and type of each variable object will be printed.

        • If help-mode is 'normal' or 'full', then the contents of each variable will be printed.

      • version

        • type: empty

        • usage: mandatory

        • default: none

        • This parameter specifies that the yangcli-pro program version string should be printed.

Positive Response:

  • the server prints the requested information

Negative Response:

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

Usage:

andy@myserver> show modules

          nc:netconf/2009-04-10
          inet:ietf-inet-types/2009-05-13
          ns:ietf-netconf-monitoring/2009-03-03
          wd:ietf-with-defaults/2009-04-10
          yang:ietf-yang-types/2009-05-13
          nacm:nacm/2009-05-13
          manageEvent:nc-notifications/2008-07-14
          ncx:ncx/2009-06-12
          ncxapp:ncx-app-common/2009-04-10
          nt:ncxtypes/2008-07-20
          nd:netconfd-pro/2009-05-28
          ncEvent:notifications/2008-07-14
          sys:system/2009-06-04
          t:test/2009-06-10

        andy@myserver>

andy@myserver> show running
  data {
    nacm {
      groups {
        group  aa {
          name aa
          user-name a1
          user-name a2
        }
      }
    }
  }


andy@myserver> sho edit
Only available in config mode.

andy@myserver> sho diff
Only available in config mode.

andy@myserver> conf t
andy@myserver# nacm groups
andy@myserver(groups)# group bb
andy@myserver(group)# user-name b1
andy@myserver(group)# user-name b2

andy@myserver(group)# do show edit
nacm {
  groups {
    group  bb {
      name bb
      user-name b1
      user-name b2
    }
  }
}

andy@myserver(group)# do show diff
Edited to merge:
nacm {
  groups {
    group  bb {
      name bb
      user-name b1
      user-name b2
    }
  }
}

Configured:
nacm {
  groups {
    group  aa {
      name aa
      user-name a1
      user-name a2
    }
  }
}

andy@myserver(group)# apply
Applying 1 edit to session 'default'
andy@myserver(group)# do sho running
data {
  nacm {
    groups {
      group  aa {
        name aa
        user-name a1
        user-name a2
      }
      group  bb {
        name bb
        user-name b1
        user-name b2
      }
    }
  }
}
andy@myserver(group)#

shutdown

The 'shutdown' command is used to shut down the NETCONF server. This command is only supported by the netconfd-pro server.

The default access control configuration for netconfd-pro will not allow any user except the designated 'superuser' account to invoke this command. Refer to the Access Control section for details.

The yuma-system.yang module must be loaded in the server for this command to be available.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <shutdown> operation for parameter details.

Usage:

andy@myserver> shutdown

ses: session 10 shut by remote peer

>

sleep

The 'sleep' command is used to pause for a number of seconds. It is intended to be used within a script.

Example script:

# send 20 get-config requests, 1 per second
while 1 maxloops=20
get-config source=running
sleep 1
end
+---x sleep
   +---w input
      +---w seconds    uint16

Command type:

local

Default parameter:

seconds

Min parameters:

1

Max parameters:

1

Return type:

none

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

none

Command Parameters:

  • seconds

    • type: uint16 (1 .. 3600)

    • usage: mandatory

    • This parameter specifies the number of seconds to sleep

Positive Response:

  • none

Negative Response:

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

Usage:

session-B> sleep 1

session-B>

start-rpc-timing

The 'start-rpc-timing' command is used to start remote operation timing mode, except that statistics can be saved to a text file for plotting or for data entry into a database program. It is used to do simple roundtrip performance measurements. It is used along with the stop-rpc-timing command.

This command automatically sets the following variables to temporary values, which are restored when the stop-rpc-timing command is invoked.

  • $$echo-replies = false

  • $$rpc-timing = true

  • $$rpc-timing-stats = true

+---x start-rpc-timing
   +---w input
      +---w statfile?   string

Command type:

local

Default parameter:

statfile

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

none

Command Parameters:

  • statfile

    • type: file specification

    • usage: mandatory

    • This parameter specifies the file specification for saving the timing statistics.

Positive Response:

  • the client prints OK

Negative Response:

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

Usage:

session-B> start-rpc-timing

OK

session-B>

start-session

The 'start-session' command is used to start a session with a NETCONF server. It is similar to the connect command except the parameters are derived from a saved session in memory instead of entered explicitly.

+---x start-session
   +---w input
      +---w name?   nt:NcxIdentifier

Command type:

local

Default parameter:

name

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • name

    • type: session name string

    • usage: mandatory

    • This parameter specifies the name of the session to start.

Positive Response:

  • The startup screen for the session should be generated and the prompt should change, indicating the new named session is now the current session.

Negative Response:

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

Usage:

session-A> start-session session-B

yangcli: Starting NETCONF session for user on myserver

NETCONF session established for user on myserver

Client Session Id: 2
Server Session Id: 4

Server Protocol Capabilities
   base:1.0
   candidate:1.0
   confirmed-commit:1.0
   rollback-on-error:1.0
   validate:1.0
   url:1.0
   xpath:1.0
   notification:1.0
   interleave:1.0
   partial-lock:1.0
   with-defaults:1.0
   base:1.1
   validate:1.1
   confirmed-commit:1.1
   yang-library:1.0

Server Module Capabilities
   ietf-inet-types@2010-09-24
   ietf-netconf-acm@2012-02-22
   ietf-netconf-monitoring@2010-10-04
   ietf-netconf-partial-lock@2009-10-19
   ietf-netconf-with-defaults@2011-06-01
   ietf-yang-library@2016-06-21
   ietf-yang-types@2010-09-24
   nc-notifications@2008-07-14
   notifications@2008-07-14
   yuma-app-common@2012-08-16
   yuma-arp@2012-01-13
   yuma-interfaces@2012-01-13
   yuma-mysession@2010-05-10
   yuma-ncx@2012-01-13
   yuma-proc@2010-06-01
   yuma-system@2012-01-15
   yuma-time-filter@2011-08-13
   yuma-types@2012-06-01
   yumaworks-app-common@2012-08-16
   yumaworks-extensions@2012-06-28

Server Enterprise Capabilities
   None

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

Checking Server Modules...

session-B>

start-timer

The 'start-timer' command is used to start a timer to do simple performance measurements. It is used along with the stop-timer command.

+---x start-timer
   +---w input
      +---w id?           TimerId
      +---w restart-ok?   boolean

Command type:

local

Default parameter:

id

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

none

Command Parameters:

  • id

    • type: number

    • usage: mandatory

    • default: 0

    • This parameter specifies the numeric ID of the timer. It is a number in the range 0 to 15.

  • restart-ok

    • type: boolean

    • usage: optional

    • default: true

    • Indicates whether the timer will be used if it is already running. If 'true', the timer will be restarted if it is already running. If 'false', an error will occur if the timer is already running.

Positive Response:

  • the client prints OK

Negative Response:

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

Usage:

andy@myserver> start-timer 1

OK

andy@myserver>

stop-rpc-timing

The 'stop-rpc-timing' command is used to stop remote operation timing mode. It is used with the start-rpc-timing command. This command automatically sets the following variables to the specified values:

  • $$echo-replies = <previous value before start-rpc-timing>

  • $$rpc-timing = false

  • $$rpc-timing-stats = false

+---x stop-rpc-timing

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

none

Positive Response:

  • the client prints OK

Negative Response:

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

Usage:

session-B> stop-rpc-timing

OK

session-B>

stop-session

The 'stop-session' command is used to stop a session with a NETCONF server. It will invoke the close-session command for the specified session. It is used with the start-session command.

+---x stop-session
   +---w input
      +---w name    nt:NcxIdentifier

Command type:

local

Default parameter:

name

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • name

    • type: session name string

    • usage: mandatory

    • This parameter specifies the name of the session to stop. The string 'default' is used to identify the default session, if that was started with the start-session or connect command.

Positive Response:

  • The prompt should change if the current session is stopped

Negative Response:

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

Usage:

session-B> stop-session session-B

RPC OK Reply 4 for session 4 [session-B]:

ses: session 2 shut by remote peer

>

stop-timer

The 'stop-timer' command is used to stop a timer to do simple performance measurements. It is used along with the start-timer command.

+---x stop-timer
   +---w input
   |  +---w id?     TimerId
   |  +---w echo?   boolean
   +--ro output
      +--ro delta?   decimal64

Command type:

local

Default parameter:

id

Min parameters:

1

Max parameters:

2

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

none

Command Parameters:

  • id

    • type: number

    • usage: mandatory

    • default: 0

    • This parameter specifies the numeric ID of the timer. It is a number in the range 0 to 15.

  • echo

    • type: boolean

    • usage: optional

    • default: true

    • Indicates whether the delta result should be printed to the log.

Positive Response:

  • data: the elapsed time is returned and can be used in assignment statements

Negative Response:

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

Usage:

andy@myserver> $time = stop-timer 1

Elapsed time: 2.003345 seconds

andy@myserver>

terminal

The 'terminal' command is used to change the terminal settings.

It is used along with the 'show terminal' command.

+---x terminal
   +---w input
      +---w length    uint16

Command type:

local

Default parameter:

length

Min parameters:

1

Max parameters:

1

Return type:

none

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

none

Command Parameters:

  • length

    • type: number

    • usage: mandatory

    • default: 0

    • This parameter specifies the length of the terminal to use for page mode output with the -More- prompt. This parameter is ignored in batch mode. It is only used if the output session is operating in interactive mode.

  • If the value 0 is used then the 'More' prompt will be disabled. Otherwise this value represents the number of lines to output for each screen in pagination output mode.

Positive Response:

  • OK

Negative Response:

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

Usage:

andy@myserver> terminal length 20

OK

andy@myserver>

test-suite

The 'test-suite' command is used to access yangcli-pro regression test scripts. Refer to the section on Automated Testing for more details.

This command has 5 sub-commands:

  • load

  • run-all

  • show (default)

  • start ('log' parameter also allowed in this mode)

  • save

+---x test-suite
   +---w input
      +---w suite-name?           nt:NcxIdentifier
      +---w log?                  string
      +---w (test-suite-action)?
         +--:(delete)
         |  +---w delete?         empty
         +--:(delete-test-case)
         |  +---w delete-test?    empty
         |  +---w test-name       nt:NcxIdentifier
         +--:(show-case)
         |  +---w show?           IdentifierOrZero
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?    empty
         |     +--:(normal)
         |     |  +---w normal?   empty
         |     +--:(full)
         |        +---w full?     empty
         +--:(load)
         |  +---w load?           string
         +--:(run-all)
         |  +---w run-all?        empty
         +--:(start)
         |  +---w start?          nt:NcxIdentifier
         +--:(save)
            +---w save?           string

Command type:

local

Default parameter:

show

Min parameters:

0

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

none

Command Parameters:

  • suite-name:

    • type: identifier string

    • usage: mandatory if 'delete' or 'delete-test' used.

    • This parameter identifies the test suite to delete for use with the delete and delete-test sub-commands.

  • test-name:

    • type: identifier string

    • usage: mandatory if 'delete-test' used.

    • This parameter identifies the test to delete for use with the delete-test sub-command.

  • choice test-suite-action (default show)

    • delete

      • type: empty

      • usage: optional

      • This parameter is used to delete a test-suite from memory. The 'suite-name' parameter must also be present.

    • delete-test

      • type: empty

      • usage: optional

      • This parameter is used to delete a test-suite from memory. The 'suite-name' and 'test-name' parameters must also be present.

    • load

      • type: string

      • usage: optional

      • This parameter specifies the name of the test-suite configuration file to load.

    • run-all

      • type: empty

      • usage: optional

      • Run all the test-suites defined in the test suite config files. The 'log' parameter may also be present if this parameter is used.

    • save

      • type: string

      • usage: optional

      • This parameter identifies the file specification of the test-suite configuration file where the test-suites in memory should be saved.

    • show

      • type: string

      • usage: optional

      • This parameter specifies the name of the test-suite in memory to show.

      • The --brief, --normal, or --full parameters can be used with this sub-command.

    • start

      • type: name string

      • usage: optional

      • This parameter specifies the name of the test-suite to start. This sub-command can only be used if a test-suite is not already in progress.

      • log (available only if 'start' or 'run-all' is present)

        • type: filespec string

        • usage: optional

        • This parameter specifies the name of the log file for the test-suite test run and results. If no parameter is specified, then STDOUT will be used instead.

Positive Response:

  • The appropriate data will be shown for a 'show' sub-command.

Negative Response:

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

Usage:

andy@myserver> test-suite start ~/mytests.conf

... commands from test executed

andy@myserver>

unlock

The 'unlock' command is used to request a global lock on a NETCONF database. It is used, along with the lock command, to obtain exclusive write access to the NETCONF server.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <unlock> operation for parameter details.

Usage:

andy@myserver> unlock target=candidate

RPC OK Reply 38 for session 10:

andy@myserver>

unset

The 'unset' command is used to delete a command alias from memory.

+---x unset
   +---w input
      +---w name    nt:NcxName

Command type:

local

Default parameter:

name

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • name

    • type: string

    • usage: mandatory

    • default: none

    • This parameter specifies the name of the command alias to delete.

Positive Response:

  • Deleted alias 'foo' is printed, where 'foo' is the name parameter string

Negative Response:

  • An error message will be printed.

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

Usage:

> unset get-running

Deleted alias 'get-running'

>

update-config

The 'update-config' command is used to force an update of the configuration cache for the current session. The current session must be connected and the $$autoconfig system variable must be true, or an error will be returned.

+---x update-config

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters: none

Positive Response:

  • Nothing will be printed unless the log-level is set to debug or higher.

andy@myserver> update-config

andy@myserver>

Negative Response:

  • An error message will be printed if the current content is not an active session or the --autoconfig CLI parameter and $$autoconfig variable is set to true.

andy@myserver> update-config

Error: auto-configure mode disabled for session 'default'

andy@myserver>

user-cfg

The 'user-cfg' command is used to access a named user.

There are 4 sub-commands:

  • delete

  • save

  • show (default)

  • create

Refer to the section on NETCONF User Configuration for more details on using saved users.

+---x user-cfg
   +---w input
      +---w (user-action)?
         +--:(show-case)
         |  +---w show?           IdentifierOrZero
         |  +---w (help-mode)?
         |     +--:(brief)
         |     |  +---w brief?    empty
         |     +--:(normal)
         |     |  +---w normal?   empty
         |     +--:(full)
         |        +---w full?     empty
         +--:(delete)
         |  +---w delete?         nt:NcxIdentifier
         +--:(save)
         |  +---w save?           nt:NcxIdentifier
         +--:(create)
            +---w create          nt:NcxName
            +---w user-name       nt:NcxName
            +---w password        string

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • delete

    • type: name string

    • This parameter specifies the name of the user to delete from the saved users in memory. An active user cannot be deleted.

  • save

    • type: name string

    • This parameter specifies the name of the user to save in the saved users in memory.

  • show

    • type: name string; default: empty string == current user

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

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

  • create

    • type: name string

    • This parameter specifies a new user to create.

Positive Response:

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

Negative Response:

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

andy@myserver> user-cfg save user-A

Saving current user as 'user-A'

andy@myserver>

> user-cfg create=usr1 user-name=admin password=password

A new user is created: user-id=usr1 name=admin password=password

users-cfg

The 'users-cfg' command is used to access the named user files.

There are 4 sub-commands:

  • clear

  • load

  • save

  • show (default)

Refer to the section on NETCONF User Configuration for more details on using saved users.

+---x users-cfg
    +---w input
       +---w (users-action)?
          +--:(show-case)
          |  +---w show?           empty
          |  +---w (help-mode)?
          |     +--:(brief)
          |     |  +---w brief?    empty
          |     +--:(normal)
          |     |  +---w normal?   empty
          |     +--:(full)
          |        +---w full?     empty
          +--:(clear)
          |  +---w clear?          empty
          +--:(load)
          |  +---w load?           string
          +--:(save)
             +---w save?           string

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Command Parameters:

  • clear

    • type: empty

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

  • load

    • type: string

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

  • save

    • type: name string

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

  • show

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

    • This parameter specifies the name of the user to show.

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

Positive Response:

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

Negative Response:

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

Usage:

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

Loading saved users from '/home/andy/more-users.conf'

Loaded saved users OK from '~/more-users.conf'

uservars

The uservars command is used to clear, load, or save the global user variables.

+---x uservars
   +---w input
      +---w (uservars-action)
         +--:(clear)
         |  +---w clear?   empty
         +--:(load)
         |  +---w load?    string
         +--:(save)
            +---w save?    string

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • uservars-action

    • type: choice

    • usage: mandatory

    • default: none

    • clear:

      • Delete all global user variables from memory

    • load [uservars-filespec]

      • Load global user variables into memory from an XML file. If the 'uservars-filespec' parameter is missing, then the default file ($HOME/.yumapro/yangcli_pro_uservars.xml) will be used.

    • save [uservars-filespec]

      • Save the global user variables from memory into an XML file. If the 'uservars-filespec' parameter is missing, then the default file ($HOME/.yumapro/yangcli_pro_uservars.xml) will be used.

Positive Response:

  • A status message is printed.

Negative Response:

  • An error message will be printed.

Usage:

> uservars clear

Deleted all global user variables from memory

>

validate

The 'validate' command is used to check if a complete NETCONF database is valid or not. The :validate capability must be supported by the server to use this command.

This command is provided by the NETCONF server, not yangcli-pro. Refer to the <validate> operation for parameter details.

Usage:

andy@myserver> validate source=candidate

RPC OK Reply 36 for session 10:

andy@myserver>

while

The 'while' command is used to start a conditional loop command block.

The 'expr' parameter is used to specify the XPath expression to test if the while conditional loop block is true or false. A false block will be skipped and a true block will be executed. The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode. This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.

The 'docroot' parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against. This is optional, since only XPath path expressions need to refer to a document.

If the 'expr' expression is true, the conditional block will be executed, and no further conditional blocks within the same if command sequence will be executed.

The maxloops parameter specifies the maximum number of iterations that should be allowed, even if the expression continues to evaluate to 'true'. This allows constant expressions to be used to construct a simple 'for' loop.

while command

   ...

end command

The 'while' command must be paired with a matching end command.

+---x while
   +---w input
      +---w expr        yang:xpath1.0
      +---w docroot?    <anyxml>
      +---w maxloops?   uint32

Command type:

local

Default parameter:

expr

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

  • expr

    • type: XPath expression string

    • usage: mandatory

    • default: none

    • This parameter specifies the XPath expression to determine if the following commands are within a true or false conditional block.

  • docroot

    • type: anyxml

    • usage: optional (typically a variable reference is used)

    • default: none

    • This parameter specifies the XML document that should be used if the expr XPath expression references any path nodes.

  • maxloops

    • type: uint32

    • usage: optional

    • default: 65535

    • Set a maximum number of loops that can be iterated for this while command. The value zero means that no maximum will be enforced. Use this mode with caution.

Positive Response:

  • the server returns <ok/>

Negative Response:

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

    • invalid XPath expression or invalid docroot reference will cause an error

Usage:

andy@myserver> while 1 --maxloops=10

SAME AS:

andy@myserver> while '$x < 10'

andy@myserver>

xget

The 'xget' command is used to invoke a NETCONF <get> operation with an XPath filter.

+---x xget
   +---w input
   |  +---w (from)
   |  |  +--:(varref)
   |  |  |  +---w varref?      string
   |  |  +--:(select)
   |  |  |  +---w select?      string
   |  |  +--:(urltarget)
   |  |     +---w urltarget?   ywt:UrlPath
   |  +---w timeout?           nt:Timeout
   |  +---w with-defaults?     CliWithDefaultsType
   |  +---w depth?             union
   |  +---w module-tag*        string
   |  +---w match-names?       ywt:NameMatchMode
   |  +---w alt-names?         ywt:AltNameMode
   |  +---w wildcard-keys?     boolean
   +--ro output
      +--ro data?   <anyxml>

Command type:

remote

Default parameter:

select

Min parameters:

1

Max parameters:

5

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

:xpath

Capabilities optional:

none

Command Parameters:

  • choice 'from' (not entered)

    • type: choice of case 'varref' or case 'select'

    • usage: mandatory

    • default: none

    • This parameter specifies the where yangcli-pro should get the data from, for the XPath filter target of the <get> operation. It is an XPath expression, either contained in a user variable or directly from the 'select' parameter.

      • varref

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the user variable the contains the XPath expression for the XPath filter in the <get> operation. The parameter must exist (e.g., created with an assignment statement) or an error message will be printed.

      • select

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the XPath expression to use for the XPath filter in the <get> operation.

  • timeout

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

    • usage: optional

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

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

  • with-defaults

    • type: enumeration (none report-all report-all-tagged trim explicit)

    • usage: optional

    • default: none

    • capabilities needed: with-defaults

    • This parameter controls how nodes containing only default values are returned in the <rpc-reply>.

  • depth

    • type: uint32 or “unbounded”

    • usage: optional

    • default: unbounded

    • capabilities needed: none: netconfd-pro NETCONF extension

    • This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.

  • module-tag:

    • type: string

    • default: none

    • capabilities needed: none

    • This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.

System Variables:

  • $$timeout

    • The response timeout interval will be derived from this system variable.

  • $$with-defaults

    • The <with-defaults> parameter for the <get> operation will be derived from this system variable.

Positive Response:

  • the server returns <data>

Negative Response:

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

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

Output:

  • data

    • type: anyxml

    • This element will contain the requested data from the <running> database or non-config data structures.

Usage:

andy@myserver> xget //name

RPC Data Reply 42 for session 10:

rpc-reply {
   data {
      nacm {
         rules {
            data-rule nacm-tree {
               name nacm-tree
            }
         }
      }
      xpath.1 {
         name barney
      }
      netconf-state {
         datastores {
            datastore {
               name {
                  candidate
               }
            }
         }
      }
      netconf {
         streams {
            stream NETCONF {
               name NETCONF
            }
         }
      }
   }
   }
}

andy@myserver>

Reference:

xget-config

The 'xget-config' command is used to invoke a NETCONF <get-config> operation with an XPath filter.

+---x xget-config
   +---w input
   |  +---w (from)
   |  |  +--:(varref)
   |  |  |  +---w varref?      string
   |  |  +--:(select)
   |  |  |  +---w select?      string
   |  |  +--:(urltarget)
   |  |     +---w urltarget?   ywt:UrlPath
   |  +---w timeout?           nt:Timeout
   |  +---w with-defaults?     CliWithDefaultsType
   |  +---w depth?             union
   |  +---w module-tag*        string
   |  +---w match-names?       ywt:NameMatchMode
   |  +---w alt-names?         ywt:AltNameMode
   |  +---w wildcard-keys?     boolean
   |  +---w source
   |     +---w (config-source)
   |        +--:(candidate)
   |        |  +---w candidate?   empty {nc:candidate}?
   |        +--:(running)
   |        |  +---w running?     empty
   |        +--:(startup)
   |        |  +---w startup?     empty {nc:startup}?
   |        +--:(url)
   |           +---w url?         nc:ConfigURIType {nc:url}?
   +--ro output
      +--ro data?   <anyxml>

Command type:

remote

Default parameter:

select

Min parameters:

2

Max parameters:

6

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

:xpath

Capabilities optional:

:url :with-defaults

Command Parameters:

  • choice 'from' (not entered)

    • type: choice of case 'varref' or case 'select'

    • usage: mandatory

    • default: none

    • This parameter specifies the where yangcli-pro should get the data from, for the XPath filter target of the <get-config> operation. It is an XPath expression, either contained in a user variable or directly from the 'select' parameter.

      • varref

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the user variable the contains the XPath expression for the XPath filter in the <get-config> operation. The parameter must exist (e.g., created with an assignment statement) or an error message will be printed.

      • select

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the XPath expression to use for the XPath filter in the <get-config> operation.

  • source

    • type: container with 1 of N choice of leafs

    • usage: mandatory

    • default: none

    • This parameter specifies the name of the source database for the retrieval operation.

    • container contents: 1 of N:

      • candidate

      • running

        • type: empty

        • capabilities needed: none

      • startup

        • type: empty

        • capabilities needed: :startup

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

  • timeout

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

    • usage: optional

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

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

  • with-defaults

    • type: enumeration (none report-all report-all-tagged trim explicit)

    • usage: optional

    • default: none

    • capabilities needed: with-defaults

    • This parameter controls how nodes containing only default values are returned in the <rpc-reply>.

  • depth

    • type: uint32 or “unbounded”

    • usage: optional

    • default: unbounded

    • capabilities needed: none: netconfd-pro NETCONF extension

    • This parameter controls how many levels of subtrees should be returned in the <rpc-reply>.

  • module-tag:

    • type: string

    • default: none

    • capabilities needed: none

    • This parameter is used as a filter to include only data nodes from modules that match the module-tag value. Multiple module-tag parameters can be used, combined to form a logical OR expression. At least one module-tag must match or no data will be returned. This filter is combined with the XPath or subtree filter, if present.

System Variables:

  • $$timeout

    • The response timeout interval will be derived from this system variable.

  • $$with-defaults

    • The <with-defaults> parameter for the <get-config> operation will be derived from this system variable.

Positive Response:

  • the server returns <data>

Negative Response:

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

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

Output:

  • data

    • type: anyxml

    • This element will contain the requested data from the 'source' database.

Usage:

andy@myserver> xget-config /nacm/rules/data-rule source=candidate

RPC Data Reply 35 for session 10:

rpc-reply {
   data {
     nacm {
         rules {
            data-rule nacm-tree {
               name nacm-tree
               path /nacm:nacm
               allowed-rights {
                  read
                  write
               }
               allowed-group nacm:admin
               comment 'access to nacm config'
            }
         }
      }
   }
}

andy@myserver>

xget-data

The 'xget-data' command is used to invoke a NETCONF NMDA <get-data> operation with an XPath filter. This command will not work unless the server supports the <get-data> operation from RFC 8526 in ietf-netconf-nmda.yang.

+---x xget-data
   +---w input
   |  +---w datastore?                     enumeration
   |  +---w (from)
   |  |  +--:(varref)
   |  |  |  +---w varref?                  string
   |  |  +--:(select)
   |  |  |  +---w select?                  string
   |  |  +--:(urltarget)
   |  |     +---w urltarget?               ywt:UrlPath
   |  +---w timeout?                       nt:Timeout
   |  +---w with-defaults?                 CliWithDefaultsType
   |  +---w depth?                         union
   |  +---w module-tag*                    string
   |  +---w match-names?                   ywt:NameMatchMode
   |  +---w alt-names?                     ywt:AltNameMode
   |  +---w wildcard-keys?                 boolean
   |  +---w config-filter?                 boolean
   |  +---w (origin-filters)?
   |  |  +--:(origin-filter)
   |  |  |  +---w origin-filter*           or:origin-ref
   |  |  +--:(negated-origin-filter)
   |  |     +---w negated-origin-filter*   or:origin-ref
   |  +---w with-origin?                   empty
   +--ro output
      +--ro data?   <anyxml>

Command type:

remote

Default parameter:

select

Min parameters:

2

Max parameters:

6

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

none

Capabilities optional:

:candidate :startup :url :with-defaults

Command Parameters:

  • choice 'from' (not entered)

    • type: choice of case 'varref' or case 'select'

    • usage: mandatory

    • default: none

    • This parameter specifies the where yangcli-pro should get the data from, for the XPath filter target of the <get-config> operation. It is an XPath expression, either contained in a user variable or directly from the 'select' parameter.

      • varref

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the name of the user variable the contains the XPath expression for the XPath filter in the <get-config> operation. The parameter must exist (e.g., created with an assignment statement) or an error message will be printed.

      • select

        • type: string

        • usage: mandatory

        • default: none

        • This parameter specifies the XPath expression to use for the XPath filter in the <get-config> operation.

  • datastore

    • type: leaf containing a datastore-ref

    • usage: mandatory

    • This parameter specifies the name of the source NMDA datastore for the retrieval operation.

    • enumeration:

      • candidate

      • running

        • capabilities needed: none

      • startup

      • operational

        • capabilities needed: none

  • timeout

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

    • usage: optional

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

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

  • with-defaults

    • type: enumeration (none report-all report-all-tagged trim explicit)

    • usage: optional

    • default: none

    • capabilities needed: with-defaults

    • This parameter controls how nodes containing only default values are returned in the <rpc-reply>.

  • depth

    • type: uint32 or “unbounded”

    • usage: optional

    • default: unbounded

    • capabilities needed: none: netconfd-pro NETCONF extension

    • This parameter controls how many levels of subtrees should be returned in the <rpc-reply>. This is called the <max-depth> parameter in the <get-data> operations.

  • config-filter:

  • type boolean

  • Specifies the type of data based on config-stmt. Retrieve all data if this parameter is not present. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

  • Only relevant if the datastore parameter is ‘operational’.

  • If set to ‘false’ for any datastore other than ‘operational’ then an empty <data> element will be returned.

  • origin-filter:

    • type: leaf-list of type origin-ref..

    • This parameter will select data nodes with the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

    • Cannot be used if negated-origin-filter present

    • Can only be used if the datastore parameter is ‘operational’

  • negated-origin-filter:

    • type: leaf-list of type origin-ref..

    • This parameter will select data nodes if they do not have the specified origin. This is a top-down filter. It will not select nodes within a subtree if the ancestor nodes do not match the filter.

    • Cannot be used if origin-filter present

    • Can only be used if the datastore parameter is ‘operational’

  • with-origin

    • type: empty

    • This parameter will cause the origin attribute to be added to data nodes returned by the server.

  • Can only be used if the datastore parameter is ‘operational’

System Variables:

  • $$timeout

    • The response timeout interval will be derived from this system variable.

  • $$with-defaults

    • The <with-defaults> parameter for the <get-data> operation will be derived from this system variable.

Positive Response:

  • the server returns <data>

Negative Response:

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

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

Output:

  • data

    • type: anyxml

    • This element will contain the requested data from the 'source' database.

Usage: