2  yangcli-pro User Guide

Program Components

Image1

2.1  Introduction

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

2.1.1  Features

The yangcli-pro client has the following features:

 

2.1.2  Starting yangcli-pro

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

 

The yangcli-pro program can be invoked several ways:


yangcli-pro --version


yangcli-pro --help

yangcli-pro --help --brief

yangcli-pro --help --full


yangcli-pro


yangcli-pro --log=mylogfile


yangcli-pro --log=mylogfile --log-append


yangcli-pro --config=~/yangcli-pro.conf


yangcli-pro server=myserver.example.com


yangcli-pro --server=myserver.example.com \

--user=andy --password=yangrocks


yangcli-pro --server=myserver.example.com \

--user=andy --password=yangrocks \

--run-script=mytestscript

 


yangcli-pro --server=myserver.example.com \

--user=andy --password=yangrocks \

--run-script=mytestscript --batch-mode

 


yangcli-pro --server=myserver.example.com \

--user=andy --password=yangrocks \

--batch-mode --run-command=”sget /system”

 

 


yangcli-pro --server=myserver.example.com \

--user=andy --password=yangrocks \

--batch-mode --autonotif=true

 

2.1.3  Stopping yangcli-pro

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

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

 

2.1.4  Statements

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

 

yangcli-pro Statements

 

type

description

example

command

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

sget /system

variable assignment

set a user variable to some value

$system = sget /system

file assignment

set the contents of a file to some value

@save.txt = $system

variable deletion

delete a user variable or clear a system variable

$system =

 

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

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

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

 


> $$default-operation = 'merge'

 

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

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

2.1.5  Commands

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

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

There are 2 types of yangcli-pro commands:

 

Local Commands

command

description

alias

Show or set a specific yangcli-pro command alias

aliases

Manage the yangcli-pro command aliases

auto-test

Run automatic edit testing on the specified session

cache

Clear 1 or all entries from the YANG module cache

cd

Change the current working directory

clear

Clear the screen

config

Enter the configuration mode for the current session

connect

Connect to a server and start a NETCONF session

device-cfg

Access a named device configuration

devices-cfg

Access the named device configuration file

elif

Start an 'else-if' conditional block

else

Start an 'else' conditional block

enable-password

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

end

End an 'if' or 'while' block

eval

Evaluate an XPath expression

eventlog

View or clear the notification event log

exit

Exit configuration mode for the current session

fill

Fill a user variable

group

Manage the session groups.

help

Get context-sensitive help

history

Manage the command history buffer

if

Start an 'if' conditional block

list

List modules, objects, or other properties of the session

log-debug

Log a debug message

log-error

Log an error message

log-info

Log an info message

log-warn

Log a warning message

mgrload

Load a YANG file into the client only

nvsave

Save the running datastore to the startup datastore

pwd

Print the current working directory

quit

Exit the program

recall

Recall a line from the command history buffer

record-test

Record commands and responses for a regression test

run

Run a script

schema-server-cfg

Access a named schema-server-cfg configuration

schema-servers-cfg

Access the named schema-servers-cfg configuration file

session

Set the current session

session-cfg

Access a named session configuration

sessions-cfg

Access the named session configuration file

show

Show variables and objects currently available

sleep

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

start-rpc-timing

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

stop-session

Stop a named session

stop-timer

Stop a script timer and display the elapsed time

terminal

Set the terminal length

test-suite

Access a configured unit-test suite for automated testing

user-cfg

Access a named user configuration

users-cfg

Access the named user configuration file

update-config

Update the shadow configuration for the current session<

unset

Remove a command alias from memory

uservars

Manage the yangcli-pro user variables

while

Start a 'while' conditional loop block

 

 

 

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

 

Standard NETCONF Commands

 

command

description

cancel-commit

Cancel the current confirmed commit procedure

close-session

Close the current NETCONF session

commit

Make the candidate database be the running config

copy-config

Copy an entire NETCONF database

create-subscription

Start receiving NETCONF notifications

delete-config

Delete an entire NETCONF database

discard-changes

Discard any edits in the candidate database

edit-config

Alteration of the target database

get

Filtered retrieval of state data and running config

get-config

Filtered retrieval of any NETCONF database

get-schema

Get a data model definition file from the server

kill-session

Force close another NETCONF session

lock

Lock a NETCONF database that is currently unlocked

unlock

Unlock a NETCONF database that is currently locked

validate

Validate the contents of a NETCONF database

 

 

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

 

Custom NETCONF Commands

 

command

description

action

Invoke a YANG 1.1 <action>

create

Invoke an <edit-config> create operation

delete

Invoke an <edit-config> delete operation

get-locks

Lock all the databases with the <lock> operation

get-walk

Walk the entries of a YANG list.

insert

Invoke an <edit-config> YANG insert operation

merge

Invoke an <edit-config> merge operation

release-locks

Unlock all the locked databases with the <unlock> operation

remove

Invoke an <edit-config> remove operation

replace

Invoke an <edit-config> replace operation

save

Save the current edits on the server in NV-storage

sget

Invoke a <get> operation with a subtree filter

sget-config

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

sget-data

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

xget

Invoke a <get> operation with an XPath filter

xget-config

Invoke a <get-config> operation with an XPath filter

xget-data

Invoke a <get-data> operation with an XPath filter

 

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

 

Extended netconfd-pro Commands

 

command

description

get-my-session

Retrieve session customization parameters

load

Load a module into the server.

no-op

No operation.

restart

Restart the server.

set-log-level

Set the server logging verbosity level.

set-my-session

Set session customization parameters.

shutdown

Shutdown the server.

 

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

 

Configuration Mode Commands

 

command

description

apply

Apply any pending edits to the current session

exit

Return to the parent mode and apply and pending edits

do

Run a command in configuration mode

no

Prefix to configuration mode command used to delete a node

return

Return to normal mode from Confing mode without applying ny edits

 

2.1.6  Variables

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

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

Variables can be 1 or more characters in length, and follow the YANG rules for identifier names.  The first character must be a letter,  'A' to 'Z', or 'a' to 'z'.  The 2nd to last characters can be a letter 'A' to 'Z', or 'a' to 'z', number ('0' to '9'), an underscore ('_'), a dash ('-'), or a period ('.')  character.

 

There are 4 categories of parameters supported:

  1. Read-only system variables

  2. Read-write system variables

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

  4. Read-write local user variables

 

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

 

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

 

Variable Syntax

 

syntax

description

example

$$<variable-name>

Left hand side:  set the global variable to some value

$$saved_get = get

$$<variable-name>

Right hand side:  access the value of a global variable

fill --target=\
   $$mytarget

$<variable-name>

Left hand side: set the local variable to some value

$myloglevel = \
   $$log-level

$<variable-name>

Right hand side: access the value of any variable with this name (try local, then global)

$myuser = $user

 

The following table shows the unix environment variables that are available as read-only global variables in 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.

 

Read-only system variables

 

variable

description

$$HOME

the HOME environment variable

$$HOSTNAME

the HOST or HOSTNAME environment variable

$$LANG

the LANG environment variable

$$PWD

the PWD environment variable, when yangcli-pro was invoked

$$SHELL

the SHELL environment variable

$$USER

the USER environment variable

$$YUMAPRO_DATAPATH

the YUMAPRO_DATAPATH environment variable

$$YUMAPRO_HOME

the YUMAPRO_HOME environment variable

$$YUMAPRO_MODPATH

the YUMAPRO_MODPATH environment variable

$$YUMAPRO_RUNPATH

the YUMAPRO_RUNPATH environment variable

 

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

 

Read-write system variables

 

variable

description

$$aliases-file

the --aliases-file configuration parameter

$$alt-names

the --alt-names configuration parameter

$$ask-password

the --ask-password configuration parameter

$$auto-discard-changes

the --auto-discard-changes parameter

$$auto-keepalive

the --auto-keepalive configuration parameter

$$auto-reconnect

the --auto-reconnect configuration parameter

$$auto-reconnect-interval

the --auto-reconnect-interval configuration parameter

$$auto-reconnect-max

the --auto-reconnect-max configuration parameter

$$autoaliases

the --autoaliases configuration parameter

$$autocomp

the --autocomp configuration parameter

$$autoconfig

the --autoconfig configuration parameter

$$autoconfig-conf-mode

the --autoconfig-conf-mode configuration parameter

$$autodevices

the --autodevices configuration parameter

$$autohistory

the --autohistory configuration parameter

$$autoload

the --autoload configuration parameter

$$autoload-cache

the --autoload-cache configuration parameter

$$autoload-get

the --autoload-get configuration parameter

$$autoload-save-cache

the --autoload-save-cache configuration parameter

$$autonotif

the --autonotif configuration parameter

$$autonvsave

   the --autonvsave configuration parameter

$$autoschemaservers

the --autoschemaservers configuration parameter

$$autosessions

   the --autosessions configuration parameter

$$autotest

   the --autotest configuration parameter

$$autousers

   the --autousers configuration parameter

$$autouservars

   the --autouservars configuration parameter

$$bad-data

the --bad-data configuration parameter

$$break-key-mode

the --break-key-mode configuration parameter

$$callhome-address

the --callhome-address configuration parameter

$$callhome-enabled

the --callhome-enabled configuration parameter

$$callhome-port

the --callhome-port configuration parameter

$$callhome-tls-port

the --callhome-tls-port configuration parameter

$$check-output

the --check-output configuration parameter

$$check-output-error

the --check-output-error configuration parameter

$$check-replies

the --check-replies configuration parameter

$$check-replies-error

the --check-replies-error configuration parameter

$$config-autosave

the --config-autosave configuration parameter

$$config-commit-mode

the --config-commit-mode configuration parameter

$$config-edit-mode

the --config-edit-mode configuration parameter

$$default-module

the --default-module configuration parameter

$$default-operation

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

$$display-mode

the --display-mode configuration parameter

$$echo-notif-loglevel

the --echo-notif-loglevel configuration parameter

$$echo-notifs

the --echo-notifs configuration parameter

$$echo-replies

the --echo-replies configuration parameter

$$encoding

the --encoding configuration parameter

$$error-option

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

$$fill-optional

the --fill-optional configuration parameter

$$fixorder

the --fixorder configuration parameter

$$help-width

the --help-width configuration parameter

$$ignore-missing-vars

the --ignore-missing-vars configuration parameter

$$indent

the --indent configuration parameter

$$keepalive-interval

The -keepalive-interval configuration parameter

$$log-level

the --log-level configuration parameter

$$match-names

the --match-names configuration parameter

$$message-indent

the --message-indent configuration parameter

$$optional

the --optional configuration parameter

$$prompt

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

$$prompt-type

the --prompt-type configuration parameter

$$save-session-vars

the --save-session-vars configuration parameter

$$script-input

the --script-input configuration parameter

$$server

the --server configuration parameter

$$ssl-fallback-ok

the --ssl-fallback-ok configuration parameter

$$term-length

the --term-length configuration parameter

$$test-option

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

$$test-suite-file

the --test-suite-file configuration parameter

$$time-rpcs

the --time-rpcs configuration parameter

$$time-rpcs-stats

the --time-rpc-stats configuration parameter

$$time-rpcs-stats-file

the --time-rpc-stats-file configuration parameter

$$timeout

the --timeout configuration parameter

$$use-data-templates

the --use-data-templates configuration parameter

$$use-rawxml

the --use-rawxml configuration parameter

$$use-session-vars

the --use-session-vars configuration parameter

$$use-traceid

the --use-traceid configuration parameter

$$use-xmlheader

the --use-xmlheader configuration parameter

$$user

the --user configuration parameter

$$uservars-file

the --uservars-file configuration parameter

$$with-defaults

the --with-defaults configuration parameter

$$with-term-msg

the --with-term-msg configuration parameter

 

Read-write global user variables

 

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

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

 

Read-write local user variables

 

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

 

Read-write session user variables

 

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

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

 

 

 

2.1.7  Files

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

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

 

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

 

session1> mgrload --module=foo

 

 

If the file extension is “.yang”, “.log”, “.txt”, or “.text”, then the value (or command output) will be saved, and yangcli-pro will strip off the outermost XML (if needed) to save the requested file as a pure text file.  Otherwise, the file will be saved in XML format.  The display mode set by the user can affect XML output.  If the display mode i s'xml-nons' then XML without namespace (xmlns) attributes will be generated instead of normal XML.

Note: The --display-mode configuration parameter, and $$display-mode system variable, only affect the output and display of data in the yangcli-pro program.  NETCONF protocol messages are always sent in 'xml' mode.

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

 

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

 

 

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

 

2.1.8  Scripts

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

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

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

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

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

 

Script Example:

 

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

 

// connect script

# start a NETCONF session

$user = $1

$server = $2

$password = $3

 

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

 

 

Run Levels

 

The run command can appear in a script.

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

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

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

 

Conditional Command Blocks

 

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

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

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

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

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

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

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

 

Conditional Command Loop Blocks

 

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

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

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

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

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

 

Sample Script 1

 

The following script does not do any useful work.

It is provided to demonstrate some simple constructs.

 

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

 

 

Sample Script 2

 

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

 

$x = 0

$y = interfaces

$z = interface

$value = ianaift:l2vlan

 

while '$x < 5'

create /if:$y/if:$z[if:name='vlan$x']/if:type value=$value

commit

$x = eval '$x + 1'

end

 

 

2.1.9  Configuration Mode Editing

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

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

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

 

Enter Configuration Mode

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

 

mysession> config term

 

mysession#

 

 

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

 

Enter Configuration Sub-Mode

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

 

mysession# interfaces

 

mysession(interfaces)# int eth0

 

mysession(interface)#

 

Exit Configuration Sub-Mode

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

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

 

mysession(interface)# exit

mysession(interfaces)#

 

Return from Configuration Editing Mode

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

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

 

mysession(interface)# return

mysession>

 

Creating or modifying server database parameters

 

mysession(interface)# mtu 9000

 

mysession(interface)# exit

 Applying 1 edit to session [mysession]

 

mysession(interfaces)# exit

 

mysession# exit

mysession>

 

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

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

 

mysession# int int eth0 mtu 9000

 

 Applying 1 edit to session [mysession]

 

mysession#

 

 

Deleting server database parameters

 

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

 

mysession# no int int eth0 mtu

 

 Applying 1 edit to session [mysession]

 

mysession#

 

 

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

 

Escaping configuration mode

 

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

 

mysession# do show session

 

  [session info shown]

 

mysession#

 

 

 

2.1.10  Configuration Parameter List

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

 

yangcli-pro CLI Parameters

 

parameter

description

--aliases-file

Specifies the command aliases file to use.

--alt-names

Controls whether alternate names will be checked for UrlPath searches.

--ask-password

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

--auto-discard-changes

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

--auto-keepalive

Controls automatic sending of keepalive messages.
NOT IMPLEMENTED - IGNORED

--auto-reconnect

Controls automatic reconnecting to dropped sessions

--auto-reconnect-interval

Controls how often automatic reconnect is attempted

--auto-reconnect-max

Controls maximum number of reconnect attempts

--autoaliases

Controls automatic loading and saving of the command aliases

--autocomp

Controls whether partial commands are allowed or not.

--autoconfig

Controls whether the running configuration will be retrieved automatically for active sessions.

--autoconfig-conf-mode

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

--autodevices

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

--autohistory

Controls whether th command line history buffer will be automatically loaded at startup and saved on exit.

--autoload

Controls whether modules used by the server will be loaded automatically, as needed.

-autoload-cache

Controls whether the modules retrieved with the <get-schema> 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

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

--check-output

Controls whether YANG <rpc> validation is done

--check-output-error

Controls whether YANG <rpc> validation errors are treated as errors or warnings

--check-replies

Controls whether YANG <rpc-reply> validation is done

--check-replies-error

Controls whether YANG <rpc-reply> validation errors are treated as errors or warnings

--config

Specifies the configuration file to use for parameters.
The --no-config option can be used instead to prevent the default config file from being used.

--config-autosave

Controls how edits in config term mode are saved to NV-storage if the server supports the :startup capability.

--config-commit-mode

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

--config-edit-mode

Controls how edits are applied during configuration mode

--datapath

Sets the data file search path.

--default-module

Specifies the default module to use to resolve identifiers.

--deviation

Species one or more YANG modules to load as deviations.`

--disable-command

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

--display-mode

Specifies how values should be displayed.

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

--help

Get program help.

--help-mode

Adjust the help output (--brief or --full).

--help-width

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

--history-file

Specifies the libtecla command line history file to use

--home

Override the $HOME environment variable.

--ignore-missing-vars

Specifies whether a missing variable in a data template is an error or the variable expands to an empty string

--indent

Specifies the indent count to use when writing data.

--insecure-ok

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

--keepalive-interval

Specifies the keepalive message interval. NOT IMPLEMENTED.

--log

Specifies the log file to use instead of STDOUT. See the YumaPro User Manual for a general discussion of logging.

--log-append

Controls whether a log file will be reused or overwritten.

--log-backtrace

Append stack trace information to log messages.

--log-backtrace-detail

Add additional (compiler/OS dependent) detail to stack trace information.

--log-backtrace-level

Specify message level(s) for which stack trace information will be generated.

--log-backtrace-stream

Include stack trace information in the specified output stream(s

--log-console

Specifies that log output will be sent to STDOUT after being sent to log file and/or syslog (assumes --log=file and/or --log-syslog are present).

--log-header

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

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

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. The “terminal length” command can also be used for the same purpose.

--test-suite-file

Specifies the name of the test suite file to load if --autotest=true.  The default value is $HOME/.yumapro/yangcli_pro_tests.conf

--time-rpcs

  Measure the round-trip time of each <rpc> request
 and <rpc-reply> at the session level.

--time-rpcs-stats

Save rpc statistics to the specified or default statistics file if the time-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.  The default value is $HOME/yangcli_pro_rpc_stats.txt

--timeout

Specifies the timeout to use in the connect command.

--transport

Specified the transport protocol to use (ssh, tcp, or tpc-ncx)

--use-data-templates

Controls whether data templates are enabled

--use-rawxml

Controls how file result variables will be read. If true then the YANG object template will not be used when parsing the XML file.

--use-session-vars

Controls how global variables will be handled when set from the context of a named session. If true then session-specific variables will be used.

--use-traceid

Controls whether the 'trace-id' attribute will be set in the RPC calls or not. By default, 'trace-id' attribute is disabled.

--use-xmlheader

Specifies how file result variables will be written for XML files.  Controls whether the XML preamble header will be written or not.

--user

The default user name for NETCONF sessions.

--uservars-file

Specifies the global user variable files to load.

--version

Prints the program version and exits.

--warn-error

Treat all warnings as errors

--warn-idlen

Controls how identifier lengths are checked.

--warn-linelen

Controls how line lengths are checked.

--warn-off

Suppresses the specified warning number.

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

 

2.2  Invoking Commands

Commands can be entered with parameters:

 

session1> merge target=/toaster/toastControl --value=”down”


session1> merge target=/toaster/toastControl \
 more> --value=”down”


session1> merge

(will be prompted for target and value)


session1> merge target=/toaster/toastControl

(will be prompted for value)

 

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

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

A command has the basic form:

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

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

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

The command name syntax is described below.

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

 

2.2.1  Command Prompt

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

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

 

>

 

2.2.2  Command Name

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


session1
> nc:get

session1
> get

 

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

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

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

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

 

2.2.3  ncx:default-parm Extension

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

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

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


> history --show=10


> history 10

 

 

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


# this is the same as history show=25

> history

 

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

> history show

 

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

 

Default Parameters

 

command

default parameter

action

target

alias

var

aliases

show

cd

dir

connect

server

create

target

elif

expr

else

expr

if

expr

eventlog

show

fill

target

help

command

history

show

 

command

default parameter

insert

target

load

module

log-debug

msg

log-error

msg

log-info

msg

log-warn

msg

merge

target

mgrload

module

recall

index

replace

target

run

script

set-log-level

log-level

sget

target

sget-config

target

sget-data

target

xget

select

xget-config

select

xget-data

select

while

expr

 

2.2.4  Parameter Mode Escape Commands

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

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

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

 

Parameter mode escape sequences

 

escape sequence

description

?

Print some help text

??

Get all available help text

?s

Skip this parameter

?se

Skip to the end of the current parameter set

?c

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

 

2.2.5  Using Inline XML or JSON Data

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

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

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

The syntax is simple:

 

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

 

 

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

 

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

 

 

 

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

 

Example script using JSON:

 

> edit-config target=candidate config="""

{"config": {

 "container.1" : {

   "uint16.1" : 42,

   "uint32.1" : 4200,

   "int32.1" : -4200

 }

}

}

"""

 

 

Example script using XML:

 

> edit-config target=candidate config="""

<config>

<container.1>

 <uint16.1>42</uint16.1>

 <uint32.1>4200</uint32.1>

 <int32.1>-4200</int32.1>

</container.1>

</config>

"""

 

 

When entering inline data at the command line, the “more>” command prompt mode will be entered automatically if an 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:

 

 

2.2.6  Using External XML

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

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

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

 

External XML Parameters

 

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

 

 

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

 

 

2.2.7  Using XPath Expressions

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

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

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

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

 

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

:fill> system

:fill> /system

:fill> /sys:system

 

 

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

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

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

 

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

 

# complete form of ifMtu leaf

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

 

# incomplete form of ifMtu leaf

 

 

:fill> /interfaces/interface/ifMtu

 

Filling key leaf <name>:

Enter string value:

 

 

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

One of the simplest XPath filters to use is the descendant-or-self filter ('//<expr>').

For example, this command will retrieve all instances of the 'ifMtu' leaf:

 

andy@myserver> xget //ifMtu

 

 

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

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

 

# reply shown with --display-mode=plain

data {

  interfaces {

             interface eth0 {

   name eth0

   ifMtu 1500

     }

             interface eth1 {

   name eth1

   ifMtu 1518

     }

  }

}

 

 

 

2.2.8  Special Parameter Handling

Some special handling of YANG data structures is done by the script interpreter.

 

Containers

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

 

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

 

 

Choices and Cases

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

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

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

 

 

# this is not allowed because 'help-mode' is not complete

> help --command=help --help-mo=brief


# this is allowed because 'help-mode' is complete,

# even though help-mode is a choice and 'brief' is

# an empty leaf

> help help help-mode=brief

 

# choice and case names are transparent when

# searching for parameter names, so the

# following command is the same as above

> help help brief

 

 

Lists and Leaf-Lists

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

 

Binary Data Type

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

2.2.9  Command Completion

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

 

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

 

2.2.10  Command Line Editing

 

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

The home page is located here:

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

 

The complete user guide for configuring libtecla is located here:

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

 

If the file $HOME/.teclarc exists, then libtecla will use it to configure the key bindings.

By default, libtecla uses emacs key bindings.  There is no need for any further libtecla configuration if emacs mode is desired.

 

In order to use the vi editor key bindings, the $HOME/.teclarc file must exist, and it must contain the following line:

 

edit-mode vi

 

 

Custom key bindings are also available.  Refer to the libtecla documentation for more details on command line editing key customization.

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

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

 

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

 

Common editing key bindings

 

command

description

^C

clear screen

^F

cursor right

^B

cursor-left

^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

 

2.2.11  Command History

Each command line is saved in the command history buffer, unless a password is being entered in parameter mode.

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

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

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

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:

 

 

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

2.2.12  Command Responses

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

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

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

 

 

> $foo = 7

  OK

>

 

 

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

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

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

 

andy@myserver> create /system

 

Filling container /system:

RPC Error Reply 5 for session 8:

 

rpc-reply {

  rpc-error {

     error-type application

     error-tag access-denied

     error-severity error

     error-app-tag limit-reached

     error-path /nc:rpc/nc:edit-config/nc:config/sys:system

     error-message 'max-access exceeded'

  }

}

 

andy@myserver>

 

 

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

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

 

2.3.1  Pipe Commands

Pipe commands are used to control the terminal output

 

Usage Notes:

 

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>

 

 

YANG Definition

 

    container pipe {

      ncx:abstract;

      ncx:hidden;

 

      description

        "Pipe command sub-commands.

         The 'begin', 'include', and 'exclude' parameters are used

         to filter command output. If these parameters contain

         any pattern meta-characters, then they will be treated

         as a YANG pattern string.  If a plain string is found

         instead, then this string must be found in the line

         to be considered a match.

 

         Each output line is processed in the following manner:

           1) if begin set and not triggered yet, then test

              the line. If a match then disable this step

              for future lines and continue testing output,

              else skip this line.

           2) check each exclude parameter. If any match then

              skip this line.

           3) check each include parameter. If any match then

              include this line, else skip this line.

           4) include the line in the output.

 

         If the 'redirect' parameter is present then the filtered

         output will be sent to a file instead of the session.

 

         If the 'display'parameter is present then the specifed

         display format will be used for the output and the

         filtering format. By default, the current display-mode

         is used for both filtering and output formats.";

 

      leaf begin {

        type string;

        description

          "Specifies the pipe begin line pattern.";

      }

 

      leaf-list include {

        type string;

        description

          "Specifies a pipe include line pattern.

           Multiple parameters are treated as a logical-OR

           expression.";

      }

 

      leaf-list exclude {

        type string;

        description

          "Specifies a pipe exclude line pattern.

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

      }

    }

 

 

 

2.3.2  Pagination

 

      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

 

2.3.3   Display Mode

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

 

> show var display-mode

 display-mode cli

YANG Definition:

 

      leaf display-mode {

        description

           "Controls how values are displayed during output

            to STDOUT or a log file.";

         type enumeration {

           enum plain {

             description

                 "Plain identifier without any prefix format.";

           }

           enum prefix {

             description

                "Plain text with XML prefix added format.";

           }

           enum module {

             description

                "Plain text with module name as prefix added format.";

           }

           enum xml {

             description

                "XML format.";

           }

           enum xml-nons {

             description

                "XML format, but no namespace (xmlns) attributes

                 will be generated.";

           }

           enum json {

             description

                "JSON format.";

           }

           enum cli {

             description

                "CLI format.";

           }

        }

        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>

 

 

2.4  NETCONF Device Configuration

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

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

 

2.4.1  Creating Devices

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

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

> device-cfg show=device-B

Device 'device-B':

   server: 192.168.0.57

   connected: false

2.4.2  Saving Devices

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

 

> connect user=andy server=myserver password=mypassword

 

   ... startup screen ...

 

andy@myserver> device-cfg save device-A

 

    Saved current device as 'device-A'

 

andy@myserver>

 

 

2.4.3  Multiple Devices

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

 

2.4.4  Saving the Configured Devices

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

 

session-A> devices-cfg save

 

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

 

session-A>

 

 

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

 

session-A> devices-cfg save myusers.conf

 

Saved 2 devices OK to 'mydevices.conf'

 

session-A>

 

 

2.4.5  Loading Additional Configured Devices

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

 

session-A> devices-cfg load devices.conf

 

Loaded 3 sessions OK from 'devices.conf'

 

session-A>

 

 

 

2.4.6  Displaying the Configured Devices

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

 

session-A> devices-cfg show

 

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

 

Device 'desktop':

  server: 10.0.0.7

  connected: false

 

Device 'device-A':

  server: localhost

   connected: false

 

Device 'device-B':

  server: 192.168.0.57

  connected: false

 

 

2.4.7  Displaying Devices

Displaying a Specific Device

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

 

> device-cfg show device-A

 

Device 'device-A':

  server: localhost

  connected: false

 

 

2.4.8  Saved Device Configuration File Format

The saved sessions are stored in a YumaPro configuration file.

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

 

container saved-devices {

       ncx:abstract;

       description

         "Represents all the saved devices in

         the ~/.yumapro/yangcli_pro_devices file.

         Use the 'devices' command to access this file.

         Edit by hand only if you follow this YANG definition.";

 

       list device {

         description

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

 

        key name;

 

        leaf name {

          type nt:NcxName;

          description

           "The name of the saved device.

            The 'device save' command will use the

            string <user>@<server-address> as the default.";

        }

 

        leaf devicetype {

              type string;

              description

                "Device type for NETCONF devices.";

        }

        leaf server {

          type inet:host;

          mandatory true;

          description

             "IP address or DNS name of the NETCONF server target.";

 

        }

 

        leaf ncport {

          type uint16 {

            range "1..max";

          }

          default 830;

          description

            "NETCONF port number to use.  If not present, then

             port 830, followed by port 22, will be tried.";

        }

 

        uses ncxapp:ProtocolsParm;

       }

    }

 

 

2.4.9  Device Configuration File Example

The following example file shows a valid device configuration file:

 

 

saved-devices

 device  'desktop' {

   server '10.0.0.7'

   ncport 830

   protocols "netconf1.0 netconf1.1"

 }

 device  'device-A' {

   server 'localhost'

   ncport 830

   protocols "netconf1.0 netconf1.1"

 }

 device  'device-B' {

   server '192.168.0.57'

   ncport 830

   protocols "netconf1.1"

 }

}

 

 

 

 

2.5  NETCONF Schema Server Configuration

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

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

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

 

2.5.1  Creating New Schema Servers

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

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

 

> user-cfg show=userA

User 'userA':

  user: admin

  password: fredlow

  connected: false

 

> device-cfg show=deviceA

Device 'deviceA':

  server: 192.168.0.57

  connected: false

 

 

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

 

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

 

 

2.5.2  Saving Schema Servers

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

 

> schema-servers-cfg save

 

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

 

> schema-server-cfg show=schema-serverA

 

Schema Server: schema-serverA

      Device Id: deviceA

      User Id: userA

      Connected: false

 

 

 

 

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

 

 

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

 

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

 

 

 

 

2.5.3  Multiple Schema Servers

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

 

2.5.4  Displaying the Configured Schema Servers

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

> schema-servers-cfg

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

Schema Server: schema-serverA

       Device Id: deviceA

       User Id: userA

       Connected: false

Schema Server: schema-server-ACER

       Device Id: device-ACER

       User Id: user-ACER

       Connected: false

Schema Server: schema-server-asus2

       Device Id: asus2-device

       User Id: asus2

       Connected: false

 

2.5.5  Displaying A Schema Server

Displaying a Specific Schema Server

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

 

 

> schema-server-cfg show=schema-serverA

 

Schema Server: schema-serverA

      Device Id: deviceA

      User Id: userA

      Connected: false

 

 

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

        }

 

       }

 }

 

2.5.7  Schema Server Configuration File Example

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

 

saved-schema-servers {

 schema-server-id  'schema-serverA' {

   user-id 'userA'

   device-id 'deviceA'

 }

 schema-server-id  'schema-server-ACER' {

   user-id 'user-ACER'

   device-id 'device-ACER'

 }

 schema-server-id  'schema-server-asus2' {

   user-id 'asus2'

   device-id 'asus2-device'

 }

}

 

2.6  NETCONF User Configuration

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

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

 

2.6.1  Creating New Users

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

 

> user-cfg create=usr1 user-name=admin password=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
>

 

 

2.6.2  Saving Users

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

 

> connect user=andy server=myserver password=mypassword

 

... startup screen ...

 

andy@myserver> user-cfg save user-A

 

  Saved current user as 'user-A'

 

andy@myserver>

 

 

2.6.3  Multiple Users

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

 

2.6.4  Saving the Configured Users

The user configuration can be saved or loaded at run-time, even if the --autousers=true parameter is used (the default).  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>

 

 

2.6.5  Loading Additional Configured Users

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

 

session-A> users-cfg load users.conf

 

Loaded 3 sessions OK from 'users.conf

 

 

2.6.6  Displaying the Configured Users

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

 

session-A> users-cfg show

 

Saved users source: '~/.yumapro/.yangcli_pro_users.conf'

User 'userA':

  user: userNameA

  password: password A

  connected: false

 

User 'userB':

  user: userNameB

  password: password B

  connected: false

 

User 'userC':

  user: userNameC

  password: password C

  connected: false

 

 

2.6.7  Displaying Users

Displaying a Specific User

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

 

> user-cfg show userA

User 'userA':

  user: userNameA

  password: password A

  connected: false

 

 

2.6.8  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 SshKeyParms;

        uses SslKeyParms;

      }

    }

 

 

2.6.9  User Configuration File Example

The following example file shows a valid user configuration file:

 

 

saved-users {

 userid  'userA' {

   user 'userNameA'

   password 'passwordA'

   public-key '$HOME/.ssh/id_rsa.pub'

   private-key '$HOME/.ssh/id_rsa'

   ssl-fallback-ok true

   ssl-trust-store '$HOME/.ssl/trust-store.pem'

   ssl-key '$HOME/.ssl/yangapi-client.key'

   ssl-certificate '$HOME/.ssl/yangapi-client.crt'

 }

 userid  'userB' {

   user 'userNameB'

   password 'passwordB'

   public-key '$HOME/.ssh/id_rsa.pub'

   private-key '$HOME/.ssh/id_rsa'

   ssl-fallback-ok true

   ssl-trust-store '$HOME/.ssl/trust-store.pem'

   ssl-key '$HOME/.ssl/yangapi-client.key'

   ssl-certificate '$HOME/.ssl/yangapi-client.crt'

 }

}

 

 

 

2.7  NETCONF Session Configuration

The yangcli-pro program can be configured to associate a name with a set of session parameters to start a NETCONF session with a server.  These named sessions are saved in a configuration file.  Use the --autosessions to suppress 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>

 

 

2.7.1  Saving Sessions

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

 

> connect user=andy server=myserver password=mypassword

 

... startup screen ...

 

andy@myserver> session-cfg save session-A

 

  Saved current session as 'session-A'

 

andy@myserver>

 

 

2.7.2  Multiple Sessions

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

2.7.3  Changing the Active Session

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

 

session-A> session set-current session-B

 

session-B>

 

 

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

 

session-A> session session-B

 

session-B>

 

 

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

 

session-A> session default

 

andy@myserver>

 

2.7.4 Saving the Configured Sessions

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

 

session-A> sessions-cfg save

 

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

 

session-A>

 

 

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

 

session-A> sessions-cfg save mysessions.conf

 

Saved 2 sessions OK to 'mysessions.conf'

 

session-A>

 

 

2.7.5  Loading Additional Configured Sessions

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

 

session-A> sessions-cfg load sessions.conf

 

Loaded 3 sessions OK from 'sessions.conf'

 

session-A>

 

 

2.7.6  Displaying the Configured Sessions

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

 

 

session-A> sessions-cfg show

 

Saved sessions source: 'mysessions.conf'

Session 'session-A':

  user: andy

  server: localhost

  connected: true

 

Session 'session-B':

  user: andy

  server: eval.yumaworks.com

  connected: false

 

 

2.7.7  Displaying Sessions

Displaying the Active Session

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

 

session-A> session-cfg

 

Session 'session-A':

  user: andy

  server: localhost

  connected: true


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>

 

 

2.7.8  Terminating a Named Session

 

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

 

session-A> stop-session session-B

 

session-A>

 

 

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

 

session-A> stop-session session-A

 

>

 

 

2.7.9  Saved Session Configuration File Format

The saved sessions are stored in a YumaPro configuration file.

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

 

   container saved-sessions {

      description

        "Represents all the saved sessions in

         the ~/.yumapro/yangcli_pro_sessions file.

         Use the 'sessions' command to access this file.

         Edit by hand only if you follow this YANG definition.";

 

      list session {

        description

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

 

        key name;

 

        leaf name {

          type nt:NcxName;

          description

           "The name of the saved session.

            The 'session save' command will use the

            string <user>@<server-address> as the default.";

        }

 

        leaf user {

          type nt:NcxName;

          mandatory true;

          description

           "The use name of the session.";

        }

 

        leaf password {

          type string;

          ncx:password;

          description

            "User password to use for NETCONF sessions.

             If none, then user will be prompted before connecting.";

        }

 

        uses SshKeyParms;

 

        leaf server {

          type inet:host;

          mandatory true;

          description

             "IP address or DNS name of the NETCONF server target.";

 

        }

 

        leaf ncport {

          type uint16 {

            range "1..max";

          }

          default 830;

          description

            "NETCONF port number to use.  If not present, then

             port 830, followed by port 22, will be tried.";

        }

 

        uses ncxapp:ProtocolsParm;

 

        container start-commands {

          ywx:cli-text-block;

          description

            "An optional block of yangcli commands to run

             after the session is successfully started.";

        }

     }

   }

 

 

 

2.7.10  Session Configuration File Example

The following example file shows a valid session configuration file:

 

saved-sessions {

 session session-A {

   user andy

   password mypassword

   public-key $HOME/.ssh/id_rsa.pub

   private-key $HOME/.ssh/id_rsa

   server localhost

   ncport 830

   protocols "netconf1.0 netconf1.1"

 }

 session session-B {

   user andy

   password mypassword

   public-key $HOME/.ssh/id_rsa.pub

   private-key $HOME/.ssh/id_rsa

   server localhost

   ncport 830

   protocols "netconf1.0 netconf1.1"

 }

 session A {

   user andy2

   password newpassword

   public-key $HOME/.ssh/id_rsa.pub

   private-key $HOME/.ssh/id_rsa

   server localhost

   ncport 830

   protocols "netconf1.0 netconf1.1"

 }

}

 

 

 

 

2.8  NETCONF Group Configuration

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

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

The named groups and their sessions are saved in a configuration file. Use the --autosessions to 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.

 

2.8.1  Create group

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

Example of 'group create':

 

 

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

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

 

 

2.8.2  List group

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

 

> group list

Group 'AB'

  This group is not connected.

  missing-ok: false
  missing-connect-ok: false

  lost-ok: false
  reconnect-interval: 30
  reconnect-tries: 5
  connected_cnt: 0
  number_of_sessions: 2
  Session 'session-A' connected:false
  Session 'session-B' connected:false

Group 'a1a2a3'

  This group is not connected.

  missing-ok: false

  missing-connect-ok: false

  lost-ok: false

  reconnect-interval: 30

  reconnect-tries: 5

  connected_cnt: 0

  number_of_sessions: 3

  Session 'a1' connected:false

  Session 'a2' connected:false

  Session 'a3' connected:false
<

 

 

2.8.3  Delete group

The group delete command is used to delete a group.

 

> group delete=AB

> group delete=a1a2a3

> group list

 

No groups found

>

 

2.8.4  Add group

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

 

> group add=AB session=session-B

> group list

Group 'AB'

  This group is not connected.

  missing-ok: false

  missing-connect-ok: false

  lost-ok: false

  reconnect-interval: 30

  reconnect-tries: 5

  connected_cnt: 0

  number_of_sessions: 2

  Session 'session-A' connected:false

  Session 'session-B' connected:false

 

 

2.8.5  Remove Group

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

 

> group remove=AB session=session-A

 

> group list

Group 'AB'

  This group is not connected.

  missing-ok: false

  missing-connect-ok: false

  lost-ok: false

  reconnect-interval: 30

  reconnect-tries: 5

  connected_cnt: 0

  number_of_sessions: 1

  Session 'session-B' connected:false

 

 

2.8.6  Show Group

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

Example of 'group show':

 

> group show=AB

Group 'AB'

  This group is not connected.

  missing-ok: false

  missing-connect-ok: false

  lost-ok: false

  reconnect-interval: 30

  reconnect-tries: 5

  connected_cnt: 0

  number_of_sessions: 1

  Session 'session-B' connected:false
>

 

 

2.8.7  Connect Group

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

The default parameters value are false.

 

> group connect=AB

yangcli-pro: Starting NETCONF session for andy on localhost over ssh on port 830

NETCONF session established for xxxxx on localhost

... startup screen ...

 

AB>

Client Session Id: 1

Server Session Id: 1

---------

---------

---------

 

NETCONF session established for xxxxx on localhost

... startup screen ...

 

AB>

Client Session Id: 2

Server Session Id: 2

---------

---------

---------

AB> group list

Group 'AB'

  This group is fully connected.

  missing-ok: false

  missing-connect-ok: false

  lost-ok: false

  reconnect-interval: 30

  reconnect-tries: 5

  connected_cnt: 2

  number_of_sessions: 2

  Session 'session-A' connected:true

  Session 'session-B' connected:true

 

 

 

2.8.8  Help Group

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

 

> help group

group

 Manage the yangcli-pro session groups.

 A group name is not allowed to have the same name as any

...

 input

   default parameter: session

   choice groupcmd <Mandatory>

     case connect

       leaf connect [NcxIdentifier]

         Connect to all sessions in the specified group.

 

       leaf missing-ok [boolean] [d:false]

         If truew, then it is OK to manage this group if 1 or

         more sessions identified in...

 

       leaf missing-connect-ok [boolean] [d:false]

         If true, then it is OK to manage this group if 1 or

         more sessions identified in ...

 

       leaf lost-ok [boolean] [d:false]

         If true, then it is OK to manage this group if 1 or

         more sessions are lost after...

 

       leaf reconnect-tries [uint32] [d:5]

         Indicates the number of times yangcli will attempt

         to reconnect to a session if ...

 

       leaf reconnect-interval [uint32] [d:10]

         Indicates the number of seconds yangcli will wait to

         re-establish a connection i...

     leaf create [NcxIdentifier]

       Name of the group to create.  The 'session' parameter

       must also be present

 

     leaf delete [NcxIdentifier]

       Name of the group to delete

 

     leaf add [NcxIdentifier]

       Name of the group to add some sessions.  The 'session'

       parameter must also be presen...

 

     leaf remove [NcxIdentifier]

       Name of the group to remove some sessions.  The

       'session' parameer must also be pres...

 

     leaf show [NcxIdentifier]

       Name of the group to show

 

     leaf list [empty]

       List the names of all the groups saved-sessions {

   leaf-list session [NcxIdentifier] <Mandatory>

     Name of a session that is being added to the group.

>

 

2.8.9  Saving Groups

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

 

AB> sessions-cfg save

 session  'session-A' {

   user 'andy'

   password 'xxxxx'

   public-key '$HOME/.ssh/id_rsa.pub'

   private-key '$HOME/.ssh/id_rsa'

   server 'localhost'

   ncport 830

   protocols "netconf1.0 netconf1.1"

 }

 session  'session-B' {

   user 'andy'

   password 'xxxxx'

   public-key '$HOME/.ssh/id_rsa.pub'

   private-key '$HOME/.ssh/id_rsa'

   server 'localhost'

   ncport 830

   protocols "netconf1.0 netconf1.1"

 }

 group  'AB' {

   missing-connect-ok false

   missing-ok false

   lost-ok false

   reconnect-interval 30

   reconnect-tries 5

   session 'session-A'

   session 'session-B'

 }

}

 

 

2.8.10  Changing the Active group

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

 

a1a2a3> session set-current AB

Group 'AB' is now active

AB>

 

 

 

2.9  Using NETCONF Sessions

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

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

This section explains how to use yangcli-pro to manage a NETCONF server.

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

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

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

 

2.9.1  Connection Startup Screen

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

 

The following example shows a typical startup screen connecting to the netconfd-pro server:

 

 

NETCONF session established for user on localhost

 

Client Session Id: 1

Server Session Id: 1

 

Server Protocol Capabilities

  base:1.0

  candidate:1.0

  confirmed-commit:1.0

  rollback-on-error:1.0

  validate:1.0

  url:1.0

  xpath:1.0

  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

 

 

 

2.9.2  Server Tailored Context

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

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

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

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

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

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

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

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

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

If autoload-cache is true, the YANG modules that are retrieved with the <sget /netconf-state/schemas> operation will be cached. And cached module can be used by yangcli-pro.

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

 

 

2.9.3  Retrieving Data

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

 

command

description

get

raw NETCONF <get> operation

get-config

raw NETCONF <get-config> operation

sget

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

sget-config

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

sget-data

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

xget

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

xget-config

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

xget-data

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

 

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

 

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

 

 

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

 

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

 

 

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

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

 

2.9.4  Modifying Data

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

 

command

description

commit

raw NETCONF <commit> operation

create

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

delete

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

delete-config

raw NETCONF <delete-config> operation

discard-changes

raw NETCONF <discard-changes> operation

edit-config

raw NETCONF <edit-config> operation

fill

fill a variable for re-use in other operations

insert

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

lock

lock a NETCONF database

merge

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

replace

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

save

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

unlock

unlock a NETCONF database

 

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

All the high-level editing operations support the $$default-operation system variable.  The <default-operation> parameter will be added the the NETCONF <edit-config> PDU if this variable is set to a value other than 'not-used'.  The default is 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.

 

save command

 

capabilities

real command(s)

:candidate

commit

:writable-running

<none>

:startup

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

 

2.9.5  Using Notifications

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

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

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

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

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

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

 

2.9.6  Configuration Parameters That Affect Sessions

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

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

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

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

The --fixorder configuration parameter can be used to control XML PDU ordering.  If set to 'true', then the PDU will be reordered (if needed),to use the canonical order, according to the YANG specification.  If 'false', the order parameters are entered at the command line will be their NETCONF PDU order as well.  The default is 'true'.  To send the server incorrectly ordered data structures on purposes, set this parameter to 'false'.

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

The --with-defaults configuration parameter, or the $$with-defaults system variable, can be used to set the default value for the 'with-defaults' parameter extension for the NETCONF get, get-config, and copy-config protocol operations.  The default is 'none'.

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

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

The --bad-data configuration parameter, or the $$bad-data system variable, can be used to control how yangcli-pro handles parameter values that are known to be invalid, or usage of optional protocol operations that the current session does not support.  The default value is 'check'.  To use yangcli-pro in a testing mode to send the server incorrect data on purpose, set this parameter to 'warn' or 'ignore'.

2.9.7  Trouble-shooting NETCONF Session Problems

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

 

If the NETCONF session does not start:

 

Port 22

Port 830

Subsystem netconf /usr/sbin/netconf-subsystem

 

 

ps -alx | grep netconf

(look for 1 'netconfd-pro and N 'netconf-subsystem' -- 1 for

each active session)

 

 

If the NETCONF session stops responding:

 

 

If the NETCONF server is not accepting a certain command:

 

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

 

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

 

2.10  Automated Testing

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

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

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

The start-session command is usually used within the setup section for each session required in all of the tests within the test-suite.  The server must already be running. (TBD: start-server and stop-server commands will be available in a future release.)

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

2.10.1  Test Templates

The test suite file structure is shown below:

Image2

 

2.10.2  YANG File Defining Test Templates

 

 

module yumaworks-unit-test {

 

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

 

  prefix "ut";

 

  import yuma-types { prefix yt; }

  import yumaworks-extensions { prefix ywx; }

 

  organization "YumaWorks, Inc.";

 

  contact

    "Support <support@yumaworks.com>";

 

  description

    "This module contains data structures representing

     server unit tests for specific use cases and YANG modules

    ";

 

 

  revision 2012-09-03 {

    description

       "Initial version";

  }

 

  typedef response-type {

    type enumeration {

      enum none {

        description "Local command, no <rpc-reply> expected.";

      }

      enum ok {

        description "Expecting the <ok> reply.";

      }

      enum data {

        description "Expecting a data reply.";

      }

      enum error {

        description "Expecting an rpc-error reply.";

      }

    }

    description

      "The type of response expected from the server

       for this request.";

  }

 

  container unit-test {

     presence

      "If this node is present then the unit-test

       service is enabled.";

 

     list test-suite {

      description

        "A list of test-suites all run against a single server.";

 

      key name;

 

      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 {

            must "../result-type = 'error'";

            type string;

            description

              "The error-tag value expected if the result-type

               is 'error'.  If not set, then any error-tag

               value is acceptable.";

          }

 

          leaf result-error-apptag {

            must "../result-type = 'error'";

            type string;

            description

              "The error-app-tag value expected if the result-type

               is 'error'.  If not set, then any error-app-tag

               value is acceptable.";

          }

 

          leaf-list result-error-info {

            must "../result-type = 'error'";

            type yt:NcxName;

            description

              "The error-info element name expected if
              the result-type is 'error'.";

          }

 

          leaf command {

            type string;

            mandatory true;

            description "The yangcli command line string to use";

          }

 

          /****  !!!! TBD leave out for now !!!!

          anyxml rpc-reply-data {

            must "../result-type = 'data'";

            description

              "The contents of <rpc-reply> element that are

                expected to be returned in the reply.

                This element itself represents <rpc-reply>

                and any child nodes are the nodes returned

                by the server.";

           }

           ****/

         }  // list step

      }     // list test

    } // list test-suite

  } // container unit-test

 

 

}

 

 

 

2.10.3   RPC Reply Testing

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

 

2.10.4  Using Wildcards in Data Response Testing

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

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

 

_***_

 

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

 

Example Step:

 

 

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>

 

 

 

 

 

2.10.5  Example Test File

 

 

unit-test {

   test-suite first-test {

     description "A set of tests to validate NETCONF locking is working

          correctly."

 

     setup [
     # example variables

       $$server ="test1"

       $$admin = "andy"

       $$user1 = "andy"

       $$pass1 = "fredlow"

       $$user2 = "andy2"

       $$pass2 = "fredlow"

       $$testlog = "$HOME/tests/first-test.log"

       $$testmod = "test"

 

       # 2 sessions used in this test; server must already be running

       start-session session-A

       start-session session-B

     ]

 

     cleanup [

       stop-session session-A

       stop-session session-B

     ]

 

     run-test locks

 

     test locks {

 

       description "Use 2 sessions to test global locks on the

          candidate and running datastores. Expects the server

          to already be started with --module=test

          and --access-control=off."

 

       step 1 {

         description "session A locks the running config;

           needs to lock candidate too, but does not!"

         session-name session-A

         result-type ok

         command "lock target=running"

       }

 

       step 2 {

         description "session B tries to lock the running config"

         session-name session-B

         result-type error

         result-error-tag lock-denied

         result-error-info session-id

         command "lock target=running"

       }

 

       step 3 {

         description "session A tries to write to the target config"

         session-name session-A

         result-type ok

         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"

       }

 

     }

   }  

}

 

 

2.11  Call Home Server

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

Call Home for NETCONF over SSH Port Assignment:

 

Service Name:           netconf-ch-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.

 

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

 

2.11.2  Call Home Accept Session Procedure

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

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

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

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

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

 

 

 

 

 

2.12  Privilege Mode In YP-Shell Enable Mode

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

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

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

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

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

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

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

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

2.12.1  enable

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

 

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

 

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

 with-enable-mode true

 

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

 restrict-edit-mode true

 

abierman@andy-u14>

abierman@andy-u14> enable <TAB>

no-password  password

abierman@andy-u14> help enable full

 

enable

 Use 'enable' to enter enable mode for yp-shell.

 Use 'enable password' to configure the password.

 Use 'enable no-password' to remove the password.

 

 If a password has been set, then it will be required to

 enter enable mode.

 input

   choice pass

     leaf password [string]

       Configure the password.

 

     leaf no-password [empty]

       Remove the password.

 

 

abierman@andy-u14> enable

abierman@andy-u14#<TAB>

config  exit

 

abierman@andy-u14#

thue@andy-u14# config t

abierman@andy-u14(config)#

 

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

 

abierman@andy-u14(config)# do show running

nc:rpc-reply {

 data {

   t:int8.1 8

 }

}

 

abierman@andy-u14(config)# exit

abierman@andy-u14#

abierman@andy-u14# exit

abierman@andy-u14>

2.12.2  enable password

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

 

abierman@andy-u14> enable password=xxxxxxxxx

Re-enter password:

Enable password entered

 

abierman@andy-u14> enable

Enter password:xxxxxxxxx

 

abierman@andy-u14# config t

abierman@andy-u14(config)# exit

abierman@andy-u14# exit

 

abierman@andy-u14> enable

Enter password:xxxxxxxxx

 

abierman@andy-u14#

 

 

 

 

2.12.3  enable no-password

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

 

abierman@andy-u14>enable no-password

Enable password entered:

xxxxxxxxx

Enable password removed

 

abierman@andy-u14> enable

 

abierman@andy-u14# <TAB>

abierman@andy-u14# config exit

 

 

2.13   Privilege Mode In  YP-Shell Config Mode

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

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

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

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

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

 

2.13.1  Enable Privilege Mode

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

 

abierman@andy-u14> config t

abierman@andy-u14#
abierman@andy-u14#
enable-password

Enter string value for leaf <password>

abierman@andy-u14:enable-password#

Re-enter password:

Enable password entered

abierman@andy-u14#

 

 

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

 

abierman@andy-u14#

abierman@andy-u14# exit

abierman@andy-u14> config t

Enter password:

abierman@andy-u14#

 

 

Restart yp-shell after enable-password is set.  

 

abierman@andy-u14# exit

abierman@andy-u14> q

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

abierman@andy-u14> config t

Enter password:

abierman@andy-u14#

 

2.13.2  Disable Privilege Mode

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

 

abierman@andy-u14# no enable-password

Enable password removed

abierman@andy-u14# exit

 

abierman@andy-u14> config t

abierman@andy-u14#

abierman@andy-u14# exit

 

abierman@andy-u14> q

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

 

abierman@andy-u14> config t

abierman@andy-u14#

 

2.14  Command Reference

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

There may be more or less commands available, depending on the YANG modules actually loaded at the time.

The specific NETCONF capabilities needed are listed for each remote command.  No capabilities are ever needed for a local command.

It is possible that other servers will support protocol operations that netconfd-pro does not support.  If yangcli-pro has the YANG file available for the module, then it can be managed with the high level commands.  Low-level commands can still be used with external data (e.g., @mydatafile.xml).

Any YANG rpc statement can be used as a remote yangcli-pro command.  Refer to the server vendor documentation for details on the protocol operations, database contents, and notification definitions that they support.

 

2.14.1 action

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

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

 

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

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

 

create command

 

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

5

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

:candidate or :writable-running

 

Command Parameters:

 

Positive Response:

Negative Response:

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:

 

2.14.2  alias

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

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

There are 3 forms of the alias command:

  1. alias: display all command aliases in memory

  2. alias <name>: display the command alias with the specified name

  3. alias <name>=<value>: set the command alias with the specified name to the string value

Use the unset command to delete an alias.

alias command

 

Command type:

local

Default parameter:

var

Min parameters:

0

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:


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


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


> alias gc=get-config

 

Positive Response:

 

Negative Response:

 

Usage:

 

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

 

Added alias 'get-running'

 

>

 

 

2.14.3  aliases

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

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

 

There are 4 forms of the aliases command:

  1. aliases [show]: display all command aliases in memory

  2. aliases clear: clear all command aliases in memory

  3. aliases save [alias-filespec]: save the command aliases in memory in an '.aliases' file.

  4. aliases load [alias-filespec]: load the command aliases from an '.aliases' file into memory.

 

aliases command

 

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

 

Positive Response:

Negative Response:

Usage:

 

> aliases save

 

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

 

>

 

 

 

2.14.4  auto-test

The auto-test command is used to test edit operations and performance on a NETCONF server.

It can be used to generate pseudo-random <edit-config> operations for a specified data node. All configuration descendant nodes will be created.  Each time an edit is done the NETCONF “replace” operation is used.

If the :startup capability is not present then the edit will be saved to non-volatile storage by the server after each edit is completed.  Otherwise the auto-test command will automatically save all edits at the end of the test.

The target parameter is used to specify the database configuration node to use for the test.  This is a schema identifier string.  No key value predicates are allowed, just object names.

The iterations parameter specifies how many edits to complete.  If the candidate database is the server target, then an edit 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.

 

auto-test command

 

Command type:

local

Default parameter:

target

Min parameters:

1

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

 

 

Positive Response:

Negative Response:

Usage:

 

andy@myserver> auto-test target=/ptest1 iterations=100

 

[edits done on current session]

 

andy@myserver>

 

2.14.5  cache

The cache command is used to clear 1 or all entries from the YANG module cache.  There are 3 forms of this command:

    cache clear

    cache delete foo

    cache delete=foo revision=2014-05-22

 

cache command

 

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

2

Return type:

none

YANG file:

yancli-pro.yang

 

There are 3 forms of the cache command:

  1. cache clear:
    Clear the YANG module cache on disk.

  2. cache delete=module-name
    Delete the specified module name from the YANG
    module cache. All revisions will be deleted from the cache.

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

Command Parameters:
cache-action

Positive Response:

Negative Response:

Usage:

 

> show cache

yumaworks-event-filter@2014-02-09

ietf-netconf-notifications@2012-02-06

yuma-ncx@2013-09-23

yuma-types@2012-06-01

yuma-netconf@2013-09-28

t79@2014-06-19

yumaworks-types@2013-02-11

ietf-netconf-partial-lock@2009-10-19

test1a@2011-07-14

ietf-inet-types@2013-07-15

yuma-proc@2013-07-16

yuma-mysession@2013-10-05

test1c@2008-10-12

yumaworks-system@2014-05-27

yang-attributes@2013-02-18

ietf-netconf-with-defaults@2011-06-01

ietf-netconf-monitoring@2010-10-04

yuma-interfaces@2012-01-13

ietf-netconf-acm@2012-02-22

test1@2008-10-12

yuma-system@2013-07-15

ietf-yang-types@2013-07-15

yuma-app-common@2012-08-16

test1b@2008-10-12              <==============

test@2009-12-26

yuma-time-filter@2012-11-15

 

andy@myserver> cache delete=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


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

 


andy@myserver>
andy@myserver> cache clear

andy@myserver>

andy@myserver> show cache

 

andy@myserver> cache clear

 

empty cache: ./yumapro/.yangcli

andy@myserver>

 

 

Reference:

2.14.6  cd

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

cd command

 

Command type:

local

Default parameter:

dir

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yangcli-pro.yang

Command Parameters:

Positive Response:

Negative Response:

Usage:

 

> cd ~/modules

 

Current working directory is /home/andy/modules

 

> cd --dir=$YUMAPRO_HOME

 

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

 

>

 

 

2.14.7  clear

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

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

 

clear command

 

Command type:

local

Default parameter:

N/A

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

yangcli-pro.yang

 

Command Parameters: none

Positive Response:

Negative Response:

Usage:

 

Before command:

 

> cd ~/modules

 

Current working directory is /home/andy/modules

 

> cd --dir=$YUMAPRO_HOME

 

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

 

> clear

 

 

After command:

 

>

 

 

2.14.8  close-session

The close-session command is used to terminate the current NETCONF session.  A NETCONF server should always accept this command if it is valid, and not reject it due to access control enforcement or if the server is in notification delivery mode.  This command is provided by the NETCONF server, not yangcli-pro.

 

close-session command

 

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yuma-netconf.yang

 

Command Parameters:

Positive Response:

Negative Response:

Usage:

 

andy@myserver> close-session

 

RPC OK Reply 2 for session 10:

 

>

 

 

Reference:

2.14.9  commit

The commit command is used to save the edits in the <candidate> database into the <running> database.  If there are no edits it will have no effect. This command is provided by the NETCONF server, not yangcli-pro.

 

commit command

 

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

2

Return type:

status

YANG file:

yuma-netconf.yang

Capabilities needed:

:candidate

Capabilities optional:

:confirmed-commit

 

Command Parameters:

 

Positive Response:

Negative Response:

Usage:

 

andy@myserver> commit

 

RPC OK Reply 5 for session 10:

 

andy@myserver>

 

 

Reference:

 

 

2.14.10  config

The config command is used to enter configuration mode.  It can only be used if the current session is connected to a NETCONF server.  The configuration source is given as the only parameter.  The 'terminal' is the only supported configuration source at this time.

 

config command

 

Command type:

local

Default parameter:

term

Min parameters:

1

Max parameters:

1

Return type:

none (enter configuration mode)

YANG file:

yangcli-pro.yang

 

Command Parameters:

Positive Response:

Negative Response:

Usage:

 

andy@myserver>  config term

 

andy@myserver#

 

 

2.14.11  config-commit

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

Config-commit command

 

Command type:

local

Default parameter:

0

Min parameters:

0

Max parameters:

0

Return type:

none

YANG file:

yangcli-pro.yang

 

Command Parameters:

Positive Response:

Negative Response:

Usage:

 

andy@myserver>  config term

 

andy@myserver#  config-commit

2.14.12 connect

The connect command is used to start a session with a NETCONF server.

This command can be used in 3 forms:

  1. Default session: All required connection parameters are specified and the default session is used. The parameters are only saved as defaults for the next connect command. They are not saved in any template.

  2. Named Session: Only the --session-name parameter is used. The specified session-cfg template for all connection parameters.

  3. Modified Named Session: The --session-name parameter is used and additional parameters can also be specified, which will cause the session-cfg template to be updated if the connection is successful.

 

If there already is a NETCONF session active, then an error message will be printed and the command will not be executed.

connect command

 

Command type:

remote

Default parameter:

server

Min parameters:

1

Max parameters:

10

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

 

Positive Response:

Negative Response:

Usage:

 

> connect myserver user=andy password=yangrocks

 

<startup screen printed>

 

andy@myserver>

 

2.14.13  copy-config

The copy-config command is used to copy one entire NETCONF database to another location.

Not all possible parameter combinations will be supported by every server.  In fact, the NETCONF protocol does not require any parameters to be supported unless the :startup or :url capabilities is supported by the server.

If the server supports the :startup capability, then it must support the following operation:


andy@myserver> copy-config source=running target=startup

 

This is the standard way to save a snapshot of the current running configuration in non-volatile storage, if the server has a separate startup database.  If not, the server will automatically save any changes to the running configuration to non-volatile storage.

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

 

copy-config command

 

Command type:

remote

Default parameter:

none

Min parameters:

2

Max parameters:

3

Return type:

status

YANG file:

yuma-netconf.yang

Capabilities needed:

none

Capabilities optional:

:candidate
:startup
:url
:with-defaults

 

Command Parameters:

Positive Response:

 

Negative Response:

Usage:


andy@myserver>
copy-config source=candidate

Enter a number of the selected case statement:

 

 1: case candidate:

      leaf candidate

 2: case running:

      leaf running

 3: case startup:

      leaf startup

 4: case url:

      leaf url

 

Enter choice number [1 - 4]:

andy@myserver:copy-config> 4

 

Filling optional case /copy-config/input/target/config-source/url

Enter string value for leaf <url>:

andy@myserver:copy-config> file://configs/myconfig.xml

 

RPC OK Reply 12 for session 10:

andy@myserver>

 

Reference:

 

2.14.14  create

The create command is a high-level <edit-config> operation.  It is used to create some new  nodes in the default target database.

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

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

 

create command

 

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

5

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

:candidate or :writable-running

 

Command Parameters:

System Variables:

Positive Response:

Negative Response:

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:

 

2.14.15  create-subscription

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

The :notification capability must be supported by the server to use this command.

Unless the :interleave capability is also supported by the server, then only the close-session command can be used while notifications are being delivered.

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

create-subscription command

 

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

4

Return type:

status

YANG file:

notifications.yang

Capabilities needed:

:notification

Capabilities optional:

:interleave

 

Command Parameters:

Positive Response:

Negative Response:

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:

2.14.16  device-cfg

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

There are 3 sub-commands:

 

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

 

device-cfg command

 

Command type:

local

Default parameter:

show

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

Capabilities needed:

none

 

Command Parameters:

Positive Response:

Negative Response:


andy@myserver>
device-cfg save device-A

 

Saving current device as 'device-A'

 

andy@myserver>

 

 

2.14.17  devices-cfg

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

There are 4 sub-commands:

 

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

devices-cfg command

 

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:

Positive Response:

Negative Response:


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

 

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

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

 

session-A>

 

2.14.18  delete

The delete command is a high-level <edit-config> operation.  It is used to delete an existing subtree in the default target database.

A target node is specified, and then any missing key leafs (if any) within the data structure are filled in.  If the target is a leaf-list, then the user will be prompted for the value of the leaf-list node to be deleted.

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

 

delete command

 

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:

System Variables:

 

Positive Response:

 

Negative Response:

Usage:


andy@myserver>
delete /nacm/rules/data-rule \

(user will be prompted to fill in the data-rule 'name' key leaf)

 

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:

 

2.14.19  delete-config

The delete-config command is used to delete an entire NETCONF database.

Not all possible target parameter values will be supported by every server.  In fact, the NETCONF protocol does not require that any database be supported by this operation.

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

If the server supports the :url capability, then it may support deletion of local file databases in this manner.:

 

delete-config command

 

Command type:

remote

Default parameter:

none

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yuma-netconf.yang

Capabilities needed:

none

Capabilities optional:

:candidate
:startup
:url

 

Command Parameters:

 

Positive Response:

Negative Response:

Usage:


andy@myserver>
delete-config target=startup

 

RPC OK Reply 17 for session 10:

 

andy@myserver>

 

Reference:

 

2.14.20  discard-changes

The discard-changes command is used to delete any edits that exist in the <candidate> database, on the NETCONF server.  The server will only accept this command if the :candidate capability is supported.  If the <candidate> database is locked by another session, then this request will fail with an 'in-use' error.

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

 

discard-changes command

 

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yuma-netconf.yang

Capabilities needed:

:candidate

 

Command Parameters: none

Positive Response:

Negative Response:

Usage:


andy@myserver>
discard-changes

 

RPC OK Reply 18 for session 10:

 

andy@myserver>

 

Reference:

2.14.21  edit-config

The edit-config command allows a subset of a NETCONF database on the server to be changed.

If the server supports the :url capability, then it may support editing of local file databases.

If the server supports the :candidate capability, then it will allow edits to the <candidate> database.

If the server supports the :writable-running capability, it will support edits to the <running> database.

It is not likely that a server will support the <candidate> and <running> database as targets at the same time, since changes to the <running> configuration would not be reflected in the <candidate> database, while it was being edited by a different session.

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

edit-config command

 

Command type:

remote

Default parameter:

none

Min parameters:

2

Max parameters:

5

Return type:

status

YANG file:

yuma-netconf.yang

Capabilities needed:

:candidate or :writable-running

Capabilities optional:

:url
:rollback-on-error
:validate

 

Command Parameters:

 

Positive Response:

Negative Response:

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:

 

2.14.22  elif

The elif command is used to define a conditional command block after an if command.

This command must be entered within the same script as the if command, when used within a script.  It can be used zero or more times within an if command sequence.

The expr parameter is used to specify the XPath expression to test if the elif conditional block is true or false.  A false block will be skipped and a true block will be executed.  The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode.  This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.

The docroot parameter (if present) specifies the XML document that the 'expr' parameter should be evaluated against.  This is optional, since only XPath path expressions need to refer to a document.

Even if the 'expr' expression is true, the conditional block will only be executed if no conditional block in the if command sequence has already been executed.

 

if command

....

[elif command]

....

[elif-command]

...

[else command]

...

end command

 

elif command

 

Command type:

local

Default parameter:

expr

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

Positive Response:

Negative Response:

 

Usage:


andy@myserver>
elif expr='$x > 4'

 

andy@myserver>

 

 

2.14.23  else

The else command is used to define a final conditional command block after an if command.

This command must be entered within the same script as the if command, when used within a script.  It can be used zero or one time within an if command sequence.

The conditional command block following the else command will only be executed if no conditional block has already been executed in the same if command sequence.

 

if command

....

[elif command]

....

[elif-command]

...

[else command]

...

end command

 

else command

 

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters: none

Positive Response:

Negative Response:

Usage:


>
else

 

>

2.14.24  enable

The enable command is used to enter enable mode.

enable command

 

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

1

Return type:

none

YANG file:

yangcli-pro.yang

 

Command Parameters:

2.14.25  end

The end command is used to terminate a conditional command block after an if command block, or after a 'while' command.

This command must be entered within the same script as the if or while command, when used within a script.

if command

....

[elif command]

....

[elif-command]

...

[else command]

...

end command

while command

....

end command

end command

 

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters: none

Positive Response:

Negative Response:

Usage:


>
end


>

2.14.26  eval

The eval command is used to evaluate an XPath expression..

The expr parameter is used to specify the XPath expression to evaluate.   This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.

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.

 

eval command

 

Command type:

local

Default parameter:

expr

Min parameters:

1

Max parameters:

2

Return type:

data

YANG file:

yangcli-pro.yang

Command Parameters:

Positive Response:

Negative Response:

Output:

Usage:


session1>
$x = eval '$x + 1'

 

session1> $sysname = eval '//sysName' docroot=$backup

 

2.14.27  eventlog

The eventlog command is used to view or clear all or part of the notification event log.  This log will be empty if no well-formed notifications have been received from any server.

The eventlog show command is used to display some event log entries.

The eventlog clear command is used to delete some event log entries.

If no parameters are entered, it is the same as entering 'eventlog show=-1'.

The event log is not automatically emptied when a session terminates, in case the session was dropped unexpectedly.  New entries will be appended to the event log as new sessions and/or subscriptions are started.

 

eventlog command

 

Command type:

local

Default parameter:

show

Min parameters:

0

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

System Variables:

Positive Response:

Negative Response:

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>

 

>

2.14.28  exit

The exit command is used to exit configuration editing mode or exit the current editing sub-mode if the configuration context node is not the root.

If the $$config-edit-mode system parameter is set to 'level', then exiting from a sub-mode to the top-level configuration mode will cause any pending edits to be applied to the current session.  

If the $$config-edit-mode system parameter is set to 'mode', then exiting from the top-level configuration mode will cause any pending edits to be applied to the current session.

There are no parameters for this command.

 

exit command

 

Command type:

local

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

none (prompt is changed)

YANG file:

yangcli-pro.yang

 

Command Parameters:

System Variables:

Positive Response:

Negative Response:

Usage:

 

andy@myserver# exit

 

andy@myserver>

 

 

 

2.14.29  fill

The fill command is used to create a user variable for reuse in other commands.

It is used in an assignment statement to create a variable from various sources.

If it is not used in an assignment statement, then the result will not be saved, so the command will have no effect in this case.

The value contents will mirror the subtree within the NETCONF database indicated by the target parameter.  If not completely provided, then missing descendant nodes will be filled in interactively, by prompting for each missing node.

 

fill command

 

Command type:

local

Default parameter:

target

Min parameters:

2

Max parameters:

3

Return type:

data

YANG file:

yangcli-pro.yang

 

Command Parameters:

 

System Variables:

Positive Response:

Negative Response:

Output:

Usage:


> $my-interface = fill \

target=/interfaces/interface optional

(user will be prompted to fill in all fields

of the <interface> element)

  OK

 

>

2.14.30  get

The get command is used to retrieve data from the server. This command is provided by the NETCONF server, not yangcli-pro.

get command

 

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

4

Return type:

data

YANG file:

yuma-netconf.yang

 

Command Parameters:

 

Positive Response:

Negative Response:

Output:

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:

2.14.31  get-config

The get-config command is used to retrieve configuration data from the server.

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

 

get-config command

 

Command type:

remote

Default parameter:

none

Min parameters:

1

Max parameters:

7

Return type:

data

YANG file:

yuma-netconf.yang

 

Command Parameters:

 

Positive Response:

Negative Response:

Output:

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:

2.14.32  get-locks

The get-locks command is a high-level wrapper for the <lock> operation.  It is used to lock all the databases (<running> plus <candidate> and/or <startup> if they exist).  If all the locks cannot be obtained, then release all the locks that were obtained (all-or-nothing).

The entire time to wait for a lock in use is set with the lock-timeout parameter.

The retry-interval parameter is used when the <lock> operation fails with a 'lock-denied' error-tag, because some other session has the lock.

If the <candidate> cannot be locked for another reason, a <discard-changes> operation will be attempted to clear any leftover edits.

Normally, the errors received while attempting to acquire locks are not printed to the log, like normal commands.  Instead, if $$log-level system parameter is set to 'debug2' or 'debug3', then these messages will be printed.

 

get-locks command

 

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

3

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

Positive Response:

Negative Response:

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>

 

 

 

 

2.14.33  get-my-session

The get-my-session command is used to retrieve the session customization parameters from the server.  It is only supported by the netconfd-pro server. This command is provided by the NETCONF server, not yangcli-pro.

The session indent amount, session line size, and default behavior for the with-defaults parameter can be controlled at this time.

get-my-session command

 

Command type:

remote

Default parameter:

none

Min parameters:

0

Max parameters:

0

Return type:

data

YANG file:

mysession.yang

Capabilities needed:

none

 

Command Parameters:

Positive Response:

Negative Response:

Output:


session1
> get-my-session

RPC Data Reply 25 for session 10:

rpc-reply {

   data {

     indent 3

     linesize 72

     with-defaults report-all

   }

}

 

session1>

2.14.34  get-schema

The get-schema command is used to retrieve data model definition files from the server.  This is part of the NETCONF monitoring draft.  The server must support the :schema-retrieval capability to use this command.

If the server reports a module or module version that yangcli-pro cannot find in its local module library, then an error message will be printed.  The get-schema command can then be used to retrieve the missing module from the server.

The ietf-netconf-monitoring.yang module includes a list of the schema supported by the server, which can be retrieved from a server that supports this module, such as netconfd-pro.

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

 


session1> sget /netconf-state/schemas

 

The preceding command will return a <schemas> container with several <schema> child nodes.  One example entry is shown below:

 


schemas {

   schema system 2009-06-04 YANG {

identifier system

version 2009-06-04

format YANG

namespace http://netconfcentral.org/ns/yuma-system

location NETCONF

   }

}

 

The <identifier>, <version> and <format> leafs can be used as the corresponding parameter values for the get-schema command.  See the example below for more details.

 

get-schema command

 

Command type:

remote

Default parameter:

none

Min parameters:

3

Max parameters:

3

Return type:

data

YANG file:

ietf-netconf-monitoring.yang

Capabilities needed:

:schema-retrieval

 

Command Parameters:

Positive Response:

Negative Response:

Output:

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

 

  OK

 

session1>

 

Reference:

 

2.14.35  get-walk

This command walks the entries of a YANG list using the netconfd-pro <get-bulk> operation. This command will send <get-bulk> requests to the server until the entire list has been retrieved or the user quits the walk.

If the yumaworks-getbulk YANG module is not supported by  the server then this command will not be attempted.

If the program is in interactive mode, then after each retrieval, the user will be prompted to continue or quit the walk. In batch mode the entries will be displayed until the walk terminates.

The server will wait the normal 'timeout' period aftereach request. It will display each response and check it for 'last-keys' data.  If present, these values will  be used for the 'last-keys' parameter in the next request  If not present, then the walk will end.

The walk will be done on the YANG list specified by the 'list-target' parameter. Each retrieval will request 1 or more entries, based on the 'count' parameter. The data returned can be filtered according to the 'content', 'depth', 'with-defaults', and 'list-test' parameters, which as passed to the <get-bulk> operation each time.  

The list-target parameter is used to specify that YANG list that will be retrieved.

The list-test parameter allows an XPath boolean expression to be used to test each list-target entry. It is used to select only 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.

 

get-walk command

 

Command type:

remote

Default parameter:

none

Min parameters:

1

Max parameters:

7

Return type:

data

YANG file:

yangcli-pro.yang

Capabilities needed:

  Yumaworks-getbulk.yang

 

Mandatory Parameters:

Optional Parameters:

 

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>

 

2.14.36  group

The group command is used to manage the session groups. Refer to the 'Using Group Configuration' section for details on the format of this file.

There are 7 sub-commands:

 

Refer to the section on “Netconf Group Configuration” for more details on using group configuration.

 

group command

 

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:

 

Positive Response:

Negative Response:

 

 

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

 

 

2.14.37  help

The help command is used to print documentation to STDOUT.

If no session is active, then only help for the local commands and the standard NETCONF commands will be available.

If a NETCONF session is active, then the documentation shown will attempt to exactly match the capabilities of the server.

If additional (i.e., augment generated) parameters are available, then they will be shown in the command output.  If the server does not implement some parameters (e.g., feature not supported) then these parameters will not be shown in the command output.

If the server has modified an object with deviation statements, then the altered object will be shown.

The ncx:hidden extension suppresses  the help command.  If this extension is present in the YANG definition associated with the request, then no help will be available for that object or command.

 

help command

 

Command type:

local

Default parameter:

command

Min parameters:

3

Max parameters:

3

Return type:

data

YANG file:

ietf-netconf-monitoring.yang

Capabilities needed:

:schema-retrieval

 

Command Parameters:

Positive Response:

Negative Response:

Usage:


> help help full

 

help

  Print the yangcli-pro help text

  input

     default parameter: command

     choice helptype

        leaf command [NcxIdentifier]

           Show help for the specified command,

           also called an RPC method

 

        leaf commands [empty]

           Show info for all local commands

 

        leaf notification [NcxIdentifier]

           Show help for the specified notification

 

        leaf object [NcxIdentifier]

           Show help for the specified object

 

        leaf type [NcxIdentifier]

           Show help for the specified type

 

     choice help-mode

        leaf brief [empty]

           Show brief help text

 

        leaf normal [empty]

           Show normal help text

 

        leaf full [empty]

           Show full help text

 

andy@myserver> help notification sysConfigChange

 

notification sysConfigChange

  Generated when the <running> configuration is changed.

  leaf userName [string]

 

  leaf sessionId [SessionId]

     range: 1..max

 

  leaf remoteHost [ip-address]

 

  leaf target [string]

 

  leaf operation [EditOperationType] [d:merge]

     enum values: merge replace create delete

 

andy@svnserver>

2.14.38  history

The history command is used to show, clear, load, or save the command line history buffer.

Use the recall command to recall a previously executed command line, after getting the line number from the history show command.

All lines entered will be saved in the history buffer except an ncx:password value entered in parameter mode.

When yangcli-pro starts, the command line history buffer is empty.  If a history file was previously stored with the history save command, then it can be recalled into the buffer with the history load command.

The history clear command is used to delete the entire command line history buffer.

The numbering sequence for commands, starts from zero and keeps incremented until the program exits.  If the history buffer is cleared, then the number sequence will continue, not start over at zero.

 

history command

 

Command type:

local

Default parameter:

show

Min parameters:

0

Max parameters:

2

Return type:

data

YANG file:

yangcli-pro.yang

 

Command Parameters:


> history load
 same as:
> history load=$HOME/.yangcli-pro_history


> history save
 same as:
> history save=$HOME/.yangcli-pro_history

Positive Response:

Negative Response:

Usage:


> history show=3 full

 [27] 2009-07-04 09:25:34 sget /system --nofill

 [28] 2009-07-04 09:34:17 @myconfig = get-config source=running

 [29] 2009-07-04 09:43:54 history show=3 full

 

> history save=~/my-temp-history-file

  OK

>

2.14.39  if

The if command is used to start a conditional command block.

The expr parameter is used to specify the XPath expression to test if the if conditional block is true or false.  A false block will be skipped and a true block will be executed.  The command prompt will contain the string '[F]' while inside a false conditional block in interactive mode.  This expression string should be entered with quotes to avoid misinterpreting any whitespace or special characters.

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 command

 

if command

 

Command type:

local

Default parameter:

expr

Min parameters:

1

Max parameters:

2

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

Positive Response:

Negative Response:

 

Usage:


andy@myserver>
if "$sysname = 'localhost'"

 

andy@myserver>

 

2.14.40  insert

The insert command is used to insert or move YANG list or leaf-list data into a NETCONF database.  It is a high level command with utilizes the YANG 'insert' extensions to the NETCONF <edit-config> operation.

 

insert command

 

Command type:

remote

Default parameter:

target

Min parameters:

2

Max parameters:

7

Return type:

status

YANG file:

yangcli-pro.yang

 

Command Parameters:

System Variables:

Positive Response:

Negative Response:

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:

 

 

2.14.41  kill-session

The kill-session command is used to terminate a NETCONF session (other than the current session).  All NETCONF implementations must support this command.  It is needed sometimes to unlock a NETCONF database locked by a session that is idle or stuck.

If the lock command returns a 'lock-denied' <error-tag>, it will also include an <error-info> field called <session-id>.  This is the session number that currently holds the requested lock.  The same value should be used for the session-id parameter in this command, to terminate the session will the lock.

Note: this is an extreme measure, which should be used with caution.

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

 

kill-session command

 

Command type:

remote

Default parameter:

target

Min parameters:

1

Max parameters:

1

Return type:

status

YANG file:

yuma-netconf.yang

 

Command Parameters:

Positive Response:

Negative Response:

Usage:


andy@myserver>  
kill-session session-id=11

 

RPC OK Reply 27 for session 10:

 

andy@myserver>

 

Reference:

2.14.42  list

This list command is used to display the commands, objects, and oids (object identifiers) that are available at the time.

The list commands command will display the local commands and the remote commands that are available in the current NETCONF session, or which have been loaded with the mgrload command.

The list files command will display the data files that are in the current data search path.  The module parameter has no affect in this mode.

The list modules command will display the YANG files that are in the current YANG module search path.  The module parameter has no affect in this mode.

The list objects command will display the top-level objects that are currently available in the current NETCONF session, or which have been loaded with the mgrload command.

The list oids command will display the object identifiers of the  top-level objects that are currently available in the current NETCONF session, or which have been loaded with the mgrload command.

The list scripts command will display the script files that are in the current script search path.  The module parameter has no affect in this mode.

 

list command

 

Command type:

local

Default parameter:

none

Min parameters:

1

Max parameters:

6

Return type:

data

YANG file:

yangcli-pro.yang

 

Command Parameters:

 

Positive Response:

 

Negative Response:

 

Usage:


andy@myserver>  
list objects full module=test

 

  test:instance1

  test:instance2

  test:leafref1

  test:leafref2

  test:test1

  test:test2

  test:test3

  test:idtest

  test:musttest

  test:anyxml.1

  test:binary.1

  test:bits.1

  test:boolean.1

  test:empty.1

  test:enumeration.1

  test:identityref.1

  test:instance-identifier.1

  test:instance-identifier.2

  test:int8.1

  test:int16.1

  test:int32.1

  test:int64.1

  test:leafref.1

  test:leafref.2

  test:string.1

  test:uint8.1

  test:uint16.1

  test:uint32.1

  test:uint64.1

  test:dec64.1

  test:dec64.2

  test:dec64.3

  test:union.1

  test:container.1

  test:container.2

  test:list.1

  test:choice.1

  test:xpath.1

 

andy@myserver>

 

2.14.43  load

The load command is used to load a YANG module into the server.

This command is only supported by the netconfd-pro server.

The YANG files must be available in the module search path for the server.

Refer to the netconfd-pro configuration section for more details on adding new YANG modules into the server.

After using this command, the mgrload command may also be needed to keep the current session synchronized with the server.

Use the revision parameter to load a specific revision of a module.

The server will return the revision date of the module that was loaded (or already present).

 

load command

 

Command type:

remote

Default parameter:

module

Min parameters:

1

Max parameters:

3

Return type:

data

YANG file:

yuma-system.yang

 

Command Parameters:

Positive Response:

Negative Response:

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>

2.14.44  lock

The lock command is used to request a global lock on a NETCONF database.  It is used, along with the unlock command, to obtain exclusive write access to the NETCONF server.

The scope of a lock command is the lifetime of the session that requested the lock.  This means that if the session that owns the lock is dropped for any reason, all the locks it holds will be released immediately by the server.

The use of database locks is optional in NETCONF, but it must be implemented by every server.  It is strongly suggested that locks be used if multiple managers are likely to log into the particular NETCONF server.

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

One or more locks may be needed to execute a transaction safely:

lock command

 

<

Command type:

remote

Default parameter:

none