netconfd-pro CLI Reference

--access-control

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

It is an enumeration with the following values:

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

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

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

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

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

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

    • Debug: normally set this parameter to off unless the testing requires NACM.

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

Syntax

enumeration:

enforcing permissive disabled off

Default:

enforcing

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --access-control=permissive

--allow-leaflist-delete-all

The --allow-leaflist-delete-all parameter controls whether the YumaPro extension “delete-all” operation should be allowed for leaf-list objects. This parameter affects the <edit-config> operation.

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.

If 'false' then the "delete-all" and "remove-all" operations are disabled for leaflists.

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

Syntax

boolean

Default:

false

Recommend:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--allow-list-delete-all

The --allow-list-delete-all parameter controls whether the YumaPro extension “delete-all” operation should be allowed for list objects. This parameter affects the <edit-config> operation.

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.

If 'false' then the "delete-all" and "remove-all" operations are disabled for lists.

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

Syntax

boolean

Default:

false

Recommend:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--allowed-user

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

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

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

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

  • Refer to the Session Admission Control section for more details.

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

Syntax

string (NcxName)

Default:

none

Min Allowed:

0

Max Allowed:

no limit

Supported by:

netconfd-pro

Example:

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

--annotation

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

Note

An annotation module is the same as a deviation module except it is not visible to clients. It should only be used when the client does not need the information.

The following example module shows how an annotation such as ncx:sil-delete-children-first could be added to the ietf-interfaces.yang module:

module devtest1-d {

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

  revision "2016-04-10";

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

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

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

leaf-list annotation {
    type yt:NcModuleSpec;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --annotation=devtest1-d

--audit-log

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

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

Syntax

filespec

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--audit-log-append

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

leaf audit-log-append {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--audit-log-candidate

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

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--audit-log-console-level

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

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

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

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

debug

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--audit-log-events

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

  • Debug: make sure this parameter includes the 'rpc-error' bit. This bit was introduced in the 23.10-6 release.

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

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

        Note that this added data could represent a security risk
        since it could expose sensitive configuration data contents.
        Use this option with caution!";
    }
    bit rpc-error {
      description
        "Add an audit record for an RPC operation that causes
         an 'rpc-error' element to be returned to the client.


         If the 'rpc-summary' bit is enabled, then an rpc-error
         report will be added to the RPC summary records that
         have a 'status' or 'error'.

         If the 'rpc-summary' bit is not enabled then an RPC summary
         with rpc-error report will be added for RPC operations
         that cause an error to be returned.";
    }
  }
  default "edit-running";
}

Syntax

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

Default:

edit-running

Recommend:

edit-running rpc-error

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

edit-candidate Audit Event

Save candidate datastore edit events in the audit log.

If the --audit-log-candidate parameter is set to true, or the <candidate> datastore is not present, then this bit will be ignored.

By default, the --audit-log-candidate parameter is set to “true” so this event type will be present in the audit log by default. To remove these events, set --audit-log-candidate=false and do not set this bit.

Example audit log entry:

edit-transaction 9616: on session 3 by [email protected]
  time: 2018-09-04T20:44:44Z
  message-id: 2
  trace-id: --
  datastore: candidate
  operation: create
  target: /t:int16.1
  comment: none

edit-running Audit Event

Save running datastore edit events in the audit log.

Example audit log entry:

edit-transaction 9617: on session 3 by [email protected]
  time: 2018-09-04T20:44:47Z
  message-id: 3
  trace-id: --
  datastore: running
  operation: create
  target: /t:int16.1
  comment: none

update-startup Audit Event

Save startup datastore update events in the audit log. If the <startup> datastore is not present then this bit will be ignored.

Example audit log entry:

update-startup on session 3 by [email protected]
  time: 2018-09-04T20:44:52Z
  message-id: 5
  sourcetype: datastore
  source: running

client-session Audit Event

Save client session start and end events in the audit log.

Example audit log entry (start-client-session)

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

Example audit log entry (end-client-session)

end-client-session:
  time: 2018-09-04T20:50:23Z
  protocol: NETCONF 1.1
  transport: netconf-ssh
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3
  term reason: closed
  killed-by: 3

control-session Audit Event

Save YControl session start and end events in the audit log.

Example audit log entry (start-control-session)

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

Example audit log entry (end-control-session)

end-control-session:
  time: 2018-09-04T21:02:39Z
  protocol: YControl
  transport: netconf-aflocal
  username: andy
  peeraddr: 127.0.0.1
  session ID: 3
  term reason: dropped
  killed-by: 0

acm-write-error Audit Event

Save access control write access denied events in the audit log.

Example audit log entry:

nacm-write-error:
  time: 2018-09-04T21:04:51Z
  username: andy
  operation: create leaf int32.1
  path:: /t:int32.1

acm-exec-error Audit Event

Save access control execute access denied events in the audit log.

Example audit log entry:

nacm-exec-error:
  time: 2018-09-04T21:08:54Z
  username: andy
  module name: yumaworks-system
  RPC name: load

rpc-summary Audit Event

Save RPC summary events in the audit log.

Example audit log entry:

RPC <get> on session 3 by* [email protected]
  start-time: 2019-12-12T01:35:47Z
  end-time: 2019-12-12T01:35:47Z
  message-id: 2
  reply-type: data
  status: 0:ok

edit-data Audit Event

Add plain display output of the data that is being edited in an edit transaction. This bit has no effect unless the edit-candidate or edit-running bit is also set.

Warning

This added data could represent a security risk since it could expose sensitive configuration data contents. Use this option with caution.

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

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

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

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

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

edit-transaction 189: on session 3 by [email protected]
  time: 2020-06-06T01:21:11Z
  message-id: 5
  trace-id: --
  datastore: running
  operation: replace
  target: /t:uint16.1
  comment: none
  new value:
    t:uint16.1 20
  old value:
    t:uint16.1 10

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

edit-transaction 191: on session 3 by [email protected]
  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

rpc-error Audit Event

Save RPC error events in the audit log.

  • Initial Release: 23.10-6

  • If 'rpc-summary' set, then this bit adds error detail to the RPC Summary, if the 'status' is non-zero (error).

  • If 'rpc-summary' not set, then generate an RPC summary and rpc-error only if the 'status' is non-zero (error).

Example audit log entry for a 'get-config' operation without any parameters:

RPC <get-config> on session 3 by [email protected]
  start-time: 2024-02-21T18:34:30Z
  end-time:   2024-02-21T18:34:30Z
  message-id: 4
  reply-type: error
  status:     296:missing mandatory choice

RPC Error 296:
rpc-error: (296) data-missing L:rpc S:error app-tag:missing-choice
  path: /get-config/input/source/config-source
  lang: en
  msg: missing mandatory choice
  error-info: missing-choice T:string = config-source
  error-info: error-number T:uint32 = 296

--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 effect unless the --audit-log parameter is also used.

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

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

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--audit-log-localtime

The --audit-log-localtime option specifies that the audit log stream output will include additional information, such as the date and time expressed in local terms.

leaf audit-log-localtime {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10T-9

Supported by:

netconfd-pro

Example:

netconfd-pro --audit-log-localtime=true

--autodelete-pdu-error

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

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

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

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--bundle

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

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

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

leaf-list bundle {
  type nt:NcxName;
}

Syntax

SIL bundle name

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

netconfd-pro --bundle=interfaces

--callhome-reconnect

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

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --callhome-reconnect=true

--callhome-retry-interval

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

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

Syntax

uint16 [1..max]

Default:

60 seconds

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--callhome-retry-max

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

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

Syntax

uint16

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--callhome-server

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

This string has the format:

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

Examples:

The server-id parameter is used for logging purposes.

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

leaf-list callhome-server {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

--callhome-sshd-command

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

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

Syntax

string

Default:

/usr/sbin/sshd

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--callhome-sshd-config

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

leaf callhome-sshd-config {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--callhome-subsys-command

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

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

Syntax

string

Default:

/usr/sbin/netconf-subsystem-pro

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--callhome-tls-server

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

This string has the format:

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

Examples:

netconfd-pro {
  [email protected]
  [email protected]:12040
}

The server-id parameter is used for logging purposes.

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

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

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

--cert-default-user

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

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

leaf cert-default-user {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--cert-usermap

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

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

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

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

Note

The full client fingerprint should be used for better security.

Example:

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

A printable fingerprint can be generated with the openssl command:

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

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

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

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

--confdir

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

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

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

The CLI parameters are set in the following order:

  1. netconfd-pro command line

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

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

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

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

Example extra config file testmods.conf:

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

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

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

Syntax

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

Default:

/etc/yumapro/netconfd-pro.d

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--convert-subtree-filter

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

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

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

  • output format is not XML

  • input format is not XML

  • subtree filter contains any attribute match expressions

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--create-empty-npcontainers

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

  • This only affects config=true non-presence container definitions with no config=true child nodes present in the configuration. If child nodes are present, then the parent container is not empty.

  • An empty NP container is only returned in a retrieval operation if defaults are requested (or configured) in the operation.

  • The --default-style CLI parameter affects the behavior of this parameter. It determines what is considered a default value. If this is set to 'report-all' then empty NP containers will always be returned.

  • Refer to the Empty NP Container section for more details.

Warning

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

  • This parameter MUST be set to 'true' for XPath technical support to be provided.

  • This parameter is deprecated and may be removed from future release trains.

  • Set --return-empty-npcontainers='false' instead of changing this setting to 'false'

An empty non-presence container has no meaning in NETCONF/YANG so it may be created by the server or not. It is an implementation choice. All clients must be capable of receiving empty NP containers in a response.

  • If this parameter is set to 'true', then the server will automatically create empty NP containers.

    • The empty NP container will treated as a default node and normally it is only returned from the retrieval operation if the 'with-defaults' parameter is set to 'report-all' or 'report-all-tagged'.

    • The following retrieval operations are affected by this parameter:

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

    • The configuration data node will not exist and will not be returned even if the 'with-defaults' parameter is used.

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

Empty NP Container Example

The following example show the difference in server behavior for this parameter.

Assume the configuration contains a simple NP container with a config=false child node named 'get2con':

container npcon1 {
  container get2con {
    config false;
    leaf A { type string; }
  }
}

If 'create-empty-npcontainers' set to 'true' then a retrieval operation will return the /npcon1 node.

This behavior can also be achieved if set to 'false', but the --create-empty-npcontainers-ro parameter is set to 'true'.

Example <get> request:

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="3"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
  <filter type="subtree">
   <npcon1 xmlns="urn:yumaworks:new9"/>
  </filter>
 </get>
</rpc>

Example <get> response:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="3"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2022-07-25T17:49:18Z" ncx:etag="1003"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <npcon1 xmlns="urn:yumaworks:new9">
   <get2con>
    <A>test value</A>
   </get2con></npcon1>
 </data>
</rpc-reply>

If 'create-empty-npcontainers' set to 'false' then a retrieval operation will not return the /npcon1 node:

Example <get> response (to the same request)

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="4"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2022-07-25T18:01:07Z" ncx:etag="1004"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data></data>
</rpc-reply>

Note

An empty NP container must be manually created if the create-empty-npcontainers parameter is 'false' and access to operational data child nodes is required.

After the NP container is manually created (e.g., with <edit-config>) then the operational data will be accessible. However the empty NP container will appear in the configuration.

Empty NP Container Example With <get-bulk>

The following example show the difference in server behavior for the --return-empty-npcontainers parameter.

Assume the configuration contains a simple list with some NP container child nodes:

container test2 {
  list T2 {
    key idx;
    leaf idx { type uint8; }
    container T3 {
      leaf string1 { type string; }
    }
    container T4 {
      leaf string2 { type string; }
    }
  }
}

If the server is configured with this parameter set to 'true' (default):

  • All the empty 'T3' and 'T4' containers are returned

andy@localhost> get-bulk list-target=/test2/T2 with-defaults=report-all count=5

RPC Data Reply 4 for session 3 [default]:

rpc-reply {
  bulk {
    data {
      T2  1 {
        idx 1
        T3 {
        }
        T4 {
        }
      }
      T2  2 {
        idx 2
        T3 {
        }
        T4 {
        }
      }
      T2  3 {
        idx 3
        T3 {
        }
        T4 {
        }
      }
    }
    last-keys {
      idx 3
    }
  }
}

If the server is configured with this parameter set to 'false' (recommended):

  • None of the empty 'T3' and 'T4' containers are returned

andy@localhost> get-bulk list-target=/test2/T2 with-defaults=report-all count=5

RPC Data Reply 3 for session 3 [default]:

rpc-reply {
  bulk {
    data {
      T2  1 {
        idx 1
      }
      T2  2 {
        idx 2
      }
      T2  3 {
        idx 3
      }
    }
    last-keys {
      idx 3
    }
  }
}

--create-empty-npcontainers-ro

The --create-empty-npcontainers-ro parameter specifies whether empty configuration NP containers with read-only children will be created by the server.

Warning

If the --create-empty-npcontainers parameter is set to 'true' then this parameter is not relevant and ignored.

Otherwise this parameter controls whether empty non-presence containers will be created if there are no default child nodes but there are read-only child nodes.

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

If this parameter is set to 'true', then the server will create empty NP containers in this case.

All behavior is the same as --create-empty-npcontainers except only the NP containers with config=false child nodes are affected.

Refer to the Empty NP Container section for more details.

leaf create-empty-npcontainers-ro {
  type boolean;
  default false;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10-4

Supported by:

netconfd-pro

Example:

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

--db-lock-retry-interval

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

--db-lock-retry-interval parameter

Syntax

number: 10 .. 60000 milliseconds

Default:

500 milliseconds

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--db-lock-timeout

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

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

Syntax

number: 0 .. 3600 seconds

Default:

30 seconds

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--default-style

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

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

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

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

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

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

Syntax

enumeration: report-all trim explicit

Default:

explicit

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --default-style=trim

--delete-empty-npcontainers

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

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

Note

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

The value 'false' is always used!!!

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--disable-imported-ok

The --disable-imported-ok parameter specifies whether the server should disable objects that are only imported, and not loaded via module or bundle parameter.

These modules are marked as conformance-type='import' the YANG Library.

  • Old behavior is 'false' which incorrectly adds all objects from the module into the schema tree and datastores

  • New behavior is to mark these objects as disabled in the obj_is_enabled() function.

Note

  • Default is to change server behavior!

  • MUST set to 'false' to preserve the old incorrect behavior.

leaf disable-imported-ok {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10T-9

Supported by:

netconfd-pro

Example:

netconfd-pro --disable-imported-ok=false

--disabled-protocols

The --disabled-protocols parameter allows sessions for client protocols to be disabled at boot-time. Sessions can then be enabled at run-time; e.g., using the <protocol-control> operation.

Note

  • This parameter only affects session admission control.

  • The protocol must be enabled and initialized properly for this parameter to have any effect.

Intended Usage

This parameter allows multiple client protocols to be available for use on the server, and allows the client protocols to be enabled or disabled at run-time without rebooting the server.

The yumaworks-server.yang module must be used to change this parameter at run-time. Changes to this parameter at run-time will take effect right away, as if the <protocol-control> operation was used instead.

If a DB-API subsystem is used then it is possible to disable protocols at boot-time without using this parameter.

If the protocol bit is set in this parameter, and the protocol has not been enabled at run-time, then incoming protocol sessions for that protocol will be dropped.

Use maintenance mode to temporarily disable client sessions instead of this parameter.

Protocols

leaf disabled-protocols {
  type bits { }
  default "";
}

Syntax

bits

Default:

""

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10T-9

Supported by:

netconfd-pro

Example:

netconfd-pro --disabled-protocols="cli restconf"

--errmsg

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

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

The string has the format:

<num>:<lang>:error string

where:

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

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

Example:

Replace error 117 (ERR_WB_WRITE_FAILED) 'db write failed'

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

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

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

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

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

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

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

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

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

--errmsg-lang

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

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

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

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

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --errmsg-lang=ru

--eventlog-size

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

Warning

  • This parameter can cause a lot of memory to be used by the server

  • Change the default of '1000' if needed:

    • Set to '0' to disable replay of any events

    • Set to a lower number to reduce memory usage for stored notifications

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

If the yumaworks-event-stream.yang module used by setting the --with-yumaworks-event-stream parameter to 'true', then the /event-streams/event-stream/eventlog-size leaf is used for the event stream instead of this CLI parameter.

The eventlog-size parameter is enforced per event-stream. It has no effect on YANG Push subscriptions.

When a new notification is added, and this limit is reached, the server will delete the oldest notification that has been delivered.

  • Prior to 22.10-10:

    • Setting a low value, such as 1 to 3 could cause queued notifications to be freed before they were delivered.

    • The SIL or SIL-SA code must not queue too many notifications at once or the oldest may be dropped.

    • Setting this parameter to zero did not cause this issue

  • Since 22.10-10:

    • Unsent notifications are not deleted even if the eventlog-size limit is reached.

    • The SIL or SIL-SA code can queue as many notifications as needed.

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

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

Syntax

uint32

Default:

1000

Recommend:

3

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --eventlog-size=20000

--event-stream

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

Note

The yumaworks-event-stream.yang module can be used instead of this parameter to configure event streams.

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

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

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

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

Syntax

NcxName (string)

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Introduced:

19.10

Supported by:

netconfd-pro

Example:

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

--event-stream-map

The --event-stream-map parameter specifies a module name to event-stream mapping for notification handling.

Note

The yumaworks-event-stream.yang module can be used instead of this parameter to configure event streams.

A mapping is a structured string using the form

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

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

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

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

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

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Introduced:

19.10

Supported by:

netconfd-pro

Example:

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

--factory-startup

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

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

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

Debug: This parameter is often useful to make sure a test server does not start with any left over configuration from a previous test.

leaf factory-startup {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --factory-startup

--ha-enabled

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

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --ha-enabled=true

--ha-initial-active

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

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

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

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

Syntax

string (NcxName)

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--ha-server

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

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

This string has the format:

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

Examples:

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

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

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

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

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

leaf-list ha-server {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

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

--ha-server-key

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

leaf ha-server-key {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--ha-sil-standby

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--hello-timeout

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

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

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

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

Note

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

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

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

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

Syntax

uint32; 0 == disabled;

range 10 .. 3600 seconds (1 hour max)

Default:

600 (10 minutes)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --hello-timeout=300

--hide-module

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

  • YANG 1.0 <hello> message

  • /netconf-state/schemas/schema list

  • /modules-state/module list

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

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

Warning

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

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

Syntax

string: module name

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Supported by:

netconfd-pro

Example:

netconfd-pro --hide-module=mysecretmod

--highres-event-time

The --highres-event-time parameter controls how the date-and-time string used in the notification 'eventTime' leaf will be output.

  • If set to 'true' then the 'eventTime' leaf value in all <notification> messages will contain a microseconds field.

  • If 'false' then this field will not contain a microseconds field.

  • This field is always 6 digits long and represents a fraction of one second as the number of microseconds.

Note

The default behavior is different than the low resolution format used in previous releases. The date-and-time data type includes this optional field so a client should accept the value.

leaf highres-event-time {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10-1

Supported by:

netconfd-pro

Example:

netconfd-pro --highres-event-time=true

Example:

The 'eventTime' leaf in the following notification for a 'netconf-config-change' includes the microseconds field:

 <?xml version="1.0" encoding="UTF-8"?>
  <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2022-09-18T15:57:21.402308Z</eventTime>
   <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
    <changed-by>
     <username>andy</username>
     <session-id>3</session-id>
     <source-host>127.0.0.1</source-host>
    </changed-by>
    <datastore>running</datastore>
    <edit>
     <target
      xmlns:nacm="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">/nacm:nacm/nacm:groups/nacm:group[nacm:name="test-group"]</target>
     <operation>create</operation>
    </edit>
   </netconf-config-change>
  </notification>

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

  • Debug: It is often useful to set this parameter to '0' so breakpoint debugging and other pauses to not cause client sessions to be dropped.

Warning

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

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

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

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

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

Syntax

uint32

Default:

3600 (1 hour)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --idle-timeout=30000

--import-version-bestmatch

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

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

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--library-mode

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

Note

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

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

Warning

Normal server operation is not possible in this mode. Only a small number of operations are permitted.

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --library-mode=true

--loadpath

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

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

leaf loadpath {
  type yt:NcPathList;
}

Syntax

string: list of directory specifications

Default:

$YUMAPRO_LOADPATH environment variable

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--log-event-drops

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--log-pthread-level

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

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

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

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info (debug for DEBUG builds)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--log-vendor

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

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

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

leaf log-vendor {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro yangcli-pro

Example:

netconfd-pro --log-vendor

--log-vendor-level

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

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

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

Syntax

enumeration: off error warn info debug debug2 debug3 debug4

Default:

info

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--max-burst

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

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

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

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-burst=100

--max-cli-sessions

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

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

This parameter does not apply to YControl sessions.

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

Syntax

uint16 (0 .. 1024)

Default:

0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--max-getbulk

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

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

  • If the value is set to 0, the internal limit of 512 will be used.

Note

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

leaf max-getbulk {
  type uint32 {
    range "0 .. 512";
  }
  default 10;
}

Syntax

uint32 (0 .. 512)

Default:

10

Min Allowed:

0

Max Allowed:

512

Supported by:

netconfd-pro

Example:

netconfd-pro --max-getbulk=128

--max-lock-hold-time

The --max-lock-hold-time parameter specifies the maximum number of seconds to allow a session to hold a global NETCONF datastore lock.

  • If zero, then no maximum lock hold time will be used. This is the behavior specified by RFC 6241.

  • If non-zero, then the standard will not be followed. Instead, a global lock will be released if held by a session too long.

    • This timeout only applies to the 'lock' operation.

    • Partial locks are not affected at all by this parameter.

    • Does not affect any edit transaction that may be in progress.

Note

If a lock is released, then the locking session will not be warned or notified in anyway.

If a session has an active notification subscription, or if the client sends at least one request periodically, then the --idle-timeout parameter will not be enforced. It is possible for a NETCONF session to hold a global datastore lock indefinitely.

This parameter allows the datastore lock time to be configured so it does not depend on the --idle-timeout parameter setting.

Warning

Using this parameter with a value greater than zero will violate RFC 6241 procedures for the 'lock' operation.

  • A minimum lock hold time of 5 seconds is allowed.

  • If a timeout occurs the datastore lock will be dropped, but the session will not be dropped.

  • If an edit is in progress, it will not be affected. Only the NETCONF lock will be released.

  • The server will output an 'info' log message if a datastore lock is released by the server due to the lock hold time exceeding this value. Example:

    Max Lock Hold Time timeout for datastore running
    Locked by session 3 at 2023-03-21T23:35:55Z
    
leaf max-lock-hold-time {
  type uint16 {
    range "0 | 5 .. max";
  }
  units seconds;
  default 0;
}

Syntax

uint16

Default:

0

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10-7

Supported by:

netconfd-pro

Example:

netconfd-pro --max-lock-hold-time=120

--max-per-user-sessions

The --max-per-user-sessions parameter specifies the maximum number of concurrent CLI sessions to allow at any time by a specific single user.

  • This parameter will override the --max-user-sessions parameter for the specified username, if both are present.

  • The --max-sessions parameter has precedence, so setting this parameter higher than 'max-sessions' will have no effect.

  • This parameter does not apply to YControl sessions.

  • The value is a formatted string and it must not contain any whitespace.

  • The username field must be followed by a single colon ':' character, which must be followed by the number field.

    username:number
    
  • username Field:

    • The username field must be between 1 and 1024 characters, and must not contain a colon ':' character.

    • This value will be compared to the username assigned to a client session when it is started. The client session will be dropped if the session limit is exceeded.

  • number Field:

    • The number field must be between 0 and 1024.

    • This must be in decimal with no leading zeroes, and must contain between 1 and 4 characters.

    • The value 0 indicates that no artificial session limit should be used for the specified user.

Example:

  • limit total concurrent client sessions to 10

  • limit total number of concurrent sessions by a single user to 2

  • except user 'admin1', and a limit of 5 for user 'admin2':

max-sessions 10
max-user-sessions 2
max-per-user-sessions admin1:0
max-per-user-sessions admin2:5

Errors:

  • Invalid entries will cause the server to terminate with an error.

  • A duplicate username will be ignored and a warning will be printed to the log.

leaf-list max-per-user-sessions {
  type string {
    length "3 .. 1029";
  }
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

unbounded

Introduced:

23.10-5

Supported by:

netconfd-pro

Example:

netconfd-pro --max-per-user-sessions=admin1:5

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

This parameter does not apply to YControl sessions.

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

Syntax

uint16 (0 .. 1024)

Default:

8

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-sessions=10

--max-strlen

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

  • This affects YANG and JSON input processing.

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

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

  • The minimum size is 64 KBytes.

  • The maximum is 2 billion bytes.

  • The default is 256 KBytes.

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

Syntax

int32 (65536 .. INT_MAX)

Default:

262144

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-strlen=1000000

--max-user-sessions

The --max-user-sessions parameter specifies the maximum number of concurrent CLI sessions to allow at any time by a single user.

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.

This parameter does not apply to YControl sessions.

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

Syntax

uint16 (0 .. 1024)

Default:

0

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10-1

Supported by:

netconfd-pro

Example:

netconfd-pro --max-user-sessions=3

--module-tagmap

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

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

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

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

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

Examples:

leaf-list module-tagmap {
  type string;
}

Syntax

structured string

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

--netconf-capability

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

To add vendor capabilities:

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

Syntax

inet:uri

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

--netconf-tls-address

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

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

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

Syntax

inet:ip-address

Default:

0.0.0.0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--netconf-tls-certificate

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

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

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

Syntax

string

Default:

$HOME/.ssl/netconfd-pro.crt

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--netconf-tls-key

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

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

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

Syntax

string

Default:

$HOME/.ssl/netconfd-pro.key

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--netconf-tls-port

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

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

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

Syntax

inet:port-number

Default:

6513

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--netconf-tls-trust-store

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

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

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

Syntax

string

Default:

$HOME/.ssl/trust-store.pem

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--no-audit-log

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

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

leaf no-audit-log {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--no-log

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

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

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

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

leaf no-log {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Introduced:

19.10

Supported by:

netconfd-pro

Example:

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

--no-nvstore

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

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

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

  • Any external NV-storage callbacks will be ignored.

The following operations are not affected by this parameter:

  • <backup> operation

  • <restore> operation

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

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

The default is not present.

leaf no-nvstore {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-nvstore

--no-startup

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

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

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

leaf no-startup {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-startup

--no-watcher

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

If present, do not launch the ypwatcher program.

If this parameter is present, then the --watcher-interval parameter cannot be present.

Note

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

leaf no-watcher {
  type empty;
}

Syntax

empty

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --no-watcher

--push-max-operational

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

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

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

Syntax

uint32 (subscriptions)

Default:

4

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

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

--push-max-periodic

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

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

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

Syntax

uint32 (subscriptions)

Default:

16

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

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

--push-min-dampening

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

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

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

Syntax

uint32 (centiseconds)

Default:

100

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

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

--push-min-period

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

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

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

Syntax

uint32 (centiseconds)

Default:

100

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

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

--push-simop-enabled

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

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

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

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

--push-simop-patch-update

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

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

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

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

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

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

--push-simop-period

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

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

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

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

--remove-schema-aug-leafs

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

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

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

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

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

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

Note

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

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

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Introduced:

21.10

Supported by:

netconfd-pro

Example:

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

--restconf-capability

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

To add vendor capabilities:

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

Syntax

inet:uri

Default:

none

Min Allowed:

0

Max Allowed:

unlimited

Supported by:

netconfd-pro

Example:

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

--restconf-default-encoding

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

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

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

Syntax

enum (xml, json)

Default:

json

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--restconf-server-url

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

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

Syntax

inet:uri

Default:

http://localhost

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--restconf-strict-headers

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

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

Normative Accept header:

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

Normative Content-Type headers:

application/yang-data+xml

application/yang-patch+json

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

Acceptable non-normative Accept header:

application/xml,application/json;q=0.9

Acceptable non-normative Content-Type headers:

application/xml

application/json

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--return-empty-npcontainers

The --return-empty-npcontainers parameter controls whether the server will return Empty NP Container nodes in retrieval operations.

If set to 'true' then empty configuration NP containers that do not have any read-only child nodes are returned in retrieval operations.

A container is not an Empty NP Container if:

  • any child nodes besides empty NP containers

  • any default child nodes

  • any read-only child nodes

Normally these empty NP containers are returned only if the 'with-defaults' retrieval parameter or --default-style CLI parameter is 'report-all'.

If this parameter is 'false' then empty NP containers will not be returned in retrieval operations at all.

Note

The default setting is 'true' for backward compatibility but the recommended setting is 'false'.

There are four operations affected by this parameter:

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10-6

Supported by:

netconfd-pro

Example:

netconfd-pro --return-empty-npcontainers=false

--return-error-with-data

The --return-error-with-data parameter controls whether "<rpc-error>" nodes will be returned in RPC output for retrieval operations

If true, and if a GET2 callback returns an error, an "<rpc-error>" will be returned after all data has been returned.

Note

Make sure the client is capable of handing this extension to the <rpc-reply> element encoding.

If 'false', then no RPC errors will be returned in addition to data, for these operations.

leaf return-error-with-data {
  type boolean;
  default false;
}

Example: GET2 Callback Returns an Error

In this example, the following YANG module is used:

container test6 {
  config false;
  container test6A {
    leaf g1 { type string; }
    leaf g2 { type string; }
  }
}

The nested container '/test6/test6A' returns an 'operation-failed' error instead of the child leafs 'g1' and 'g2':

  • Client Requests container '/test6'

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="5"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
  <filter type="subtree">
   <test6 xmlns="http://netconfcentral.org/ns/test6"/>
  </filter>
 </get>
</rpc>

The GET2 callback for container 'test6A' returns an error but instead of ignoring the error, it is reported after the data is returned.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="5"
 xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 ncx:last-modified="2024-04-10T18:35:51Z" ncx:etag="547"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <test6 xmlns="http://netconfcentral.org/ns/test6">
   <test6A>
   </test6A>
  </test6>
 </data>
 <rpc-error>
  <error-type>application</error-type>
  <error-tag>operation-failed</error-tag>
  <error-severity>error</error-severity>
  <error-app-tag>general-error</error-app-tag>
  <error-path>/test6/test6A</error-path>
  <error-message xml:lang="en">operation failed</error-message>
  <error-info>
    <error-number
     xmlns="http://netconfcentral.org/ns/yuma-ncx">274</error-number>
  </error-info>
 </rpc-error>
</rpc-reply>

The yangcli-pro program will report this response as an RPC Error Reply but the complete message is handled correctly.

andy@localhost> sget /test6

Filling container /test6:
RPC Error Reply 4 for session 3 [default]:

rpc-reply {
  data {
    test6 {
      test6A {
      }
    }
  }
  rpc-error {
    error-type application
    error-tag operation-failed
    error-severity error
    error-app-tag general-error
    error-path /test6/test6A
    error-message 'operation failed'
    error-info {
      error-number 274
    }
  }
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10T-7

Supported by:

netconfd-pro

Example:

netconfd-pro --return-error-with-data=true

--return-status

The --return-status parameter controls whether the server will return the status code or return zero, when it exits.

If 'true' then the server will return the 'status_t' enumeration number for the error that occurred, or zero if no error occurred. Note that these error codes do not follow Linux conventions. Values above 255 (but less than 2000) can be returned.

If 'false' then the server will always return zero. This is the existing server behavior and therefore the default behavior.

leaf return-status {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

netconfd-pro --return-status=true

--running-error

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

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

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

Note

There are YANG modules that have top-level mandatory nodes. Set this parameter to continue to allow such modules to load anyway.

There are 3 values supported:

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

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

    Note

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

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

    Note

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

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

Syntax

enum:
stop
continue
fallback

Default:

stop

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --running-error=continue

--save-owners

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10T-0

Supported by:

netconfd-pro

Example:

netconfd-pro --save-owners=true

--server-root

The --server-root parameter specifies the Server Root Identifier string to use for this server.

  • Used to run the server in Multi-Instance Mode. This feature is only available in source code and Advanced feature set binary packages.

  • Every server running on the same host must have a unique server-root value.

  • If this leaf is not present, then the server will run in Single-Instance Mode.

  • This value must match a Server Root ID in a mapping in the Server Root Map File file usually located in the /etc/yumapro directory.

  • If this parameter is provided on the command line then the --fileloc-fhs parameter must also be provided on the command-line (if it is set to 'true').

leaf server-root {
  type nt:NcxName;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --server-root=sr1

--session-sync-mutex

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

Note

This parameter is deprecated. Do not use.

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

Syntax

empty

Default:

not preset

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --session-sync-mutex

--sil-cc-callback-all

The --sil-cc-callback-all parameter specifies how the server should handle the Commit Completeness callbacks. Refer to the Using Commit Completeness Callbacks section for details.

Note

  • The new Edit Phase Complete callback provides all of the functionality of this CLI parameter.

  • This parameter and the Commit Completeness callbacks are not deprecated, but usage of the new callback is suggested

  • If 'false', the server will invoke Commit Completeness callbacks only for the <commit> operation.

  • If 'true', the server will invoke Commit Completeness callbacks for all edit transactions, not just for the <commit> operation.

If 'true' the following operations will cause Commit Completeness callbacks to be invoked:

If 'true' and the target datastore for the edit transaction is the 'candidate' datastore or the 'running' datastore:

  • The Validate Complete Callback is invoked for the <candidate> datastore only if the --sil-validate-candidate parameter is set to 'true'.

  • Any error stops the validation so each step is only reached if all the previous steps passed.

  • The validation steps are done in the following order.

    • Field validation (simple types pass typedef constraints)

    • Datastore Constraint Check (Root Check)

    • SIL or SIL validation callbacks

    • Validate Complete callbacks

If 'true' and the target datastore for the edit transaction is the 'running' datastore:

  • The Validate Complete Callback is invoked for the <running> datastore as described in the previous section.

  • The Apply Complete callbacks are invoked if the Validate Phase completed without error and all SIL or SIL-SA callbacks have also completed for the Apply Phase without error.

  • The Commit Complete callbacks are invoked if the Apply Phase completed without error and all SIL or SIL-SA callbacks have also completed for the Commit Phase without error.

  • The Rollback Complete callbacks are invoked if any error is raised during (or after) the Apply Phase. All Rollback Phase SIL or SIL-SA callbacks have completed before the Rollback Complete callbacks are invoked.

leaf sil-cc-callback-all {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Recommend:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10-8

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-cc-callback-all=true

--sil-delete-children-first

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--sil-invoke-false-when-deletes

The --sil-invoke-false-when-deletes parameter specifies how the server should handle SIL callbacks for false-when auto-deletion.

If 'true' then a SIL or SIL-SA callback will be invoked for false-when auto-deletion data nodes during the edit transaction.

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

leaf sil-invoke-false-when-deletes {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10-12

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-invoke-false-when-deletes=true

--sil-invoke-for-defaults

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

If 'true' then a SIL or SIL-SA callback will be invoked for default data nodes during the edit transactions.

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

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--sil-missing-error

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--sil-prio-reverse-for-deletes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--sil-root-check-first

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

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

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

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

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

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

Syntax

boolean

default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--sil-skip-load

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

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

leaf sil-skip-load {
  type empty;
}

Syntax

empty

default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --sil-skip-load

--sil-test-get-when

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

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

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

Syntax

boolean

default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--sil-validate-candidate

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

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

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

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

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

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--simple-json-names

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--sm-config

The --sm-config parameter specifies the XML or JSON file to read which contains the configuration data needed to create desired mount-points.

This config file controls what is in the YANG Library for each mount-point label.

If this parameter is set then the file must be found and be valid or the server will exit with an error.

Example JSON configurations:

{
  "yumaworks-schema-mount:schema-mount" : {
    "sm-config" : [
      {
        "mp-module" : "sm-test",
        "mp-label" : "sm-label-root1",
        "mp-config" : true,
        "mp-cli" : {
          "module" : [ "test",
                       "get2-test"
                     ]
        }
      }
    ]
  }
}

If --with-schema-mount is set to 'false' then this parameter is ignored.

leaf sm-config {
  type string;
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10T

Supported by:

netconfd-pro

Example:

netconfd-pro --sm-config=/etc/yumapro/sm-config.xml

--sm-config-encoding

The --sm-config-encoding parameter specifies the Schema Mount Config file encoding. Based on this encoding the server will parse the config file accordingly.

If --with-schema-mount is set to 'false' then this parameter is ignored.

The supported values are xml and json.

leaf sm-config-encoding {
  type enumeration {
    enum json {
      description "Identify JSON encoding.";
    }
    enum xml {
      description "Identify XML encoding.";
    }
  }
  default json;
}

Syntax

enum (xml | json)

Default:

json

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10T

Supported by:

netconfd-pro

Example:

netconfd-pro --sm-config-encoding=json

--socket-address

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

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

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

Syntax

inet:ipv4-address

default:

0.0.0.0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--socket-port

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

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

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

Syntax

inet:port-number

default:

2023

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--socket-type

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

This mode is required for:

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

  • YP-HA standby servers

    Warning

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

Two enumeration values are supported:

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

Manual configuration for distributed system

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

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

Example using IP address 192.168.0.10 and port 2023:

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

Syntax

enumeration

default:

aflocal

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --socket-type=tcp

--startup

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

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

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

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

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

Note

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

leaf startup {
  type string;
}

Syntax

filespec

Default:

first startup-cfg.xml in the data path

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup=$TESTDIR/testrun

start choice

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

There are 3 values supported:

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

  leaf factory-startup {
    type empty;
  }

  leaf startup {
    type string;
  }
}

Syntax

choice:

Default:

first startup-cfg.xml in the data path

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup=$TESTDIR/testrun

--startup-error

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

  • Affects processing of the startup configuration file.

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

Note

There are YANG modules that have top-level mandatory nodes. Set this parameter to continue to allow such modules to load anyway.

There are 3 values supported:

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

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

    Note

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

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

    Note

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

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

Syntax

enum:
stop
continue

fallback

Default:

stop

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --startup-error=fallback

--startup-factory-file

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

  1. first-time boot and no configuration file found

  2. --factory-startup CLI option used

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

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

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

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

Syntax

filespec

Default:

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

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--startup-prune-ok

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

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--startup-skip-validation

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

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

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

  • must

  • when (see note)

  • leafref path

  • unique

  • min-elements

  • max-elements

  • mandatory

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

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

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

Warning

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

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

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

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

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

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

19.10

Supported by:

netconfd-pro

Example:

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

--subsys-timeout

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

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

  • The default is 30 seconds.

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

Syntax

uint16

Default:

30

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --subsys-timeout=0

--superuser

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

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

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

Note

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

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

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --superuser=admin

--system-notifications

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

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

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

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

Note

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

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

Syntax

bits

Default:

ietf

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--system-sort-type

The --system-sort-type parameter specifies the sort type for system-ordered configuration lists and leaf-lists.

  • The --system-sorted parameter must be set to 'true' or this object will have no effect.

  • The ywx:sort-type YANG extension can be used to control the sort behavior for a single list or leaf-list.

  • There are 3 sort type values supported:

    • off: No sorting will be done

    • ascending: Entries will be sorted in ascending order

    • descending: Entries will be sorted in descending order

leaf system-sort-type {
  type enumeration {
    enum off;
    enum ascending;
    enum descending;
  }
  default off;
}

Syntax

enumeration off ascending descending

Default:

off

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10-6

Supported by:

netconfd-pro

Example:

netconfd-pro --system-sort-type=ascending

--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 simply enables sytem-ordered sorting.

  • The --system-sort-type parameter controls the default sort behavior, if this parameter is set to 'true'.

  • The ywx:sort-type YANG extension can be used to control the sort behavior for a single list or leaf-list.

leaf system-sorted {
  type boolean;
  default false;
  status current;   // changed in 23.10-6
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --system-sorted=true

--target

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

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

  • running: Edits will be written directly to the <running> configuration. The :startup capability will also be used in this mode. This means that a <copy-config> operation (from <running> to <startup>) must be used to save any edits to non-volatile storage, for use on the next reboot.

  • candidate: Edits will be written to the <candidate> configuration. The <commit> operation must be used to save any edits in <candidate> configuration into the <running> configuration. The non-volatile storage is updated automatically in this mode, and the <startup> configuration will not be present.

leaf target {
  type enumeration {
    enum running {
    }
    enum candidate {
    }
  }
  default candidate;
}

Syntax

enumeration: running candidate

Default:

candidate

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --target=running

--tls-cipherlist

The --tls-cipherlist parameter

The cipherlist parameter to use to configure the server using the SSL_CTX_set_cipher_list function in openssl. This parameter is passed directly and not checked.

Warning

For Advanced OpenSSL Users Only!

Refer to the OpenSSL documentation for all details and support. OpenSSL problems due to use of this parameter are not supported.

leaf tls-cipherlist {
  type string {
    length "1 .. 256";
  }
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Introduced:

21.10

Supported by:

netconfd-pro

Example:

netconfd-pro --tls-cipherlist=ECDHE

--tls-crl-missing-ok

The --tls-crl-missing-ok parameter controls how a missing CRL Distribution Points section in a TLS certificate is handled.

  • If true then a missing CRL Distribution Points section within a client or CA certificate will be ignored. Not relevant unless --tls-crl-mode is set to 'client' or 'ca'.

  • If false, and CRL verification is enabled for the certificate, the TLS session will not be accepted.

Certificate revocation checking is still done, even if this parameter is set to ‘true’. If the --netconf-tls-trust-store parameter is set, then any hash.rN will be loaded into the openssl library and used to reject sessions using a revoked certificate. (E.g. /etc/ssl/certs/5443e9e3.r0)

leaf tls-crl-missing-ok {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--tls-crl-mode

The --tls-crl-mode parameter controls how Certificate Revocation Lists are checked for NETCONF over TLS sessions.

This has no effect unless --with-netconf-tls=true is set.

  • off: Do not use CRL verification when verifying any certificates.

  • client: Use CRL verification when verifying client certificates.

  • ca: Use CRL verification when verifying client and CA certificates.

leaf tls-crl-mode {
  type enumeration {
    enum off {
    }
    enum client {
    }
    enum ca {
    }
  }
  default off;
}

Syntax

enum

Default:

off

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --tls-crl-mode=ca

--tls-debug

The --tls-debug parameter enables extra NETCONF over TLS session debugging messages. It is used with the --log-level parameter to increase the amount of debugging info printed.

leaf tls-debug {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

21.10

Supported by:

netconfd-pro

Example:

netconfd-pro --tls-debug=true

--tls-deprecated-ok

The --tls-deprecated-ok parameter allows deprecated versions of TLS to be used in NETCONF over TLS sessions.

  • If 'true' then any TLS version used will be accepted.

  • If 'false' then only TLS versions 1.2 and 1.3 will be accepted.

  • This parameter SHOULD NOT be set to true since the deprecated TLS versions are not considered to be secure.

Note

The default value is false, which is not backward-compatible with server versions prior to YumaPro version 22.10-3.

leaf tls-deprecated-ok {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10-3

Supported by:

netconfd-pro

Example:

netconfd-pro --tls-deprecated-ok=true

--trim-whitespace

The --trim-whitespace parameter specifies if whitespace should be trimmed.

If true, then trim leading and trailing whitespace from XML string nodes. If false, adhere to the standard and do not trim any leading or trailing whitespace.

The server previously would trim whitespace but no longer does this by default.

This leaf must be set to trim this whitespace now.

This should only be needed if the NETCONF client does not send XML leaf nodes correctly.

Warning

Using this parameter will cause the NETCONF server to be non-compliant to RFC 6241.

leaf trim-whitespace {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --trim-whitespace=true

--usexmlorder

The --usexmlorder parameter specifies that the netconfd-pro server should enforce XML ordering when applicable (such as YANG list key leafs entered first). The default is not to check for adherence to strict XML order, as defined by YANG. The netconfd-pro server does not depend on XML order for normal operations.

leaf usexmlorder {
  type empty;
}

Syntax

empty

Default:

off

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --usexmlorder

--user-parm

The --user-parm parameter specifies a user-defined parameter. This is an optional user parameter that can be accessed by the server instrumentation code within netconfd-pro.

Note

This parameter has no defined purpose or structure. It is simply stored by the server for retrieval by instrumentation code.

This parameter can be accessed with the 'agt_get_user_parm' API function from agt.h.

const xmlChar *agt_get_user_parm(void)

Get the user-parm string (if any)

Returns:

pointer to user-parm value string or NULL if none

The opaque string is only limited in length, not content.

type string {
  length "1 .. 8192";
}

Syntax

string

Default:

none

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10-1

Supported by:

netconfd-pro

Example:

netconfd-pro --user-parm="test41=tunnel1"

--wait-datastore-ready

The --wait-datastore-ready parameter determines if client sessions will be available even if the running datastore is not ready to use yet.

For example, if SIL-SA bundles are used then the server must wait until all of them have been loaded (by subsystems) before the startup configuration can be loaded into the running datastore. The running datastore is not ready to use in this state.

If 'true' then client sessions will be locked until the datastores are ready. Protocol operations that do not access the datastores can be used in this state.

If 'false' then client session connections will be rejected until the datastores are ready.

Note

The default is 'false' only to be backwards-compatible. The 'true' setting should be used in most cases.

leaf wait-datastore-ready {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

netconfd-pro --wait-datastore-ready=true

--watcher-interval

The --watcher-interval parameter specifies the sleep interval between ypwatcher program attempts to check availability of the server. Provided value is in seconds.

The server does not accept the value of 0 for this parameter. The minimal acceptable value is 1 second.

leaf watcher-interval {
  type uint32 {
     range "1 .. max";
  }
  default 10;
}

Syntax

uint32

Default:

10

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --watcher-interval=60

--with-callhome

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

This feature is only available if the server image is built with the WITH_CALLHOME=1 or EVERYTHING=1 make flags.

If set to 'true', then the IETF Callhome for SSH feature will be enabled.

If set to 'false', then this feature will be disabled and the following CLI parameters will be ignored:

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-callhome=true

--with-canonical

The --with-canonical parameter controls automatic conversion to canonical format for certain YANG data types.

If set to 'true', then the server will automatically convert XML and JSON input parameters to the canonical format for the YANG data type, if possible.

The following built-in YANG data types are affected:

  • ipv6-address

  • ipv6-address-no-zone

  • domain-name

  • phys-address

  • mac-address

  • hex-string

  • uuid

Any canonical callbacks for user-defined data types are also affected by this parameter.

Internal values can be manually converted to canonical format using the val_set_canonical API.

leaf with-canonical {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-canonical=false

--with-config-id

The --with-config-id parameter controls whether the server will enable or disable the :config-id capability URI in NETCONF <hello> messages.

  • If set to 'true', then the YumaWorks :config-id capability will be enabled. This is used to help cache device configurations. It is an enterprise capability URI, not a standard YANG module URI.

  • If set to 'false', then the YumaWorks :config-id capability will be disabled.

leaf with-config-id {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-config-id=false

--with-db-lock

The --with-db-lock parameter specifies if the DB-Config-Lock mode will be used. If set to 'true', then the server will use the DB-API DB-Config-Lock service for all configuration edit transactions to the <running> datastore. All client edits will be require this lock be granted or it will fail.

The server will use the db-lock-retry-interval and db-lock-timeout CLI parameters to control how lock retries will be done.

If set to 'false', the DB-Config-Lock will not be used by the server.

leaf with-db-lock {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--with-error-number

The --with-error-number parameter specifies how the <error-number> leaf will be handled.

  • If set to 'true', then the <error-info> element will include the proprietary <error-number> element.

  • If set to 'false', then the <error-info> element will not include the proprietary <error-number> element.

  • This leaf corresponds to the error status enumerations defined in 'status_enum.h'.

  • The default is 'true'. Added in 22.10-8.

leaf with-error-number {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10-8

Supported by:

netconfd-pro

Example:

netconfd-pro --with-error-number=false

NETCONF Error Examples

Here is an example of an error response if this parameter is set to the default (true).

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="4" xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <rpc-error>
  <error-type>protocol</error-type>
  <error-tag>lock-denied</error-tag>
  <error-severity>error</error-severity>
  <error-app-tag>no-access</error-app-tag>
  <error-message xml:lang="en">lock denied</error-message>
  <error-info>
   <session-id>3</session-id>
   <error-number>268</error-number>
  </error-info>
 </rpc-error>
</rpc-reply>

Here is an example of the same error response if this parameter is set to 'false'.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="4" xmlns:ncx="http://netconfcentral.org/ns/yuma-ncx"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <rpc-error>
  <error-type>protocol</error-type>
  <error-tag>lock-denied</error-tag>
  <error-severity>error</error-severity>
  <error-app-tag>no-access</error-app-tag>
  <error-message xml:lang="en">lock denied</error-message>
  <error-info>
   <session-id>3</session-id>
  </error-info>
 </rpc-error>
</rpc-reply>

--with-gnmi

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

If set to 'true', then the gNMI protocol will be enabled. Otherwise, the gNMI protocol will not be enabled.

Any incoming connection will be dropped if the protocol is disabled.

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-gnmi=true

--with-grpc

The --with-grpc parameter controls whether the gRPC protocol is enabled or not.

If set to 'true', then the gRPC protocol will be enabled. Otherwise, the gRPC protocol will not be enabled.

Any incoming connection will be dropped if the protocol is disabled.

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

21.10

Supported by:

netconfd-pro

Example:

netconfd-pro --with-grpc=true

--with-maintenance-mode

The --with-maintenance-mode parameter enables or disables the maintenance mode feature. It does not cause maintenance mode to be active or inactive. If set to 'true', then allow the maintenance mode to be used. Otherwise, ignore all requests to place the server in maintenance mode.

Client protocols cannot activate maintenance mode. This parameter can prevent internal server instrumentation from working properly. Use with caution.

leaf with-maintenance-mode {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-maintenance-mode=false

--with-modtags

The --with-modtags parameter controls the module-tag filtering feature.

If set to 'true', then the module tags feature will be enabled. Otherwise, this feature will be disabled.

If disabled, the module-tagmap parameter will be ignored and the ietf-module-tags module will not be loaded.

Note: the ietf-module-tags module is not used yet and is not loaded into the server.

leaf with-modtags {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-modtags=false

--with-netconf

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

If set to 'true', then the NETCONF over SSH protocol will be enabled. Otherwise, the NETCONF over SSH protocol will not be enabled.

An incoming connection will be dropped if the protocol is disabled.

leaf with-netconf {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-netconf=false

--with-netconf-tls

The --with-netconf-tls parameter controls whether the server will enable the NETCONF over TLS protocol or not.

The default for this parameter is ‘false’ because the server will terminate if the server certificates are not found, but only if this parameter is set to ‘true’.

If set to 'true', then the NETCONF over TLS protocol will be enabled. Otherwise, the NETCONF over TLS protocol will not be enabled. An incoming connection will be dropped if the protocol is disabled.

leaf with-netconf-tls {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-netconf-tls=true

--with-new-notifs

The --with-new-notifs parameter enables the use of the current notification operations defined in RFC 8639.

Note

The default setting will cause a backward-compatible behavior change in the server, required for standards conformance.

  • The module 'ietf-subscribed-notifications' will be loaded into the server at boot-time.

leaf with-new-notifs {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10T-8

Supported by:

netconfd-pro

Example:

netconfd-pro --with-new-notifs=false

--with-new-yanglib

The --with-new-yanglib parameter enables the use of the current YANG Library defined in RFC 8525.

  • If set to 'true', then the new YANG Library from RFC 8525 will be used, even if --with-nmda='false'.

    • This will cause the /yang-library subtree to be present.

    • It does not cause the /modules-state subtree to be removed.

  • If set to 'false', then the new YANG Library will not be used unless --with-nmda='true'.

  • This parameter is ignored if --with-nmda is set to 'true'. The effective value will be 'true' in this case, as required by NMDA.

Note

The default setting will cause a backward-compatible behavior change in the server, required for standards conformance.

  • The module revision of the 'ietf-yang-library' module will be different.

  • The /modules-state data is the YANG module has not changed, but the status is now 'deprecated'.

leaf with-new-yanglib {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Introduced:

23.10T-8

Supported by:

netconfd-pro

Example:

netconfd-pro --with-new-yanglib=false

--with-nmda

The --with-nmda parameter enables or disables NMDA functionality.

Currently the server fully supports the <get-data> operation from the ietf-netconf-nmda module.

If set to 'true', then NMDA operations and YANG modules will be enabled:

The server does not implement all the NMDA features at this time:

  • <edit-data> operation: This operation has less functionality than <edit-config> and provides no useful features. It is not really needed until dynamic datastores are standardized and supported.

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Introduced:

19.10

Supported by:

netconfd-pro

Example:

netconfd-pro --with-nmda=true

--with-notifications

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

leaf with-notifications {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-notifications=false

--with-restconf

The --with-restconf parameter controls whether the server will disable the RESTCONF protocol or not. The incoming RESTCONF connection will be dropped if the protocol is disabled.

The WITH_RESTCONF=1 or EVERYTHING=1 make flags must be used for this protocol to be present in the server.

leaf with-restconf {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-restconf=false

--with-rollback-on-error

The --with-rollback-on-error parameter controls rollback during the <edit-config> operation. If set to 'true', then the NETCONF :rollback-on-error capability and feature will be enabled and advertised. Otherwise, this feature will not be enabled or advertised.

Note

The server always uses all-or-none fully recoverable edit transactions so this parameter has no effect other than to change the NETCONF <hello> message.

leaf with-rollback-on-error {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-rollback-on-error=false

--with-schema-mount

The --with-schema-mount parameter controls whether the Schema Mount feature is enabled or not.

This feature is only available if the server image is built with the WITH_SCHEMA_MOUNT=1 compiler flag.

If set to 'true', then the Schema Mount feature will be enabled and the Schema Mount related YANG modules and SIL code will be loaded.

Additional configuration will be required. The server needs to know which YANG modules should be mounted at a given mount-point. Refer to the following CLI parameter:

If set to 'false', then this feature will be disabled and the following CLI parameters will be ignored:

leaf with-schema-mount {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-schema-mount=false

--with-snmp

The --with-snmp parameter controls whether the SNMP protocol will be enabled.

  • If set to 'true', then the SNMP protocol will be enabled.

  • If set to 'false', the SNMP protocol will not be enabled. Incoming SNMP requests will be dropped if the protocol is disabled.

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-snmp=true

--with-startup

The --with-startup parameter controls whether the server will support the :startup capability or not.

This is a memory intensive capability, and setting this parameter to 'false' will reduce memory usage during normal operations.

The non-volatile copy of the <running> configuration will not be saved automatically if this capability is enabled. Instead, a <copy-config>operation from the <running> to <startup> configuration will be needed, as defined in RFC 6241.

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-startup=true

--with-support-save

The --with-support-save parameter controls whether the yumaworks-support-save.yang module will be loaded by the server.

  • If set to 'true', then this module will be loaded and enabled.

  • Otherwise, this module will not be loaded.

  • Ignored if the server image is not built with the WITH_SUPPORT_SAVE=1 or EVERYTHING=1 compile flag.

leaf with-support-save {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-support-save=false

--with-url

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

If set to 'true', then the :url capability will be enabled and the 'file' scheme will be enabled. Otherwise, the :url capability will not be enabled.

This capability requires a file system and may introduce security risks because internal files could be exposed.

leaf with-url {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-url=false

--with-url-ftp

The --with-url-ftp parameter controls whether the server will support FTP transfers. If set to 'true', then the 'ftp' protocol scheme will be enabled for the :url capability. Ignored if the --with-url parameter is false.

leaf with-url-ftp {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-url-ftp=true

--with-url-tftp

The --with-url-tftp parameter controls whether the server will support TFTP transfers. If set to 'true', then the 'tftp' protocol scheme will be enabled for the :url capability. Ignored if the --with-url parameter is false.

leaf with-url-tftp {
  type boolean;
  default false;
}

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-url-tftp=true

--with-validate

The --with-validate parameter controls whether the server will support the :validate capability or not. This is a memory intensive capability, and setting this parameter to 'false' may reduce memory usage during <edit-config> operations.

leaf with-validate {
  type boolean;
  default true;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-validate=false

--with-warnings

The --with-warnings parameter controls whether the server will allow the <error-severity> field in an <rpc-error> to be set to the value “warning”. If set to 'true', then setting the error-severity field to warning (instead of error) will be enabled. Otherwise, the error-severity field will be set to error, even if the server code tries to set it to warning.

Warning

This is not compliant with the NETCONF protocol and tools may reject rpc-error data sent with an error-severity value of warning.

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

Syntax

boolean

Default:

false

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-warnings=true

--with-yang-api

The --with-yang-api parameter controls whether the server will disable the YANG-API protocol or not. Any incoming YANG-API connection will be dropped if the protocol is disabled

This parameter is ignored unless the server was built with the obsolete WITH_YANGAPI=1 make option. No binary packages use this flag.

Warning

The YANG-API protocol and this parameter are obsolete. Do not use!

leaf with-yang-api {
  type boolean;
  default false;
  status deprecated;
}

Syntax

boolean

Default:

true

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yang-api=false

--with-yang-cbor

The --with-yang-cbor parameter controls whether the server will enable the YANG to CBOR message encoding. This is used for Binary YANG Push operation.

  • The WITH_YANG_CBOR=1 make flag must be used for this module to be present.

  • This parameter is only available in the 21.10T release train

leaf with-yang-cbor {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10T

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yang-cbor=true

--with-yang11-hello

The --with-yang11-hello parameter control whether the NETCONF hello message should conform to the standard and leave out YANG 1.1 modules.

Control whether the NETCONF hello message should conform to the standard and leave out YANG 1.1 modules. Starting in YANG 1.1, the YANG library defined in ietf-yang-library.yang is used to advertise the YANG modules, instead of the NETCONF <hello> message.

  • If set to 'true', then leave out YANG 1.1 modules from <capability> used in <hello>. Also keep out of monitoring <capabilities> list.

  • If 'false' then ignore the standard and advertise YANG 1.1 module capabilities.

Note

The default value has been changed from 'false' to 'true' starting in 22.10T-8.

leaf with-yang11-hello {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE (starting 22.10T-8)

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yang11-hello=false

--with-yang-patch-running

The --with-yang-patch-running parameter control whether the YANG-PATCH will be enabled when the server supports only the :writable-running capability.

This parameter is not relevant if the --target parameter is set to the default (candidate).

If set to 'true', the YANG-PATCH will be enabled when the server supports only the :writable-running capability.

If 'false' then the YANG-PATCH requests will be rejected.

leaf with-yang-patch-running {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Introduced:

19.10

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yang-patch-running=true

--with-yp-coap

The --with-yp-coap parameter controls whether the server will disable the YP-CoAP protocol or not. Any incoming YP-CoAP request will be dropped if the protocol is disabled. This protocol is NOT SECURE. It should not be used.

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

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf with-yp-coap {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yp-coap=true

--with-yp-coap-dtls

The --with-yp-coap-dtls parameter controls whether the server will disable the YP-CoAP over DTLS protocol or not. Any incoming YP-CoAP over DTLS request will be dropped if the protocol is disabled.

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf with-yp-coap-dtls {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yp-coap-dtls=true

--with-yp-shell

The --with-yp-shell parameter controls whether the server will disable the YP-SHELL protocol or not. The incoming YP-SHELL connection will be dropped if the protocol is disabled.

The WITH_CLI=1 or EVERYTHING=1 make flag must be used for this feature to be present in the server.

leaf with-yp-shell {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yp-shell=false

--with-yuma-system

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

If set to 'true', then this module will be loaded and enabled. Otherwise, this module will not be loaded.

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

leaf with-yuma-system {
  description
  type boolean;
  default false;   // true in 17.10, false in 18.10
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yuma-system=true

--with-yuma-time-filter

The --with-yuma-time-filter parameter controls whether the yuma-time-filter.yang module will be enabled. This module adds the <if-modified-since> filter to <get> and <get-config> operations.

leaf with-yuma-time-filter {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yuma-time-filter=false

--with-yumaworks-callhome

The --with-yumaworks-callhome parameter controls usage of the yumaworks-callhome.yang YANG module.

If set to 'true', then yumaworks-callhome.yang will be loaded and enabled. Otherwise, this module will not be loaded.

If not enabled then the run-time configuration of Call Home servers will not be available.

The WITH_CALLHOME=1 or EVERYTHING=1 make flag must be used for this feature to be present in the server.

leaf with-yumaworks-callhome {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-callhome=false

--with-yumaworks-cert-usermap

The --with-yumaworks-cert-usermap parameter controls usage of the yumaworks-cert-usermap.yang module.

If set to 'true', then the yumaworks-cert-usermap module will be loaded and enabled. Otherwise, this module will not be loaded.

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

leaf with-yumaworks-cert-usermap {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Introduced:

21.10

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-cert-usermap=false

--with-yumaworks-config-change

The --with-yumaworks-config-change parameter controls usage of the yumaworks-config-change.yang module.

If set to 'true', then the yumaworks-config-change module will be loaded and enabled. Otherwise, this module will not be loaded. This modules adds data to the 'netconf-config-change' notification.

Warning

This data represents a security risk since it is not subject to the same access control rules within a notification as within a datastore.

NACM does not provide access control for the contents of a notification, only for the notification event type. Use this module with caution! Only allow a superuser administrator access to the 'netconf-config-change' notification if this module is used.

leaf with-yumaworks-config-change {
  type boolean;
  default false;
}

Syntax

boolean

Default:

FALSE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-config-change=true

--with-yumaworks-event-filter

The --with-yumaworks-event-filter parameter controls whether the yumaworks-event-filter.yang module will be enabled. This module adds configurable event type filtering for notification delivery.

leaf with-yumaworks-event-filter {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Introduced:

20.10

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-event-filter=false

--with-yumaworks-event-stream

The --with-yumaworks-event-stream parameter controls whether the yumaworks-event-stream.yang module will be enabled.

If set to 'true', then this module will be loaded and enabled. Otherwise, this module will not be loaded. If disabled the /event-streams subtree will not be available.

This YANG module can be used with or instead of the --event-stream and --event-stream-map CLI parameters.

leaf with-yumaworks-event-stream {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-event-stream=false

--with-yumaworks-getbulk

The --with-yumaworks-getbulk parameter controls whether the yumaworks-getbulk.yang module will be enabled. This module provides the <get-bulk> operation for YANG list retrieval.

If set to 'true', then this module will be loaded and enabled. Otherwise, this module will not be loaded. If disabled the <get-bulk> operation will not be available.

leaf with-yumaworks-getbulk {
  description
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-getbulk=false

--with-yumaworks-ids

The --with-yumaworks-ids parameter controls whether the yumaworks-ids.yang YANG module will be enabled. This module provides additional YANG identities for the <transport> leaf in the <session> list in ietf-netconf-monitoring.yang. If disabled, extra sessions such as YControl sessions will not be stored in this list.

leaf with-yumaworks-ids {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-ids=false

--with-yumaworks-lock

The --with-yumaworks-lock parameter controls whether the yumaworks-lock.yang YANG module will be enabled. This module provides the <lock-all> and <unlock-all> RPC operations.

leaf with-yumaworks-lock {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10-8

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-lock=false

--with-yumaworks-sm-yanglib

The --with-yumaworks-sm-yanglib parameter controls whether the yumaworks-sm-yanglib.yang YANG module will be enabled. If set to 'true', then yumaworks-sm-yanglib.yang module will be loaded and enabled. Otherwise, this module will not be loaded and the <get-sm-yanglib> operation will not be available. This parameter is ignored unless the Schema Mount feature is enabled and configured in the server.

leaf with-yumaworks-sm-yanglib {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10T

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-sm-yanglib=false

--with-yumaworks-system

The --with-yumaworks-system parameter controls whether the yumaworks-system.yang module will be enabled. This module provides module/bundle load and unload operations, plus several augmentations to standard modules.

If set to 'true', then the yumaworks-system module will be loaded and enabled. Otherwise, this module will not be loaded. The <load>, <unload>, <load-bundle>, and <unload-bundle> operations will not be available.

Other operations and data model augments will not be available as well.

leaf with-yumaworks-system {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-system=false

--with-yumaworks-templates

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

If set to 'true', then the yumaworks-templates module will be loaded and enabled. Otherwise, this module will not be loaded.

Ignored unless the server is built with the WITH_TEMPLATES=1 or EVERYTHING=1 compiler flag.

leaf with-yumaworks-templates {
  type boolean;
  default true;
}

Syntax

boolean

Default:

TRUE

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --with-yumaworks-templates=false

--yangapi-server-url

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

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

Syntax

inet:uri

Default:

http://localhost

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

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

--yang-sid-mode

The --yang-sid-mode parameter specifies the SID usage mode within the server. Identifies the mode to use for the source of YANG SID assignments.

typedef yang-sid-mode {
  type enumeration {
    enum sid-file {
      description
        "Use YANG SID files for SID assignments";
    }
    enum lsid {
      description
        "Use LSID SID generation mode for SID assignments.
         For publisher only.";
    }
    enum lsid-file {
      description
        "Use LSID SID file generation mode for SID assignments.
         For subscriber only.";
    }
  }
  description
    "The source of SID assignments for YANG schema items.";
}

This parameter has no effect unless the WITH_YANG_CBOR=1 make parameter is used in the build and the --with-yang-cbor CLI parameter is set to 'true'.

leaf yang-sid-mode {
  type ywt:yang-sid-mode;
  default sid-file;
}

Syntax

enum

Default:

sid-file

Min Allowed:

0

Max Allowed:

1

Introduced:

22.10T

Supported by:

netconfd-pro

Example:

netconfd-pro --yang-sid-mode=lsid

--yp-coap-address

The --yp-coap-address parameter specifies the IP address that the YP-CoAP protocol will use to listen for incoming requests. This will also be used as the source address in YP-CoAP packets sent by the server.

The YP-CoAP protocol is NOT SECURE. It should not be used.

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

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

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

Syntax

inet:ip-address

Default:

0.0.0.0

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --yp-coap-address=192.168.0.100

--yp-coap-dtls-port

The --yp-coap-dtls-port parameter specifies the UDP port number that the YP-CoAP over DTLS protocol will use to listen for incoming requests for CoAP over DTLS. This will also be used as the source port number in YP-CoAP packets sent by the server.

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

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf yp-coap-dtls-port {
  type inet:port-number;
  default "5684";
}

Syntax

inet:port-number

Default:

5684

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --yp-coap-dtls-port=12904

--yp-coap-port

The --yp-coap-port parameter specifies the UDP port number that the YP-CoAP protocol will use to listen for incoming requests. This will also be used as the source port number in YP-CoAP packets sent by the server.

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

Note

The Yp-CoAP protocol is not implemented and obsolete. Do not use this parameter.

leaf yp-coap-port {
  type inet:port-number;
  default "5683";
}

Syntax

inet:port-number

Default:

5863

Min Allowed:

0

Max Allowed:

1

Supported by:

netconfd-pro

Example:

netconfd-pro --yp-coap-port=12903