../_images/logo.png

YumaPro CLI Reference

The YumaPro SDK programs support many configuration parameters. Many of the parameters are shared by multiple programs. They are documented in the next section..

The configuration parameters for each YumaPro program are also documented here, each in their own section.

Note

The YANG snippets shown have the "description" removed and contents moved to regular text.

Common CLI Parameters

--address

The --address parameter specifies the IP address of the main server. It is used by subsystem applications that are not on the same local system as the main server.

leaf address {
    type inet:ip-address;
}

Syntax

ip-address

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

combo-app sil-sa-app

Example:

sil-sa-app --address=192.168.1.25

--alt-names

The --alt-names parameter specifies whether the server will recognize the ywx:alt-name YANG extension which allows an alternate name to be used for a node in the database. This defines the alternate name search mode that should be used when resolving YANG node names in leafs or leaf-lists using the UrlPath data type.

  • If 'true' then nodes with an 'alt-name' defined will be considered a match if the YANG name or the alternative name matches the search string.

  • If 'false' then only the YANG node name will be used in node name searches.";

The real name will be checked before the alt-name if it is used, so the alt-name extension cannot be used if there is a node already in the system with a real name that matches the alt-name.

leaf alt-names {
  type ywt:AltNameMode;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --alt-names=false

--binary-display-maxlen

The --binary-display-maxlen parameter specifies the maximum number of bytes to display when dumping the contents of a binary value. Normally a message will be displayed showing the name and length.

If this parameter is set to a value greater than zero then a standard 8-byte per line hex dump of the binary type will also be displayed for a maximum number of bytes set by this parameter.

leaf binary-display-maxlen {
  type uint32;
  default 0;
}

Syntax

uint32

Default:

0

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro, netconfd-pro

Example:

netconfd-pro --binary-display-maxlen=100

--ca

The --ca parameter specifies the gNMI server CA certificate file. The path to the CA certificate should be absolute.

--ca parameter

Syntax

filespec

Default:

none

Min Allowed:

1

Max Allowed:

1

Supported by:

ypgnmi-app

Example:

ypgnmi-app --ca=/tmp/ca.crt

--cert

The --cert parameter specifies the gNMI server certificate file. The path to the certificate should be absolute.

--cert parameter

Syntax

filespec

Default:

none

Min Allowed:

1

Max Allowed:

1

Supported by:

ypgnmi-app

Example:

ypgnmi-app --cert=/tmp/cert.crt

--config

The --config parameter specifies the name of a YumaPro configuration file that contains more parameters to process, in addition to the CLI parameters. The --no-config parameter can be used instead of this parameter to force the server to skip loading the default config file if it is present.

For netconfd-pro, this parameter is ignored if the --no-nvstore parameter is used.

Refer to the Configuration Files section for details on the format of this file.

leaf config {
  type string;
}

Syntax

string: complete file specification of the text file to parse for more parameters.

Default:

/etc/yumapro/<program-name>.conf

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro
netconfd-pro
yangdiff-pro
yangdump-pro

Example:

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

--datapath

The --datapath parameter specifies the directory search path to use while searching for data files. It consists of a colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.

This parameter overrides the $YUMAPRO_DATAPATH environment variable, if it is present.

leaf datapath {
  type yt:NcPathList;
}

Syntax

string: list of directory specifications

Default:

$YUMAPRO_DATAPATH environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

yangcli-pro --datapath=”~/work2:~/data”

--deviation

The --deviation parameter is a leaf-list of modules that should be loaded automatically when the program starts, as a deviation module. In this mode, only the deviation statements are parsed and then made available later when the module that contains the objects being deviated is parsed.

~/some/path ==> <my-home-dir>/some/path

~fred/some/path ==> <fred-home-dir>/some/path

$workdir/some/path ==> <workdir-env-var>/some/path

The deviations must be known to the parser before the target module is parsed.

This parameter is used to identify any modules that have deviation statements for the set of modules being parsed (e.g., --module and --subtree parameters).

A module can be listed with both the --module and --deviation parameters, but that is not needed unless the module contains external deviations. If the module only contains deviations for objects in the same module, then the --deviation parameter does not need to be used.

The program will attempt to load each module in deviation parsing mode, in the order the parameters are entered.

For the netconfd-pro program, If any modules have fatal errors then the program will terminate.

For the yangdump-pro and yangcli-pro programs, each module will be processed as requested.

Deviations are applied as patches to the target module. Since they are not identified in the target module at all (ala imports), they have to be specified explicitly, so they will be correctly processed.

If this string represents a filespec, ending with the '.yang' or '.yin' extension, then only that file location will be checked.

If this string represents a module name, then the module search path will be checked for a file with the module name and the '.yang' or '.yin' extension.

If this string begins with a '~' character, then a username is expected to follow or a directory separator character. If it begins with a '$' character, then an environment variable name is expected to follow.

leaf-list deviation {
    type yt:NcModuleSpec;
}

Syntax

module name or filespec

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro yangcli-pro yangdump-pro

Example:

netconfd-pro --deviation=test1_deviations

--feature-disable

The --feature-disable parameter directs all programs to disable a specific feature.

This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name, e.g.,

test:feature1

It is an error if a --feature-enable and --feature-disable parameter specify the same feature.

Parameters for unknown features will be ignored.

leaf-list feature-disable {
  type yt:FeatureSpec;
}

Syntax

formatted string (module:feature

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangcli-pro yangdiff-pro yangdump-pro netconfd-pro

Example:

netconfd-pro --feature-disable=test:feature1

--feature-enable

The --feature-enable parameter directs all programs to enable a specific feature.

This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name, e.g.,

test:feature1

It is an error if a --feature-disable and --feature-enable parameter specify the same feature.

Parameters for unknown features will be ignored.

leaf-list feature-enable {
  type yt:FeatureSpec;
}

Syntax

formatted string (module:feature

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangcli-pro yangdiff-pro yangdump-pro netconfd-pro

Example:

netconfd-pro --feature-enable=test:feature1

--feature-enable-default

The --feature-enable-default parameter controls how netconfd-pro will enabled YANG features in modules by default.

If 'true', then by default, features will be enabled.

If 'false', then by default, features will be disabled.

If a --feature-enable or --feature-disable parameter is present for a specific feature, then this parameter will be ignored for that feature.

leaf feature-enable-default {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro yangdiff-pro yangdump-pro netconfd-pro

Example:

netconfd-pro --feature-enable-default=false

--fileloc-fhs

The --fileloc-fhs parameter is used to control where data files are kept. It is used by the following programs

  • netconfd-pro

  • ypgrpc-go-app

  • ypgnmi-go-app

leaf fileloc-fhs {
   type boolean;
   default false;
}

Syntax

boolean (true or false)

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro ypgnmi-app

Example:

netconfd-pro --fileloc-fhs=true

fileloc-fhs behavior for netconfd-pro

The --fileloc-fhs parameter is used to control where the server keeps its data files.

If -fileloc-fhs=true:

if true, then the server should use Filesystem Hierarchy Standard (FHS) directory locations to create and store server data. May need to run as root..

The FHS server log file will be created by default unless the 'log' parameter is used, then that location will be used instead. If the 'no-log' parameter is present then no log will be created.

The FHS audit log file will be created by default unless the 'audit-log' parameter is used, then that location will be used instead. If the 'no-audit-log' parameter is present then no audit log will be created.

server log

/var/log/netconfd-pro/server.log

audit log

/var/log/netconfd-pro/audit.log

config file

/var/lib/netconfd-pro/startup-cfg.xml

TXID file

/var/lib/netconfd-pro/startup-cfg-txid.txt

backups

/var/lib/netconfd-pro/backups/backup1.xml

PID file

/var/run/netconfd-pro/netconfd-pro.pid

AF socket

/var/run/netconfd-pro/ncxserver.sock

If --fileloc-fhs=false:

If false then the server will use $HOME/.yumapro and other file locations to store server data.

File Type

Example

server log

STDOUT; no server log created by default

no output at all if --no-log used

audit log

STDOUT; no audit log created by default

config file

$HOME/.yumapro/startup-cfg.xml

TXID file

$HOME/.yumapro/startup-cfg-txid.txt

backups

$HOME/.yumapro/backups/backup1.xml

PID file

$HOME/.yumapro/netconfd-pro.pid

AF socket

/tmp/ncxserver.sock

fileloc-fhs behavior for ypgnmi-go-app and ypgrpc-go-app

The --fileloc-fhs parameter specifies whether the ypgnmi-app should use Filesystem Hierarchy Standard (FHS) directory locations to create, store and use data and files. May need to run as root. If false then the server will use $HOME/.yumapro and other file locations to store application data and to access the netconfd-pro files.

--help

The --help parameter causes program help text to be printed, and then the program will exit instead of running as normal.

This parameter can be combined with the --help-mode parameter to control the verbosity of the help text. Use --brief for less, and --full for more than the normal verbosity.

This parameter can be combined with the --version parameter in all programs. It can also be combined with the --show-errors parameter in yangdump-pro.

The program configuration parameters will be displayed in alphabetical order, not in schema order.

leaf help {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --help

--help-mode

The --help-mode parameter is used to control the amount of detail printed when help text is requested in some command. It is always used with another command, and makes no sense by itself. It is ignored unless used with the --help parameter.

choice help-mode {
  default normal;
  leaf brief {
    type empty;
  }
  leaf normal {
    type empty;
  }
  leaf full {
    type empty;
  }
}

Syntax

choice of 3 empty leafs

--brief
--normal
--full

Default:

normal

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --help --brief

  • default choice: normal

  • choice help-mode

    • brief

      • type: empty

      • This parameter specifies that brief documentation mode should be used.

    • normal

      • type: empty

      • This parameter specifies that normal documentation mode should be used.

    • full

      • type: empty

      • This parameter specifies that full documentation mode should be used.

--home

The --home parameter over-rides the $HOME environment variable, if it is set. File searches that use the user's home directory will use this path specification instead.

leaf home {
    type string { length "1..max"; }
}

Syntax

string: pathspec

Default:

$HOME environment value

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --home=/var/run/netconfd-pro

--indent

The --indent parameter specifies the number of spaces that will be used to add to the indentation level, each time a child node is printed during program operation.

leaf indent {
  type yt:IndentType;
}

Syntax

uint32 (0 .. 9)

Default:

2

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --indent=4

--insecure-ok

The --insecure-ok parameter specifies if insecure NETCONF over TLS should be allowed. If true then X.509 certificates will be accepted even if they cannot be verified. Used for debugging only!

This parameter is only available if the image was built with the DEBUG=1 parameter.

leaf insecure-ok {
    type boolean;
    default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --insecure-ok=true

--library

The --library parameter specifies the name of a SIL-SA library.

  • This can be a module name or a bundle name.

  • Multiple values are allowed

  • If this parameter is present at all in sil-sa-app or combo-app, then registration requests will only be done for the specified libraries.

  • If this parameter is not present, then the application will attempt to find a SIL-SA library for every module and bundle advertised by the server.

leaf-list library {
    type nt:NcxName;
}

Syntax

NcxName (string)

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

combo-app sil-sa-app

Example:

sil-sa-app --library=interface-bundle --library=diag-bundle

--log

The --log parameter specifies a file name to be used for logging program messages, instead of STDOUT. It can be used with the optional parameters below to control how the log file is written. (See also --log-syslog which directs message output to a syslog daemon.)

If this string begins with a '~' character, then a username is expected to follow or a directory separator character. If it begins

with a '$' character, then an environment variable name is expected to follow.

If this parameter is used on the command line then the --log-append parameter must also be present on the command line if append mode is desired.

leaf log {
  type string;
}

Syntax

string: log file specification

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --log=~/server.log&

--log-append

The --log-append parameter specifies that the existing log file (if any) should be appended , instead of deleted. It is ignored unless the --log parameter is present.

leaf log-append {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --log-append --log=~/server.log&

--log-backtrace

The --log-backtrace parameter specifies that stack frame trace information be appended to selected log messages. By default, this information will be included in all enabled output streams (STDOUT, STDERR, log file, and/or syslog). Such output may be further modified by inclusion of any of the log-backtrace-xxx commands below.

leaf log-backtrace {
  type uint32 {
    range "0 .. 100";
  }
}

Syntax

Max frame count: 0..200

Default:

0 means use internal default (20)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-backtrace=0

--log-backtrace-detail

The --log-backtrace-detail adds compiler/OS dependent information to the output of --log-backtrace.

leaf log-backtrace-detail {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-backtrace=0 --log-backtrace-detail

--log-backtrace-level

The --log-backtrace-level parameter specifies that stack frame trace information be appended only to selected log message levels (see --log-level). It indicates for which debug level(s) backtrace info will be generated.

leaf log-backtrace-level {
  type bits {
    bit write {
      description "Include backtrace info in write messages.";
    }
    bit dev0 {
      description "Include backtrace info in developer
                   level 0 messages.";
    }
    bit error {
      description "Include backtrace info in error messages.";
    }
    bit warn {
      description "Include backtrace info in warning messages.";
    }
    bit info {
      description "Include backtrace info in info messages.";
    }
    bit dev1 {
      description "Include backtrace info in developer
                   level 1 messages.";
    }
    bit debug {
      description "Include backtrace info in debug messages.";
    }
    bit debug2 {
      description "Include backtrace info in debug2 messages.";
    }
    bit debug3 {
      description "Include backtrace info in debug3 messages.";
    }
    bit debug4 {
      description "Include backtrace info in debug4 messages.";
    }
  }
}

Syntax

Bits: error warn info debug debug2 debug3 debug4

One or more bits may be specified

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-backtrace=0 --log-backtrace-level=”error debug”

--log-backtrace-stream

The --log-backtrace-stream parameter specifies that stack frame trace information will be limited to output streams specified by the argument list. Possible arguments include logfile, stdout, stderr, syslog, and vendor.

leaf log-backtrace-stream {
  type bits {
    bit logfile {
      description "Include backtrace in logfile stream.";
    }
    bit stderr {
      description "Include backtrace in stderr stream.";
    }
    bit stdout {
      description "Include backtrace in stdout stream.";
    }
    bit syslog {
      description "Include backtrace in syslog stream.";
    }
    bit vendor {
      description "Include backtrace in vendor stream.";
    }
  }
}

Syntax

Bits: logfile stdout stderr syslog vendor

One or more bits may be specified

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-syslog --log=server.log --log-backtrace=0 --log-backtrace-stream=”logfile”

--log-console

The --log-console parameter directs that log output will be be sent to STDOUT, after being sent to the log file and/or local syslog daemon.

This parameter has no affect unless --log and/or --log-syslog are present.

leaf log-console {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log=file --log-syslog --log-console

--log-header

The --log-header parameter specifies that additional information (date/time/level) will be included in the log stream output. Possible arguments to this command include custom (add date/time/level info) and localtime (express date/time in local terms).

leaf log-header {
  type bits {
    bit custom {
      description "Include date, time, and level.";
    }
    bit localtime {
      description
        "Include localtime instead of Yang canonical format.";
    }
  }
}

Syntax

Bits: custom localtime

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-append

--log=~/server.log --log-header=”custom localtime”

--log-level

The --log-level parameter controls the verbosity level of messages printed to the log file or STDOUT, if no log file is specified.

The log levels are incremental, meaning that each higher level includes everything from the previous level, plus additional messages.

There are 8 settings that can be used:

  • none: All logging is suppressed. Use with extreme caution!

  • error: Error messages are printed, indicating problems that require attention.

  • warn: Warning messages are printed, indicating problems that may require attention.

  • info: Informational messages are printed, that indicate program status changes.

  • debug: Debugging messages are printed that indicate program activity.

  • debug2: Protocol debugging and trace messages are enabled.

  • debug3: Very verbose debugging messages are enabled. This has an impact on resources and performance, and should be used with caution.

  • debug4: Maximum debugging messages are enabled. This has an impact on resources and performance, and should be used with caution.

leaf log-level {
  type yt:NcDebugType;
}

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --log-level=debug --log=~/server.log&

--log-mirroring

The --log-mirroring parameter is a synonym for --log-console.

--log-stderr

The --log-stderr parameter directs that error level log output be directed to STDERR rather than STDOUT. (Note however that if --log is present, all error level messages will be directed to the specified log file. This parameter has no effect in this case.

leaf log-stderr {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-stderr > logFile&

! All log messages redirected to logFile except ...

! Error level messages displayed on console

--log-suppress-ctrl

The --log-suppress-ctrl parameter causes certain control parameters to br stripped from log messages.

leaf log-suppress-ctrl {
  ncx:hidden;
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-suppress-ctrl

--log-syslog

The --log-syslog parameter directs log output to be sent to the local syslog daemon, rather than to STDOUT. See the --log-console parameter for information on how log output may also be duplicated via STDOUT.

leaf log-syslog {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-syslog

--log-syslog-level

The --log-syslog-level parameter acts as a filter for the message level sent to the syslog or vendor output stream. The filter level is set by default to “info” if not specified.

The log levels are incremental, meaning that each higher level includes everything from the previous level, plus additional messages.

This parameter uses the same values as the --log-level parameter.

leaf log-syslog-level {
  type yt:NcDebugType;
}

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info (debug for DEBUG builds)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-logfile --log-level=debug3 --log-syslog --log-syslog-level=debug2

--key

The --key parameter specifies the gNMI or gRPC server private key file. The path to the key should be absolute.

Syntax

filespec

Default:

none

Min Allowed:

1

Max Allowed:

1

Supported by:

ypgnmi-app ypgrpc-app

Example:

ypgnmi-app --key=/tmp/cert.crt

--match-names

The --match-names parameter specifies how names are matched when performing UrlPath searches.

The following values are supported:

Enum

Description

exact

The name must exactly match the node name for all characters in both name strings. This mode must be used in the server to be compliant with the NETCONF and RESTCONF protocols.

exact-nocase

The name must match the node name for all characters in both name strings. Strings are not case-sensitive.

one

The name must exactly match the first N characters of just one node name, which must be the only partial name match found.

one-nocase

The name must exactly match the first N characters of just one node name, which must be the only partial name match found. Strings are not case-sensitive.

first

The name must exactly match the first N characters of any node name. The first one found will be used.

first-nocase

The name must exactly match the first N characters of any node name. The first one found will be used. Strings are not case-sensitive.

leaf match-names {
  type ywt:NameMatchMode;
}

Syntax

enum:
exact
exact-nocase
one
one-nocase
first
first-nocase

Default:

yangcli: one-nocase, server: exact

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --match-names=first

--message-indent

The --message-indent parameter specifies the number of spaces that will be used to add to the indentation level, each time a child node is printed during protocol messages such as NETCONF requests. This does not affect the indentation for logging messages, which is controlled by the --indent parameter.

  • The values 0 to 9 indicate the number of spaces to indent after each new line.

  • The value -1 requests that no newlines or indentation will be used in protocol messages..

leaf message-indent {
  type int8 {
    range "-1 .. 9";
  }
  default -1;
}

Syntax

int32 (-1 .. 9)

Default:

-1

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

yangcli-pro --message-indent=2

--modpath

The --modpath parameter specifies the YANG module search path to use while searching for YANG files. It consists of a colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.

This parameter overrides the $YUMAPRO_MODPATH environment variable, if it is present.

leaf modpath {
  type yt:NcPathList;
}

Syntax

string: list of directory specifications

Default:

$YUMAPRO_MODPATH environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

yangcli-pro --modpath=”~/testmodules:~/modules:~/trunk/netconf/modules”

--module

The --module parameter is a leaf-list of modules that should be loaded automatically when the program starts.

  • The program will attempt to load each module in the order the parameters were entered.

  • For the netconfd-pro program, If any modules have fatal errors then the program will terminate.

  • For the yangdump-pro program, each module will be processed as requested.

leaf-list module {
    type yt:NcModuleSpec;
}

Syntax

module name or filespec

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro yangcli-pro yangdump-pro

Example:

yangcli-pro --module=test1 --module=test2

--no-config

The --no-config parameter specifies that the default configuration file (e.g., /etc/yumapro/yangcli_pro.conf) should not be loaded, even if it is present.

choice config-choice {
  leaf config {
     type string;
  }
  leaf no-config {
    type empty;
  }
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

yangcli-pro --no-config

--output

The --output parameter specifies where the output files generated by the program will be stored.

  • The default is STDOUT if this parameter is not specified and the --defnames parameter is set to 'false'.

  • If this parameter represents an existing directory, then the --defnames parameter will be set to 'true' by default.

  • If this parameter represents a file name, then the --defnames parameter will be ignored, and all translation output will be directed to the specified file.

  • If this string begins with a '~' character, then a username is expected to follow or a directory separator character. If it begins with a '$' character, then an environment variable name is expected to follow.

    ~/some/path ==> <my-home-dir>/some/path
    
    ~fred/some/path ==> <fred-home-dir>/some/path
    
    $workdir/some/path ==> <workdir-env-var>/some/path
    
  • If the target specified in this parameter does not exist:

    • If there is only one file to be output, then this parameter is used as the file name.

    • If there are multiple files to be output, then this parameter is used as a directory name. A new directory will be created, if it is needed.

  • If the target specified in this parameter does exist:

    • If there is only one file to be output:

      • If the existing target is also a file, then the current file is over-written.

      • If the existing target is a directory, then the output file will be created in this directory.

    • If there are multiple files to be output:

      • If the existing target is a file, then an error will be generated instead of the output files.

      • If the existing target is a directory, then the output files will be created in the specified directory.

  • Use a trailing path separator character to force this parameter value to be treated as a path specification (e.g., '~/workfiles/').

  • This parameter is ignored if the --format parameter is missing.

leaf output {
  type string;
}

Syntax

string (path or file specification)

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdiff-pro

Example:

yangdiff-pro --output=~/diff-files

--port

port for netconfd-pro

The --port parameter specifies the TCP port number(S) that should be used for NETCONF sessions.

This parameter specifies the TCP port numbers to accept NETCONF session from. If any instances of this parameter are found, then the default (port 830) will not be added automatically. Up to 4 port parameter values can be entered.

--port parameter

Syntax

uint32

Default:

830

Min Allowed:

0

Max Allowed:

4

Supported by:

netconfd-pro

Example:

netconfd-pro --port=22 --port=830

port for ypgrpc-go-app

The --port parameter specifies the gRPC server binding. This is the address that the gRPC client will use top contact the gRPC server. By default the address is the local host and default port is 50830.

--port parameter

Syntax

inet:port-number

Default:

:50830

Min Allowed:

0

Max Allowed:

1

Supported by:

ypgrpc-go-app

Example:

ypgrpc-go-app --port=50051

--protocols

The --protocols parameter specifies which protocol versions the program or session will attempt to use. Empty set is not allowed.

leaf protocols {
      must ". != ''";
   type bits {
      bit netconf1.0 {
         description "RFC 4741 base:1.0";
         position 0;
      }
      bit netconf1.1 {
         description "RFC 6241 base:1.1";
         position 1;
      }
      bit yang-api {
         description "YANG-API protocol";
         reference "draft-bierman-netconf-yang-api-01.txt";
         position 2;
         status deprecated;
      }
      bit restconf {
         description "RESTCONF Protocol";
         reference "RFC 8040";
         position 3;
      }
   }
   /* default "netconf1.0 netconf1.1"; */
}

Syntax

bits

Default:

netconf1.0 netconf1.1

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

yangcli-pro --protocols=netconf1.0

--runpath

The --runpath parameter specifies the directory search path to use while searching for script files. It consists of a colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.

This parameter overrides the $YUMAPRO_RUNPATH environment variable, if it is present.

leaf runpath {
  type yt:NcPathList;
}

Syntax

string: list of directory specifications

Default:

$YUMAPRO_RUNPATH environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

yangcli-pro --runpath=”~/testscripts”

--server

The --server parameter specifies the IP address or DNS name of the NETCONF server that should be connected to automatically, when the program starts.

leaf server {
   type inet:host;
   mandatory true;
 }

Syntax

string:IP address or DNS name

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro ypgrpc-go-app ypgnmi-go-app

Example:

yangcli-pro --server=myserver

--server-id

The --server-id parameter specifies the Server Identifier string to use for this server. Used in YControl and SIL-SA messages to identifier the server to all subsystems. Used in YP-HA to identify this server in the YP-HA server pool.

leaf server-id {
  type nt:NcxName;
  default "server1";
}

Syntax

NcxName

Default:

server1

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro ypgnmi-app

Example:

netconfd-pro --server-id=main

--subdirs

The --subdirs parameter controls whether sub-directories should be searched or not, if they are found during a module search.

  • If false, the file search paths for modules, scripts, and data files will not include sub-directories if they exist in the specified path.

  • If true, then these file search paths will include sub-directories, if present. Any directory name beginning with a dot '.' character, or named 'CVS', will be ignored.";

leaf subdirs {
  description
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangdump-pro

Example:

netconfd-pro --subdirs=false

--subsys-id

The --subsys-id parameter specifies the subsystem identifier to use when registering with the netconfd-pro server. The default is 'yp-gnmi' if no value is specified.

--subsys-id parameter

Syntax

string

Default:

yp-gnmi

Min Allowed:

0

Max Allowed:

1

Supported by:

ypgnmi-app ypgrpc-go-app

Example:

ypgnmi-app --subsys-id=subsys1

--version

The --version parameter causes the program version string to be printed, and then the program will exit instead of running as normal.

All YumaPro version strings use the same format:

DEBUG: <major>.<minor>.<svn-build-version>

or

NON-DEBUG: <major>.<minor>-<release>

The netconfd-pro version string has a feature code string appended to it. This is a hex string that identifies several of the make flag feature variants used in the server binary.

An example version number that may be printed:

netconfd-pro-20.10-8-3fcf

This parameter can be combined with the --help parameter.

leaf version {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --version

--warn-error

The --warn-error parameter controls whether all warnings are elevated to errors.

  • If true then warnings that are enabled will be elevated to errors for reporting purposes.

  • If false then warnings will not be elevated to an error.

  • The --warn-up parameter can override this parameter for a specific error number.

leaf warn-error {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --warn-error=true

--warn-idlen

The --warn-idlen parameter controls whether identifier length warnings will be generated.

The value zero disables all identifier length checking. If non-zero, then a warning will be generated if an identifier is defined which has a length is greater than this amount.

leaf warn-idlen {
  type uint32 {
    range "0 | 8 .. 1023";
  }
  default 64;
}

Syntax

uint32: 0 to disable, or 8 .. 1023

Default:

64

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --warn-idlen=50

--warn-linelen

The --warn-linelen parameter controls whether line length warnings will be generated.

The value zero disables all line length checking. If non-zero, then a warning will be generated if a YANG file line is entered which has a length is greater than this amount.

Tab characters are counted as 8 spaces.

leaf warn-linelen {
  type uint32 {
    range "0 | 40 .. 4095";
  }
  // default 72;
  default 0;
}

Syntax

uint32: 0 to disable, or 40 .. 4095

Default:

72

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --warn-linelen=79

--warn-off

The --warn-off parameter suppresses a specific warning number.

The error and warning numbers, and the default messages, can be viewed with the yangdump-pro program by using the --show-errors configuration parameter.

The specific warning message will be disabled for all modules. No message will be printed and the warning will not count towards the total for that module.

leaf-list warn-off {
  type uint32 {
    range "1000 .. 1999";
  }
}

Syntax

uint32: 400 .. 899

Default:

none

Min Allowed:

0

Max Allowed:

499

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --warn-off=435 # revision order not descending

--warn-up

The --warn-up parameter elevates a specific warning number to an error.

The error and warning numbers, and the default messages, can be viewed with the yangdump-pro program by using the --show-errors configuration parameter.

The specific warning message will be elevated for all modules. An error message will be printed and the warning will be counted towards the error total for that module.

leaf-list warn-up {
  type uint32 {
    range "1000 .. 1999";
  }
}

Syntax

uint32: 1000 .. 1999

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --warn-up=1022

--wildcard-keys

The --wildcard-keys parameter controls whether the server will support YANG-API/RESTCONF URL requests that contain a dash character '-' to indicate all instances of that key leaf.

  • Set to 'true' if UrlPath targets for GET operations are allowed to replace key values with the dash '-' character to indicate that all instances of that key are requested.

  • Set to false to treat the '-' character as a plain character if entered as a key value in a UrlPath string.

leaf wildcard-keys {
  type boolean;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --wildcard-keys=true

--with-ocpattern

The --with-ocpattern parameter controls whether the server will support the OpenConfig usage of the YANG pattern statement.

  • If true, then OpenConfig patterns with be checked

    • If the module name starts with the string 'openconfig-' then all pattern statements within that module are treated as POSIX patterns, not YANG patterns.

    • Otherwise the module pattern statements will be checked as YANG patterns.

  • If false, then the pattern statements in all modules will be checked as YANG patterns.

  • If the oc-ext:regexp-posix extension is found in the module then this parameter will be ignored and Posix patterns will be used.

    leaf with-ocpattern {
        type boolean;
        default false;
    }
    

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

yangcli-pro

yangdump-pro

Example:

yangcli-pro --with-ocpattern=true

--yumapro-home

The --yumapro-home parameter specifies the project directory root to use when searching for files.

If present, this directory location will override the $YUMAPRO_HOME environment variable, if it is set. If this parameter is set to a zero-length string, then the $YUMAPRO_HOME environment variable will be ignored.

The following directories are searched when either the $YUMAPRO_HOME environment variable or this parameter is set:

  • $YUMAPRO_HOME/modules

    • This sub-tree is searched for YANG files.

  • $YUMAPRO_HOME/data

    • This directory is searched for data files.

  • $YUMAPRO_HOME/scripts

    • This directory is searched for yangcli-pro script files.

leaf yumapro-home {
  type string;
}

Syntax

string: directory specification

Default:

$YUMAPRO_HOME environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yangdiff-pro yangdump-pro

Example:

netconfd-pro --yumapro-home=~/sw/netconf --log=~/server.log&

--with-term-msg

The --with-term-msg parameter specifies if the <term-msg> notification should be supported. If set to 'true', then the yumaworks-term-msg module will be loaded and enabled. Otherwise, this module will not be loaded. The <term-msg> notification is used by yp-shell for displaying terminal diagnostic messages.

The server API function agt_make_term_msg can be used by SIL or SIL-SA code to generate a <term-msg> notification.

The yp-shell and yangcli-pro programs will automatically display the <term-msg> as a terminal message if the --with-term-msg parameter is also set to “true” for the client program.

leaf with-term-msg {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro yp-shell

Example:

netconfd-pro --with-term-msg=false

netconfd-pro CLI Reference

--access-control

The --access-control parameter specifies how access control is enforced in the netconfd-pro program.

It is an enumeration with the following values:

  • enforcing: All configured access control rules will be enforced.

  • permissive: All configured access control rules will be enforced for write and execute requests. All read requests will be allowed, unless the requested object contains the nacm:default-deny-all extension. In that case, all configured access control rules will be enforced, and no default access will be allowed.

  • disabled: All read, write, and execute requests will be allowed, unless the object contains the nacm:default-deny-write or nacm:default-deny-all extension.

    • If the nacm:default-deny-write extension is in effect, then all configured access control rules will be enforced for write and execute requests.

    • If the nacm:default-deny-all extension is in effect, then all configured access control rules will be enforced for all requests. Use this mode with caution.

  • off: All access control enforcement is disabled. Use this mode with extreme caution.

leaf access-control {
  type ywt:access-control-mode;
  default enforcing;
}

Syntax

enumeration:

enforcing permissive disabled off

Default:

enforcing

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --access-control=permissive

--allow-leaflist-delete-all

The --allow-leaflist-delete-all parameter controls whether the YumaPro extension “delete-all” operation should be allowed for leaf-list objects. If true, then the client can send nc:operation=”delete-all” or nc:operation=”remove-all”, and the server will accept the edit if the target node is a leaf-list object. Do not provide a value for the leaf-list.

This parameter affects the <edit-config> operation.

These operations have the following meaning:

  • delete-all: delete all instances of the leaf-list Return a 'data-missing' error if there are no instances of the leaf-list

  • remove-all: delete all instances of the leaf-list Return 'OK' if there are no instances of the leaf-list

leaf allow-leaflist-delete-all {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --allow-leaflist-delete-all=true

--allow-list-delete-all

The --allow-list-delete-all parameter controls whether the YumaPro extension “delete-all” operation should be allowed for list objects. If true, then the client can send nc:operation=”delete-all” or nc:operation=”remove-all”, and the server will accept the edit if the target node is a list object. The key leaf values should not be provided.

This parameter affects the <edit-config> operation.

These operations have the following meaning:

  • delete-all: delete all instances of the list Return a 'data-missing' error if there are no instances of the list

  • remove-all: delete all instances of the list Return 'OK' if there are no instances of the list

leaf allow-list-delete-all {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --allow-list-delete-all=true

--allowed-user

The --allowed-user parameter specifies a set of user names that are allowed to login and use the server.

  • If none are configured then this parameter will have no affect on access control.

  • If the “superuser” account name is configured, then logins to the superuser account will bypass access control and not be checked against the allowed-user list.

  • If any allowed-user names are configured, then the user name for a new session must be in the configured allowed-user list. If not, then the session will be denied with an NCX_ERR_ACCESS_DENIED status code.

leaf-list allowed-user {
  type nt:NcxName;
}

Syntax

string (NcxName)

Default:

none

Min Allowed:

0

Max Allowed:

no limit

Supported by:

netconfd-pro

Example:

netconfd-pro --allowed-user=fred allowed-user=barney allowed-user=admin

--annotation

The --annotation parameter is a leaf-list of modules that should be loaded automatically when the program starts, as a deviation module containing annotations. In this mode, only the deviation statements are parsed and then made available later when the module that contains the objects being deviated is parsed. The annotation file is not advertised to clients or shown in the YANG library.

The following example module shows how annotations could be added to the ietf-interfaces.yang module:

module devtest1-d {

  namespace "http://netconfcentral.org/ns/devtest1-d";
  prefix dt1-d;
  import ietf-interfaces { prefix if; }
  import yuma-ncx { prefix ncx; }

  revision "2016-04-10";

  deviation /if:interfaces {
    deviate add {
      ncx:sil-delete-children-first;
    }
  }

  deviation /if:interfaces/if:interface {
    deviate add {
      ncx:sil-delete-children-first;
    }
  }
}

The program will attempt to load each module in annotation parsing mode, in the order the parameters are entered. All deviation parameters will be processed, then all annotation parameters. An annotation module is just a YANG module that contains only 'deviation' statements with “deviate add” sub-statements.

leaf-list annotation {
    type yt:NcModuleSpec;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --annotation=devtest1-d

--audit-log

The --audit-log parameter specifies the file path of the configuration edit audit log. If this parameter is present, then edits to the running database will cause an audit log entry to be created for each edit point. This is done in addition to normal logging, but it is not affected by the --log-level parameter. The --no-audit-log parameter cannot be present if this parameter is present. The --audit-log-events parameter selects the event types that are recorded in the audit log file.

choice audit-log-choice {
  leaf audit-log {
    type string;
  }
  leaf no-audit-log {
    type empty;
  }
}

Syntax

filespec

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --audit-log=/var/log/nc-audit.log

--audit-log-append

The --audit-log-append parameter specifies that the existing audit log file (if any) should be appended, instead of deleted. It is ignored unless the --audit-log parameter is present.

leaf audit-log-append {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --audit-log=/var/log/ncaudit.log --audit-log-append

--audit-log-candidate

The --audit-log-candidate parameter specifies whether edit transactions on the candidate datastore are recorded in the audit log or not. If true, then edits to the candidate datastore are recorded. If false, then edits to the candidate datastore are not recorded.

leaf audit-log-candidate {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --audit-log=/var/log/ncaudit.log --audit-log-candidate=false

--audit-log-console-level

The --audit-log-console-level parameter controls the minimum logging level needed to log datastore audit records to the server console log. This does not affect output to the audit log.

This parameter uses the same values as the --log-level parameter.

leaf audit-log-console-level {
  type nt:NcDebugType;
  default debug;
}

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

debug

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --audit-log-console-level=info

--audit-log-events

The --audit-log-events parameter controls the event types that are output to the audit log. It has no affect unless the audit-log is enabled.

leaf audit-log-events {
  type bits {
    bit edit-candidate {
      description
        "Save candidate datastore edit events in the audit log.
         If the --audit-log-candidate parameter is set to true,
         or the <candidate> datastore is not present, then this
         bit will be ignored.";
    }
    bit edit-running {
      description
        "Save running datastore edit events in the audit log";
    }
    bit update-startup {
      description
        "Save startup datastore update events in the audit log.
         If the <startup> datastore is not present then this
         bit will be ignored.";
    }
    bit client-session {
      description
       "Save client session start and end events in the audit log";
    }
    bit control-session {
      description
       "Save YControl session start and end events in the audit log";
    }
    bit acm-write-error {
      description
       "Save access control write access denied events in
        the audit log";
    }
    bit acm-exec-error {
      description
       "Save access control execute access denied events in
        the audit log";
    }
    bit rpc-summary {
      description
       "Save <rpc> summary records in the audit log.";
    }
    bit edit-data {
      description
       "Add plain display output of the data that is being
        edited in an edit transaction. This bit has no affect
        unless the edit-candidate or edit-running bit is
        also set.

        Note that this added data could represent a security risk
        since it could expose sensitive configuration data contents.
        Use this option with caution!";
    }
  }
  default "edit-running";
}

Syntax

bits: edit-candidate edit-running update-startup client-session control-session acm-write-error acm-exec-error rpc-summary edit-data

Default:

edit-running

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --audit-log-events=”edit-candidate edit-data edit-running client-session”

--audit-log-events Examples

This parameter uses the YANG “bits” type, so any combination of the following bit definitions are permitted:

  • edit-candidate: Save candidate datastore edit events in the audit log. If the --audit-log-candidate parameter is set to true, or the <candidate> datastore is not present, then this bit will be ignored. By default, the --audit-log-candidate parameter is set to “true” so this event type will be present in the audit log by default. To remove these events, est --audit-log-candidate=false and do not set this bit.

    Example audit log entry:

edit-transaction 9616: on session 3 by andy@127.0.0.1
  time: 2018-09-04T20:44:44Z
  message-id: 2
  trace-id: --
  datastore: candidate
  operation: create
  target: /t:int16.1
  comment: none
  • edit-running: Save running datastore edit events in the audit log.

    Example audit log entry:

edit-transaction 9617: on session 3 by andy@127.0.0.1
  time: 2018-09-04T20:44:47Z
  message-id: 3
  trace-id: --
  datastore: running
  operation: create
  target: /t:int16.1
  comment: none
  • update-startup: Save startup datastore update events in the audit log. If the <startup> datastore is not present then this bit will be ignored.

    Example audit log entry:

update-startup on session 3 by andy@127.0.0.1
  time: 2018-09-04T20:44:52Z
  message-id: 5
  sourcetype: datastore
  source: running
  • client-session: Save client session start and end events in the audit log.

    Example audit log entry (start-client-session)

start-client-session:
  time: 2018-09-04T20:44:31Z
  protocol: NETCONF
  transport: netconf-ssh
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3

Example audit log entry (end-client-session)
end-client-session:
  time: 2018-09-04T20:50:23Z
  protocol: NETCONF 1.1
  transport: netconf-ssh
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3
  term reason: closed
  killed-by: 3
  • control-session: Save YControl session start and end events in the audit log.

    Example audit log entry (start-control-session)

start-control-session:
  time: 2018-09-04T20:53:59Z
  protocol: YControl
  transport: netconf-aflocal
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3

Example audit log entry (end-control-session)
end-control-session:
  time: 2018-09-04T21:02:39Z
  protocol: YControl
  transport: netconf-aflocal
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3
  term reason: dropped
  killed-by: 0
  • acm-write-error: Save access control write access denied events in the audit log.

    Example audit log entry:

nacm-write-error:
  time: 2018-09-04T21:04:51Z
  username: andy
  operation: create leaf int32.1
  path:: /t:int32.1
  • acm-exec-error: Save access control execute access denied events in the audit log.

    Example audit log entry:

nacm-exec-error:
  time: 2018-09-04T21:08:54Z
  username: andy
  module name: yumaworks-system
  RPC name: load
  • rpc-summary: Save RPC summary events in the audit log.

    Example audit log entry:

RPC <get> on session 3 by* andy@127.0.0.1
  start-time: 2019-12-12T01:35:47Z
  end-time: 2019-12-12T01:35:47Z
  message-id: 2
  reply-type: data
  status: 0:ok
  • edit-data: Add plain display output of the data that is being edited in an edit transaction. This bit has no affect unless the edit-candidate or edit-running bit is also set. Note that this added data could represent a security risk since it could expose sensitive configuration data contents. Use this option with caution.

    • The ‘new value’ data will be added if the edit has a new value (create, modify).

    • The ‘current value’ will be added if the edit has a current value (modify, delete)

    Example audit log entries for create a leaf “uint16.1”:

edit-transaction 187: on session 3 by andy@127.0.0.1
  time: 2020-06-06T01:19:52Z
  message-id: 3
  trace-id: --
  datastore: running
  operation: create
  target: /t:uint16.1
  comment: none
  new value:
    t:uint16.1 10


Example audit log entries for modify a leaf “uint16.1”:
edit-transaction 189: on session 3 by andy@127.0.0.1
  time: 2020-06-06T01:21:11Z
  message-id: 5
  trace-id: --
  datastore: running
  operation: replace
  target: /t:uint16.1
  comment: none
  new value:
    t:uint16.1 20
  old value:
    t:uint16.1 10


Example audit log entries for delete a leaf “uint16.1”:
edit-transaction 191: on session 3 by andy@127.0.0.1
  time: 2020-06-06T01:21:24Z
  message-id: 7
  trace-id: --
  datastore: running
  operation: delete
  target: /t:uint16.1
  comment: none
  old value:
    t:uint16.1 20

--audit-log-level

The --audit-log-level parameter controls the minimum logging level needed to log datastore audit records to the audit log. This does not affect debug logging to the server console log. This parameter has no affect unless the --audit-log parameter is also used.

This parameter uses the same values as the --log-level parameter.

leaf audit-log-level {
  type nt:NcDebugType;
  default info;
}

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --audit-log-level=debug --audit-log=~/server-audit.log&

--autodelete-pdu-error

The --autodelete-pdu-error parameter specifies whether auto-deletion of a configuration parameter provided in an edit PDU is treated as an error or not.

  • If true, then configuration nodes provided in the edit payload (e.g., <config> element) that are conditional on 'when' statements must evaluate to true or else an operation-failed error will be returned.

  • If false, then such 'false when' will be silently removed from the target datastore.

leaf autodelete-pdu-error {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --autodelete-pdu-error=false

--bundle

The --bundle parameter is a leaf-list of SIL bundle names that should be loaded automatically when the program starts.

The program will attempt to load each SIL bundle in the order the parameters were entered.

If any SIL bundle initialization callback functions return any error, then the program will terminate. There cannot be any errors in any of the YANG modules in the SIL bundle.

leaf-list bundle {
  type nt:NcxName;
}

Syntax

SIL bundle name

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --bundle=interfaces

--callhome-reconnect

The --callhome-reconnect parameter specifies whether server will reconnect after client closes the session.

  • If 'true' the server will attempt to start a new callhome connection if the client closes the session.

  • If 'false' the server will not attempt to start a new callhome session after the client closes the session.

Be careful that the server is running with proper permissions because a successful connection that fails during authentication will cause a reconnect loop if this parameter is set to 'true'.

leaf callhome-reconnect {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --callhome-reconnect=true

--callhome-retry-interval

The --callhome-retry-interval parameter specifies the number of seconds to wait after a connect attempt to the callhome server has failed before attempting another connect attempt to that server.

leaf callhome-retry-interval {
  units "seconds";
  type uint16 {
    range "1 .. max";
  }
  default 60;
}

Syntax

uint16 [1..max]

Default:

60 seconds

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --callhome-retry-interval=30

--callhome-retry-max

The --callhome-retry-max parameter specifies the number of retry attempts the server should attempt to the callhome server before giving up. The value 0 indicates the server should never give up.

leaf callhome-retry-max {
  type uint16;
  default 10;
}

Syntax

uint16

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --callhome-retry-max=0

--callhome-server

The --callhome-server parameter specifies a callhome/SSH server that this server should attempt to initiate a callhome connection at boot-time. This is a leaf-list parameter and multiple entries are supported.

This string has the format:

<server-id> '@' <server-addr> [ ':' <port-num> ]

Examples:

server1@192.168.0.101

server1@192.168.0.101:12040

The server-id parameter is used for logging purposes.

This parameter is ignored if the --with-callhome parameter is set to 'false'.

leaf-list callhome-server {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --callhome-server=ch1@192.168.0.40

--callhome-sshd-command

The --callhome-sshd-command parameter specifies the command string used to invoke the SSH server when a callhome session is initiated.

leaf callhome-sshd-command {
  type string;
  default "/usr/sbin/sshd";
}

Syntax

string

Default:

/usr/sbin/sshd

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

Netconfd-pro --callhome-sshd-command=/bin/sshd

--callhome-sshd-config

The --callhome-sshd-command parameter specifies the SSH server configuration file to use when invoking the SSH server when a callhome session is initiated. The default config file to use is a dynamic string using the pattern ch_sshd_config.<client>. It is located in the $HOME/.yumapro directory.

leaf callhome-sshd-config {
  type string;
}

Syntax

string

Default:

NONE (dynamic default)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

Netconfd-pro --callhome-sshd-config=/etc/ssh/callhome_config

--callhome-subsys-command

The --callhome-subsys-command parameter specifies the netconf subsystem to use in the default ch_sshd_config files to specify the NETCONF subsystem for the incoming NETCONF session expected on the callhome session.

leaf callhome-subsys-command {
  type string;
  default "/usr/sbin/netconf-subsystem-pro";
}

Syntax

string

Default:

/usr/sbin/netconf-subsystem-pro

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

Netconfd-pro --callhome-subsys-command=/bin/netconf-subsystem-pro

--callhome-tls-server

The --callhome-tls-server parameter specifies a callhome/TLS server that this server should attempt to initiate a callhome connection at boot-time. This is a leaf-list parameter and multiple entries are supported.

This string has the format:

<server-id> '@' <server-addr> [ ':' <port-num> ]

Examples:

netconfd-pro {
  server1@192.168.0.101
  server1@192.168.0.101:12040
}

The server-id parameter is used for logging purposes.

This parameter is ignored if the --with-callhome parameter is set to 'false'.

leaf-list callhome-tls-server {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --callhome-tls-server=ch1@192.168.0.40

--cert-default-user

The --cert-default-user parameter specifies a user-name that should be used if no certificate mapping is found for a NETCONF over TLS session. This is the username to use if no username mapping is found for a NETCONF over TLS session. This parameter is non-standard and should only be used for debugging. This parameter is not available unless image is built with DEBUG=1 parameter.

This parameter is ignored if the --with-netconf-tls parameter is set to 'false'.

leaf cert-default-user {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --cert-default-user=admin

--cert-usermap

The --cert-usermap parameter specifies a user-name to certificate mapping.

Each entry specifies a certificate to user name mapping for NETCONF over TLS sessions. A mapping is a structured string using the form <user>@<fingerprint>.

The 'user' field is the case-sensitive user name for the mapping.

The 'fingerprint' field is a hex-string representation of the SHA-1 fingerprint for the X.509 certificate. It does not have to be complete. Usually 6 bytes should be sufficient to ensure uniqueness. The hex digits are not case-sensitive. At least 6 hex digits must be provided. A maximum of 20 hex digits can be provided.

Note

The full client fingerprint should be used for better security.

Example:

admin@DF:4A:D4:92:1C:53:A5:91:1B:78:C5:E5:71:40:3F:E5:99:FC:AB:D4

A printable fingerprint can be generated with the openssl command:

> openssl x509 -noout -fingerprint -sha1 -inform pem -in [certificate-file.crt]

This parameter is ignored if the --with-netconf-tls parameter is set to 'false'.

leaf-list cert-usermap {
  ordered-by user;
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --cert-usermap=admin@60:C8:5C:08:82:55

--confdir

The --confdir parameter specifies the CLI parameter configuration directory to use for extra configuration files. The server will check this directory for files that end with the suffix '.conf' and process them similar to the main configuration file. Other files will be ignored. Sub-directories will not be checked.

This parameter is ignored if the --no-nvstore parameter is used.

Files will be processed in alphabetical order. The server will keep the first value set if a CLI leaf parameter is set multiple times.

The CLI parameters are set in the following order:

  1. netconfd-pro command line

  2. --config file or /etc/yumapro/netconfd-pro.conf

  3. --confdir files or /etc/yumapro/netconfd-pro.d/

If the --no-config parameter is present in step (1) then steps (2) and (3) will be skipped, and this parameter will be ignored. If this parameter is encountered in step (3) it will be ignored.

Extra configuration files in step (3) have the exact same syntax as the configuration file used in step (2).

Example extra config file testmods.conf:

netconfd-pro {
  module acme-test1
  module acme-test2
  log-level debug2
  message-indent 1
  idle-timeout 0
}

Refer to the Configuration Files section for details on the format of configuration files.

leaf confdir {
  type string;
  default "/etc/yumapro/netconfd-pro.d";
}

Syntax

string: complete directory specification of the directory to look for more configuration files

Default:

/etc/yumapro/netconfd-pro.d

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --confdir=/mnt/conf/device12

--convert-subtree-filter

The --convert-subtree-filter parameter specifies whether subtree filters will be converted to XPath filters for internal processing. If set to 'true' then subtree filters for retrieval operations might be converted to XPath expressions for processing.

The subtree filtering algorithm has a minor flaw which can cause subtree containment nodes to be printed in the output even though a nested selection filter does not match. A containment node should be completely pruned from the result no selection filters within it produce a match. This only affects data that needs to be retrieved by the server with a GET2 callback.

This issue has been fixed by converting a subtree filter to XPath and processing as if it were an XPath filter. If this parameter is set to 'true' then the conversion will be attempted. The conversion will be skipped if any of the following conditions are true:

  • output format is not XML

  • input format is not XML

  • subtree filter contains any attribute match expressions

This bugfix is not enabled by default because it might change filter output which was previously incorrect, but a client might be relying on the incorrect output anyway.

leaf convert-subtree-filter {
   type boolean;
   default false;
 }

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --convert-subtree-filter=true

--create-empty-npcontainers

The --create-empty-npcontainers parameter specifies whether empty NP container will be created by the server.

Warning

The YANG Xpath validation within the server may not function properly if this parameter is set to 'false'.

An empty non-presence container has no meaning in NETCONF/YANG so it may be created by the server. In particular, the presence of the container node with no child nodes is semantically equivalent to the absence of the container node. This is the default style.

If this parameter is set to false, then the server will not create empty NP containers.

leaf create-empty-npcontainers {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --create-empty-npcontainers=false

--db-lock-retry-interval

The --db-lock-retry-interval parameter specifies the number of milliseconds to wait before attempting to get a DB-Config-Lock from the DB-API subsystem. The server will wait this amount of time after a db-lock request fails.

--db-lock-retry-interval parameter

Syntax

number: 10 .. 60000 milliseconds

Default:

500 milliseconds

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --db-lock-retry-interval=1000

--db-lock-timeout

The --db-lock-timeout parameter specifies the the total number of seconds to wait before giving up on a DB-Config-Lock from the DB-API subsystem. The value zero indicates that no retries will be attempted if the lock is busy.

leaf db-lock-retry-interval {
  type uint32 {
    range "10 .. 60000";
  }
  units "milli-seconds";
  default 500;
}

Syntax

number: 0 .. 3600 seconds

Default:

30 seconds

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --db-lock-timeout=120

--default-style

The --default-style parameter specifies the way leafs with default values are returned from the server for data retrieval operations. This setting will be used as the default behavior when processing the operations that support the <with-defaults> extension, and no value is provided.

The values and their meanings are defined in ietf-netconf-with-defaults.yang. Here is a summary:

  • report-all: Report all nodes as the default behavior. The will be the behavior used if this parameter is not specified.

  • trim: Report only nodes that do not have the server-assigned value, as the default behavior. This includes all leafs with a YANG default and any other node created by the server.

  • explicit: Report only nodes that have been set by client action, as the default behavior. Any node created via the <startup> configuration at boot-time is considered to be a client-created node. It does not matter what the actual values are, with respect to YANG defaults or server-supplied defaults. Any nodes created by the server are skipped.

leaf default-style {
     type enumeration {
       enum report-all;
       enum trim;
       enum explicit;
     }
     default explicit;
  }

Syntax

enumeration: report-all trim explicit

Default:

report-all

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --default-style=trim

--delete-empty-npcontainers

The --delete-empty-npcontainers parameter is a boolean that indicates whether the server should keep or delete empty non-presence containers in the database.

If 'true', empty NP containers will be deleted. If 'false', they will not be deleted.

Note

This parameter is obsolete!
The server ignores this parameter!
Do not use!

The value 'false' is always used!!!

leaf delete-empty-npcontainers {
  type boolean;
  default false;
  status obsolete;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --delete-empty-npcontainers=true

--errmsg

The --errmsg parameter specifies a language specific error message, for a specific error code.

Specifies a replacement string for a specific error number. Can specify error message for 1 specific language.

The string has the format:

<num>:<lang>:error string

where:

<num> = error number to use for error message
<lang> = language code (en for English)
error string = error string text
  • The 'num' component must match the <error-number> found in status_enum.h. New error enums are always added at the end of the list, so the numbers will not change.

  • The 'lang' component should use the ISO-639-1 code Max length is 7 characters.

Example:

Replace error 117 (ERR_WB_WRITE_FAILED) 'db write failed'

errmsg='117:en:The database could not be written'

There are several pre-defined error message configuration files, found in directory:

/usr/share/yumapro/util/errmsg-lang

To use an error message configuration file, copy the file to the netconfd.d configuration directory:

The --errmsg-lang parameter must be set to the correct language code for the server to use this configuration file.

Example: Copy the Russian (ru) error codes to the configuration directory:

> sudo mkdir /etc/yumapro/netconfd-pro.d
> sudo cp /usr/share/yumapro/util/errmsg-lang/errmsg-ru.conf /etc/yumapro/netconfd-pro.d/
leaf-list errmsg {
  type string;
  description
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --errmsg="117:en:Database write failed"

--errmsg-lang

The --errmsg-lang parameter specifies the language to use for <error-message> content.

The --errmsg parameter must be used to configure the language-specific error message strings.

This value should use the ISO-639-1 code for the language.

leaf errmsg-lang {
  type string {
    length "1 .. 7";
  }
  default "en";
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --errmsg-lang=ru

--eventlog-size

The --eventlog-size parameter controls the maximum number of events that will be stored in the notification replay buffer by the netconfd-pro server.

If set to 0, then notification replay will be disabled, meaning that all requests for replay subscriptions will cause the <replayComplete> Event to be sent right away, since there are no stored notifications.

The server will delete the oldest entry, when this limit is reached and a new event is added to the replay buffer.

No memory is actually set aside for the notification replay buffer, so memory limits may be reached before the maximum number of events is actually stored, at any given time.

leaf eventlog-size {
   type uint32;
   default 1000;
}

Syntax

uint32

Default:

1000

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --eventlog-size=20000

--event-stream

The --event-stream parameter specifies the name of a NETCONF event stream that should be created by the server..

Each event stream has its own subscriptions and notification replay buffer. Each event stream has the same replay buffer size, using the shared eventlog-size parameter. Each generated notification is sent to one event stream.

The YANG module instrumentation will select an event stream to use or the default event stream will be used. Copies of the same notification can be sent to multiple event streams. If the event-stream specified by the instrumentation is not available, then a warning will be generated in the log and the default event stream will be used instead.

The default event stream is named 'NETCONF'. It cannot be replaced or removed. No other event stream can have this name. The standard NETCONF notification events are always sent to this event stream, unless there is an event-stream-map assigning the module to a different event stream.

leaf-list event-stream {
   type ywt:NcxNumName;
}

Syntax

NcxName (string)

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --event-stream=hardware --event-stream=routing

--event-stream-map

The --event-stream-map parameter specifies a module name to event-stream mapping for notification handling. A mapping is a structured string using the form

<module-name>@<stream-name>
  • The 'module-name' field is the case-sensitive module name for the mapping.

  • The 'stream-name' field is the case-sensitive stream name for the mapping. It must match an 'event-stream' parameter or the default 'NETCONF'.

  • Note there is no need to define a mapping for the 'NETCONF' stream since it will be picked if no other stream is selected.

The built-in notifications such as <replayComplete> Event and <notificationComplete> Event are subscription-specific and always sent only to the subscription, not the event stream. Therefore these notifications are not affected by this parameter.

leaf-list event-stream-map {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --event-stream-map=ietf-hardware@hardware

--factory-startup

The --factory-startup CLI parameter forces the server to over-write the startup configuration file and replace it with the factory installed default configuration.

Force the system to use the factory configuration and delete the startup config file if it exists. Force the NV-storage startup to contain the factory default configuration.

Use this parameter with caution!!! Use the backup operation to save the current configuration first.

leaf factory-startup {
  type empty;
}

Syntax

--factory-startup

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --factory-startup

--ha-enabled

The --ha-enabled parameter is used to enable or disable the High Availability protocol (YP-HA). This allows redundant systems to stay up-to-date with all configuration changes, and other server state.

  • If 'true', then YP-HA will be enabled

  • If 'false', then YP-HA will be disabled.

If this parameter is enabled then the following parameters must be configured or the server will exit with an error:

leaf ha-enabled {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --ha-enabled=true

--ha-initial-active

The --ha-initial-active parameter specifies the server name for the initial YP-HA active server. This is ignored unless --ha-enabled=true.** There is no default.

This parameter is used to hardwire the initial High Availability roles instead of setting it in the yp-system init1 or init2 callback functions. If this parameter is the same as 'server-id' then this server will be the initial YP-HA active server.

This parameter is intended for debug mode only. The real operational mode should use signaling only to set the HA mode. Otherwise if the server reboots it will use the configured HA mode, which may not be correct if it has been changed during runtime.

leaf ha-initial-active {
  type nt:NcxName;
}

Syntax

string (NcxName)

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --ha-initial-active=ha-1

--ha-server

The --ha-server parameter specifies a server in the YP-HA server pool.

This parameter must be configured if the --ha-enabled parameter is set to true.

This string has the format:

<server-id> '@' <server-addr> [ ':' <port-num> ]

Examples:

server1@192.168.0.101

server1@192.168.0.101:12040

If no port number is used then the port '8088' is used.

The server-addr field must match the --socket-address parameter for the server.

The port-num field must match the --socket-port parameter for the server.

The server running with this configuration must be listed in the ha-server pool. The --server-id parameter must match the entry for this server.

There must be at least 2 entries present to configure an HA server pool.

leaf-list ha-server {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

no limit

Supported by:

netconfd-pro

Example:

netconfd-pro --ha-server=ha-1@192.168.0.100

--ha-server=ha-2@192.168.0.10:8090

--ha-server-key

The --ha-server-key parameter specifies the string the standby server must present to the active server during registration. Used to prevent servers from going the wrong HA pool. If not set then the active server will reject the YP-HA connection. This parameter must be set if the ha-enabled parameter is set to 'true'. It is ignored unless --ha-enabled=true.** There is no default.

leaf ha-server-key {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --ha-server-key=ha-pool-1

--ha-sil-standby

The --ha-sil-standby parameter specifies whether the edit callbacks such as SIL, SIL-SA and HOOK instrumentation will be invoked if the server is operating in HA standby mode.

leaf ha-sil-standby {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --ha-sil-standby=true

--hello-timeout

The --hello-timeout parameter controls the maximum number of seconds that the netconfd-pro server will wait for a <hello> PDU, for each session.

If set to 0, then hello state timeouts will be disabled, meaning that no sessions will be deleted while waiting for a <hello> PDU.

The hello timer starts when a session is started within the server, and therefore using a session resource that counts against the 'max-sessions' limit.

For NETCONF over SSH sessions the session starts after the SSH session is setup and the 'netconf' subsystem is invoked. The SSH server has its own timeout values for maximum session startup time. For NETCONF over TLS sessions the session starts when the TCP connection is accepted.

Note

It is strongly suggested that this parameter not be disabled, since a denial-of-service attack will be possible if sessions are allowed to remain in the 'hello wait' state forever.

A finite number of SSH and NETCONF sessions are supported, so if an attacker simply opened lots of SSH connections to the netconf subsystem, the server would quickly run out of available sessions.

Sessions cannot be deleted manually via <kill-session> operation if no new sessions are being allocated by the server.

leaf hello-timeout {
   type uint32 {
      range "0 | 10 .. 3600";
   }
   units seconds;
   default 600;    // 10 minutes
}

Syntax

uint32; 0 == disabled;

range 10 .. 3600 seconds (1 hour max)

Default:

600 (10 minutes)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --hello-timeout=300

--hide-module

The --hide-module parameter specifies the name of a module to hide from advertisements to client sessions. If the specified module name is loaded into the server, then this parameter will cause it to be omitted from the following data structures:

  • YANG 1.0 <hello> message

  • /netconf-state/schemas/schema list

  • /modules-state/module list

This parameter will prevent the client from knowing about the hidden module. If an advertised module imports a hidden module then it is very likely a client will not be able to use the advertised module because of the missing imports.

This parameter can be dangerous! It does not prevent loading or enabling of the module. The SIL code is responsible for not returning any data to a client using a hidden module.

Warning

Use of this parameter violates conformance to NETCONF, RESTCONF, and the YANG Library. Use with caution, only for modules that are not accessible by clients.

leaf-list hide-module {
   type nt:NcxName;
}

Syntax

string: module name

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --hide-module=mysecretmod

--idle-timeout

The --idle-timeout parameter controls the maximum number of seconds that the netconfd-pro server will wait for a <rpc> PDU, for each session.

If set to 0, then idle state timeouts will be disabled, meaning that no sessions will be deleted while waiting for a <rpc> PDU.

A session will never be considered idle while a notification subscription is active.

Warning

It is strongly suggested that this parameter not be disabled, since a denial-of-service attack will be possible if sessions are allowed to remain in the 'idle wait' state forever.

A finite number of SSH and NETCONF sessions are supported, so if an attacker simply opened lots of SSH connections to the netconf subsystem, the server would quickly run out of available sessions.

This parameter will affect a <confirmed-commit> operation!

Make sure this timeout interval is larger than the value of the <confirm-timeout> parameter used in the confirmed commit procedure. Otherwise, it is possible that the session will be terminated before the confirm-timeout interval has expired, effectively replacing that timer with this one.

leaf idle-timeout {
   type uint32 {
      range "0 | 10 .. 360000";
   }
   units seconds;
   default 3600;    // 1 hour
}

Syntax

uint32

Default:

3600 (1 hour)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --idle-timeout=30000

--import-version-bestmatch

The --import-version-bestmatch parameter specifies if the bestmatch search feature should be used for import resolution when no revision-date field is specified in the import-stmt.

If 'true' then the server will scan the module search path during startup and determine the most recent revisions of each module. If a module is loaded or imported and no revision date is specified then the best match revision will be used.

This feature requires some additional memory and bootup processing time. It should be avoided if possible. The module search path on the server should only contain the modules and revisions that are needed by the server.

If set to 'false', then the best match feature will not be enabled. It is possible for the server to find and load the wrong version of a module during imports processing.

For example, while loading module A, it imports module B. Then module B is loaded but a revision is specified (e.g., --module=B@2019-06-20). This can cause errors during callback registration such as 'definition not found' or 'segment not found', depending on how the module has changed.

leaf import-version-bestmatch {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --import-version-bestmatch=true

--library-mode

The --library-mode parameter is used to run the server in YANG library mode.

Note

Refer to the Using the Server in Library Mode section for details on Library Mode usage.

The NETCONF <get-schema> operation will support retrieval of the YANG modules found in the search path.

leaf library-mode {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --library-mode=true

--loadpath

The --loadpath parameter specifies the YANG module load path to use while loading YANG modules at boot-time. It consists of a colon (':') separated list of path specifications, commonly found in Unix, such as the $PATH environment variable.

This parameter overrides the $YUMAPRO_LOADPATH environment variable, if it is present.

leaf loadpath {
  type yt:NcPathList;
}

Syntax

string: list of directory specifications

Default:

$YUMAPRO_LOADPATH environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --loadpath =”~/testmodules:~/modules:~/trunk/netconf/modules”

--log-event-drops

The --log-event-drops parameter indicates if a log entry would be generated when a notification is dropped because the specific notification events are disabled with an event-filter configuration entry.

This parameter has no effect if the --with-notifications CLI parameter is set to false.

leaf log-event-drops {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --log-event-drops=true

--log-pthread-level

The --log-pthread-level parameter controls the verbosity level of thread-specific messages printed to the log file or STDOUT, if no log file is specified. Note that this parameter is only effective in thread-based images.

This parameter uses the same values as the --log-level parameter.

leaf log-pthread-level {
  type nt:NcDebugType;
}

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info (debug for DEBUG builds)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro > --log-pthread-level=debug --log=~/server.log&

--log-vendor

The --log-vendor parameter directs log output to be sent to a customer-written and registered callback function, rather than to STDOUT.

This functionality is defined by an API specified in the Syslog Interface section.

In the absence of a registered callback, this parameter will direct logging messages to syslog. See the --log-console parameter for information on how log output may also be duplicated via STDOUT.

leaf log-vendor {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-vendor

--log-vendor-level

The --log-vendor-level parameter sets the vendor debug logging level filter for output to the vendor-specific log output file stream for the program.

This parameter uses the same values as the --log-level parameter.

leaf log-vendor-level {
  type yt:NcDebugType;
}

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --log-vendor-level=debug

--max-burst

The --max-burst parameter specifies the maximum number of notifications to send in a burst, to one session. Even though TCP will control the transmission rate, this parameter can limit the memory usage due to buffering of notifications waiting to be sent.

The value zero means no limit will be used at all.

leaf max-burst {
  type uint32;
  default 10;
}

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-burst=100

--max-cli-sessions

The --max-cli-sessions parameter specifies the maximum number of concurrent CLI sessions to allow at any time.

The value zero means no artificial limit will be used at all. The --max-sessions parameter has precedence, so setting this parameter to a value larger than --max-sessions will have no effect.

leaf max-cli-sessions {
  type uint16 {
    range "0 .. 1024";
  }
  default 0;
}

Syntax

uint32 (0 .. 1024)

Default:

0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-cli-sessions=2

--max-getbulk

The --max-getbulk parameter specifies the maximum number of getbulk entries to request from a GET2 callback.

  • This value will be used in the get2cb 'max_entries' field.

  • The value 0 is used to indicate there is no max and the GET2 callback can return as many getbulk entries as desired.

Note

A GET2 callback is expected to ignore this value for a leaf-list object and always return all instances of the leaf-list.

leaf max-getbulk {
  type uint32;
  default 10;
}

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-getbulk=100

--max-sessions

The --max-sessions parameter specifies the maximum number of concurrent sessions to allow at any time.

The value zero means no artificial limit will be used at all.

leaf max-sessions {
  type uint16 {
    range "0 .. 1024";
  }
  default 8;
}

Syntax

uint32 (0 .. 1024)

Default:

8

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-sessions=10

--max-strlen

The --max-strlen parameter specifies the maximum number of bytes in length that will be accepted for a quoted string, by the internal token parser.

  • This affects YANG and JSON input processing.

  • Set this value to allow large binary leafs to be parsed by the server.

  • This value includes 1 byte for the string termination character.

  • The minimum size is 64 KBytes.

  • The maximum is 2 billion bytes.

  • The default is 256 KBytes.

leaf max-strlen {
  type int32 {
     range "65536 .. max";  // 64KB to 2G-1
  }
  units bytes;
  default 262144;  // 256K
}

Syntax

int32 (65536 .. INT_MAX)

Default:

262144

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-strlen=1000000

--module-tagmap

The --module-tagmap parameter is a leaf-list of module name to module-tag mappings.

  • Specifies a module tag mapping for use in module tags registry.

  • The format is <modname>@<tag-string>.

  • Strings should follow the format in the ietf-module-tags YANG module.

The <get> and <get-config> operations accept this parameter, which is used as a filter to include only data nodes from modules that match the specified module-tag.

Examples:

leaf-list module-tagmap {
  type string;
}

Syntax

structured string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --module-tagmap=test1@test --module-tagmap=test2@test

--netconf-capability

The --netconf-capability parameter is a leaf-list of URI values that should be added to the server NETCONF <hello> message as a NETCONF <capability> URI and monitoring data in the /netconf-state/capabilities container.

To add vendor capabilities:

leaf-list netconf-capability {
  type inet:uri;
}

Syntax

inet:uri

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --netconf-capability=urn:acme:test

--netconf-tls-address

The --netconf-tls-address parameter specifies the IP address to listen on for NETCONF over TLS messages.

This parameter is ignored if the --with-netconf-tls parameter is set to ‘false’.

leaf netconf-tls-address {
  type inet:ip-address;
  default "0.0.0.0";
  reference "RFC 7589: NETCONF over TLS";
}

Syntax

inet:ip-address

Default:

0.0.0.0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --netconf-tls-address=192.168.0.15

--netconf-tls-certificate

The --netconf-tls-certificate parameter contains the file path specification for the file containing the server SSL certificate, used for the NETCONF over TLS protocol.

This parameter is ignored if the --with-netconf-tls parameter is set to ‘false’.

leaf netconf-tls-certificate {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/netconfd-pro.crt";
}

Syntax

string

Default:

$HOME/.ssl/netconfd-pro.crt

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --netconf-tls-certificate=/etc/ssl/certs/mycert.crt

--netconf-tls-key

The --netconf-tls-key parameter contains the file path specification for the file containing the server SSL private key, used for the NETCONF over TLS protocol.

This parameter is ignored if the --with-netconf-tls parameter is set to ‘false’.

leaf netconf-tls-key {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/netconfd-pro.key";
}

Syntax

string

Default:

$HOME/.ssl/netconfd-pro.key

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --netconf-tls-key=/etc/ssl/private/mycert.key

--netconf-tls-port

The --netconf-tls-port parameter specifies the TCP port number to listen on for NETCONF over TLS messages.

This parameter is ignored if the --with-netconf-tls parameter is set to ‘false’.

leaf netconf-tls-port {
  type inet:port-number;
  default 6513;
  reference "RFC 7589: NETCONF over TLS";
}

Syntax

inet:port-number

Default:

6513

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --netconf-tls-port=10200

--netconf-tls-trust-store

The --netconf-tls-trust-store parameter contains the file path specification for the file containing the server SSL trust-store, or the path specification for the directory to use for finding trusted certificates. If the default value is used and the file is not found, then the default directory location '/etc/ssl/certs' will be used.

This parameter is ignored if the --with-netconf-tls parameter is set to ‘false’.

leaf netconf-tls-trust-store {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/trust-store.pem";
}

Syntax

string

Default:

$HOME/.ssl/trust-store.pem

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --netconf-tls-trust-store=/opt/certs

--no-audit-log

The --no-audit-log parameter specifies that no default audit log will be created. This parameter is only relevant if --fileloc-fhs=true.

The --audit-log parameter cannot be present if this parameter is present.

leaf no-audit-log {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --fileloc-fhs=true --no-audit-log

--no-log

The --no-log parameter specifies that no main log file will be created. This is usually only relevant if --fileloc-fhs is 'true'.

This is usually only relevant if --fileloc-fhs is 'true'. In this case the default log file will not be created. The --log-level parameter will be set to 'off'.

This parameter will be ignored if the --log parameter is set.

This parameter has no affect on the audit-log or syslog logging.

leaf no-log {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-log --fileloc-fhs=true

--no-nvstore

If the --no-nvstore parameter is present, the server should not load or save using the normal APIs during transaction management.

  • The 'start' choice will be ignored and the server will not attempt to load a startup-cfg.xml file.

  • Transactions will not be saved to NV-storage at all.

  • Any external NV-storage callbacks will be ignored.

The following operations are not affected by this parameter:

  • <backup> operation

  • <restore> operation

  • confirmed-commit procedure will save backup-cfg.xml to use if the commit needs to be rolled back

Use this mode if NV-load and NV-storage are handled internally and not via the startup-cfg.xml file.

The default is not present.

leaf no-nvstore {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-nvstore

--no-startup

The --no-startup parameter specifies that the default startup configuration file (any startup-cfg.xml in the data search path) should not be loaded, even if it is present.

If present, do not load the startup config file. Use the factory default settings but do not overwrite the NV-storage startup unless it is altered.

This option does not delete the startup config file if it exists.

leaf no-startup {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-startup

--no-watcher

The --no-watcher parameter controls the ypwatcher program.

If present, do not launch the ypwatcher program. If this parameter is present, then the --watcher-interval parameter cannot be present.

This parameter is useful for debugging server code to make sure the ypwatcher does not interfere if the server is stopped at a breakpoint.

leaf no-watcher {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-watcher

--push-max-operational

The --push-max-operational parameter specifies the maximum number of on-change push subscriptions that can be in use at once for the <operational> datastore. The value zero will disable on-change subscriptions for the <operational> datastore. Applies to all sessions.

Setting this parameter to a high value can increase the resources used by the server. Use with extreme caution.

leaf push-max-operational {
  type uint32;
  units "subscriptions";
  default 4;
}

Syntax

uint32 (subscriptions)

Default:

4

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --push-max-operational=0

--push-max-periodic

The --push-max-periodic parameter specifies the maximum number of periodic push subscriptions that can be in use at once. The value zero will disable periodic subscriptions. Applies to all sessions.

Setting this parameter to a high value can increase the resources used by the server. Use with extreme caution.

leaf push-max-periodic {
  type uint32;
  units "subscriptions";
  default 16;
}

Syntax

uint32 (subscriptions)

Default:

16

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --push-max-periodic=0

--push-min-dampening

The --push-min-dampening parameter specifies the minimum value for the 'dampening-period' parameter that will be accepted for an on-change push subscription. Applies to all sessions.

Setting this parameter to a low value can increase the resources used by the server. Use with extreme caution.

leaf push-min-dampening {
  type uint16 {
    range "1 .. max";
  }
  units "centiseconds";
  default 100;    // 1 second
}

Syntax

uint32 (centiseconds)

Default:

100

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --push-min-dampening=10

--push-min-period

The --push-min-period parameter specifies the minimum value for the 'period' parameter that will be accepted for a periodic push subscription.

Setting this parameter to a low value can increase the resources used by the server. Use with extreme caution.

leaf push-min-period {
  type uint16 {
    range "1 .. max";
  }
  units "centiseconds";
  default 100;    // 1 second
}

Syntax

uint32 (centiseconds)

Default:

100

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --push-min-period=10

--push-simop-enabled

The --push-simop-enabled parameter specifies if the simulated on-change push subscriptions should be enabled for the <operational> datastore. The value false will disable simulated on-change subscriptions for the <operational> datastore. Applies to all sessions.

Real on-change subscriptions reported from subsystems are not affected by this parameter.

leaf push-simop-enabled {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --push-simop-enabled=false

--push-simop-patch-update

The --push-simop-patch-update parameter specifies the notification message that should be used for a simulated on-change push subscription.

If 'true' then the standard <push-change-update> notification will be used for the report. This format uses YANG Patch to report individual edits. This is conformant with RFC 8641 requirements.

If 'false' then the non-standard <push-update> notification will be used for the report. This will make the subscription similar to a periodic subscription, except that an update is only sent when the content changes. This is not conformant with RFC 8641 requirements.

Real on-change subscriptions reported from subsystems are not affected by this parameter.

leaf push-simop-patch-update {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --push-simop-patch-update=false

--push-simop-period

The --push-simop-enabled parameter specifies if the simulated on-change push subscriptions should be enabled for the <operational> datastore. The value false will disable simulated on-change subscriptions for the <operational> datastore. Applies to all sessions.

Real on-change subscriptions reported from subsystems are not affected by this parameter.

leaf push-simop-period {
  type uint16 {
    range "1 .. max";
  }
  units "centiseconds";
  default 500;    // 5 seconds
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --push-simop-enabled=false

--remove-schema-aug-leafs

The --remove-schema-aug-leafs parameter is used to remove the 'conformance' and 'module-type' leafs from the /netconf-state/schemas/schema list.

  • The deprecated leafs are added if --with-yumaworks-system is true.

  • This parameter allows the rest of yumaworks-system.yang to be used, such as the RPC operations.

  • The leafs will be removed from the 22.10 release train when the status is changed to obsolete.

  • This parameter will be forced to the value 'true' if the server is built with the REMOVE_SCHEMA_AUG_LEAFS=1 compile flag.

  • This parameter has no effect if the --with-yumaworks-system CLI parameter is set to false.

Note

The default is 'false' to maintain backward compatibilty with previous releases. The value 'true' should be used since the information from these deprecated leafs is available in the YANG Library data structures.

leaf remove-schema-aug-leafs {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --remove-schema-aug-leafs=true

--restconf-capability

The --restconf-capability parameter is a leaf-list of URI values that should be added to the server as monitoring data in the /restconf-state/capabilities container.

To add vendor capabilities:

leaf-list restconf-capability {
  type inet:uri;
}

Syntax

inet:uri

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --restconf-capability=urn:acme:foo1

--restconf-default-encoding

The --restconf-default-encoding parameter specifies the default response encoding to use if the incoming request does not have an indication of preferred content type (E.g., no Content-Type header, no Accept header).

The values “xml” and “json” are supported.

leaf restconf-default-encoding {
  type enumeration {
    enum json {
      description "Use JSON message encoding as the default.";
    }
    enum xml {
      description "Use XML message encoding as the default.";
    }
  }
  default json;
}

Syntax

enum (xml, json)

Default:

json

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --restconf-default-encoding=xml

--restconf-server-url

The --restconf-server-url parameter specifies the starting string for the server URL to use in Location header lines returned by RESTCONF.

leaf restconf-server-url {
  type inet:uri;
  default "http://localhost";
}

Syntax

inet:uri

Default:

http://localhost

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --restconf-server-url= https://device1.example.com

--restconf-strict-headers

The --restconf-strict-headers parameter specifies how the RESTCONF server will validate Accept header entries.

If set to 'true' the server will only accept requests with normative Accept and Content-Type headers entries specified in the draft-ietf-netconf-restconf-18. The Accept header must not be empty; otherwise 'not acceptable' error will be returned.

Normative Accept header:

application/yang-data+xml,application/yang-data+json;q=0.9

Normative Content-Type headers:

application/yang-data+xml

application/yang-patch+json

If set to 'false', the server will try to accept additional non-normative header entries.

Acceptable non-normative Accept header:

application/xml,application/json;q=0.9

Acceptable non-normative Content-Type headers:

application/xml

application/json

text/xml
leaf restconf-strict-headers {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --restconf-strict-headers=true

--running-error

The --running-error parameter is an enumeration, specifying how the netconfd-pro server will treat errors encountered while validating the running database, when loaded from the non-volatile startup configuration at boot-time.

  • Affects processing of the running datastore at boot-time.

  • This parameter is used together with the --startup-error parameter.

There are 3 values supported:

  • stop: Terminate the program if any errors are encountered in the running configuration.

  • continue: Continue the program if any errors are encountered in the running configuration.

    Note

    Altering the running configuration will fail until the commit validation tests succeed. This mode is intended to allow an operator to correct a mis-configured device.

  • fallback: Fallback to the factory configuration if errors are encountered in the running configuration at boot time. The server will restart as if the --factory-startup configuration parameter was used.

    Note

    The server will restart with the factory configuration. This mode is intended to recover a device that is expected to have a correct startup configuration.

leaf running-error {
   type enumeration {
     enum stop {
     }
     enum continue {
     }
     enum fallback {
     }
  }
  default stop;
}

Syntax

enum:
stop
continue
fallback

Default:

stop

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --running-error=continue

--save-owners

The --save-owners parameter specifies whether owner names will be saved as meta-data with the configuration data.

The owner is the client user-name assigned to the session.

leaf save-owners {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --save-owners=true

--session-sync-mutex

The --session-synch-mutex parameter, if present, will force synchronous request processing (pthread version only).

Note

This parameter is deprecated. Do not use.

leaf session-sync-mutex {
  type empty;
  status deprecated;
}

Syntax

empty

Default:

not preset

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --session-sync-mutex

--sil-delete-children-first

The --sil-delete-children-first parameter specifies how the server should handle data node deletions.

If 'true', the server default behavior will be to treat all data deletion operations as if the ncx:sil-delete-children-first extension is present. A child node will be checked for a SIL callback before it is deleted.

If 'false' the server default behavior will be to invoke SIL callbacks for deletion of child nodes only if the ncx:sil-delete-children-first extension is present.

leaf sil-delete-children-first {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-delete-children-first=true

--sil-invoke-for-defaults

The --sil-invoke-for-defaults parameter specifies how the server should handle SIL callbacks for default data nodes.

If 'true' then when a SIL or SIL-SA callback will be invoked for default data nodes during the load and load_config operations.

If 'false' then a SIL or SIL-SA callback will not be invoked for default data nodes.

leaf sil-invoke-for-defaults {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-invoke-for-defaults=false

--sil-missing-error

The --sil-missing-error parameter indicates if a missing SIL library file will be treated as an error or not.

If 'true' then when a module is loaded, but the SIL library code for the module is not found, an error will be returned instead of a warning printed.

If 'false' then when a module is loaded, but the SIL library code for the module is not found, no error will be returned. Instead, only a warning will be printed.

leaf sil-missing-error {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-missing-error=true

--sil-prio-reverse-for-deletes

The --sil-prio-reverse-for-deletes parameter specifies whether edit transactions are validated by the regular SIL priority of should be reversed for DELETE edits. This parameter can be used to delete leafref nodes with referenced by node in reverse order.

It is possible for the client to send several edits within a single <edit-config> request. Sometimes it is useful to make sure certain data structures are validated and processed before other data structures.

The ywx:sil-priority extension can be used to control the order of the edits and how they are processed.

  • If set to "true" the "sil-prio-reverse-for-deletes" parameter for netconfd-pro dictates that the SIL priority for DELETE operations will be reversed. This parameter can be used to delete leafref nodes with referenced by node in reverse order.

  • If 'false' then the SIL priority will not be reversed. The default is "false".

When the parameter is set to "true" the server will invoke callbacks for the specific objects with "sil-prority" configured in reverse order.

  • It will NOT change the "sil-priority" of the specific objects, it will instead reverse the "sil-priority" and the server will invoke the callbacks in reverse order

  • This parameter will reverse "sil-priority" only if the edit operation is DELETE or REMOVE

  • The server will not reverse the "sil-priority" for EDIT2 MERGE mode with mixed edits (if there is delete and other operations). Since the real operation is in the children objects and the server invokes a single callback for all the children edits at once.

Please note that the EDIT2 MERGE edits will not make any effect on the invocation order if the callbacks have mixed operations on children (if there are delete on one child and other edit operation on second child), they will not be reversed anyhow.

The EDIT2 MERGE mode combines multiple edits in one callback and the server invokes just one callback for all the edits. The server has no control of when it should reverse the priority for this callback in case of mixed children operations.

The priority in this case will remain the same and the server will warn a user with following warning:

SIL priority for object 'uint16-leaf' set to 100.100

Warning: Cannot reverse SIL priority for EDIT2 child 'test:uint16-leaf'

However, in case the EDIT2 MERGE mode has only delete or remove operations on children the priority for this callback will be reversed.

leaf sil-prio-reverse-for-deletes {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-prio-reverse-for-deletes=true

--sil-root-check-first

The --sil-root-check-first parameter is used to control the order of the YANG validation procedure during edit transaction processing. It affects the <edit-config> operation, but not the <commit> operation.

If 'true', the server will perform a YANG validation check before the SIL validate callbacks are invoked for an edit-config operation. This is always done for a load-config or commit operation.

If 'false', the server will invoke the SIL validate callbacks before performing a YANG validation check. Instead the validation will be done before the SIL apply callback. This is the only behavior in the 17.10 release train.

It is recommended that the default setting be used. This parameter is provided in case existing SIL callbacks depend on the order of the validation processing.

If the <edit-config> operation is used on the candidate datastore then no YANG validation is done unless the “test-option” used is “test-then-set”.

leaf sil-root-check-first {
  type boolean;
  default true;
}

Syntax

boolean

default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-root-check-first=false

--sil-skip-load

The --sil-skip-load parameter is an empty leaf, specifying whether the SIL edit callback functions will be skipped during system initialization.

Normally the SIL callbacks are invoked when the running datastore is loaded from non-volatile storage. If this parameter is present these SIL callback functions will not be invoked during the load_running_config operation.

leaf sil-skip-load {
  type empty;
}

Syntax

empty

default:

none (not present)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-skip-load

--sil-test-get-when

The --sil-test-get-when parameter specifies the global default for evaluating when-stmts on operational data nodes during retrieval operations. If 'true', the server will evaluate 'when' statements for GET2 callback requests for config=false nodes. If 'false' then the SIL or SIL-SA callback is expected to test the 'when' condition internally somehow and return a no-instance error if the condition is 'false'.

This parameter can be overridden by the ywx:sil-test-get-when YANG extension. If that extension is found for an operational data node then its value will be used instead of this parameter.

leaf sil-test-get-when {
  type boolean;
  default false;
}

Syntax

boolean

default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-test-get-when=true

--sil-validate-candidate

The --sil-validate-candidate parameter specifies whether edit transactions on the candidate datastore are validated by the object SIL callbacks or not. If true, then edits to the candidate datastore are validated by SIL callbacks. If false, then edits to the candidate datastore are not validated by SIL callbacks..

The SIL callbacks will be invoked if an attempt to commit the candidate datastore to the running datastore is done. The only SIL callbacks that would be skipped are the individual edits to the candidate datastore. If 'true' then the client might be informed of an error sooner. If 'false' then edit processing will be faster.

Validate callbacks for the candidate configuration are invoked on behalf of these operations:

This parameter has no affect unless the --target parameter is set to “candidate”.

leaf sil-validate-candidate {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-validate-candidate=false --target=candidate

--simple-json-names

The --simple-json-names parameter specifies whether the server will output name of the module in which the data node is defined or not.

If false, a namespace-qualified member name will be used for all members of a top-level JSON object and then also whenever the namespaces of the data node and its parent node are different. In all other cases, the simple form of the member name will be used.

The default value is to use strict JSON encoding, based on RFC 7951.

leaf simple-json-names {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --simple-json-names=true

--socket-address

The --socket-address parameter specifies the IPv4 address to listen on when the --socket-type parameter is set to 'tcp'. It is ignored if the socket-type is 'aflocal'.

Note that this parameter specifies the IP address for internal <ncx-connect> protocol messages. The server will accept NETCONF sessions over SSH, as specified in the OpenSSH config file.

leaf socket-address {
  type inet:ip-address;
  default "0.0.0.0";
}

Syntax

inet:ipv4-address

default:

0.0.0.0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --socket-address=192.168.0.10 --socket-type=tcp

--socket-port

The --socket-port parameter specifies the TCP port number to listen on when the --socket-type parameter is set to 'tcp'. Ignored if the socket-type is 'aflocal'.

Note that this parameter specifies the port number for internal <ncx-connect> protocol messages. The server will accept NETCONF sessions over SSH, specified with the 'port' parameter (E.g. 830).";

leaf socket-port {
  type inet:port-number;
  default 2023;
}

Syntax

inet:port-number

default:

2023

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --socket-port=8082 --socket-type=tcp

--socket-type

The --socket-type parameter specifies which type of socket the server should create for incoming <ncx-connect> protocol sessions. The “tcp” mode is useful for debugging the packets between thin client (e.g., netconf-subsystem-pro programs).

This mode is required for:

  • sil-sa-app on a different platform than the netconfd-pro process.

  • YP-HA standby servers

    Warning

    This mode is not secure. You should use some system mechanism to control access to the socket identified by the --socket-address and --socket-port parameter.

Two enumeration values are supported:

The “tcp mode” can also be used to distribute the components on different systems than the one running the netconfd-pro server. In this case follow these instructions on the host running the front-end application (e.g. the host running OpenSSH):

Manual configuration for distributed system

> echo IPADDR:PORT > /tmp/netconfd-pro-subsys-info.txt

where IPADDR is the IPv4 address and PORT is the TCP port number

Example using IP address 192.168.0.10 and port 2023:

> echo 192.168.0.10:2023 > /tmp/netconfd-pro-subsys-info.txt
leaf socket-type {
  type enumeration {
    enum aflocal {
    }
    enum tcp {
    }
  }
  default aflocal;
}

Syntax

enumeration

default:

aflocal

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --socket-type=tcp

--startup

The --startup parameter specifies the file to use to load into the running configuration at boot-time. It contains the full or relative filespec of the startup configuration file to use.

  • If present, it overrides the default startup config file name startup-cfg.xml.

  • This will also override the YUMAPRO_DATAPATH environment variable and the datapath CLI parameter, if the first character is the forward slash '/', indicating an absolute file path.

  • For a relative filespec, the $YUMAPRO_DATAPATH environment variable or --datapath parameter will be used to search for the specified file name.

  • If not present and --no-startup is also not present, the $YUMAPRO_DATAPATH environment variable or --datapath parameter will be used to search for the default file name startup-cfg.xml.

Note

This parameter is not related to the <startup> datastore or --with-startup parameter.

leaf startup {
  type string;
}

Syntax

filespec

Default:

first startup-cfg.xml in the data path

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup=$TESTDIR/testrun

start choice

The start choice parameter specifies how the netconfd-pro server will load the non-volatile startup configuration at boot-time. If no choice is made at all, then the server will check its data path for the file startup-cfg.xml.

There are 3 values supported:

choice start {
  leaf no-startup {
    type empty;
  }

  leaf factory-startup {
    type empty;
  }

  leaf startup {
    type string;
  }
}

Syntax

choice:

Default:

first startup-cfg.xml in the data path

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup=$TESTDIR/testrun

--startup-error

The --startup-error parameter is an enumeration, specifying how the netconfd-pro server will treat errors encountered while loading the non-volatile startup configuration at boot-time.

  • Affects processing of the startup configuration file.

  • This parameter is used together with the --running-error parameter.

There are 3 values supported:

  • stop: Terminate the program if any errors are encountered in the running configuration.

  • continue: Continue the program if any errors are encountered in the running configuration.

    Note

    Altering the running configuration will fail until the commit validation tests succeed. This mode is intended to allow an operator to correct a mis-configured device.

  • fallback: Fallback to the factory configuration if errors are encountered in the running configuration at boot time. The server will restart as if the --factory-startup configuration parameter was used.

    Note

    The server will restart with the factory configuration. This mode is intended to recover a device that is expected to have a correct startup configuration.

leaf startup-error {
   type enumeration {
     enum stop {
     }
     enum continue {
     }
     enum fallback {
     }
  }
  default stop;
}

Syntax

enum:
stop
continue

fallback

Default:

stop

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup-error=fallback

--startup-factory-file

The --startup-factory-file parameter specifies the file to use to load into the running configuration at boot-time under the following conditions:

  1. first-time boot and no configuration file found

  2. --factory-startup CLI option used

  3. server is in a factory default restart (--running-error=fallback or --startup-error=fallback)

The default is to check the data path for the file factory-startup-cfg.xml. Specifies the file name of the boot-time configuration. The server expects this to be an XML configuration file. Unless a path specification is included, the $YUMAPRO_DATAPATH environment variable or --datapath parameter will be used to search for the specified file name. No '.xml' extension will be added. The exact file name will be used instead.

If this parameter is set and the filespec is not found then the server will exit with an error. If the default filespec is not found then an empty datastore will be used to load the running configuration datastore at boot-time.

leaf startup-factory-file {
  type string;
  default "factory-startup-cfg.xml";
}

Syntax

filespec

Default:

first factory-startup-cfg.xml in the data path

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup-factory-file=start1.xml

--startup-prune-ok

The --startup-prune-ok parameter specifies if unknown nodes can be skipped at boot-time.

If set to 'true' then the server will prune unknown data nodes from the startup configuration instead of treating this as an error. A log_info message will be printed. If other known data nodes depend on the pruned nodes, then an error may occur anyway. If so, the 'startup-error' parameter will determine how this is handled.

If set to 'false' then unknown data nodes found in the startup configuration will cause an error.

Unknown data nodes can occur if modules were previously loaded dynamically, or if a YANG feature is configured from enabled to disabled.

leaf startup-prune-ok {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup-prune-ok=true

--startup-skip-validation

The --startup-skip-validation parameter specifies if the YANG validation should be skipped when loading the startup configuration at boot-time.

If set to 'true' then the server will skip all YANG validation of the startup configuration when it is loaded into the running configuration at boot-time. This should make the server boot faster but it assumes the startup configuration is already valid. Only the initial startup load operation is affected by this parameter.

This parameter affects the 'root check' only. This includes the following datastore validation:

  • must

  • when (see note)

  • leafref path

  • unique

  • min-elements

  • max-elements

  • mandatory

This parameter does not affect 'default' processing or 'when' statement processing for default nodes. It does affect 'when' statement processing for nodes provided in the startup configuration.

It is possible that any invalid configuration will need to be fixed before any edits can be made to the <running> datastore. The full datastore can be checked using the <validate> operation.

If the startup configuration is completely valid such that all validation tests would have passed, then this parameter should be safe to use.

Warning

If the startup configuration contains data that does not pass the affected validation tests, then it may not be safe to use this parameter.

This is extremely dangerous and can lead to incorrect processing of datastore editing operations.

The server does not validate the complete datastore unless the <validate> operation is used. Any <edit-config> and <commit> operations done on a datastore that contains invalid YANG data may produce incorrect results. It is possible that edits will fail because the server detects invalid nodes from the startup during processing of the requested edit.

The <restore> operation is not affected by this parameter. It is possible to save an invalid configuration that cannot be restored. Use the <validate> operation before using the <backup> operation to ensure a backup configuration can be restored later.

If set to 'false' then startup validation is not skipped.

leaf startup-skip-validation {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup-skip-validation=true

--subsys-timeout

The --subsys-timeout parameter indicates the number of seconds to wait for a response from a sub-system before declaring a timeout.

  • The value '0' indicates that no timeout should be used.

  • The default is 30 seconds.

leaf subsys-timeout {
  type uint16;
  units seconds;
  default 30;
}

Syntax

uint16

Default:

30

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --subsys-timeout=0

--superuser

The --superuser parameter specifies the user name that the netconfd-pro server will treat as the super-user account. The 'root' account should be used with caution. It is strongly suggested that root access be disabled in sshd, and a different account be used as the NETCONF super-user account.

Any NETCONF session started with this user name will be exempt from access control enforcement. This is especially useful if the current NACM configuration is preventing access to the <nacm> subtree itself. The superuser account can be used in this situation to repair the mis-configured access control rules.

By default, no user will be accepted as the super-user account, if no value is specified.

Note

Do not set this parameter to an empty string. This mode is deprecated and should not be used. To disable all super-user account privileges, simply do not use this parameter.

leaf-list superuser {
  type union {
      type nt:NcxName;
      type string { length 0; }
  }
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --superuser=admin

--system-notifications

The --system-notifications parameter specifies the YANG module(s) the server should use for system events such as a new session, configuration change, or capability change.

This parameter uses the bits type. It is possible to configure zero, one, or both types of system notifications.

If 'ietf' is used, then the system notifications from the ietf-netconf-notifications module in RFC 6470 will be generated. This module can be found at ietf-netconf-notifications.yang.

If 'yuma' is used, then the system notifications from the yuma-system will be generated. This module can be found at yuma-system.yang.

Note

The "yuma-system" notifications are deprecated. Only the value ietf should be used.

leaf system-notifications {
     type bits {
       bit ietf {
       }
       bit yuma {
       }
     }
     default "ietf";
   }

Syntax

bits

Default:

ietf

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --system-notifications='ietf yuma'

--system-sorted

The --system-sorted parameter specifies whether the server will keep system-ordered lists and leaf-lists in sorted order.

If 'true', then lists and leaf-lists will be maintained in order, based on the list keys, or leaf-list value itself. If 'false', then system ordered entries will be kept in the order they were entered in the database.

All entries are maintained in schema-order (except list keys are ordered first).

Warning

THIS PARAMETER IS OBSOLETE. IT IS IGNORED BY THE SERVER.

leaf system-sorted {
  type boolean;
  default false;
  status deprecated;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --system-sorted=true

--target

The --target parameter specifies the name of the database that netconfd-pro will use as its edit target. There are two targets supported at this time:

This parameter controls the value of the <target> parameter allowed in the <edit-config> operation.

  • running: Edits will be written directly to the <running> configuration. The :startup capability will also be used in this mode. This means that a <copy-config> operation (from <running> to <startup>) must be used to save any edits to non-volatile storage, for use on the next reboot.

  • candidate: Edits will be written to the <candidate> configuration. The <commit> operation must be used to save any edits in <candidate> configuration into the <running> configuration. The non-volatile storage is updated automatically in this mode, and the <startup> configuration will not be present.

leaf target {
  type enumeration {
    enum running {
    }
    enum candidate {
    }
  }
  default candidate;
}

Syntax

enumeration: running candidate

Default:

candidate

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --target=running

--tls-crl-missing-ok

The --tls-crl-missing-ok parameter controls how a missing CRL Distribution Points section in a TLS certificate is handled.

  • If true then a missing CRL Distribution Points section within a client or CA certificate will be ignored. Not relevant unless --tls-crl-mode is set to 'client' or 'ca'.

  • If false, and CRL verification is enabled for the certificate, the TLS session will not be accepted.

Certificate revocation checking is still done, even if this parameter is set to ‘true’. If the --netconf-tls-trust-store parameter is set, then any hash.rN will be loaded into the openssl library and used to reject sessions using a revoked certificate. (E.g. /etc/ssl/certs/5443e9e3.r0)

leaf tls-crl-missing-ok {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --tls-crl-missing-ok=true

--tls-crl-mode

The --tls-crl-mode parameter controls how Certificate Revocation Lists are checked for NETCONF over TLS sessions.

This has no affect unless --with-netconf-tls=true is set.

  • off: Do not use CRL verification when verifying any certificates.

  • client: Use CRL verification when verifying client certificates.

  • ca: Use CRL verification when verifying client and CA certificates.

leaf tls-crl-mode {
  type enumeration {
    enum off {
    }
    enum client {
    }
    enum ca {
    }
  }
  default off;
}

Syntax

enum

Default:

off

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --tls-crl-mode=ca

--trim-whitespace

The --trim-whitespace parameter specifies if whitespace should be trimmed.

If true, then trim leading and trailing whitespace from XML string nodes. If false, adhere to the standard and do not trim any leading or trailing whitespace.

The server previously would trim whitespace but no longer does this by default.

This leaf must be set to trim this whitespace now.

This should only be needed if the NETCONF client does not send XML leaf nodes correctly.

Warning

Using this parameter will cause the NETCONF server to be non-compliant to RFC 6241.

leaf trim-whitespace {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --trim-whitespace=true

--usexmlorder

The --usexmlorder parameter specifies that the netconfd-pro server should enforce XML ordering when applicable (such as YANG list key leafs entered first). The default is not to check for adherence to strict XML order, as defined by YANG. The netconfd-pro server does not depend on XML order for normal operations.

leaf usexmlorder {
  type empty;
}

Syntax

empty

Default:

off

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --usexmlorder

--wait-datastore-ready

The --wait-datastore-ready parameter determines if client sessions will be available even if the running datastore is not ready to use yet.

For example, if SIL-SA bundles are used then the server must wait until all of them have been loaded (by subsystems) before the startup configuration can be loaded into the running datastore. The running datastore is not ready to use in this state.

If 'true' then client sessions will be locked until the datastores are ready. Protocol operations that do not access the datastores can be used in this state.

If 'false' then client session connections will be rejected until the datastores are ready.

Note

The default is 'false' only to be backwards-compatible. The 'true' setting should be used in most cases.

leaf wait-datastore-ready {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --wait-datastore-ready=true

--watcher-interval

The --watcher-interval parameter specifies the sleep interval between ypwatcher program attempts to check availability of the server. Provided value is in seconds.

The server does not accept the value of 0 for this parameter. The minimal acceptable value is 1 second.

leaf watcher-interval {
  type uint32 {
     range "1 .. max";
  }
  default 10;
}

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --watcher-interval=60

--with-callhome

The --with-callhome parameter controls whether the IETF CallHome over SSH protocol is enabled or not.

This feature is only available if the server image is built with the WITH_CALLHOME=1 or EVERYTHING=1 make flags.

If set to 'true', then the IETF Callhome for SSH feature will be enabled.

If set to 'false', then this feature will be disabled and the following CLI parameters will be ignored:

leaf with-callhome {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-callhome=true

--with-canonical

The --with-canonical parameter controls automatic conversion to canonical format for certain YANG data types.

If set to 'true', then the server will automatically convert XML and JSON input parameters to the canonical format for the YANG data type, if possible.

The following built-in YANG data types are affected:

  • ipv6-address

  • ipv6-address-no-zone

  • domain-name

  • phys-address

  • mac-address

  • hex-string

  • uuid

Any canonical callbacks for user-defined data types are also affected by this parameter.

Internal values can be manually converted to canonical format using the val_set_canonical API.

leaf with-canonical {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-canonical=false

--with-config-id

The --with-config-id parameter controls whether the server will enable or disable the :config-id capability URI in NETCONF <hello> messages.

  • If set to 'true', then the YumaWorks :config-id capability will be enabled. This is used to help cache device configurations. It is an enterprise capability URI, not a standard YANG module URI.

  • If set to 'false', then the YumaWorks :config-id capability will be disabled.

leaf with-config-id {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-config-id=false

--with-db-lock

The --with-db-lock parameter specifies if the DB-Config-Lock mode will be used. If set to 'true', then the server will use the DB-API DB-Config-Lock service for all configuration edit transactions to the <running> datastore. All client edits will be require this lock be granted or it will fail.

The server will use the db-lock-retry-interval and db-lock-timeout CLI parameters to control how lock retries will be done.

If set to 'false', the DB-Config-Lock will not be used by the server.

leaf with-db-lock {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-db-lock=true

--with-gnmi

The --with-gnmi parameter controls whether the gNMI protocol is enabled or not.

If set to 'true', then the gNMI protocol will be enabled. Otherwise, the gNMI protocol will not be enabled.

Any incoming connection will be dropped if the protocol is disabled.

leaf with-gnmi {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-gnmi=true

--with-grpc

The --with-grpc parameter controls whether the gRPC protocol is enabled or not.

If set to 'true', then the gRPC protocol will be enabled. Otherwise, the gRPC protocol will not be enabled.

Any incoming connection will be dropped if the protocol is disabled.

leaf with-grpc {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-grpc=true

--with-maintenance-mode

The --with-maintenance-mode parameter enables or disables the maintenance mode feature. It does not cause maintenance mode to be active or inactive. If set to 'true', then allow the maintenance mode to be used. Otherwise, ignore all requests to place the server in maintenance mode.

Client protocols cannot activate maintenance mode. This parameter can prevent internal server instrumentation from working properly. Use with caution.

leaf with-maintenance-mode {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-maintenance-mode=false

--with-modtags

The --with-modtags parameter controls the module-tag filtering feature.

If set to 'true', then the module tags feature will be enabled. Otherwise, this feature will be disabled.

If disabled, the module-tagmap parameter will be ignored and the ietf-module-tags module will not be loaded.

Note: the ietf-module-tags module is not used yet and is not loaded into the server.

leaf with-modtags {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-modtags=false

--with-netconf

The --with-netconf parameter controls whether the server will enable the NETCONF over SSH protocol or not. The incoming NETCONF over SSH connection will be dropped if the protocol is disabled.

If set to 'true', then the NETCONF over SSH protocol will be enabled. Otherwise, the NETCONF over SSH protocol will not be enabled.

An incoming connection will be dropped if the protocol is disabled.

leaf with-netconf {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-netconf=false

--with-netconf-tls

The --with-netconf-tls parameter controls whether the server will enable the NETCONF over TLS protocol or not.

The default for this parameter is ‘false’ because the server will terminate if the server certificates are not found, but only if this parameter is set to ‘true’.

If set to 'true', then the NETCONF over TLS protocol will be enabled. Otherwise, the NETCONF over TLS protocol will not be enabled. An incoming connection will be dropped if the protocol is disabled.

leaf with-netconf-tls {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-netconf-tls=true

--with-nmda

The --with-nmda parameter enables or disables NMDA functionality.

Currently the server fully supports the <get-data> operation from the ietf-netconf-nmda module.

If set to 'true', then NMDA operations and YANG modules will be enabled:

The server does not implement all the NMDA features at this time:

  • <edit-data> operation: This operation has less functionality than <edit-config> and provides no useful features. It is not really needed until dynamic datastores are standardized and supported.

leaf with-nmda {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-netconf=false

--with-notifications

The --with-notifications parameter controls whether the server will support the :notification and :interleave capabilities or not. To save memory and CPU processing, this parameter can be set to 'false' if notifications are not needed.

leaf with-notifications {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-notifications=false

--with-restconf

The --with-restconf parameter controls whether the server will disable the RESTCONF protocol or not. The incoming RESTCONF connection will be dropped if the protocol is disabled.

The WITH_RESTCONF=1 or EVERYTHING=1 make flags must be used for this protocol to be present in the server.

leaf with-restconf {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-restconf=false

--with-rollback-on-error

The --with-rollback-on-error parameter controls rollback during the <edit-config> operation. If set to 'true', then the NETCONF :rollback-on-error capability and feature will be enabled and advertised. Otherwise, this feature will not be enabled or advertised.

Note

The server always uses all-or-none fully recoverable edit transactions so this parameter has no affect other than to change the NETCONF <hello> message.

leaf with-rollback-on-error {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-rollback-on-error=false

--with-snmp

The --with-snmp parameter controls whether the SNMP protocol will be enabled.

  • If set to 'true', then the SNMP protocol will be enabled.

  • If set to 'false', the SNMP protocol will not be enabled. Incoming SNMP requests will be dropped if the protocol is disabled.

leaf with-snmp {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-snmp=true

--with-startup

The --with-startup parameter controls whether the server will support the :startup capability or not.

This is a memory intensive capability, and setting this parameter to 'false' will reduce memory usage during normal operations.

The non-volatile copy of the <running> configuration will not be saved automatically if this capability is enabled. Instead, a <copy-config>operation from the <running> to <startup> configuration will be needed, as defined in RFC 6241.

leaf with-startup {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-startup=true

--with-support-save

The --with-support-save parameter controls whether the yumaworks-support-save.yang module will be loaded by the server.

  • If set to 'true', then this module will be loaded and enabled.

  • Otherwise, this module will not be loaded.

  • Ignored if the server image is not built with the WITH_SUPPORT_SAVE=1 or EVERYTHING=1 compile flag.

leaf with-support-save {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-support-save=false

--with-url

The --with-url parameter controls whether the server will support the :url capability or not. This capability requires file system storage.

If set to 'true', then the :url capability will be enabled and the 'file' scheme will be enabled. Otherwise, the :url capability will not be enabled.

This capability requires a file system and may introduce security risks because internal files could be exposed.

leaf with-url {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-url=false

--with-url-ftp

The --with-url-ftp parameter controls whether the server will support FTP transfers. If set to 'true', then the 'ftp' protocol scheme will be enabled for the :url capability. Ignored if the --with-url parameter is false.

leaf with-url-ftp {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-url-ftp=true

--with-url-tftp

The --with-url-tftp parameter controls whether the server will support TFTP transfers. If set to 'true', then the 'tftp' protocol scheme will be enabled for the :url capability. Ignored if the --with-url parameter is false.

leaf with-url-tftp {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-url-tftp=true

--with-validate

The --with-validate parameter controls whether the server will support the :validate capability or not. This is a memory intensive capability, and setting this parameter to 'false' may reduce memory usage during <edit-config> operations.

leaf with-validate {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-validate=false

--with-warnings

The --with-warnings parameter controls whether the server will allow the <error-severity> field in an <rpc-error> to be set to the value “warning”. If set to 'true', then setting the error-severity field to warning (instead of error) will be enabled. Otherwise, the error-severity field will be set to error, even if the server code tries to set it to warning.

Warning

This is not compliant with the NETCONF protocol and tools may reject rpc-error data sent with an error-severity value of warning.

leaf with-warnings {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-warnings=true

--with-yang-api

The --with-yang-api parameter controls whether the server will disable the YANG-API protocol or not. Any incoming YANG-API connection will be dropped if the protocol is disabled

This parameter is ignored unless the server was built with the obsolete WITH_YANGAPI=1 make option. No binary packages use this flag.

Warning

The YANG-API protocol and this parameter are obsolete. Do not use!

leaf with-yang-api {
  type boolean;
  default false;
  status deprecated;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yang-api=false

--with-yang11-hello

The --with-yang11-hello parameter control whether the NETCONF hello message should conform to the standard and leave out YANG 1.1 modules.

Control whether the NETCONF hello message should conform to the standard and leave out YANG 1.1 modules.

If set to 'true', then leave out YANG 1.1 modules from <capability> used in <hello>. Also keep out of monitoring <capabilities> list.

If 'false' then ignore the standard and advertise YANG 1.1 module capabilities.

Note

The value 'true' should be used with care. Some clients might expect all YANG modules to be advertised, not just YANG 1.0 modules.

leaf with-yang11-hello {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yang11-hello=true

--with-yang-patch-running

The --with-yang-patch-running parameter control whether the the YANG-PATCH will be enabled when the server supports only the :writable-running capability.

This parameter is not relevant if the --target parameter is set to the default (candidate).

If set to 'true', the YANG-PATCH will be enabled when the server supports only the :writable-running capability.

If 'false' then the YANG-PATCH requests will be rejected.

leaf with-yang-patch-running {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yang-patch-running=true

--with-yp-coap

The --with-yp-coap parameter controls whether the server will disable the YP-CoAP protocol or not. Any incoming YP-CoAP request will be dropped if the protocol is disabled. This protocol is NOT SECURE. It should not be used.

The YP-CoAP protocol is only available in images built from sources, using the WITH_COAP=1 make parameter.

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf with-yp-coap {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yp-coap=true

--with-yp-coap-dtls

The --with-yp-coap-dtls parameter controls whether the server will disable the YP-CoAP over DTLS protocol or not. Any incoming YP-CoAP over DTLS request will be dropped if the protocol is disabled.

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf with-yp-coap-dtls {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yp-coap-dtls=true

--with-yp-shell

The --with-yp-shell parameter controls whether the server will disable the YP-SHELL protocol or not. The incoming YP-SHELL connection will be dropped if the protocol is disabled.

The WITH_CLI=1 or EVERYTHING=1 make flag must be used for this feature to be present in the server.

leaf with-yp-shell {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yp-shell=false

--with-yuma-system

The --with-yuma-system parameter controls whether the yuma-system.yang module will be enabled.

If set to 'true', then this module will be loaded and enabled. Otherwise, this module will not be loaded.

This parameter is default TRUE in 17.10 and FALSE starting in 18.10. This module is considered deprecated and has been replaced by yumaworks-system.yang.

leaf with-yuma-system {
  description
  type boolean;
  default false;   // true in 17.10, false in 18.10
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yuma-system=true

--with-yuma-time-filter

The --with-yuma-time-filter parameter controls whether the yuma-time-filter.yang module will be enabled. This module adds the <if-modified-since> filter to <get> and <get-config> operations.

leaf with-yuma-time-filter {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yuma-time-filter=false

--with-yumaworks-callhome

The --with-yumaworks-callhome parameter controls usage of the yumaworks-callhome YANG module.

If set to 'true', then the yumaworks-callhome module will be loaded and enabled. Otherwise, this module will not be loaded.

If not enabled then the run-time configuration of CallHome servers will not be available.

The WITH_CALLHOME=1 or EVERYTHING=1 make flag must be used for this feature to be present in the server.

leaf with-yumaworks-callhome {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-callhome=false

--with-yumaworks-cert-usermap

The --with-yumaworks-cert-usermap parameter controls usage of the yumaworks-cert-usermap.yang module.

If set to 'true', then the yumaworks-cert-usermap module will be loaded and enabled. Otherwise, this module will not be loaded.

This parameter is ignored if the --with-netconf-tls parameter is set to 'false'.

leaf with-yumaworks-cert-usermap {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-cert-usermap=false

--with-yumaworks-config-change

The --with-yumaworks-config-change parameter controls usage of the yumaworks-config-change.yang module.

If set to 'true', then the yumaworks-config-change module will be loaded and enabled. Otherwise, this module will not be loaded. This modules adds data to the 'netconf-config-change' notification.

Warning

This data represents a security risk since it is not subject to the same access control rules within a notification as within a datastore.

NACM does not provide access control for the contents of a notification, only for the notification event type. Use this module with caution! Only allow a superuser administrator access to the 'netconf-config-change' notification if this module is used.

leaf with-yumaworks-config-change {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-config-change=true

--with-yumaworks-event-filter

The --with-yumaworks-event-filter parameter controls whether the yumaworks-event-filter.yang module will be enabled. This module adds configurable event type filtering for notification delivery.

leaf with-yumaworks-event-filter {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-event-filter=false

--with-yumaworks-event-stream

The --with-yumaworks-event-stream parameter controls whether the yumaworks-event-stream.yang module will be enabled.

If set to 'true', then this module will be loaded and enabled. Otherwise, this module will not be loaded. If disabled the /event-streams subtree will not be available.

This YANG module can be used with or instead of the --event-stream and --event-stream-map CLI parameters.

leaf with-yumaworks-event-stream {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-event-stream=false

--with-yumaworks-getbulk

The --with-yumaworks-getbulk parameter controls whether the yumaworks-getbulk.yang module will be enabled. This module provides the <get-bulk> operation for YANG list retrieval.

If set to 'true', then this module will be loaded and enabled. Otherwise, this module will not be loaded. If disabled the <get-bulk> operation will not be available.

leaf with-yumaworks-getbulk {
  description
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-getbulk=false

--with-yumaworks-ids

The --with-yumaworks-ids parameter controls whether the yumaworks-ids YANG module will be enabled. This module provides additional YANG identities for the <transport> leaf in the <session> list in ietf-netconf-monitoring.yang. If disabled, extra sessions such as YControl sessions will not be stored in this list.

leaf with-yumaworks-ids {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-ids=false

--with-yumaworks-system

The --with-yumaworks-system parameter controls whether the yumaworks-system.yang module will be enabled. This module provides module/bundle load and unload operations, plus several augmentations to standard modules.

If set to 'true', then the yumaworks-system module will be loaded and enabled. Otherwise, this module will not be loaded. The <load>, <unload>, <load-bundle>, and <unload-bundle> operations will not be available.

Other operations and data model augments will not be available as well.

leaf with-yumaworks-system {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-system=false

--with-yumaworks-templates

The --with-yumaworks-templates parameter controls whether the yumaworks-templates.yang YANG module will be enabled. This module provides configuration templates and the <with-template> parameter added to the <edit-config> operation.

If set to 'true', then the yumaworks-templates module will be loaded and enabled. Otherwise, this module will not be loaded.

Ignored unless the server is built with the WITH_TEMPLATES=1 or EVERYTHING=1 compiler flag.

leaf with-yumaworks-templates {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-templates=false

--yangapi-server-url

The --yangapi-server-url parameter specifies the starting string for the server URL to use in Location header lines returned by YANG-API.

leaf yangapi-server-url {
  type inet:uri;
  default "http://localhost";
}

Syntax

inet:uri

Default:

http://localhost

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --yangapi-server-url= https://device1.example.com

--yp-coap-address

The --yp-coap-address parameter specifies the IP address that the YP-CoAP protocol will use to listen for incoming requests. This will also be used as the source address in YP-CoAP packets sent by the server.

The YP-CoAP protocol is NOT SECURE. It should not be used.

The YP-CoAP protocol is only available in images built from sources, using the WITH_COAP=1 make parameter.

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf yp-coap-address {
  type inet:ip-address;
  default "0.0.0.0";
}

Syntax

inet:ip-address

Default:

0.0.0.0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --yp-coap-address=192.168.0.100

--yp-coap-dtls-port

The --yp-coap-dtls-port parameter specifies the UDP port number that the YP-CoAP over DTLS protocol will use to listen for incoming requests for CoAP over DTLS. This will also be used as the source port number in YP-CoAP packets sent by the server.

The YP-CoAP protocol is only available in images built from sources, using the WITH_COAP=1 make parameter.

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf yp-coap-dtls-port {
  type inet:port-number;
  default "5684";
}

Syntax

inet:port-number

Default:

5684

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --yp-coap-dtls-port=12904

--yp-coap-port

The --yp-coap-port parameter specifies the UDP port number that the YP-CoAP protocol will use to listen for incoming requests. This will also be used as the source port number in YP-CoAP packets sent by the server.

The YP-CoAP protocol is only available in images built from sources, using the WITH_COAP=1 make parameter.

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf yp-coap-port {
  type inet:port-number;
  default "5683";
}

Syntax

inet:port-number

Default:

5863

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --yp-coap-port=12903

yangcli-pro CLI Reference

--aliases-file

The --aliases-file parameter specifies the yangcli-pro command aliases file specification to use.

leaf aliases-file {
  type string;
  default "~/.yumapro/.yangcli_pro_aliases";
}

Syntax

string

Default:

$HOME/.yumapro/.yangcli_pro_aliases

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --aliases-file=~/myalaises

--allow-shell

The -–allow-shell parameter specifies whether the run-shell command will be allowed or not.

Warning

Enabling shell access from yangcli-pro can be a security risk. Th run-shell operation is disabled by default.

leaf allow-shell {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro –allow-shell=true

--ask-password

The --ask-password parameter controls whether the user will be prompted for a password for the connect command. This parameter is intended to support servers that use keys for authentication instead of passwords.

  • If 'true' then the connect command will expect that a password is needed. The --no-password parameter can still be used in the connect command instead of providing a password.

  • If 'false' the connect command will not require a password, but it will use the password parameter if it is set.

leaf ask-password {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --ask-password=false

--auto-discard-changes

The --auto-discard-changes parameter controls whether the <discard-changes> operation will be automatically sent when errors occur for the edit and save mode.

  • If true, discard-change will be automatically sent.

  • If false, discard-change will not be automatically sent.

leaf auto-discard-changes {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --auto-discard-changes=true

--autoeventhandlers

The --autoeventhandlers parameter controls whether the saved event_handlers will be loaded into memory at startup and saved to file at exit.

  • If true, the default event-handler-cfg file will be used (~/.yumapro/.yangcli_pro_event_handlers.conf) for loading and saving the configured event-handlers in memory.

  • If false, the configured event-handlers will only be stored and loaded manually with the event-handlers-cfg command.

leaf autoeventhandlers {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoeventhandlers=false

--auto-keepalive

The --auto-keepalive parameter Controls whether keepalive messages will be automatically sent on a connected session.

  • If 'true', keepalive message is sent every keepalive-interval.

  • If 'false', then keepalive message will not be sent..

Note

This parameter is NOT IMPLEMENTED. IT IS IGNORED.

leaf auto-keepalive {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --auto-keepalive=true

--auto-reconnect

The --auto-reconnect parameter controls whether yangcli-pro will try to reconnect to the server If the session gets dropped by the server.

  • If 'true', yangcli-pro will try to reconnect to the server.

  • If 'false', yangcli-pro will not try to reconnect to the server.

 leaf auto-reconnect {
   type boolean;
   default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --auto-reconnect=false

--auto-reconnect-interval

The --auto-reconnect-interval parameter indicates the number of seconds yangcli-pro will wait to re-establish a connection if a session is dropped and the server becomes unreachable. The default is 10 seconds.

leaf auto-reconnect-interval {
  type uint16 { range "1 .. 3600"; }
  units seconds;
  default 10;
}

Syntax

uint16

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --auto-reconnect-interval =15

--auto-reconnect-max

The --auto-reconnect-max parameter controls the number of times to retry the connection. Zero means no limit, otherwise re-connect attempts will stop after this number of failures. The default is 5 times.

leaf auto-reconnect-max {
  type uint16;
  default 5;
}

Syntax

uint16

Default:

5

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --auto-reconnect-max=3

--autoaliases

The --autoaliases parameter controls automatic loading and saving of the command aliases file.

  • If 'true', the 'aliases-file' parameter will be used if it is set, or else the default aliases file will be used (~/.yumapro/.yangcli_pro_aliases), for loading and saving the yangcli-pro command aliases.

  • If 'false', the yangcli-pro command aliases will only be stored and loaded manually with the aliases command.

leaf autoaliases {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoaliases=false

--autocomp

The --autocomp parameter controls automatic completion of command and parameter names.

If true, then the program will attempt to find a partial match by comparing only the number of characters entered. For example '--log-l=debug' is the same as '--log-level=debug'.

If 'false', then command and parameter names must match exactly.

leaf autocomp {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autocomp=false

--autoconfig

The --autoconfig parameter controls whether the running configuration will be retrieved automatically for active sessions.

By default, the running config will not be retrieved and maintained. This option must be set to true to support value-node command tab completion.

  • If true, then the program will attempt to retrieve and maintain a shadow configuration for each session, using the NETCONF <get-config> operation.

  • If 'false', then automatic shadow configuration handling will not be done.

leaf autoconfig {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoconfig=true

--autoconfig-conf-mode

The --autoconfig-conf-mode parameter controls whether the running configuration will be retrieved automatically for active sessions in config-mode.

This parameter must be set to 'true' to support value node tab completion in config mode.

  • If --autoconfig = true then autoconfig-conf-mode is ignored and autoconfig will be done for config mode.

  • If --autoconfig = false then autoconfig-conf-mode is checked

    • If true, the autoconfig updates after each update will be done. The current config will be available to assist tab completion.

    • If false, the autoconfig updates after each update will not be done. The current config will not be available to assist tab completion.

leaf autoconfig-conf-mode {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoconfig-conf-mode=false

--autodevices

The --autodevices parameter controls whether the saved devices will be loaded into memory at startup and saved to file at exit.

  • If 'true', the default device-cfg file will be used (~/.yumapro/.yangcli_pro_devices.conf) for loading and saving the configured devices in memory.

  • If 'false', the configured devices will only be stored and loaded manually with the devices-cfg command.

leaf autodevices {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autodevices=false

--autohistory

The --autohistory parameter controls automatic loading and saving of the command line history buffer in the yangcli-pro program.. The default location for this file is ~/.yumapro/.yangcli_pro_history.

  • If 'true', then when the program starts, the default command line history buffer will be loaded, and the previous set of commands will be available with the history and recall commands. The --history-file parameter specifies which file is used to load and save the command line history.

  • If 'false', then the command line history buffer will not be loaded and saved automatically.

leaf autohistory {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autohistory=false

--autoload

The --autoload parameter controls automatic loading of session YANG modules, as needed.

  • If 'true', then the program will attempt to find a needed YANG module.

  • If 'false', then YANG modules must be loaded manually.

leaf autoload {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoload=false

--autoload-cache

The --autoload-cache parameter controls whether the modules retrieved with the <get-schema> operation are cached for use by the running instance of yangcli-pro.

  • If true, then the YANG modules that are retrieved with the <get-schema> operation will be cached. A cached module will be used by yangcli-pro instead of calling <get-schema>, if that module revision is requested again.

  • If false, then the YANG modules that are retrieved with the <get-schema> operation will not be cached.

leaf autoload-cache {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoload=false

--autoload-get

The --autoload-get parameter controls whether the <get> operation will be used to retrieve the /netconf-state/schemas sub-tree.

This option is needed to autoload sub-modules that are not available to yangcli-pro, since YANG submodules are not advertised in the <hello> message. The value 'true' should be used.

  • If 'true', then the schema list will be used instead of the <hello> message module capabilities, if the server supports the 'ietf-netconf-monitoring' module.

  • If 'false', then just the <hello> message module list will be used to retrieve YANG modules with the <get-schema> operation.

leaf autoload-get {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoload=false

--autoload-save-cache

The --autoload-save-cache parameter controls whether the modules held in the YANG module cache are saved when yangcli-pro exits, as needed.

  • If true, then the YANG modules that are cached will be saved when yangcli-pro exits.

  • If false, then the YANG modules that are cached will not be saved when yangcli-pro exits.

leaf autoload-save-cache {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoload-save-cache=false

--autonotif

The --autonotif parameter controls whether notifications will automatically be enabled when a session starts, if the server supports the :notification and :interleave capabilities.

By default, notifications will not be enabled. If enabled, a <create-subscription> operation will be performed when the session starts, and notification events for the session will be monitored.

This parameter does not affect echoing of notification messages. The --echo-notifs and --echo-notif-loglevel parameters need to be set appropriately to echo received notification messages.

  • If 'true', then the program will attempt to start a notification subscription if the server advertises support, using the <create-subscription> NETCONF operation.

  • If 'false', then notification subscriptions must be started manually.

leaf autonotif {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autonotif=true

--autonvsave

The --autonvsave parameter controls whether the save and apply commands will NV-save the configuration changes or not. If the server advertises the :startup capability and this variable is set to 'false', then the final step to save running to startup will not be done.

The nvsave command can be used to manually save the running datastore to non-volatile memory (startup datastore). If this parameter is set to 'true' the final step of saving the running datastore to the startup datastore will be done.

leaf autonvsave {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autonvsave=false

--autoschemaservers

The --autoschemaservers controls whether the saved schema servers will be loaded into memory at startup and saved to file at exit.

  • If true, the default Schema Server Config file will be used (~/.yumapro/.yangcli_pro_schemaservers .conf) for loading and saving the configured schema servers in memory.

  • If false, the configured schema servers will only be stored and loaded manually with the schema-server-cfg command.

leaf autoschemaservers {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autoschemaservers=false

--autosessions

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

  • If true, the default session-cfg file will be used (~/.yumapro/.yangcli_pro_sessions.conf) for loading and saving the configured sessions in memory.

  • If false, the configured sessions will only be stored and loaded manually with the sessions-cfg command.

leaf autosessions {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autosessions=false

--autotest

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

  • If true, the default test-suite-cfg file will be used (~/.yumapro/.yangcli_pro_tests.conf) for loading and saving the configured test-suites in memory.

  • If false, the configured test-suites will only be stored and loaded manually with the test-suite command.

leaf autotest {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autotest=false

--autousers

The --autousers parameter controls whether the saved sessions will be loaded into memory at startup and saved to file at exit.

  • If true, the default users-cfg file will be used (~/.yumapro/.yangcli_pro_users.conf) for loading and saving the configured users in memory.

  • If false, the configured sessions will only be stored and loaded manually with the users-cfg command.

leaf autousers {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autousers=false

--autouservars

The --autouservars parameter controls whether the yangcli-pro user variables will be saved at exit and loaded at startup.

  • If 'true', the 'uservars-file' parameter will be used if set, or else the default user variables file will be used (~/.yumapro/yangcli_pro_uservars.xml), for loading and saving the yangcli-pro user variables.

  • If 'false', the yangcli-pro user variables will only be stored and loaded manually with the uservars command.

leaf autouservars {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --autouservars=false

--bad-data

The --bad-data parameter controls how invalid parameter input is handled by the program.

  • ignore: Use invalid parameter values. Use with caution.

  • warn: Issue a warning message, but use the invalid data anyway.

  • check: Prompt the user interactively, and check if the invalid data should be used, or a new value re-entered.

  • error: Do not use invalid parameter values. Prompt the user to re-enter the invalid value.

leaf bad-data {
  type enumeration {
    enum ignore {
    }
    enum warn {
    }
    enum check {
    }
    enum error {
    }
  }
  default "check";
}

Syntax

enumeration: ignore warn check error

Default:

check

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --bad-data=warn

--batch-mode

The --batch-mode parameter specifies that the interactive CLI will not be used.

If present, the interactive CLI will not be used. A script should be provided with the --run-script parameter, or a command provided with the --run-command parameter, or else the program will simply exit.

leaf batch-mode {
   type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --batch-mode --run-script=~/run-tests

--break-key-mode

The --break-key-mode parameter specifies the behavior when the break key is pressed during a command. The default mode is 'program' to maintain backward compatibility.

  • program

    • Break key will cause the program to exit no matter what mode or state the program is in at the moment.

  • command

    • Break key will cause the current command in the current session to be terminated.

If no command is in progress, or currently in config mode or enable mode, then the break key will have no affect.

leaf break-key-mode {
   type enumeration {
     enum program {
     }
     enum command {
     }
   }
   default program;
}

Syntax

enum (program | control)

Default:

program

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --break-key-mode=command

--callhome-address

The --callhome-address parameter specifies the IP address that should be used to listen for callhome connections. Ignored if --callhome-enabled is false.

leaf callhome-address {
  type inet:ip-address;
  default "0.0.0.0";
}

Syntax

Inet:ip-address

Default:

0.0.0.0

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --callhome-address=192.168.0.40

--callhome-enabled

The --callhome-enabled parameter enables the Call Home protocol.

  • If 'true', then yangcli-pro will listen for SSH CallHome connections on the socket identified by the --callhome-address and --callhome-port parameters.

  • If 'false' then the CallHome server function will not be enabled

leaf callhome-enabled {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --callhome-enabled=true

--callhome-port

The --callhome-port parameter specifies the TCP port number that should be used to listen for NETCONF over SSH callhome connections. Ignored if --callhome-enabled is false.

leaf callhome-port {
  type inet:port-number;
  default 4334;
  reference "RFC 8071";
}

Syntax

Inet:port-number

Default:

4334

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --callhome-port=8400

--callhome-tls-port

The --callhome-tls-port parameter specifies the TCP port number that should be used to listen for NETCONF over TLS callhome connections. Ignored if --callhome-enabled is false.

leaf callhome-tls-port {
  type inet:port-number;
  default 4335;
  reference "RFC 8071";
}

Syntax

Inet:port-number

Default:

4335

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --callhome-tls-port=8401

--callhome-user

The --callhome-user parameter specifies the name specifies the name of a configured user entry that should be used as the default user for callhome sessions, if no saved session entry is found matching the server IP address. Will be ignored if the user is not currently configured.

If a callhome session is attempted with an entry and that connection fails, then that callhome-user will not be attempted for the specific server address until yangcli-pro is restarted. This only applies if there are multiple callhome-user entries.

If only one callhome-user entry exists then it will be used every time, to be backward-compatible with previous releases.

If used in yp-client then it is possible an application callback will pick the callhome-user for a specific address.

It that case, the ordered-by user property will be ignored. Otherwise the callhome-user entries are attempted in the order they are processed from the CLI or configuration file.

leaf-list callhome-user {
  type nt:NcxUserName;
  ordered-by user;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangcli-pro

Example:

yangcli-pro --callhome-user=chuser1 --callhome-user=chuser2

Note that the user value is the name of a user-cfg entry, which has to be set up in advance for this parameter to have any effect.

Example user-cfg command for user “chuser1”

  • username: fred

  • password: secret1

> user-cfg create chuser1 user-name=fred password=secret1

--check-output

The --check-output parameter specifies whether <rpc> messages about to be sent to a remote server should be validated against the YANG schema for the specific RPC operation.

If true, then yangcli-pro will validate remote commands against the YANG definition for the rpc/input node. This checks the operation parameters about to be sent to a server session.

Note that validation of the contents of a <config> element is not done.

This CLI parameter is also the $$check-output global parameter.

leaf check-output {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --check-output=false

--check-output-error

The --check-output-error parameter specifies whether validation errors detected in <rpc> messages about to be sent to a remote server should be treated as warnings or errors.

  • If 'true', then errors found during the check-output validation tests will be treated as errors, causing the <rpc> about to be sent to fail.

  • If 'false', then errors found during the check-output validation tests will be treated as warnings.

This CLI parameter is also the $$check-output-error global parameter.

leaf check-output-error {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --check-output-error=true

--check-replies

The --check-replies parameter specifies whether <rpc-reply> messages received from a remote server should be validated against the YANG schema for the specific RPC operation.

  • Note that validation of the contents of a <config> element is not done.

  • This CLI parameter is also the $$check-replies global parameter.

  • If 'true', then yangcli-pro will validate remote commands against the YANG definition for the rpc/output node. If the “output” section is missing or empty, then the <rpc-reply> will be checked to make sure it contains either <ok> or 1 or more <rpc-error> elements.

  • If 'false' then <rpc-reply> messages from the server will not be validated against the rpc "output" statement for the operation.

leaf check-replies {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --check-replies=false

--check-replies-error

The --check-replies-error parameter specifies whether validation errors detected in <rpc-reply> messages received from a remote server should be treated as warnings or errors.

  • If 'true', then errors found during the check-replies validation tests will be treated as errors, causing the <rpc-reply> about to be processed to be rejected instead.

  • If 'false', then errors found during the check-replies validation tests will be treated as warnings.

This CLI parameter is also the $$check-replies-error global parameter.";

leaf check-replies-error {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --check-replies-error=true

--config-autosave

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

  • If 'true', automatically copy running to startup when an edit is applied.

  • If 'false', no automatically copy from running to startup when an edit is applied. The user will enter save or copy-config manually once config term mode is exited.

leaf config-autosave {
  description
     type boolean;
     default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yancli-pro

Example:

yangcli-pro --config-autosave=true

--config-commit-mode

The --config-commit-mode parameter controls how edits will be committed in configuration mode.

  • If 'true' then edits done in config mode will be made to the candidate datastore if possible. The edits will not be committed to the running datastore automatically. Instead, the config-commit command in config mode, or <commit> operation in normal mode is required to activate the edits in the server.

  • If 'false' then edits done in config mode will be committed to the running datastore after each apply or exit command in config mode.

The default configuration commit mode is 'false'.

leaf config-commit-mode {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --config-commit-mode=true

--config-edit-mode

The --config-edit-mode parameter controls how edits will be applied in configuration mode.

There are 3 possible editing modes:

  • line: The edit(s) are automatically applied after each line is entered

  • level: The edits(s) are automatically applied when the current level is exited

  • manual: The edit(s) are only applied manually with the apply command.

The default configuration editing mode is level. Note that the apply command can be used even if the value of this parameter is not manual.

leaf config-edit-mode {
  type config-edit-mode-type;
  default level;
}

Syntax

enum: line level manual

Default:

level

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --config-edit-mode=line

--default-module

The --default-module parameter specifies the module to search for identifiers, after the "netconf" and other modules have been checked. This allows a specific module to match identifier names first, before all modules are searched at once. This can avoid a collision if the same identifier value is used in more than one module.

leaf default-module {
   type nt:NcxName;
}

Syntax

string: module name without any path or file extension included.

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --default-module=testmod

--disable-command

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

For example, to disable the NETCONF <delete-config> operation:

> disable-command ietf-netconf:delete-config
leaf-list disable-command {
   type nt:NcxIdentifier;
}

Syntax

nt:NcxIdentifier

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangcli-pro

Example:

yangcli-pro --disable-command=nc:delete-config

--display-mode

The --display-mode parameter controls how data is displayed in the program.

The qualified names (identifiers, identityref, XPath) within a text configuration can be generated several ways. This is needed because sibling nodes in different XML namespaces can have the same name.

--display-mode values

enum value

description

example

plain

no prefix, just local-name

sysBootError

prefix

XML prefix and local-name

sys:sysBootError

module

module name and local name

system:sysBootError

xml

XML format

<sysBootError xmlns=”foo”>

xml-nons

XML format without namespace (xmlns) attributes

<sysBootError>

json

JSON format

{ “sysBootError” : “blah” }

cli

CLI format

sysBootError blah

When saving configuration files in non-volatile storage, then it is suggested that only module, json, or xml modes be used, since these are the only deterministic modes.

The set of XML prefixes in use at any one time is not persistent, and cannot be relied upon, unless the namespace declarations are saved (xml mode) or the module names are saved (module mode).

The json format uses RFC 7951 format which does not rely on XML prefixes.

leaf display-mode {
   type enumeration {
     enum plain {
     }
     enum prefix {
     }
     enum module {
     }
     enum xml {
     }
     enum xml-nons {
     }
     enum json {
     }
     enum cli {
     }
  }
  default plain;
}

Syntax

enumeration: plain prefix module xml xml-nons json cli

Default:

plain

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --display-mode=module

--echo-notif-loglevel

The --echo-notif-loglevel parameter controls how unregistered notifications are echoed when notification messages are received. If the --echo-notifs parameter is true, then this parameter controls the logging debug level needed for notifications to be printed, If --echo-notifs is 'false' then this parameter has no affect.

Only notifications other than <netconf-config-change> Event are echoed. This notification is used to maintain shadow configurations.

If the --log-level is set to the same value or higher as this parameter, then the full notification message will be echoed.

If the --log-level is set to one level lower than this parameter, then a 1 line notification summary message will be echoed. For example, if --log-level=info and --echo-notifs=true and --echo-notif-loglevel=debug, then a one line summary will be printed for received notifications.

Note

The default is different on yp-shell (debug) and yangcli-pro (info). The YANG default is not used correctly

leaf echo-notif-loglevel {
  type nt:NcDebugType;
  default debug;
}

Syntax

enum: (same as log-level)

Default:

debug

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --echo-notif-loglevel=info

--echo-notifs

The --echo-notifs parameter controls whether unregistered notifications are echoed when notification messages are received, to the log or STDOUT.

  • If 'true', <notification> messages will be output to the log, if log-level is set to the value specified by the echo-notif-loglevel or higher.

  • If 'false', <notifications> messages will not be output to the log.

  • The $$echo-notifs system variable is derived from this parameter.

  • If --autonotif=true then this parameter will also be set to true.

  • Only notifications other than <netconf-config-change> Event are echoed. This notification is used to maintain shadow configurations.

Note

The default is different on yp-shell (false) than yangcli-pro (true). The YANG default is not used correctly.

leaf echo-notifs {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --echo-notifs=false

--echo-replies

The --echo-replies parameter controls whether <rpc-reply> messages are echoed when they are received. The $$echo-replies system variable is derived from this parameter.

  • If 'true' then replies with data will be displayed.

  • If 'false' then they will not be displayed.

Note

This parameter does not affect error replies (messages with <rpc-error> elements in them).

leaf echo-replies {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --echo-replies=false

--encoding

The --encoding parameter identifies the desired encoding format for RESTCONF request messages.

The supported values are xml and json.

leaf encoding {
  type ywt:encoding-type;
  default xml;
}

Syntax

enum (xml | json)

Default:

xml

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --encoding=json

--entry-point

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

leaf entry-point {
  type string;
}

Syntax

string

Default:

/restconf

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --entry-point=/api/restconf

--fill-optional

The --fill-optional parameter controls the default for the --optional parameter that can be passed to many interactive commands such as fill or create.

  • If 'true' then the user will be prompted to enter optional nodes while filling YANG datastore content.

  • If 'false' then the user will not be prompted to enter optional nodes while filling YANG datastore content.

leaf fill-optional {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

Yangcli-pro --fill-optional=true

--fixorder

The --fixorder parameter controls whether PDU parameters will be automatically sent in NETCONF PDUs in the correct order.

  • If 'true', the schema-defined, canonical order will be used.

  • If 'false', the specified order that parameters are entered will be used for the PDU order as well.

leaf fixorder {
  type boolean;
  default true;
}

Syntax

boolean (true or false)

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --fixorder=false

--force-target

The --force-target parameter controls whether the candidate or running configuration datastore will be used as the default edit target, when both are supported by the server.

  • candidate: Force the default edit target to be candidate.

  • running: Force the default edit target to be running.

leaf force-target {
  type enumeration {
    enum candidate {
    }
    enum running {
    }
  }
  default candidate;
}

Syntax

enum (candidate or running)

Default:

candidate

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --force-target=running

--handle-bad-reply

The --handle-bad-reply controls the behavior of the XML parser and dictates how a bad RPC reply will be handled, whether the bad node(s) will be pruned or the value will be adapted and the client will try to convert it to an acceptable type.

Settings that can be used:

  • adapt: Leaf or leaf-list: convert bad value to a string value and try to keep it if possible or prune if not. Container or list: leave in the data if possible or prune if not.

  • prune: Prune failing node(s).

  • error: Do not attempt to prune or modify nodes. Report an error.

leaf handle-bad-reply {
  type enumeration {
    enum adapt {
    }
    enum prune {
    }
    enum error {
    }
  }
  default error;
}

Syntax

enum (adapt | prune | error)

Default:

error

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --handle-bad-reply=prune

--help-width

The --help-width parameter specifies the line width to use when displaying help text for the help key '?' within config term mode.

This help mode aligns the description to the right of the widest object node name being displayed.

If the 'help' extension is used, then that text is displayed in its entirety. Otherwise the total line width will be limited to this help-width value.

leaf help-width {
  type uint16 {
    range "80 .. 511";
  }
  default 80;
}

Syntax

uint16

Default:

80

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --help-width=120

--history-file

The --history-file parameter specifies the file location for the libtecla command line history file used if --autohistory is 'true'. This file will be created if if does not exist and the --autohistory parameter is 'true'.

leaf history-file {
  type string;
  default "~/.yumapro/.yangcli_pro_history";
}

Syntax

string

Default:

~/.yumapro/.yangcli_pro_history

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --history-file=~/my-history.txt

--ignore-missing-vars

The --ignore-missing-vars parameter specifies how missing variable errors in data templates are handled. This parameter has no affect unless the --use-data-templates parameter is 'true'.

  • If 'true', then variable expressions that contain references to missing variables will not cause a parsing error. Instead, an empty string will be used or the value of a missing variable.

  • If 'false', then variable expressions that contain references to missing variables will cause a parsing error.

leaf ignore-missing-vars {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --ignore-missing-vars=true

--keepalive-interval

The --keepalive-interval parameter Specifies the time interval, in seconds, between keepalive messages sent from a session. This value is only used if --auto-keepalive is true.

Note

This parameter is NOT IMPLEMENTED. IT IS IGNORED.

leaf keepalive-interval {
  type uint32 {
    range "1 .. 3600";
  }
  units "seconds";
  default '4';
}

Syntax

uint32 (1 .. 3600)

Default:

4

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --keepalive-interval=10

--leaflist-multi-line

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

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

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

leaf leaflist-multi-line {
   type boolean;
   default false;
 }

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --leaflist-multi-line=true

--ncport

The --ncport parameter specifies the TCP port number that should be used for NETCONF sessions.

leaf ncport {
  type uint16 {
    range "1..max";
  }
  default 830;
}

Syntax

uint32

Default:

830

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --server=myserver --ncport=22 --user=fred --password=mypassword

--no-aliases

The --no-aliases parameter disables the alias substitution feature. The default is not present.

If present:

  • The alias file will not be read.

  • The aliases and alias commands will be disabled.

leaf no-aliases {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --no-aliases

--no-password

The --no-password parameter indicates that no user password is needed for the connection. It is used when connecting to a server in batch mode.

leaf no-password { type empty; }

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --no-password [server connect parms]

--optional

The --optional parameter specifies the the default for the $$optional global variable.

  • If 'true' then the user will be prompted to enter optional nodes for all input.

  • If 'false' then the user will not be prompted to enter optional nodes for all input.

This parameter affects all YANG input and should normally not be used. The --fill-optional parameter should be used instead.

leaf optional {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --optional=true

--password

The --password parameter specifies the password string that should be used when a NETCONF session is connected during the startup of the program.

leaf password {
  type string;
  ncx:password;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --server=myserver --password=yangrocks --user=andy

--private-key

The --private-key parameter specifies the file path specification for the file containing the client-side private key.

If both 'public-key' and 'private-key' files are present, the client will attempt to connect to the server using these keys. If this fails, or not done, then password authentication will be attempted.

leaf private-key {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssh/id_rsa";
}

Syntax

string

Default:

$HOME/.ssh/id_rsa

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --private-key=~/.ssh/mykey

--prompt

The --prompt parameter is used to set the command line prompt to the user defined value.

user1@homedev:~$ yp-shell  --prompt=admin@console

admin@console>

This parameter is only supported for yp-shell, not yangcli-pro.

The prompt can also be set using the $$prompt variable at any time. If this parameter is set then that value will be used as the prompt when yp-shell starts.

If this parameter is used, then --prompt-name and --prompt-type will be ignored.

leaf prompt {
   type string {
       length "1 .. 512";
   }
}

Syntax

String (length "1 .. 512")

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yp-shell

Example:

yp-shell --prompt=admin-session

--prompt-name

The --prompt-name parameter customize just the server name portion of the yp-shell prompt. It is ignored if --prompt is used.

This parameter is only supported for yp-shell, not yangcli-pro.

user1@homedev:~$ yp-shell  --prompt-name=myserver

user1@myserver>
leaf prompt-name {
   type string {
       length "1 .. 512";
   }
}

Syntax

String (length "1 .. 512")

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --prompt-name=yumaworks

--prompt-type

The --prompt-type parameter specifies the verbosity of the prompt storing.

The values allowed are brief, normal and full.

Note

This parameter is ignored by yangcli-pro and yp-shell. It has no affect on the prompt that is used.

leaf prompt-type {
  type ywt:show-mode;
  default normal;
}

Syntax

enum: brief normal full

Default:

normal

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --prompt-type=full

--public-key

The --public-key parameter specifies the file path specification for the file containing the client-side public key.

If both 'public-key' and 'private-key' files are present, the client will attempt to connect to the server using these keys. If this fails, or not done, then password authentication will be attempted.

leaf public-key {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssh/id_rsa.pub";
}

Syntax

string

Default:

$HOME/.ssh/id_rsa.pub

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --public-key=~/.ssh/mykey.pub

--restrict-edit-mode

The --restrict-edit-mode parameter controls whether an 'restrict edit mode' will be supported for yp-shell.

This parameter can be used instead of specifying individual --disable-command parameters for all the editing commands.

leaf restrict-edit-mode {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yp-shell

Example:

yp-shell --restrict-edit-mode=true

--run-command

The --run-command parameter specifies a command will be invoked upon startup.

In the yangcli-pro program, if the auto-connect parameters are provided, then a session will be established before running the command.

The --run-script parameter cannot be used if this parameter is used.

leaf run-command {
  type string {
    length "1 .. 4095";
  }
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --run-command="history load=~/test3-history"

--run-script

The --run-script parameter specifies a script will be invoked upon startup.

In the yangcli-pro program, if the auto-connect parameters are provided, then a session will be established before running the script.

If a quoted string is used, then any parameters after the script name will be passed to the script.

The --run-command parameter cannot be used if this parameter is used.

leaf run-script {
   type string {
     length "1 .. 4095";
   }
}

Syntax

string (file specification)

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --run-script="test3-start"

--save-session-vars

The --save-session-vars parameter specifies if session variables will be saved when the program exits. If use-session-vars is 'false' then this variable is ignored.

  • If 'true', then session variables will be saved when the program exits, but only if user variables are being saved.

  • If 'false', then session variables will not be saved when the program exits.

leaf save-session-vars {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --save-session-vars=false

--script-input

The --script-input parameter specifies whether scripts run in interactive mode should attempt to fill in missing command parameters from the CLI command line or not.

  • If true, then the user will be prompted for input when needed.

  • If false, then script commands will be attempted with whatever parameters are present in the script.

leaf script-input {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --script-input=false

--server-commands

The --server-commands parameter specifies whether RPC operations learned from server YANG modules will be added as a command available to the user.

  • The module ietf-netconf is exempt from this parameter.

  • Use the disable-command parameter to disable individual NETCONF operations.

leaf server-commands {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --server-commands=false

--shell-command

The --shell-command parameter specifies the shell program to invoke with the run-shell command, in case the default cannot be used.

leaf shell-command {
  type string;
  default "/bin/bash";
}

--shell-command parameter

Syntax

string

Default:

/bin/bash

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro –shell-command=/bin/sh

--ssl-certificate

The --ssl-certificate parameter contains the file path specification for the file containing the client-side SSL certificate.

If both 'certificate' and 'key' files are present, the client will attempt to setup a secure connection with the server using the certificate and SSL key.

If this fails, and the --ssl-fallback-ok parameter is set to 'true', the client will attempt to setup a raw TCP connection with the server.

leaf ssl-certificate {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/yangapi-client.crt";
}

Syntax

filespec

Default:

$HOME/.ssl/yangapi-client.crt

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --ssl-certificate=~/certs/client.crt

--ssl-fallback-ok

The --ssl-fallback-ok parameter controls SSL connection behavior. This parameter only applies if the transport is 'ssl'.

  • If 'true' then an attempt to establish a plain TCP connection will be made if an SSL connection cannot be made.

  • If 'false' then an attempt to establish a plain TCP connection will not be made if an SSL connection cannot be made.

leaf ssl-fallback-ok {
    type boolean;
    default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --ssl-fallback-ok=false

--ssl-key

The --ssl-key parameter contains the file path specification for the file containing the client-side SSL key certificate.

If both 'certificate' and 'key' files are present, the client will attempt to setup a secure connection with the server using the certificate and SSL key.

If this fails, and the --ssl-fallback-ok leaf is set to 'true', the client will attempt to setup a raw TCP connection with the server.

leaf ssl-key {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/yangapi-client.key";
}

Syntax

filespec

Default:

$HOME/.ssl/yangapi-client.key

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --ssl-key=~/certs/client.key

--ssl-trust-store

The --ssl-strust-store parameter 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.

If the default value is used and the file is not found, then the default directory location /etc/ssl/certs will be used.

leaf ssl-trust-store {
  type string {
    length "1 .. max";
  }
  default "$HOME/.ssl/trust-store.pem";
}

Syntax

filespec

Default:

$HOME/.ssl/trust-store.pem
/etc/ssl/certs directory

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --ssl-trust-store= $HOME/certs/trust-store.pem

--term-length

The --term-length parameter specifies the length of the terminal to use for page mode output with the -More- prompt.

  • This parameter is ignored in batch mode.

  • It is only used if the output session is operating in interactive mode.

  • If the value 0 is used then the 'More' prompt will be disabled.

  • Otherwise this value represents the number of lines to output for each screen in pagination output mode.

leaf term-length {
  type uint16 {
    range "0 .. 511";
  }
  default 0;
}

Syntax

uint16 (0..511)

Default:

0

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --term-length=24

--test-suite-file

The --test-suite-file parameter contains the file specification of the default test suite configuration file to use.

leaf test-suite-file {
  type string;
  default "~/.yumapro/yangcli_pro_tests.conf";
}

Syntax

string:filespec

Default:

$HOME/.yumapro/.yangcli_pro_tests.conf

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --test-suite-file=~/mytests.conf

--time-rpcs

The --time-rpcs parameter is used to measure the round-trip time of each <rpc> request and <rpc-reply> at the session level.

  • Echo the elapsed time value to screen if in interactive mode, as well as the log if the log is a file instead of stdout.

  • The $$time-rpcs system variable is derived from this parameter.

leaf time-rpcs {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --time-rpcs=true

--time-rpcs-stats

The --time-rpcs-stats parameter is used to control whether the timed rpc statistics should be saved if the time-rpcs parameter is set to 'true'.

  • If 'true', then timing statistics will be saved.

  • If 'false', then timing statistics will not be saved.

  • The $$time-rpcs-stats system variable is derived from this parameter.

leaf time-rpcs-stats {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --time-rpcs-stats=true

--time-rpcs-stats-file

The --time-rpc-stats-file parameter contains the file specification of the default rpc timing data file to use.

The default filename to use for saving RPC timing statistics. if the --time-rpcs and --time-rpcs-stats variables are true.

The $$time-rpcs-stats-file system variable is derived from this parameter.

leaf time-rpcs-stats-file {
  type string {
    length "1 .. max";
  }
  default "~/yangcli_pro_rpc_stats.txt";
}

Syntax

string:filespec

Default:

$HOME/yangcli_pro_rpc_stats.txt

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --time-rpc-stats-file=~/mystats.txt

--timeout

The --timeout parameter specifies the number of seconds that should pass before giving up on a response during a NETCONF session.

  • The value zero means wait forever (no timeout).

typedef Timeout {
    type uint32;
    units seconds;
    default 30;
}

leaf timeout {
    type nt:Timeout;
}

Syntax

uint32 (0 for no timeout; otherwise number of seconds to wait)

Default:

30

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --timeout=0

--transport

The --transport parameter specifies the NETCONF transport protocol to use.

This parameter is also supported in the 'connect' command.

There are 5 values defined:

  • ssh

  • tcp

    • tail-f NETCONF over TCP transport.

    • Note that netconfd-pro does not support this transport protocol!

    • The transport is TCP. The usage depends on the protocol used.

      • NETCONF over TCP: (tail-f NETCONF over TCP). If this enum is selected:

      • YANG-API or RESTCONF over HTTP/TCP. If this enum is selected:

  • tcp-ncx

    • YumaWorks NETCONF over TCP transport

    • Note that netconfd-pro does support this transport protocol, if the netconfd-pro --socket-type CLI parameter is set to 'tcp'.

    • If this enum is selected:

  • tls

    • If the protocol is 'netconf' and this enum is selected, a NETCONF over TLS session will be attempted.

    • If the protocol is 'RESTCONF' and this enum is selected the RESTCONF client will try to communicate with the server using the HTTPS protocol.

  • coap

    • RESTCONF over CoAP. If this enum is selected:

      • the default --ncport value is set to 5683

      • the --password value will be ignored.

      • this parameter is no longer supported in yangcli-pro.

typedef transport-type {
  description
    "Identifies the transport protocol that should be used.";
  type enumeration {
    enum ssh {
    }
    enum tcp {
    }
    enum tcp-ncx {
    }
    enum tls {
      description
    }
    enum coap {
    }
  }
}

leaf transport {
    type ywt:transport-type;
    default ssh;
}

Syntax

Enum (ssh, tcp, tpc-ncx, tls, coap)

Default:

ssh

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --transport=tls

--use-data-templates

The --use-data-templates parameter specifies if variable expressions are enabled for data in XML, JSON or .conf instance documents.

  • If 'true', then text matching the pattern for variable expressions in these instance documents will be processed as variable expressions.

  • If 'false', then text matching the pattern for variable expressions in these instance documents will be treated as plain strings.

leaf use-data-templates {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --use-data-templates=false

--use-rawxml

The --use-rawxml parameter specifies how file result variables will be read for XML files. Controls whether the XML will be parsed against the target YANG object (the default) or injected into a variable or request message from the raw XML text in the file.

  • If 'true', then inject the XML file into the request message

  • If 'false', then attempt to parse the XML file as the intended object. Fallback to 'true' if this parse fails.

Note

  • It is possible for yangcli-pro to change namespaces and drop XML attributes in some cases.

  • This parameter should be set to 'true' if an XML file is getting sent to the server incorrectly.

  • This parameter needs be set to 'true' if an XML file contains invalid XML or invalid YANG values (e.g. for negative testing)

leaf use-rawxml {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --use-rawxml=true

--use-session-vars

The --use-session-vars parameter specifies how global variables will be handled when set from the context of a named session.

  • If 'true', then an assignment (e.g., $$foo = 'bar') will only affect the session-specific instance of the variable, and only be visible within the scope of the named session.

  • If 'false', then assignment statements for global variables will affect the global instance of the variable, and be visible to all sessions.

If the current session is the default session, and not a named session, then the value of this variable is ignored, and all global variable assignments will affect the global instance of the variable, and be visible to all sessions.

leaf use-session-vars {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --use-session-vars=false

--use-traceid

The --use-traceid parameter controls whether the 'trace-id' attribute will be set in the RPC calls or not. By default, 'trace-id' attribute is disabled.

  • If 'true', then the XML RPC will contain 'trace-id' attribute

  • If 'false', then the XML RPC will not contain 'trace-id' attribute

leaf use-traceid {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --use-traceid=true

--use-xmlheader

The --use-xmlheader parameter specifies how file result variables will be written for XML files.

Controls whether the XML preamble header will be written or not. Do not set to 'false' or XML messages sent to a server will be invalid.

leaf use-xmlheader {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --use-xmlheader=false

--user

The --user parameter specifies the user name string on the NETCONF server that should be used when establishing a NETCONF session.

leaf user {
  type nt:NcxName;
}

Syntax

string:user name

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --user=admin --server=myserver

--uservars-file

The --uservars-file parameter contains the file specification of the user global variables XML file to use.

leaf uservars-file {
  type string;
  default "~/.yumapro/yangcli_pro_uservars.xml";
}

Syntax

string:filespec

Default:

$HOME/.yumapro/yangcli_pro_uservars.xml

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro

Example:

yangcli-pro --uservars-file=~/myvars.xml

--with-enable-mode

The --with-enable-mode parameter controls whether an 'enable mode' will be supported for yp-shell.

  • If set to 'true', the user must enter the enable command to enter enable mode. If the enable password has been configured then this password must be provided by the user in order to enter enable mode.

    Within enable mode, the 'config term' command can be used to enter configuration mode.

  • If set to 'false', then enable mode will not be used and the enable, enable password, and enable no-password commands will not be present.

leaf with-enable-mode {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yp-shell

Example:

yp-shell --with-enable-mode=true

--with-notif-commands

The --with-notif-commands parameter controls whether notifications will be supported for yp-shell.

This parameter does not affect yp-shell echoing of notification messages. The --echo-notifs and --echo-notif-loglevel parameters need to be set appropriately to echo received notification messages.

leaf with-notif-commands {
  type boolean;
  default false;
}

Syntax

boolean (true or false)

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

yp-shell

Example:

yp-shell --with-notif-commands=true

--yangmap

The --yangmap parameter specifies a yangmap XML file that should be loaded into the program. See yumaworks-yangmap.yang for details on using YANG mappings in config term mode.

leaf-list yangmap {
  type string;   // filespec
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangcli-pro

Example:

yangcli-pro --yangmap=$HOME/maps/map1.xml

yangdiff-pro CLI Reference

--difftype

The --difftype parameter controls how differences are displayed in the yangdiff-pro program..

The allowed values are 'terse', 'normal', and 'revision'.

The basic report format is:

[add/delete/modify] field-name [field-value]

The 'terse' option will include the names of the top-level fields that are different. The actual differences for modification lines ('M') are not printed.

M typedef C
D container test-D1
D leaf test-D
M container test33

The 'normal' option will include any changes for any nested fields or objects. A brief description of the changes made in a modification line ('M') are printed. This is the default reporting mode.

M typedef C
M type
   M range from 'min .. 41 | 45' to 'min .. 41'
D container test-D1
D leaf test-D
M container test33
   D presence 'not a top-level mand...'
   M choice f
      M case f1
         M leaf f1
            A if-feature 'X'

The 'revision' option will generate the differences report in YANG revision-stmt format. For example:

revision 2009-09-10 {
    description "
       - Changed typedef C
          - Changed type
             - Changed range from 'min .. 41 | 45' to 'min .. 41'
       - Removed container test-D1
       - Removed leaf test-D
       - Changed container test33
          - Removed presence 'not a top-level mand...'
          - Changed choice f
             - Changed case f1
                - Changed leaf f1
                   - Added if-feature 'X'
    ";
 }
typedef DiffType {
    type enumeration {
        enum terse;
        enum normal;
        enum revision;
    }
    default "normal";
}

leaf difftype {
   type DiffType;
}

Syntax

enumeration: terse normal revision

Default:

normal

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdiff-pro

Example:

yangdiff-pro --difftype=revision --new=test3a --old=~test3

--new

The --new parameter specifies the YANG file or directory containing the new revision to be compared in the yangdiff-pro program.

  • If this parameter indicates a filename, then it represents the YANG source module name to compare as the newer of the two revisions.

  • If this parameter indicates a directory (and the --old parameter indicates a filename), then it will be used to to search for a file with the same name as this parameter.

  • If the --old parameter identifies a directory as well (and the --subdirs parameter is 'false'), then the modules within the 'new' directory will be compared to files with the same name in the 'old' directory.

  • If the --subdirs parameter is ''true'', then all sub-directories within the 'src' directory will also be checked.

  • If this string begins with a '~' character, then a username is expected to follow or a directory separator character.

  • If this string begins with a '$' character, then an environment variable name is expected to follow.

~/some/path ==> <my-home-dir>/some/path

~fred/some/path ==> <fred-home-dir>/some/path

$workdir/some/path ==> <workdir-env-var>/some/path

This parameter must be present unless the --help or --version parameters are present.

leaf new {
    type nt:NcModuleSpec;
}

Syntax

string (module or directory specification. length 1 .. 4095)

Default:

none

Min Allowed:

1

Max Allowed:

1

Supported by:

yangdiff-pro

Example:

yangdiff-pro --new=test3a --difftype=terse --old=test3

--old

The --old parameter specifies the YANG file or directory containing the older revision to be compared in the yangdiff-pro program.

  • If this parameter indicates a filename, then it represents the YANG source module name to compare as the older of the two revisions.

  • If this parameter indicates a directory (and thise --new parameter indicates a filename), then it will be used to to search for a file with the same name as the 'new' parameter.

  • If this string begins with a '~' character, then a username is expected to follow or a directory separator character.

  • If this string begins with a '$' character, then an environment variable name is expected to follow.

~/some/path ==> <my-home-dir>/some/path

~fred/some/path ==> <fred-home-dir>/some/path

$workdir/some/path ==> <workdir-env-var>/some/path

This parameter must be present unless the --help or --version parameters are present.

leaf old {
    type nt:NcModuleSpec;
}

Syntax

string (module or directory specification. length 1 .. 4095)

Default:

none

Min Allowed:

1

Max Allowed:

1

Supported by:

yangdiff-pro

Example:

yangdiff-pro --old=test3 --difftype=terse --new=test3a

yangdump-pro CLI Reference

--defnames

The --defnames parameter causes the program output file to be named with the default name for the format, based on the input module name and revision date. Refer to the HTML Translation section for details on specific file formats for HTML output.

If the --output parameter is present and represents an existing directory, then the default filename will be created in that directory, instead of the current directory.

This parameter is ignored if the --format parameter is missing.

leaf defnames {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --defnames=true --subtree=~/workdir/ --format=html

--dependencies

The --dependencies parameter causes information to be reported for the symbols that this [sub]module imports from other modules.

The following information is reported for each dependency:

  • module name

  • revision date

Example report for module 'yangdump-pro':

dependencies:

import ncx 2009-06-12
import ncx-app-common 2009-04-10
import ncxtypes 2008-07-20
leaf dependencies {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --dependencies --module=test4

--doxygen-headers

The --doxygen-headers parameter controls whether doxygen format headers will be used.

  • If 'true' then doxygen comments will be generated in the yumapro-pro program for C and H file generation.

  • If 'false' then the older existing header format will be generated in the yumapro-pro program for C and H file generation.

leaf doxygen-headers {
    type boolean;
    default true;
  }

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --doxygen-headers=false

--exports

The --exports parameter causes information to be reported for the symbols that this [sub]module exports to other modules.

The exports for the entire module are printed, unless the specified input file is a YANG submodule. In that case, just the exports in the submodule are reported.

It includes the following information, generated in this order:

  • [sub]module name

  • version

  • source filespec

  • namespace (module only)

  • prefix (module only)

  • belongs-to (submodule only)

  • typedefs

  • groupings

  • objects

  • RPC operations

  • notifications

  • extensions

  • features

leaf exports {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --exports --module=test3

--feature-code-default

The --feature-code-default parameter controls how yangdump-pro will generate C code for YANG features by default.

  • If dynamic, then by default, features can be loaded at run-time, and objects with if-feature statements will be available in case the feature is enabled.

  • If static, then by default, features are set at compile-time, and any disabled objects will be removed at load-time.

  • If a --feature-dynamic or --feature-static parameter is present for a specific feature, then this parameter will be ignored for that feature.

leaf feature-code-default {
  type enumeration {
    enum static {
    }
    enum dynamic {
    }
  }
  default dynamic;
}

Syntax

enum (dynamic or static)

Default:

dynamic

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --format=c --feature-code-default=static --module=test

--feature-dynamic

The --feature-dynamic parameter controls how yangdump-pro will generate dynamic code for a specific feature. This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name:

test:feature1

It is an error if a --feature-static and this parameter specify the same feature.

Parameters for unknown features will be ignored.

leaf-list feature-dynamic {
  type yt:FeatureSpec;
}

Syntax

formatted string (module:feature)

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangdump-pro

Example:

yangdump-pro --format=c --feature-dynamic=test:feature1 --module=test

--feature-static

The --feature-static parameter controls how yangdump-pro will generate static code for a specific feature.

This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name, e.g.,

test:feature1

It is an error if a --feature-dynamic and this parameter specify the same feature.

Parameters for unknown features will be ignored.

leaf-list feature-dynamic {
  type yt:FeatureSpec;
}

Syntax

formatted string (module:feature)

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangdump-pro

Example:

yangdump-pro --format=c --feature-static=test:feature1 --module=test

--force-prefix

The --force-prefix parameter specifies the prefix to use for short name generation.

If the --short-names parameter is 'true' then this object can be used to force a specific prefix value instead of the module prefix, when generating instrumentation code.

This object should only be used if the module prefix is known to cause a naming conflict with existing code.

This object cannot be used if the --sil-bundle parameter is also used, and --short-names=true.

leaf force-prefix {
  type yt:NcxName;
}

Syntax

identifier string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-sdk --format=c --force-prefix=acme --module=test4

--format

The --format parameter controls the type of yangdump-pro conversion desired, if any.

YumaPro SIL developers should refer to the make_sil_dir_pro or other script to generate SIL code instead of using the yangdump-pro command directly for code generation formats (c, h, uc, uh, yc, yh).

If this parameter is missing, then no translation will be done, but the module will be validated, and any requested reports will be generated.

The following values are supported:

  • yin

    • Generate standard YIN format (XML instance document)

  • xsd

    • XSD 1.0 translation .

    • Data model XSD can be integrated with the with the NETCONF protocol XSD in RFC 4741.

  • html

    • XHTML 1.0 translation.

  • yang

    • Canonical YANG translation .

  • copy

    • Copy with a new name, in canonical module naming format.

  • sql

    • TBD: Generate a module specific SQL template

    • This option is not implemented and not supported.

  • sqldb

    • Generate module specific SQL data for the netconfcentral.sql template.

  • h

    • Generate a module specific netconfd-pro agent instrumentation combined SIL H file.

  • c

    • Generate a module specific netconfd-pro agent instrumentation combined SIL C file.

  • uh

    • Generate a module specific netconfd-pro agent instrumentation User SIL H file.

  • uc

    • Generate a module specific netconfd-pro agent instrumentation User SIL C file.

  • yh

    • Generate a module specific netconfd-pro agent instrumentation YumaPro SIL H file.

  • yc

    • Generate a module specific netconfd-pro agent instrumentation YumaPro SIL C file.

  • bh

    • Generate a SIL bundle netconfd-pro agent instrumentation YumaPro SIL H file.

  • bc

    • Generate a SIL bundle netconfd-pro agent instrumentation YumaPro SIL C file.

leaf format {
  type FormatType;
}

Syntax

enumeration (xsd, sql, sqldb, html, yang, copy, h, c, uc, uh, yc, yh))

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro test1 test2 --format=html --defnames=true --output=~/workdir

--html-div

The --html-div parameter controls whether yangdump-pro HTML translation will generate a single <div> element, or an entire HTML document.

If HTML translation is requested, then setting this parameter to 'true' will cause the output to be a single <div> element, instead of an entire HTML file. This parameter is ignored unless the --format=html parameter is used.

This parameter allows the HTML translation to be easily integrated within more complex WEB pages, but the proper CSS definitions need to be present for the HTML to render properly. It is suggested only HTML experts use this parameter.

The default filename extension will be '.div' instead of '.html' if this parameter is present. The contents will be well-formed XHTML 1.0, but without any namespace declarations.

leaf html-div {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --html-div=true --format=html --module=test

--html-toc

The --html-toc parameter controls how yangdump-pro HTML translation will generate a table of contents for the HTML document.

If HTML translation is requested, then this parameter will cause the output to contain a bullet list TOC, a drop-down menu TOC, or none.

This option has no effect unless the --format=html parameter is also present.

The following values are supported:

  • none

    • No TOC is generated.

  • plain

    • A plain list-based TOC is generated

  • menu

    • A suckerfish (Javascript) drop-down menu will be generated.

    • This is the default option.

leaf html-toc {
  type TocType;
}

Syntax

enumeration (none, plain, menu)

Default:

menu

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --html-toc=plain --format=html --module=test

--identifiers

The --identifiers parameter causes information to be object identifier strings to be reported for the object, RPC operation, and notification definitions within the input module(s).

Each accessible object node is listed once, including all child nodes. Notifications and RPC methods are considered top-level objects, and have object identifiers as well as configuration and state data.

The following information is reported for each identifier:

  • object type (e.g., leaf, container, rpc)

  • absolute XPath expression for the object

Example report for module yuma-mysession.yang:

identifiers:

rpc /get-my-session
container /get-my-session/output
leaf /get-my-session/output/indent
leaf /get-my-session/output/linesize
leaf /get-my-session/output/with-defaults
container /get-my-session/input
rpc /set-my-session
container /set-my-session/input
leaf /set-my-session/input/indent
leaf /set-my-session/input/linesize
leaf /set-my-session/input/with-defaults
container /set-my-session/output
leaf identifiers {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --identifiers --module=yuma-mysession

--lang-errors

The --lang-errors parameter causes the yangdump-pro program to list all the error and warning numbers, and the default message for each one. This is done in the format expected by the errmsg-tr.py error message translator program.

After this is done, the yangdump-pro program will exit.

Example output:

400@session dropped
401@media type not in range
402@an appropriate representation could not be found
403@data is not in a format acceptable for processing
404@unknown query parameter
405@missing Accept header
406@password is too short
407@missing input data
408@value disabled by if-feature-stmt
409@when-stmt not allowed on key leaf
410@if-feature-stmt not allowed on key leaf
411@invalid XML response would be returned
412@JSON encoding not yet supported
413@missing data definition statement
414@default value conditional on if-feature
415@invalid escape sequence in double-quoted string
416@invalid status for child node
417@configuration template not found
leaf lang-errors {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --lang-errors

--modversion

The --modversion parameter causes the module name and revision date to be displayed for each module specified in the input.

Example output for module 'test':

modversion:

module test 2009-06-10
leaf modversion {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --modversion --module=test

--objview

The --objview parameter specifies how objects will be generated during translation, for HTML and canonical YANG file translations.

The enumeration values are:

  • raw

    • output includes augment and uses clauses, not the expanded results of those clauses.

  • cooked

    • output does not include augment or uses clauses, just the objects generated from those clauses.

The default mode is the 'raw' view.

leaf objview {
  type ObjViewType;
}

Syntax

enumeration (raw, cooked)

Default:

raw

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --objview=cooked --module=test --format=html

--quiet-mode

The --quiet-mode parameter specifies that quiet mode reporting should be done. In this mode, the module summary line will not be printed unless there are errors or warnings for the module. This parameter only works with the --module parameter, not the --subtree parameter.

Without this parameter:

user1$ yangdump-pro --module=test

*** /home/andy/swdev/ypwork/netconf/modules/test/pass/test.yang
*** 0 Errors, 0 Warnings

user1$

With this parameter:

user1$ yangdump-pro --module=test  --quiet-mode

user1$
leaf quiet-mode {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --quiet-mode --subtree=test

--short-names

The --short-names parameter specifies if short names of long names will be used in SIL or SIL-SA code generation.

If 'true', generate instrumentation code using short names whenever possible. The module prefix and the node name will be used. A numeric qualifier will be appended to the name if the short name would cause a duplicate symbol to be generated. The 'force-prefix' value will be use for the prefix if that parameter is present.

If 'false', then generate instrumentation code using long names which encode the module name and the entire path to the object into the name.

Refer to the Short Names for SIL and SIL-SA Code Generation section for more details.

leaf short-names {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --short-names=false --module=test --format=yc

--show-errors

The --show-errors parameter causes the yangdump-pro program to list all the error and warning numbers, and the default message for each one.

The 3 digit number, followed by the message string, will be printed 1 per line.

After this is done, the yangdump-pro program will exit.

This parameter can be combined with the --help parameter. The --version parameter has no affect if this parameter is present. The program version string will be printed in both cases.

The NETCONF error-tag values are used directly when no other error number is appropriate. These error numbers are as follows:

257     resource in use
258     invalid value
259     too big
260     missing attribute
261     bad attribute
262     unknown attribute
263     missing element
264     bad element
265     unknown element
266     unknown namespace
267     access denied
268     lock denied
269     resource denied
270     rollback failed
271     data exists
272     data missing
273     operation not supported
274     operation failed
275     partial operation
leaf show-errors {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --show-errors

--sil-bundle

The --sil-bundle parameter specifies the name of the SIL bundle to create. It is used with the --format parameter to generate specific SIL C or H files. The --module parameter is used to specify the YANG modules that will be included in the SIL bundle.

The parameter specifies the name of the SIL bundle to create. It is used to create SIL code stubs for a bundle of YANG modules.

All the specified modules will be loaded into memory. Then the SIL code stubs will be generated according to the given parameters. Any external augment-stmt data will be expanded at this point, so the SIL code will be generated for the fully augmented version.

leaf sil-bundle {
  type yt:NcxName;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

no maximum

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --format=yc --sil-bundle=test --module=test1 --module=test2 --module=test3

--sil-edit1

The --sil-edit1 parameter is used to control code generation. If present, then the deprecated first generation 'edit' functions will be generated for SIL or SIL-SA modes instead of current 2nd generation 'edit' functions, if code generation is being requested. Ignored otherwise. Refer to the EDIT1 Callback section for more details.

Note

The EDIT1 callbacks are now deprecated. A warning will be generated if this parameter is used for code generation.

leaf sil-edit1 {
  type empty;
  status deprecated;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --format=yc --sil-edit1 --module=test1

--sil-edit2

The --sil-edit2 parameter specifies that the second generation SIL or SIL-SA edit callbacks should be generated instead of the first generation callbacks. The new callbacks are optimized so the terminal nodes (leaf, leaf-list-, anyxml) are handled by a parent callback (for container, list, or choice). Refer to the EDIT2 Callback section for mode details.

The EDIT2 callbacks are now the default. This parameter is no longer needed.

leaf sil-edit2 {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --format=yc --sil-edit2 --module=test1

--sil-get1

The --sil-get1 parameter is used to control code generation. If present, then the deprecated first generation 'get' functions will be generated for SIL or SIL-SA modes instead of current 2nd generation 'get' functions, if code generation is being requested. Ignored otherwise.

Note

The GET1 callbacks are now deprecated. A warning will be generated if this parameter is used for code generation.

leaf sil-get1 {
  type empty;
  status deprecated;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --format=yc --sil-get1 --module=test1

--sil-get2

The --sil-get2 parameter specifies that the second generation SIL or SIL-SA get callbacks should be generated instead of the first generation callbacks. The new callbacks are optimized so the terminal nodes (leaf, leaf-list-, anyxml) are handled by a parent callback (for container, list, or choice). Refer to the GET2 Callback section for more details.

Note

The GET2 callbacks are now the default. This parameter is no longer needed.

leaf sil-get2 {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --format=yc --sil-get2 --module=test1

--sil-include

The --sil-include parameter specifies the name of a file to use in a C “#include” statement. These statements will be generated in the C files only, and in the order they are specified.

Specifies the name of an include file to inject into C files when the conversion format is equal to 'c' or 'yc'. An #include statement will be generated for each instance of this parameter, in the order these parameters are given.

The #include statements will be generated after the system <include> statement and general YumaPro include statements, but before the YANG module specific include statements.

leaf-list sil-include {
  ordered-by user;
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

no maximum

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --format=yc --sil-include=system1.h --sil-include=system2.h --module=test

--sil-nmda

The --sil-nmda parameter specifies that NMDA specific SIL or SIL-SA C code should be generated.

If present, then the 2nd generation NMDA 'get' functions will be generated for SIL or SIL-SA modes, if code generation is being requested. Ignored otherwise.

The GET2 callbacks will be generated with extra NMDA specific code for config=true data nodes.

It is an error if this parameter is selected but --sil-get2 is not selected.

The extra code generated is used to support the <get-data> operation. There will be GET2 callbacks generated for configuration data nodes, along with corresponding register and unregister code.

There are 2 new parameters within the GET2 control block passed to the GET2 callback function:

  • datastore: identifies the NMDA datastore to retrieve data from.

  • with_origin: flag indicating that the NMDA “origin” property should be set for the data nodes returned by the GET2 callbacks

leaf sil-nmda {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro --format=yc --sil-get2 --sil-nmda --module=test

--sil-sa

The --sil-sa parameter specifies that the server callback code for a subagent (SIL-SA) should be generated instead of code for running in the master agent (SIL).

leaf sil-sa {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro yangdump-sdk

Example:

yangdump-pro--format=yc --sil-get2 --sil-sa --module=test1

--simurls

The --simurls parameter specifies how URL strings are generated for HTML links.

If HTML translation is requested, then setting this parameter to 'true' will cause the format of URLs within links to be generated in simplified form, for WEB development engines such as CherryPy, which support this format.

leaf simurls {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --simurls=true --format=html --module=test

--stats

The --stats parameter is used to request a YANG usage statistics report.

See the --totals parameter to control statistics totals reporting, when used with this parameter.

Statistics are not normally collected. This must be enabled by setting this parameter to a value other than 'none' (the default). Any other value will cause statistics to be collected and reported after each input module is validated.

The verbosity of the statistics report is controlled with this parameter. Each enumeration includes all the previous statistics (from lower enumerations), plus additional statistics. The following table describes the counters that are displayed at each minimum enumeration value.

Complexity score

brief

Numeric score characterizing the level of implementation complexity for the module. A higher number indicates a more complex module.

Total nodes

brief

The total number of object nodes (data, notification, rpc) in the module.

Extensions

basic

The number of extension statements.

Features

basic

The number of feature statements.

Groupings

basic

The number of exported groupings.

Typedefs

basic

The number of exported typedefs.

Deviations

basic

The number of deviation statements.

Top Data Nodes

basic

The number of top-level data nodes.

Config nodes

basic

The number of configurable nodes.

Non-config nodes

basic

The number of non-configurable nodes.

Mandatory nodes

advanced

The number of mandatory nodes.

Optional nodes

advanced

The number of optional nodes.

Notifications

advanced

The number of notification statements.

Rpcs

advanced

The number of rpc statements.

Rpc inputs

advanced

The number of RPC input statements.

Rpc outputs

advanced

The number of rpc output statements

Augments

advanced

The number of top-level augment statements within data nodes (not groupings).

Uses

advanced

The number of uses statements within data nodes (not groupings).

Choices

advanced

The number of choice statements.

Cases

advanced

The number of case statements. This includes implied cases which contain a single data node.

Anyxmls

advanced

The number of anyxml statements.

NP containers

advanced

The number of non-presence containers.

P containers

advanced

The number of presence containers.

Lists

advanced

The number of list statements.

Leaf-lists

advanced

The number of leaf-list statements.

Key leafs

advanced

The number of leaf statements which are defined within a list to be a key.

Plain leafs

advanced

The number of plain leaf statements.

Imports

all

The number of import statements.

Integral numbers

advanced

The number of leaf and leaf-list statements that used a numeric data type other than decimal64.

Decimal64s

advanced

The number of leaf and leaf-list statements that used the decimal64 data type.

Enumerations

advanced

The number of leaf and leaf-list statements that used the enumeration data type.

Bits

advanced

The number of leaf and leaf-list statements that used the bits data type.

Booleans

advanced

The number of leaf and leaf-list statements that used the boolean data type.

Emptys

advanced

The number of leaf and leaf-list statements that used the empty data type.

Strings

advanced

The number of leaf and leaf-list statements that used the string data type.

Binarys

advanced

The number of leaf and leaf-list statements that used the binary data type.

Instance Identifiers

advanced

The number of leaf and leaf-list statements that used the instance-identifier data type.

Leafrefs

advanced

The number of leaf and leaf-list statements that used the leafref data type.

Identityrefs

advanced

The number of leaf and leaf-list statements that used the identityref data type.

Unions

advanced

The number of leaf and leaf-list statements that used the union data type.

leaf stats {
  type enumeration {
     enum none {
     }
     enum brief {
     }
     enum basic {
     }
     enum advanced {
     }
     enum all {
     }
  }
  default "none";
}

Syntax

enumeration [none, brief, basic, advanced, all]

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --stats=advanced --module=test

--subtree

The --subtree parameter is a leaf-list of path specifications that may contain YANG files.

It must be a string value that represents a path specification of the directory subtree to use.

All of the YANG source modules contained in the specified directory sub-tree will be processed.

Note that symbolic links are not followed during the directory traversal. Only real directories will be searched and regular files will be checked as modules. Processing will continue to the next file if a module contains errors.

If this string begins with a '~' character, then a username is expected to follow or a directory separator character. If it begins with a '$' character, then an environment variable name is expected to follow.

If 'false', then only the top-level directory specified by this parameter will be searched for YANG files.

If 'true', then all the directories contained within the one specified by this parameter will also be searched for YANG files. The exceptions are:

  • any directory beginning with a dot character ('.'), such as '.svn'

  • any directory named 'CVS'

Examples:

~/some/path ==> <my-home-dir>/some/path
~fred/some/path ==> <fred-home-dir>/some/path
$workdir/some/path ==> <workdir-env-var>/some/path
leaf-list subtree {
    type yt:NcPathSpec;
}

Syntax

string: path specification

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

yangdiff-pro yangdump-pro

Example:

yangdump-pro --format=html --subtree=~/testmods --subtree=./workdir --output=./yang-html-files

--totals

The --totals parameter is used with the --stats parameter to control how summary statistics are reported.

  • The --stats parameter must be set to a value other than 'none' for this parameter to have any affect. The value of this parameter will control which statistics are reported.

  • Normally, no summary is generated (default is 'none').

  • The 'summary' value will not have any affect unless there is more than one input module in the statistics collection.

  • The 'summary-only' value will cause the module statistics reports to be skipped, and only a summary of all the input modules will be displayed.

leaf totals {
   type enumeration {
      enum none {
      }
      enum summary {
      }
      enum summary-only {
      }
   }
   default "none";
}

Syntax

enumeration [none, summary, summary-only]

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --stats=basic --totals=summary-only --subtree=~/my-test-modules

--tree-identifiers

The --tree-identifiers parameter causes information to be object identifier name strings to be reported for the object, RPC operation, and notification definitions within the input module(s).

The following information is reported for each identifier:

  • object type (e.g., leaf, container, rpc)

  • local name for the object (indented for each descendant node)

Example report for module 'yuma-mysession':

identifiers:
  rpc get-my-session
    container output
      leaf indent
      leaf linesize
      leaf with-defaults
    container input
  rpc set-my-session
    container input
      leaf indent
      leaf linesize
      leaf with-defaults
    container output
leaf tree-identifiers {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --tree-identifiers --module=yuma-mysession

--unified

The --unified parameter indicates if submodules should be combined into the main module for yangdump-pro translation output. Any include statements will be replaced by the module definitions contained within the submodule.

If set to 'true', then submodules will be processed within the main module, in a unified report, instead of separately, one report for each file.

For translation purposes, this parameter will cause any sub-modules to be treated as if they were defined in the main module. Actual definitions will be generated instead of an 'include' statement, for each submodule.

If this mode is selected, then submodules will be ignored:

  • If entered with the --module parameter explicitly.

  • If found when searching for main YANG files to process in a directory, e.g., for the --subtree parameter.

If set to 'false', then a separate output file is generated for each input file, so that XSD output and other reports for a main module will not include information for submodules.

Note

This parameter must be set to 'true' for SIL and SIL-SA code generation.

leaf unified {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --unified=true --format=html --subtree=$PROJECT_X/modules --defnames=true --output=$PROJECT_X/html

--urlstart

The --urlstart parameter specifies the string to start all URLs during yangdump-pro HTML translation.

If present, then this string will be used to start all HREF links and URLs generated for SQL and HTML translation. It is expected to be a URL ending with a directory path. The trailing separator '/' will be added if it is missing.

If not present (the default), then relative URLs, starting with the file name will be generated instead.

For example, if this parameter is set to the following string:

http://acme.com/public

The URL generated for the 'bar' type on line 53, in the module FOO (version 2008-01-01) would be:

  • if --versionnames=false:

    http://acme.com/public/FOO.html#bar.53
    
  • if --versionnames=true (default):

    http://acme.com/public/FOO_2008-01-01.html#bar.53
    
leaf urlstart {
  type string;
}

Syntax

string (URL format)

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --urlstart="/example.com/public/" --unified=true --format=html --subtree=$PROJECT_X/modules --defnames=true --output=$PROJECT_X/html

--versionnames

The --versionnames parameter indicates that revision dates should not be used when constructing any output YANG module file names.

If present, the default filenames will not contain the module version string. Normally, the [sub]module name and version string are both used to generate a default file name, when the --defnames output parameter is set to 'true'. This parameter will cause filenames to be generated which do not contain the revision date string.

leaf versionnames {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --versionnames=false --subtree=/testpath --defnames=true --output=~/work3 --format=html

--xsd-schemaloc

The --xsd-schemaloc parameter specifies that yangdump-pro XSD translations should include the 'schemaLocation' attribute.

If present, then the 'schemaLocation' attribute will be generated during XSD translation. This will be done for the module being processed, and any modules that are imported into that module.

If not present (the default), then the 'schemaLocation' attribute is not generated during XSD translation.

Relative URLs for include and import directives will be generated, starting with the file name.

For example, if this parameter is set to the following string:

http://example.com/public

The 'schemaLocation' XSD for the module test3 (version 10-19-2008) would be:

  • If --versionnames=false:

    xsi:schemaLocation='http://netconfcentral.org/ns/test3
    http://example.com/public/test3.xsd'
    
  • if --versionnames=true (default):

    xsi:schemaLocation='http://netconfcentral.org/ns/test3
    http://example.com/public/test3_2008-10-19.xsd'
    

Note

This parameter is no longer supported because XSD translation is no longer supported.

leaf xsd-schemaloc {
  type string;
}

Syntax

string (URL formal)

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

yangdump-pro

Example:

yangdump-pro --xsd-schemaloc="http://example.com" --format=xsd --module=test3 --defnames=true

ypgnmi-app CLI Reference

The ypgnmi-app program uses command line interface (CLI) parameters to control program behavior.

The following sections document all the CLI parameters relevant to this program, in alphabetical order.

--bind-address

The --bind-address parameter specifies the gNMI server binding. This is the address that the gNMI client will use top contact the gNMI server. By default the address is the local host and default port is 10161.

Syntax

inet:ip-address : inet:port-number

Default:

localhost:10161

Min Allowed:

0

Max Allowed:

1

Supported by:

ypgnmi-app

Example:

ypgnmi-app --bind-address=192.168.1.200:10161

--service-id

The --service-id parameter specifies the service identifier to use when registering with the netconfd-proserver. The default is 'yp-gnmi' if no value is specified.

Syntax

string

Default:

yp-gnmi

Min Allowed:

0

Max Allowed:

1

Supported by:

ypgnmi-app

Example:

ypgnmi-app --service-id=service1

ypgrpc-go-app CLI Reference

The ypgrpc-go-app program uses command line interface (CLI) parameters to control program behavior.

The following sections document all the CLI parameters relevant to this program, in alphabetical order.

--insecure

The --insecure parameter directs to skip TLS validation and allowing to run the program without the --ca and --cert parameters.

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

ypgrpc-go-app

Example:

ypgrpc-go-app --insecure=true

--proto

The --proto parameter specifies the .proto files for the ypgrpc-go-app application to use. There can be multiple .proto files specified.

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

ypgrpc-go-app

Example:

ypgrpc-go-app --proto=example --proto=helloworld

--protopath

The --protopath parameter specifies the .proto file search path to use while searching for .proto files.

Syntax

string

Default:

$HOME/protos

Min Allowed:

0

Max Allowed:

N

Supported by:

ypgrpc-go-app

Example:

ypgrpc-go-app --protopath=/tmp/proto --protopath=$HOME/protos

--server-address

The --server-address parameter specifies the netconfd-pro server IP address. The default is '127.0.0.1' if no value is specified.

Syntax

inet:ip-address

Default:

127.0.0.1

Min Allowed:

0

Max Allowed:

1

Supported by:

ypgrpc-go-app

Example:

ypgrpc-go-app --server-address=10.10.0.11