3  CLI Reference

The netconfd-pro program uses command line interface (CLI) parameters to control program behavior.

The following sections document all the YumaPro CLI parameters relevant to this program, in alphabetical order.

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

 

--access-control parameter

 

Syntax

enumeration:

   enforcing
  permissive
  disabled
  off

Default:

enforcing

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \
 --access-control=permissive

 

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

These operations have the following meaning:

--allow-leaflist-delete-all parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

These operations have the following meaning:

--allow-list-delete-all parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

3.4  --allowed-user

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

--allowed-user parameter

 

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

 

3.5  --alt-names

The --alt-names parameter specifies whether the server will recognize the '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.

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.

 

--alt-names parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro --alt-names=false

 

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

The following example module shows how annotations could be added to the ietf-interfaces 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-chilren-first;

    }

  }

 

  deviation /if:interfaces/if:interface {

    deviate add {

      ncx:sil-delete-chilren-first;

    }

  }

 

 

}

 

 

 

 

--annotation parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro –annotation=devtest1-d

 

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

 

--audit-log parameter

 

Syntax

filespec

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

 

--no-audit-log parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

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

 

--audit-log-append parameter

 

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&

 

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

 

--audit-log-candidate parameter

 

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&

 

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

There are 7 settings that can be used:

 

--audit-log-console-level parameter

 

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

 

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

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

 

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-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 on session 3 by andy@127.0.0.1

  time: 2018-09-04T20:44:52Z

  message-id: 5

  sourcetype: datastore

  source: running

 

 

 

start-client-session:

  time: 2018-09-04T20:44:31Z

  protocol: NETCONF

  transport: netconf-ssh

  username: andy

  peeraddr: 127.0.0.1

  session ID: 3

 

 

 

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

 

 

 

start-control-session:

  time: 2018-09-04T20:53:59Z

  protocol: YControl

  transport: netconf-aflocal

  username: andy

  peeraddr: 127.0.0.1

  session ID: 3

 

 

 

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

 

 

 

nacm-write-error:

  time: 2018-09-04T21:04:51Z

  username: andy

  operation: create leaf int32.1

  path:: /t:int32.1

 

 

nacm-exec-error:

  time: 2018-09-04T21:08:54Z

  username: andy

  module name: yumaworks-system

  RPC name: load

 

 

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

 

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

 

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

 

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”

 

 

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

 

There are 7 settings that can be used:

 

--audit-log-level parameter

 

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&

 

 

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

 

--autodelete-pdu-error parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

3.15  --binary-display-maxlen

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

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

 

 

--binary-display-maxlen parameter

 

Syntax

uint32

Default:

0

Min Allowed:

0

Max Allowed:

1

Supported by:

yangcli-pro, netconfd-pro

Example:

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

 

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

--bundle parameter

 

Syntax

SIL bundle name

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --bundle=interfaces

 

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

 

--callhome-reconnect parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –callhome-reconnect=true

 

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

 

--callhome-retry-interval parameter

 

Syntax

uint16 [1..max]

Default:

60 seconds

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –callhome-retry-interval=30

 

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

 

--callhome-retry-max parameter

 

Syntax

uint16

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –callhome-retry-max=0

 

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

 

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

 

--callhome-server parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

 

 

3.21  --callhome-sshd-command

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

 

--callhome-sshd-command parameter

 

Syntax

string

Default:

/usr/sbin/sshd

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

Netconfd-pro \

  –callhome-sshd-command=/bin/sshd

 

 

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

 

--callhome-sshd-config parameter

 

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

 

 

 

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

 

--callhome-subsys-command parameter

 

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

 

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

 

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

 

--callhome-tls-server parameter

 

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

 

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

 

--cert-default-user parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –cert-default-user=admin

 

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

 

 

            Example: admin@60:C8:5C:08:82:55

 

 

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

 

--cert-usermap parameter

 

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

 

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

               }

 

 

Default "/etc/yumapro/netconfd-pro.d";

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

--config parameter

 

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

 

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

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.

--config parameter

 

Syntax

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

Default:

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

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro \
 --config=~/testconf.conf

 

 

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

 

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.

 

--convert-subtree-filter parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

3.30  --create-empty-npcontainers

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

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.

 

--create-empty-npcontainers parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

3.31  --datapath

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

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

--datapath parameter

 

Syntax

string: list of directory specifications

Default:

$YUMAPRO_DATAPATH environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro \
 --datapath=”~/work2:~/data”

 

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

 

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

 

--db-lock-timeout parameter

 

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

 

 

3.34  --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-with-defaults.yang.  Here is a summary:

--default-style parameter

 

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

 

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

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

The value 'false' is always used!!!

 

--delete-empty-npcontainers parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

3.36  --deviation

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

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

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

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

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

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

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

--deviation parameter

 

Syntax

module name or filespec

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro
yangcli-pro
yangdump-pro

Example:

netconfd-pro \
 --deviation=test1_deviations

 

 

3.37  --errmsg

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

 

 

           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.

 

           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

 

           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/

 

 

--errmsg parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro \
 --errmsg=”117:en:Database write failed”

 

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

 

--errmsg-lang parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --errmsg-lang=ru

 

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

 

--eventlog-size parameter

 

Syntax

uint32

Default:

1000

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --eventlog-size=20000

 

 

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

 

--event-stream parameter

 

Syntax

NcxName (string)

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

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

 

 

3.41  --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' and 'notificationComplete' are subscription-specific and  always sent only to the subscription, not the event stream.  Therefore these notifications are not affected by this parameter.

 

--event-stream-map parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro \

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

 

3.42  --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.  Use this parameter with caution!!!  Use the backup operation to save the current configuration first.

 

--factory-startup parameter

 

Syntax

   --factory-startup

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --factory-startup

 

3.43  --feature-disable

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

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

 

test:feature1

 

 

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

Parameters for unknown features will be ignored.

 

--feature-disable parameter

 

Syntax

formatted string (module:feature

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

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

Example:

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

 

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

 

--feature-enable parameter

 

Syntax

formatted string (module:feature

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

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

Example:

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

 

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

 

--feature-enable-default parameter

 

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

 

 

3.46  --fileloc-fhs

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

 

If -fileloc-fhs=true:

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

 

              File Type     

Example

              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 parameter

 

Syntax

boolean (true or false)

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –fileloc-fhs=true

 

3.47  --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 this parameter is enabled then the following parameters must be configured or the server will exit with an error:

 

--ha-enabled parameter

 

Syntax

boolean (true or false)

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –ha-enabled=true

 

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

 

--ha-initial-active parameter

 

Syntax

string (NcxName)

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

 

--ha-server parameter

 

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.105:8090

 

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

 

--ha-server-key parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

    –ha-server-key=ha-pool-1

 

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

 

--ha-sil-standby parameter

 

Syntax

boolean (true or false)

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –ha-sil-standby=true

 

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

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.

--hello-timeout parameter

 

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

 

3.53  --help

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

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

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

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

--help parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro --help

 

3.54  --help-mode

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

 

--help-mode parameter

 

Syntax

choice of 3 empty leafs

  --brief
 --normal
 --full

Default:

normal

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro --help --brief

 

 

 

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

 

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.

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.

 

--hide-module parameter

 

Syntax

string: module name

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro \
  --hide-module=mysecretmod

 

 

3.56  --home

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

 

--home parameter

 

Syntax

string: pathspec

Default:

$HOME environment value

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

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

 

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

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.

 

--idle-timeout parameter

 

Syntax

uint32; 0 == disabled;

range 30 .. 360000 seconds (100 hours max)

Default:

3600 (1 hour)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --idle-timeout=30000

 

 

 

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

 

--import-version-bestmatch parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

3.59  --indent

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

 

--indent parameter

 

Syntax

uint32 (0 .. 9)

Default:

2

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro --indent=4

 

3.60  --insecure-ok

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

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

 

--insecure-ok parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro –insecure-ok=true

 

3.61  --library-mode

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

 

 

      leaf library-mode {

        description

          "If true, then the server will operate in YANG module

           library mode. It will find all the YANG modules

           and make them available for <get-schema> operations.

 

           The following NETCONF operations are available when

           the server is operating in library mode:

 

             ietf-netconf:get

             ietf-netconf:get-config

             ietf-netconf-monitoring:get-schema

             yuma-system:restart

             yuma-system:shutdown

          ";

        type boolean;

        default false;

      }

 

 

If library-mode is true, then the server will ignore all the –module, --deviation, and –bundle parameters.  Instead of using these parameters to load modules, only the base modules loaded by default into the server will be used.

The server will scan the module search path and add all revisions of all modules it finds to the YANG library “module” list. Only one copy of each revision will be loaded in case the same file existing in multiple places in the module search path.

The YANG library will provide a “schema” leaf that can be used by RESTCONF to retrieve the YANG module.

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

The server cannot be used for editing or normal operations if YANG library mode is activated.

 

--library-mode parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –library-mode=true

 

 

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

 

--loadpath parameter

 

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”

 

 

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

 

--log parameter

 

Syntax

string: log file specification

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

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

 

3.64  --log-append

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

 

--log-append parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

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

 

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

 

--log-backtrace parameter

 

Syntax

Max frame count: 0..200

Default:

0 means use internal default (20)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro --log-backtrace=0

 

3.66  --log-backtrace-detail

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

 

--log-backtrace-detail parameter

 

Syntax

empty

Default:

  none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro --log-backtrace=0 \

  --log-backtrace-detail

 

3.67  --log-backtrace-level

The –log-backtrace-level parameter specifies that stack frame trace information be appended only to selected log message levels (see --log-level).

 

--log-backtrace-level parameter

 

Syntax

Enumeration:
error
warn
info
debug
debug2
debug3
debug4

One or more enumeration(s) may be specified by enclosing the string in double quotes ('”') and separating each member with a space.

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro –log-backtrace=0 \

  --log-backtrace-level=”error debug”

 

 

3.68  --log-backtrace-stream

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

--log-backtrace-stream parameter

 

Syntax

Enumeration:
logfile

stdout

stderr

syslog

vendor

One or more enumeration(s) may be specified by enclosing the string in double quotes ('”') and separating each member with a space.

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro --log-syslog         \

  --log=server.log                \

  --log-backtrace=0               \

  --log-backtrace-stream=”logfile”

 

3.69  --log-console

The –log-console parameter directs that log output will be be sent to STDOUT, after being sent to the log file and/or local syslog daemon. (This assumes that –-log and/or --log-syslog are present).

 

--log-console parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro –log=file --log-syslog \

--log-console &

 

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

Assumes that the --with-notifications CLI parameter is set to 'true'

 

--log-event-drops parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –log-event-drops=true

 

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

--log-header parameter

 

Syntax

Enumeration:
custom

localtime

One or more enumeration(s) may be specified by enclosing the string in double quotes ('”') and separating each member with a space.

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

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

  --log-header=”custom localtime”&

 

 

3.72  --log-level

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

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

There are 7 settings that can be used:

 

--log-level parameter

 

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&

 

3.73  --log-mirroring

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

 

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

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

There are 7 settings that can be used:

 

--log-pthread-level parameter

 

Syntax

enumeration:
 off
 error
 warn
 info
 debug
 debug2
 debug3
 debug4

Default:

--info (--debug for DEBUG builds)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

Netconfd-pro \

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

 

3.75  --log-stderr

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

 

--log-stderr parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro --log-stderr > logFile&

! All log messages redirected to logFile except ...

! Error level messages displayed on console

 

 

3.76  --log-syslog

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

 

--log-syslog parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro --log-syslog

 

3.77  --log-syslog-level

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

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

There are 7 settings that can be used:

--log-syslog-level parameter

 

Syntax

enumeration:
 off
 error
 warn
 info
 debug
 debug2
 debug3
 debug4

Default:

--info (--debug for DEBUG builds)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

Netconfd-pro –log-logfile \

> --log-level=debug \

> --log-syslog \

> --log-syslog-level=info &

 

3.78  --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 YumaPro API Reference Manual. 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.

 

--log-vendor parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro --log-vendor

 

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

 

--log-vendor-level parameter

 

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

 

3.80  --match-names

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

The following values are supported::

          The name must exactly match the node name for all characters in both name strings.

          The name must match the node name for all characters in both name strings.

          Strings are not case-sensitive.

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

          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.

          The name must exactly match the first N characters of any node name. The first one

          found will be used.

          The name must exactly match the first N characters of any node name. The first one

          found will be used. Strings are not case-sensitive.

 

--match-names parameter

 

Syntax

enum:
exact
exact-nocase
one
one-nocase
first

 first-nocase

Default:

one-nocase

Min Allowed:

0

Max Allowed:

1

Supported by:

 netconfd-pro
yangcli-pro

Example:

netconfd-pro --match-names=first

 

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

 

--max-burst parameter

 

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-burst=100

 

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

 

--max-cli-sessions parameter

 

Syntax

uint32 (0 .. 1024)

Default:

0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –max-cli-sessions=2

 

3.83  --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. This is the default for leaf-list GET2 callbacks.

 

--max-getbulk parameter

 

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-getbulk=100

 

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

 

--max-sessions parameter

 

Syntax

uint32 (0 .. 1024)

Default:

8

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-sessions=10

 

 

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

 

--max-strlen parameter

 

Syntax

int32 (65536 .. INT_MAX)

Default:

262144

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-strlen=1000000

 

 

 

3.86  --message-indent

The --message-indent parameter specifies the number of spaces to indent for each level of output in a protocol message, e.g. NETCONF request. The value zero means no indent, just line feeds.  The value -1 means no indent and no line feeds either.  If --log-level=debug4 then this parameter will be set to at least the value ‘1’ (if the set value is less than 1).

 

--message-indent parameter

 

Syntax

int32 (-1 .. 9)

Default:

-1

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

yangcli-pro

Example:

netconfd-pro --message-indent=2

 

 

3.87  --modpath

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

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

 

--modpath parameter

 

Syntax

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:

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

 

3.88  --module

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

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

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

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

 

--module parameter

 

Syntax

module name or filespec

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro
yangcli-pro
yangdump-pro

Example:

netconfd-pro \
 --module=test1 \
 --module=test2

 

3.89  --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 the –module-tag parameter which is used as a filter to include only data nodes from modules that match the specified module-tag.

 

Examples:

 

 

--module-tagmap parameter

 

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

 

 

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

 

--netconf-capability parameter

 

Syntax

inet:uri

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

 

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

 

--netconf-tls-address parameter

 

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

 

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

 

--netconf-tls-certificate parameter

 

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

 

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

 

--netconf-tls-key parameter

 

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

 

 

 

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

 

--netconf-tls-port parameter

 

Syntax

inet:port-number

Default:

6513

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

 

--netconf-tls-trust-store parameter

 

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

 

3.96  --no-config

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

--no-config parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro --no-config

 

 

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

In this case the default log file will not be created.  The --log-level parameter will be set to 'none'.

This parameter will be ignored if the --log parameter is set. This parameter has no affect on the audit-log or syslog logging.

 

--no-log parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

3.98  --no-nvstore

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

 

The following operations are not affected by this parameter:

 

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.

 

--no-nvstore parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-nvstore

 

 

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

 

--no-startup parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-startup

 

 

3.100  --no-watcher

The no-watcher parameter controls the ypwatcher program. With the parameter the server starts without launching the ypwatcher program.

 

--no-watcher parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-watcher

 

 

3.101  --port

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

 

 

3.102  --protocols

The --protocols parameter specifies which NETCONF protocol versions should be enabled.
The base:1.0 (RFC 4741/4742) and base:1.1 (RFC 6241/6242) capabilities are controlled with this parameter.

 

--protocols parameter

 

Syntax

bits

Default:

netconf1.0 netconf1.1

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –protocols=netconf1.0

 

 

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

 

--push-max-operational parameter

 

Syntax

uint32 (subscriptions)

Default:

4

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –push-max-operational=0

 

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

 

--push-max-periodic parameter

 

Syntax

uint32 (subscriptions)

Default:

16

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –push-max-periodic=0

 

 

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

 

--push-min-dampening parameter

 

Syntax

uint32 (centiseconds)

Default:

100

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –push-min-dampening=10

 

 

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

 

--push-min-period parameter

 

Syntax

uint32 (centiseconds)

Default:

100

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –push-min-period=10

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

 

--push-simop-enabled parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –push-simop-enabled=false

 

 

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

 

--push-simop-patch-update parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

 

--push-simop-enabled parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –push-simop-enabled=false

 

 

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

 

--restconf-capability parameter

 

Syntax

inet:uri

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

 

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

 

--restconf-default-encoding parameter

 

Syntax

enum (xml, json)

Default:

json

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

 

--restconf-server-url parameter

 

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

 

3.113  --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 header:

            application/yang-data+xml

            application/yang-patch+json

 

If set to 'false', the server will try to accept not normative header entries.

Acceptable not normative Accept header:

            application/xml,application/json;q=0.9

 

Acceptable not normative Content-Type headers:

            application/xml

            application/json

            text/xml

--restconf-strict-headers parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

  --restconf-strict-headers=true

 

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

 

--running-error parameter

 

Syntax

enum:
stop
continue

 fallback

Default:

stop

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro  \

   --running-error=continue

 

3.115  --runpath

The --runpath parameter specifies the server instrumentation library (SIL) search path to use while searching for library 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.
If no path is specified or a SIL is not found, the directories /usr/lib/yumapro and /usr/lib64/yumapro (for 64-bit platforms) are checked.

 

--runpath parameter

 

Syntax

string: list of directory specifications

Default:

$YUMAPRO_RUNPATH environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangcli-pro

Example:

netconfd-pro \
 --runpath=”~/testsil:/yumapro/device”

 

3.116  --save-owners

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

 

--save-owners parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –save-owners=true

 

3.117  --session-sync-mutex

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

 

--session-sync-mutex parameter

 

Syntax

empty

Default:

not preset

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --session-sync-mutex

 

3.118  --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.  See also the ywx:no-sil-delete-children-first extension to override this parameter when it is set to ‘true’.

 

--sil-delete-children-first parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

 

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

 

--sil-invoke-for-defaults parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

 

--sil-missing-error parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –sil-missing-error=true

 

3.121  --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 "sil-priority" extension can be used to control the order of the edits and how they are processed.

 

In a case where you set "sil-priority" for multiple specific objects and want the order to be reversed during the DELETE operations there is a netconfd-pro configuration parameter "sil-prio-reverse-for-deletes".

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.

The "sil-prio-reverse-for-deletes" parameter has following facts that should be noted:

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 invoke just one callback for all the edits. Hence, the server has no any 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.

It is recommended to use EDIT1 callbacks to fully control the reverse priority behavior. Or as an alternative it is recommended to avoid the EDIT2 MERGE mode with mixed operations if you want to reverse the priority of the edits.

Also, the server will reverse the edits priorities in case the EDIT2 children edit is the edit to delete or remove the default node. And if there is no any other children edits with not equal to remove or delete, or merge edit operation in case of default node removal.

--sil-prio-reverse-for-deletes parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

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

 

--sil-root-check-first parameter

 

Syntax

boolean

default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

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

 

--sil-skip-load parameter

 

Syntax

empty

default:

none (not present)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro  --sil-skip-load

 

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

 

--sil-test-get-when parameter

 

Syntax

boolean

default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro  \

     --sil-test-get-when=true

 

 

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

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

 

--sil-validate-candidate parameter

 

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

 

--simple-json-names parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

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

 

--socket-address parameter

 

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

 

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

--socket-port parameter

 

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

 

3.129  --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 also required to run sil-sa-app on a different platform than the netconfd-pro process.

This mode is not secure. You should use some system mechanism to control access to the --server-address and --server-port, if this mode is used.

 

Note that this parameter specifies the socket type for internal <ncx-connect> protocol messages.  The server will use TCP connections for NETCONF sessions over SSH.

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

 

 

--socket-type parameter

 

Syntax

enumeration

default:

aflocal

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro  --socket-type=tcp

 

3.130  --startup

The --startup parameter specifies the file to use to load into the running configuration at boot-time.

The default is to check the data path for the file startup-cfg.xml.

 

--startup parameter

 

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

 

 

3.131  start choice

The --start parameter is a choice, specifying 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.

 

start choice

 

Syntax

choice:
  --no-startup
  --factory-startup

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

 

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

 

--startup-error parameter

 

Syntax

enum:
   stop
   continue

    fallback

Default:

stop

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro  \

   --startup-error=fallback

 

 

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

 

--startup-factory-file parameter

 

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

 

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

 

--startup-prune-ok parameter

 

Syntax

  boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

 

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

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

 

--startup-skip-validation parameter

 

Syntax

  boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

 

3.136  --subdirs

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

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

--subdirs parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro
yangdump-pro

Example:

netconfd-pro \
 --subdirs=false

 

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

 

--subsys-timeout parameter

 

Syntax

uint16

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

  netconfd-pro

Example:

netconfd-pro --subsys-timeout=0

 

3.138  --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 ietf-netcon-acm.yang configuration is preventing access to the <nacm> subtree itself.  The super-user 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.

To disable all super-user account privileges, set this parameter to a zero-length string.

 

--superuser parameter

 

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --superuser=admin

 

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

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

If 'yuma' is present, then the system notifications from the yuma-system will be generated.  This module can be found at netconf/modules/netconfcentral/iyuma-system.yang.

 

--system-notifications parameter

 

Syntax

bits

Default:

ietf

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

 

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

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

 

--system-sorted parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --system-sorted=true

 

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

 

--target parameter

 

Syntax

enumeration:
  running
  candidate

Default:

candidate

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --target=running

 

 

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

 

--tls-crl-missing-ok parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –tls-crl-missing-ok=true

 

 

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

 

 

 

--tls-crl-mode parameter

 

Syntax

enum

Default:

off

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –tls-crl-mode=ca

 

 

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

 

--trim-whitespace parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –trim-whitespace=true

 

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

 

--usexmlorder parameter

 

Syntax

empty

Default:

off

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --usexmlorder

 

3.146  --version

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

All YumaPro version strings use the same format:

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

or

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

An example version number that may be printed:

netconfd-pro 2.0-0

 

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

--version parameter

 

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro –version

 

 

3.147  --warn-error

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

If ‘true’ then warnings that are enabled will be elevated to errors for reporting purporses.

If the –warn-off parameter is entered for a specific error, that warning is considered disabled, and will not be elevated to an error.

 

--warn-error parameter

 

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro --warn-error=true

 

3.148  --warn-idlen

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

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

 

--warn-idlen parameter

 

Syntax

uint32: 0 to disable, or 8 .. 1023

Default:

64

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro --warn-idlen=50

 

3.149  --warn-linelen

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

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

Tab characters are counted as 8 spaces.

--warn-linelen parameter

 

Syntax

uint32: 0 to disable, or 40 .. 4095

Default:

72

Min Allowed:

0

Max Allowed:

1

Supported by:

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

Example:

netconfd-pro --warn-linelen=79

 

3.150  --warn-off

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

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

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

--warn-off parameter

 

Syntax

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

 

3.151  --warn-up

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

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

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

 

--warn-up parameter

 

Syntax

uint32: 1000 .. 1999

Default:

none

Min Allowed:

0

Max Allowed:

unlimied

Supported by:

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

Example:

netconfd-pro --warn-up=1022

 

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

 

--watcher-interval parameter

 

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –watcher-interval=60

 

3.153  --wildcard-keys

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

--wildcard-keys parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --wildcard-keys=true

 

 

3.154  --with-callhome

The --with-callhome parameter controls whether the IETF CallHome over SSH protocol is enabled or not.

 

--with-callhome parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-callhome=true

 

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

 

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.

 

--with-canonical parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-canonical=false

 

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

 

--with-config-id parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-config-id=false

 

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

 

--with-db-lock parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-db-lock=true

 

 

3.158  --with-gnmi

The --with-gnmi parameter controls whether the gNMI protocol is enabled or not.

 

--with-gnmi parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-gnmi=true

 

 

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

 

--with-maintenance-mode parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-maintenance-mode=false

 

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

 

--with-modtags parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-modtags=false

 

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

 

--with-netconf parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-netconf=false

 

3.162  --with-netconf-tls

The --with-netconf-tls parameter controls whether the server will enable the NETCONF over TLS protocol or not.  The incoming NETCONF over TLS connection will be dropped if the protocol is disabled.

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

 

--with-netconf-tls parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-netconf-tls=true

 

 

3.163  --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 conform all the NMDA specifications at this time:

 

--with-nnda parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-netconf=false

 

 

 

3.164  --with-notifications

The --with-notifications parameter controls whether the server will support the :notifications and :interleave capabilities or not.  To save memory and CPU processing, this parameter can be set to 'false' if notifications are not needed.

 

--with-notifications parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-notifications=false

 

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

 

--with-restconf parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-restconf=false

 

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

 

--with-rollback-on-error parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-rollback-on-error=false

 

 

3.167  --with-ocpattern

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

 

--with-ocpattern parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

yangcli-pro

yangdump-pro

Example:

netconfd-pro --with-ocpattern=true

 

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

 

--with-startup parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-startup=true

 

 

 

3.169  --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 the yumaworks-support-save 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 compile flag.

 

--with-support-save parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-support-save=false

 

 

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

 

--with-term-msg parameter

 

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

 

 

 

3.171  --with-url

The --with-url parameter controls whether the server will support the :url capability or not.  This capability requires file system storage.

--with-url parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-url=false

 

 

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

 

--with-url-ftp parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –with-url-ftp=true

 

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

 

--with-url-tftp parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro –with-url-tftp=true

 

3.174  --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' will reduce memory usage during <edit-config> operations.

--with-validate parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-validate=false

 

3.175  --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.  This is not compliant with the NETCONF protocol and tools may reject rpc-error data sent with an error-severity value of warning.

 

--with-warnings parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-warnings=true

 

 

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

 

--with-yang-api parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yang-api=false

 

 

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

 

--with-yang11-hello parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yang11-hello=true

 

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

 

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.

 

-- with-yang-patch-running parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yang-patch-running=true

 

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

 

--with-yp-coap parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yp-coap=true

 

 

 

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

 

THIS PROTOCOL IS NOT IMPLEMENTED YET.

The YP-CoAP over DTLS protocol is only available in images built from sources, using the WITH_COAP=1 make parameter.

--with-yp-coap-dtls parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yp-coap-dtls=true

 

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

 

--with-yp-shell parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yp-shell=false

 

3.182  --with-yuma-system

The --with-yuma-system parameter controls whether the yuma-system YANG module will be enabled.

This parameter is default TRUE in 17.10 and FALSE in 18.10. This module is considered deprecated and has been replaced by ietf-system and yumaworks-system.

 

--with-yuma-system parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yuma-system=true

 

 

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

 

--with-yuma-time-filter parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yuma-time-filter=false

 

 

 

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

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.

 

--with-yumaworks-config-change parameter

 

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yumaworks-config-change=true

 

 

 

 

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

 

--with-yumaworks-event-filter parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yumaworks-event-filter=false

 

 

 

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

 

--with-yumaworks-getbulk parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yumaworks-getbulk=false

 

 

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

 

--with-yumaworks-ids parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yumaworks-ids=false

 

 

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

 

--with-yumaworks-system parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yumaworks-system=false

 

 

3.189  --with-yumaworks-templates

The --with-yumaworks-templates parameter controls whether the yumaworks-templates YANG module will be enabled. This module provides configuration templates and the <with-template> parameter added to the <edit-config> operation.

 

--with-yumaworks-templates parameter

 

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

   --with-yumaworks-templates=false

 

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

--yangapi-server-url parameter

 

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

 

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

 

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&

 

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

 

--yp-coap-address parameter

 

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

 

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

 

THIS PARAMETER IS NOT YET IMPLEMENTED!

The YP-CoAP protocol is only available in images built from sources, using the WITH_COAP=1 make parameter.

 

--yp-coap-dtls-port parameter

 

Syntax

inet:port-number

Default:

5684

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro \

  --yp-coap-dtls-port=12904