NETCONF
This section describes the use of the Network Configuration Protocol (NETCONF) in SR Linux.
NETCONF overview
NETCONF is a standardized IETF configuration management protocol specified in RFC 6241. It is secure, connection-oriented, and runs on top of the SSHv2 transport protocol as specified in RFC 6242. NETCONF is an XML-based protocol that can be used as an alternative to the CLI or gNMI for managing SR Linux.
NETCONF uses Remote Procedure Call (RPC) messaging to facilitate communication between a NETCONF client and the NETCONF server that is running on SR Linux. The RPC operation, and the associated configuration or state data, is encoded in an XML document. These XML documents are exchanged between the NETCONF client and a NETCONF server in a series of request and response message interactions.
The NETCONF interface on SR Linux supports configuration and state.
The NETCONF interface on SR Linux does not support actions or notifications.
Transport and sessions
NETCONF uses the SSHv2 secure transport as defined in RFC 6242.
The NETCONF protocol standard specifies a default port of 830 over TCP as registered in IANA (see Service Name and Transport Protocol Port Number Registry). The port must be specifically configured in the SSH server configuration for NETCONF. The default port is permitted inbound in the default CPM filter.
NETCONF sessions do not time out automatically and are not subject to the CLI and SSH session timeouts. Operators can disconnect sessions manually as needed.
A locally configured user (including admin
and
linuxadmin
) or a remote user assigned the
netconf
role can authenticate with the system to establish a
NETCONF session. For more information about how to establish a session, see Initiating a connection to a NETCONF server.
- binding to one or more network instances, including support for:
- use of SSH public keys and certificates
- multiple SSH channels (additional NETCONF sessions created as required over additional SSH channels)
NETCONF in SR Linux
In SR Linux, the NETCONF server is implemented as the netconf_mgr
process; it owns the nokia_srl-netconf-server.yang,
srl_nokia-tools-netconf-server.yang,
ietf-netconf-monitoring.yang, and
ietf-yang-library.yang YANG modules. The
netconf-mgr
process operates as the netconfmgr
user. Functionally, the NETCONF server becomes a client of mgmt-server
and in the netconf-server
YANG module, there is s pointer to the
ssh-server
context to configure the SSH transport.
![](graphics/netconf-layers.png)
Overview of the SR Linux NETCONF implementation
-
supports SSHv2 transport as specified in RFC 6242
-
supports only XML encoding
Every communication with the NETCONF server takes the form of an XML document. An XML document is a correctly formatted and encoded set of YANG validated XML statements. Any invalid XML returns a
malformed-message
error. Every XML document can optionally contain an XML specification, for example:<?xml version="1.0"?>
. -
does not support notifications over NETCONF
-
does not support partial locks as defined in RFC 5717
-
does not support XPath filtering
The NETCONF server implements the ietf-netconf.yang model as defined in RFC 6241.
NETCONF IETF monitoring
module: ietf-netconf-monitoring
+--ro netconf-state
+--ro capabilities
| +--ro capability* inet:uri
+--ro datastores
| +--ro datastore* [name]
| +--ro name netconf-datastore-type
| +--ro locks!
| +--ro (lock-type)?
| +--:(global-lock)
| | +--ro global-lock
| | +--ro locked-by-session uint32
| | +--ro locked-time yang:date-and-time
| +--:(partial-lock)
| +--ro partial-lock* [lock-id]
| +--ro lock-id uint32
| +--ro locked-by-session uint32
| +--ro locked-time yang:date-and-time
| +--ro select* yang:xpath1.0
| +--ro locked-node* instance-identifier
+--ro schemas
| +--ro schema* [identifier version format]
| +--ro identifier string
| +--ro version string
| +--ro format identityref
| +--ro namespace inet:uri
| +--ro location* union
+--ro sessions
| +--ro session* [session-id]
| +--ro session-id uint32
| +--ro transport identityref
| +--ro username string
| +--ro source-host? inet:host
| +--ro login-time yang:date-and-time
| +--ro in-rpcs? yang:zero-based-counter32
| +--ro in-bad-rpcs? yang:zero-based-counter32
| +--ro out-rpc-errors? yang:zero-based-counter32
| +--ro out-notifications? yang:zero-based-counter32
+--ro statistics
+--ro netconf-start-time? yang:date-and-time
+--ro in-bad-hellos? yang:zero-based-counter32
+--ro in-sessions? yang:zero-based-counter32
+--ro dropped-sessions? yang:zero-based-counter32
+--ro in-rpcs? yang:zero-based-counter32
+--ro in-bad-rpcs? yang:zero-based-counter32
+--ro out-rpc-errors? yang:zero-based-counter32
+--ro out-notifications? yang:zero-based-counter32
rpcs:
+---x get-schema
+---w input
| +---w identifier string
| +---w version? string
| +---w format? identityref
+--ro output
+--ro data? <anyxml>
capabilities
: lists the capabilities that are currently supported on the server. These capabilities can differ from the capabilities listed in the initial server<hello>
message as various configuration options can change them during the session, for example, additional YANG modules may have been enabled. Whenever there is a change server capabilities, the NETCONF user should consider restarting the session.datastores
: lists the currently available datastores, for example, candidate and operational.schemas
: lists the schemas currently available; this is similar to the output in the IETF YANG library. For details, see YANG library.sessions
: lists the currently active NETCONF sessions on the NETCONF server.statistics
: provides statistics for the lifecycle of the NETCONF server (instead of the current session).
YANG library
SR Linux supports the YANG library mechanism to identify the available functionality of
the NETCONF server including the YANG modules, sub-modules, YANG features and deviations
that are implemented or imported by the NETCONF server as well the datastores provided.
NETCONF clients can query or cache the YANG library contents and identify whether their
cache is out of date using the content-id
value, which changes each
time the set of YANG modules is updated.
SR Linux implements version 1.1 of the IETF YANG library specification, as described in
RFC 8525. For backwards compatibility, SR Linux also implements the
modules-state
branch of version 1.0 RFC 7895.
Elements that are not supported in a YANG module (Nokia or third-party) are deviated as not supported and are advertised by the node.
Following is the IETF YANG library version 1.1:
module: ietf-yang-library
+--ro yang-library
+--ro module-set* [name]
| +--ro name string
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? revision-identifier
| | +--ro namespace inet:uri
| | +--ro location* inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? revision-identifier
| | | +--ro location* inet:uri
| | +--ro feature* yang:yang-identifier
| | +--ro deviation* -> ../../module/name
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro namespace inet:uri
| +--ro location* inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro location* inet:uri
+--ro schema* [name]
| +--ro name string
| +--ro module-set* -> ../../module-set/name
+--ro datastore* [name]
| +--ro name ds:datastore-ref
| +--ro schema -> ../../schema/name
+--ro content-id string
The following sections describe the contents of IETF YANG library version 1.1.
module-set
list
The module-set
list ensures that remote management systems
understand and can obtain the correct list of modules that make up the devices
schema. This list can change while the system is active based on the configuration
and YANG modules available to the system.
module-set
list has a name and provides a list of YANG modules
that the device has. The YANG modules (whether Nokia or third-party) are grouped as
follows:module
: lists implemented modules.A module is considered implemented if, after stripping out deviated/not-supported nodes, it meets at least one of the following requirements:
- has a data node
- contains an RPC
- contains an action
- contains a notification
- contains a deviation (different from the module has been deviated to remove nodes)
- contains an identity
import-only-module
: lists modules that do not meet any of the requirements listed for an implemented module.
schema
list
schema
list comprises:name
the name of the schemamodule-set
: points to themodule-set
list
datastore
list
datastore
list comprises:name
the name of the datastoreschema
: the schema advertised and used by the specified datastore
content-id
The content-id
value changes whenever there is any change in the
YANG modules or module versions that make up the node's entire schema.
The change in content ID means that a change has occurred in the YANG modules that
the node is advertising. The change in content ID is a signal to a client to
re-obtain a list of YANG modules and then obtain those modules using the
<get-schema>
operation.
SR Linux provides a randomized value for the content-id
field. There
is no expectation made by the standard specification for the
content-id
field to reflect a specific value for a set of
modules. The NETCONF session should also be restarted.
If a change in the content-id
field is detected, it is good practice
to restart the NETCONF session.
Error handling
If an error or warning occurs during a NETCONF operation, the RPC reply message reports
the error as <rpc-error>
. By specification, the NETCONF server is
required to return only one <rpc-error>
even if more than one error
occurs; however, to assist with troubleshooting the SR Linux NETCONF server reports all
errors.
RPC errors are described in RFC 6241. An rpc-error
message contains the
following fields:
Field | Description |
---|---|
error-app-tag
|
Identifies the data-model-specific or implementation-specific error
condition if one exists. This element is present if no appropriate
application |
error-info
|
Contains protocol or data-model-specific error content. This
element is not present if no appropriate message is provided for an
error condition. The list in Appendix A of RFC 6241
defines the mandatory After any protocol-mandated content, SR Linux includes
application-layer error information in the
|
error-message
|
Provides the human-readable string that describes the error. This element is not present if no appropriate message is provided for a particular error condition. |
error-path
|
Provides an absolute XPath expression identifying the element path to the node that is associated with the error being reported. |
error-severity
|
Reports whether the error severity is an error or warning. |
error-tag
|
Identifies the error condition. For details, see Appendix A
of RFC 6241. Some operations provide specific
error-tag values from this list on an
operation-by-operation basis to ensure that the correct
error-tag value is selected. |
error-type
|
Identifies in which of the following levels the error occurred:
|
Network Management Datastore Architecture (NMDA)
The Network Management Datastore Architecture (NMDA), as specified in RFC 8342, provides the framework for NETCONF, where each datastore is exposed separately. RFC 8256 provides the extensions to the NETCONF protocol to support the NMDA.
The NMDA separates configuration datastores from datastores that contain the state of the device (such as the operational datastore). It also provides a framework where different datastores can be combined together to provide an operator views of configurations where translations, expansions and replacements are performed.
The following table provides an overview of the supported datastores.
Datastore | Description |
---|---|
running | This datastore contains the current configuration of the device.
By default, changes committed to the running configuration
datastore (using a system configuration auto-save
true configuration has been applied, SR Linux
automatically performs a <copy-config> operation
between the running and startup datastores following a successful
change to the running configuration datastore. |
candidate |
The candidate datastore, also known as a shared candidate
datastore, can be manipulated without affecting the running
configuration of the system. When the candidate configuration is
ready, you can Multiple NETCONF clients or CLI users can concurrently make
changes to the same candidate datastore. A
The candidate configuration datastore is represented by the named
configuration datastore called |
startup | This datastore contains the configuration that the device uses
at boot up. Changes made to other datastores are not
automatically reflected in the startup datastore and an explicit
system configuration auto-save
true configuration has been applied, SR Linux
automatically performs a <copy-config> operation
between the running and startup datastores following a successful
change to the running configuration datastore.The startup configuration datastore obtains information from, and writes information to, the saved /etc/opt/srlinux/config.json configuration file. The NETCONF representation of this data is always provided in correctly namespaced XML format. The contents of this datastore is copied into the running datastore at system boot up. The configuration in the startup datastore may contain configuration that requires transformations before it can be applied to the system. |
intended |
This read-only datastore contains the complete configuration of the device, including all configuration transformations (in their fully expanded form). |
operational |
This datastore is a read-only datastore that contains all the state and configuration in use by the system. The configuration contained in the operational datastore is the fully expanded configuration that would be found in the intended datastore. |
NETCONF server capabilities
Capabilities are advertised in the <hello>
messages exchanged by
NETCONF client and the SR Linux NETCONF server when a session is started.
Each peer (client and server) must send at least the base NETCONF capability,
urn:ietf:params:netconf:base:1.1
. SR Linux also sends the older
version 1.0 base NETCONF capability urn:ietf:params:netconf:base:1.0
.
Both NETCONF peers verify that the other peer has advertised a common base protocol version. When comparing protocol version capability URIs, if any parameters are encoded at the end of the URI string, they are ignored. If no base protocol version capability in common is found, the NETCONF session terminates. If more than one protocol version URI in common is present, both peers use the latest protocol version.
If the base protocol selected is urn:ietf:params:netconf:base:1.0
, the
standard framing method is used. This means that each NETCONF message sent and received
is terminated with the following special set of characters:
]]>]]>
. While this method is sufficient for most NETCONF
operations, in some cases, the ]]>]]>
string may occur naturally
in a NETCONF message. In this very rare case, the NETCONF message may not be
successfully received and parsed by the client or server.
<rpc message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter>
<network-instance xmlns="urn:nokia.com:srlinux:net-inst:network-instance"/>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<network-instance xmlns="urn:nokia.com:srlinux:net-inst:network-instance">
<name>mgmt</name>
<type>ip-vrf</type>
<admin-state>enable</admin-state>
<description>Management network instance</description>
<interface>
<name>mgmt0.0</name>
</interface>
<protocols>
<linux xmlns="urn:nokia.com:srlinux:linux:linux">
<import-routes>true</import-routes>
<export-routes>true</export-routes>
<export-neighbors>true</export-neighbors>
</linux>
</protocols>
</network-instance>
</data>
</rpc-reply>
]]>]]>
If the base protocol selected is urn:ietf:params:netconf:base:1.1
, the
more modern chunked framing method is used. When using the chunked framing method, each
NETCONF message is sent and received alongside additional metadata describing the size
of the message in octets. Using this method, a well-known message terminator is not
required.
#248
<rpc message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source><running/></source>
<filter>
<network-instance xmlns="urn:nokia.com:srlinux:net-inst:network-instance"/>
</filter>
</get-config>
</rpc>
##
#76
<rpc-reply message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
#11
<data>
#143
<network-instance xmlns="urn:nokia.com:srlinux:net-inst:network-instance">
#30
<name>mgmt</name>
#32
<type>ip-vrf</type>
#46
<admin-state>enable</admin-state>
#67
<description>Management network instance</description>
#24
<interface>
#37
<name>mgmt0.0</name>
#25
</interface>
#24
<protocols>
#66
<linux xmlns="urn:nokia.com:srlinux:linux:linux">
#56
<import-routes>true</import-routes>
#56
<export-routes>true</export-routes>
#62
<export-neighbors>true</export-neighbors>
#25
</linux>
#25
</protocols>
#28
</network-instance>
#12
</data>
#13
</rpc-reply>
##
urn:ietf:params:netconf:base:1.0
capability.<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&content-id=22.10.1</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-origin?module=ietf-origin&revision=2018-02-14</capability>
<capability>http://openconfig.net/yang/telemetry?module=openconfig-telemetry&revision=2018-08-17&deviations=nokia-sr-openconfig-telemetry-deviations</capability>
Capabilities can advertise functionality specified in RFC specifications, YANG modules available on the node along with potential deviations, and less commonly, proprietary information.
The SR Linux NETCONF server advertises the following capabilities:
Capability (shorthand) | Advertised capability/description | Specification |
---|---|---|
base:1.0 |
Support for the original NETCONF base specification, including the
original |
RFC 4742, Using the NETCONF Configuration Protocol over Secure SHell (SSH) |
base:1.1 |
Support for the current NETCONF base specification using chunked framing. |
RFC 6242, Using the NETCONF Protocol over Secure Shell (SSH) |
candidate |
Support
for the Support for the candidate datastore as input for the
Support for the candidate datastore as an input for the following NMDA-defined operations.
|
RFC 6241, Network Configuration Protocol (NETCONF) RFC 8526, NETCONF Extensions to Support the Network Management Datastore Architecture |
confirmed-commit |
<cancel-commit> NETCONF operation.Support
for the following additional parameters for the
|
RFC 6241, Network Configuration Protocol (NETCONF) |
rollback-on-error |
Supports the
rollback-on-error option for the
<error-option> parameter in the
<edit-config> NETCONF operation. Note: The system rolls back all changes made in
the shared candidate configuration no matter which user or
session made them. Use of the
<lock> operation when using
rollback-on-error and the shared candidate
configuration datastore is strongly recommended |
RFC 6241, Network Configuration Protocol (NETCONF) |
validate |
Support for the Also enables the use of the |
RFC 6241, Network Configuration Protocol (NETCONF) |
validate |
Support for the original |
RFC 4741, NETCONF Configuration Protocol |
startup |
Support for the startup configuration datastore. For more information about the startup datastore, see Network Management Datastore Architecture (NMDA). Support for the startup datastore as input for the
<source> or
<target> parameters in the following
operations:
SR Linux does not support the use of the startup datastore with the
|
RFC 6241, Network Configuration Protocol (NETCONF) |
url |
url option as a source or target for the following
operations:
url option for the
<delete-config> operation.SR Linux support for HTTP, HTTPS, FTP, SFTP, and file URL formats. |
RFC 6241, Network Configuration Protocol (NETCONF) |
with-defaults |
Support for the
<with-defaults> option in the
following operations:
The SR Linux NETCONF server uses the For related information, see with-defaults option. |
RFC 6243, With-defaults Capability for NETCONF |
with-operational-defaults |
Support for the For related information, see with-defaults option. |
RFC 8526, NETCONF Extensions to Support the Network Management Datastore Architecture |
yang-library |
Support for the IETF YANG library module and the Network Management Datastore Architecture (NMDA). For related information, see YANG library. |
RFC 8525 NETCONF Extensions to Support the Network Management
Datastore Architecture
RFC 8526, NETCONF Extensions to Support the Network Management Datastore Architecture |
ietf-netconf-monitoring |
Support for the IETF NETCONF monitoring information. For related information, see NETCONF IETF monitoring. |
RFC 6022, YANG Module for NETCONF Monitoring |
NETCONF configuration
This section describes how to configure the NETCONF server.
Configuring the SSH transport
NETCONF on SR Linux operates over the SSH transport. The SSH server in SR Linux is configured under the system ssh-server context.
Operators can choose whether to create a specific SSH server for the NETCONF protocol or whether to use an existing SSH server. The selected SSH server and its associated configuration determines the TCP port that the NETCONF protocol, which runs as a SSH subsystem, is bound to. A NETCONF server instance may bind to a single SSH server instance. Multiple NETCONF server instances may be created as required.
The following is an example configuration of an SSH server that will be used to support NETCONF. This example provides the following:
- an SSH server on the IANA defined TCP port for NETCONF of 830
- operation in the mgmt network-instance
- the restriction of shell access using this SSH server instance
system {
ssh-server mgmt-netconf {
admin-state enable
network-instance mgmt
port 830
disable-shell true
}
}
Configuring the NETCONF server
Having ensured an SSH server instance is available and configured, the next step is to create a Authentication, Authorization and Accounting (AAA) role that specifically allows the NETCONF operations needed.
The following example shows a AAA role configuration that enables specific NETCONF
operations. Replace the <list-of-allowed-rpcs>
field with one or
more NETCONF operations as required. For details, see Enabling the NETCONF operations.
system {
aaa {
authorization {
role netconf {
services [
netconf
]
netconf {
allowed-operations [ <list-of-allowed-rpcs...> ]
}
}
}
}
}
You can now configure a NETCONF server. The NETCONF server configuration creates a named netconf-server instance and binds it to a configured SSH server as described in Transport and sessions.
The following example configuration creates a NETCONF server called mgmt
and binds it to the SSH server named mgmt-netconf
:
system {
ssh-server mgmt-netconf {
admin-state enable
network-instance mgmt
port 830
disable-shell true
}
netconf-server mgmt {
admin-state enable
ssh-server mgmt-netconf
}
}
Enabling the NETCONF operations
The NETCONF server provides multiple operations that are disabled by default. The
operations are enabled one-by-one in an AAA role configuration under /system aaa
authorization role <rolename> netconf allowed-operations
. The list of
available operations is shown below:
<cancel-commit>
<close-session>
<commit>
<copy-config>
<delete-config>
<discard-changes>
<edit-config>
<edit-data>
<get>
<get-config>
<get-data>
<get-schema>
<kill-session>
<lock>
<unlock>
<validate>
For details about the NETCONF operations, see NETCONF operations.
Adding filter entries to allow connections to the chosen TCP port
The factory installed CPM filters for IPv4 and IPv6 allow the default NETCONF TCP port to access the system. If this is not required, they should be removed.
If using an alternative TCP port for NETCONF or if defining custom CPM filters instead of
the system default ones, add the following entries to the required
ipv4-filter
and the ipv6-filter
CPM filters.
IPv4-adding filter entries to allow connections to the default port specified by
<port-number>
acl {
acl-filter cpm type ipv4 {
entry 400 {
description "Accept incoming SSH connections on the NETCONF port"
match {
ipv4 {
protocol tcp
}
transport {
destination-port {
operator eq
value <port-number>
}
}
}
action {
accept {
}
}
}
}
}
IPv6-adding filter entries to allow connections to the NETCONF port specified by
the <port-number>
acl {
acl-filter cpm type ipv6 {
entry 440 {
description "Accept incoming SSH connections on the NETCONF port"
match {
ipv6 {
next-header tcp
}
transport {
destination-port {
operator eq
value <port-number>
}
}
}
action {
accept {
}
}
}
}
}
SR Linux logging
SR Linux performs logging for several operations.
Additional extensive logging can be enabled for debugging purposes using the
traceoptions
configuration container.
The following items are logged by default:
- Session start/stop
- Session client IP address
- Transport (SSH only currently)
- Each RPC start/stop/operation type/datastore targeted (if applicable)/success or failure/error on failure
With trace-options
enabled, the system logs at the
DEBUG
level all of the preceding elements and in addition:
- the input content of each message in XML
- the output content of each message in XML
trace-options
be used for debugging purposes only.Initiating a connection to a NETCONF server
To connect to the NETCONF server on SR Linux, a NETCONF client uses the SSH protocol to
connect to the SR Linux device on the chosen TCP port and requests the
netconf
SSH subsystem.
- The SR Linux device is available on IP address 192.168.0.1.
- The admin user has the correct permissions to connect to the node.
- The SSH server for NETCONF is configured to run on TCP port 830.
Initiating a NETCONF session
ssh -l admin -p 830 192.168.0.1 -s netconf
NETCONF state information
The SR Linux NETCONF implementation provides statistical counters on a per NETCONF session basis and aggregated for the NETCONF server instance. The statistics are available under the statistics container.
In addition, state information provides the operating state of the NETCONF server and the date and time of the last operational state change.
SR Linux native models
+--rw system
+--rw netconf-server* [name] {srl-feat:netconf}?
+--ro oper-state? srl-comm:oper-state
+--ro last-oper-change? srl-comm:date-and-time
+--ro statistics
+--ro active-sessions? uint8
+--ro total-requests? srl-comm:zero-based-counter32
+--ro total-responses? srl-comm:zero-based-counter32
+--ro total-error-responses? srl-comm:zero-based-counter32
+--ro total-close-session-requests? srl-comm:zero-based-counter32
+--ro total-in-bad-hellos? srl-comm:zero-based-counter32
+--ro total-dropped-sessions? srl-comm:zero-based-counter32
+--ro total-get-requests? srl-comm:zero-based-counter32
+--ro total-get-config-requests? srl-comm:zero-based-counter32
+--ro total-get-data-requests? srl-comm:zero-based-counter32
+--ro total-get-schema-requests? srl-comm:zero-based-counter32
+--ro total-edit-config-requests? srl-comm:zero-based-counter32
+--ro total-failed-edit-config-requests? srl-comm:zero-based-counter32
+--ro total-edit-data-requests? srl-comm:zero-based-counter32
+--ro total-failed-edit-data-requests? srl-comm:zero-based-counter32
+--ro total-kill-session-requests? srl-comm:zero-based-counter32
+--ro total-copy-config-requests? srl-comm:zero-based-counter32
+--ro total-delete-config-requests? srl-comm:zero-based-counter32
+--ro total-validate-requests? srl-comm:zero-based-counter32
+--ro total-lock-requests? srl-comm:zero-based-counter32
+--ro total-failed-lock-requests? srl-comm:zero-based-counter32
+--ro total-unlock-requests? srl-comm:zero-based-counter32
+--ro total-commit-requests? srl-comm:zero-based-counter32
+--ro total-discard-changes-requests? srl-comm:zero-based-counter32
+--ro total-action-requests? srl-comm:zero-based-counter32
+--ro session* [session-id]
+--ro session-id uint32
+--ro process-id? uint32
+--ro in-bad-hellos? srl-comm:zero-based-counter32
+--ro get-requests? srl-comm:zero-based-counter32
+--ro get-config-requests? srl-comm:zero-based-counter32
+--ro get-data-requests? srl-comm:zero-based-counter32
+--ro get-schema-requests? srl-comm:zero-based-counter32
+--ro edit-config-requests? srl-comm:zero-based-counter32
+--ro failed-edit-config-requests? srl-comm:zero-based-counter32
+--ro edit-data-requests? srl-comm:zero-based-counter32
+--ro failed-edit-data-requests? srl-comm:zero-based-counter32
+--ro kill-session-requests? srl-comm:zero-based-counter32
+--ro copy-config-requests? srl-comm:zero-based-counter32
+--ro delete-config-requests? srl-comm:zero-based-counter32
+--ro validate-requests? srl-comm:zero-based-counter32
+--ro lock-requests? srl-comm:zero-based-counter32
+--ro failed-lock-requests? srl-comm:zero-based-counter32
+--ro unlock-requests? srl-comm:zero-based-counter32
+--ro commit-requests? srl-comm:zero-based-counter32
+--ro discard-changes-requests? srl-comm:zero-based-counter32
+--ro action-requests? srl-comm:zero-based-counter32
IETF standard models
NETCONF supports standardized IETF YANG models that contain state data relating explicitly to the NETCONF server. These IETF models (along with OpenConfig models) are returned by the various NETCONF operations (unless specifically filtered out). While these IETF modules are visible in the native schema management server in CLI and gNMI, you cannot obtain data from them using the CLI or gNMI.
NETCONF operations
Where appropriate, Nokia recommends the use of the NDMA <get-data>
and <get-data>
operations for obtaining information and configuring
the device.
Operations and mixed module author groups
SR Linux supports mixed module author groups, such as Nokia native SR Linux YANG modules. In conjunction with OpenConfig YANG modules in the current implementation of NETCONF in SR Linux:
- NETCONF clients can make
<edit-config>
and<edit-data>
requests that target Nokia-authored SR Linux native YANG models or OpenConfig authored YANG models only.If a single
<edit-config>
or<edit-data>
request includes both models in a single transaction, the request is rejected with anrpc-error
response. - The YANG module author group that the operator initially targeted in their first
<edit-config>
or<edit-data>
request restricts the candidate configuration to that module author group while that candidate exists. Additionally, if another session (or a CLI user session) has entered configuration into the candidate, the specific type of configuration restricts the candidate configuration to that specific module author group.For example, if the initial configuration change was made using OpenConfig modules, additional
<edit-config>
or<edit-data>
RPCs containing OpenConfig modeled data can be sent. However, sending an<edit-config>
or<edit-data>
RPC that contains data modeled in SR Linux native models returns anrpc-error
and those changes are not made in the candidate configuration. - A
<commit>
operation applies the changes to the running configuration datastore. The candidate is cleared of configuration, returning the operator to the beginning where another choice of model author group in the candidate configuration may be made. - The current implementation supports requests to obtain state data from the
running configuration using the
<get>
RPC or from operational datastore using the<get-data>
RPC filtered on either or both models. - Requests to obtain state data from the running configuration datastore using the
<get>
RPC or from the operational datastore using the<get-data>
RPC that do not contain a filter returns data represented in both SR Linux native and OpenConfig YANG modules (if they are enabled in the system).
get
The <get>
operation, as defined in RFC 6241, retrieves configuration
and state data from the running configuration datastore.
Parameter | Description | Comment |
---|---|---|
<filter>
|
Limits the data returned. The filter provided must be a correctly namespaced filter restricting the data returned from configuration, state, or both. SR Linux supports only the subtree filter type. For details, see NETCONF filtering. |
Optional. If no filter is specified, the operation returns all configuration and state information from the running datastore. |
<with-defaults> |
Specifies how the NETCONF server handles the retrieval of default data. For details, see with-defaults option. | Optional. |
In a successful RPC, the response includes a <data>
node that
contains the requested data. In an unsuccessful RPC, the response includes the
<rpc-error>
.
RPC request and reply messages for the get operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter>
<system xmlns="urn:nokia.com:srlinux:general:system">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh">
<name>mgmt</name>
</ssh-server>
</system>
</filter>
</get>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<system xmlns="urn:nokia.com:srlinux:general:system">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh">
<name>mgmt</name>
<admin-state>enable</admin-state>
<oper-state>up</oper-state>
<network-instance>mgmt</network-instance>
<port>22</port>
<disable-shell>false</disable-shell>
<timeout>0</timeout>
<rate-limit>20</rate-limit>
<protocol-version>2</protocol-version>
<host-key>
<preserve>true</preserve>
</host-key>
</ssh-server>
</system>
</data>
</rpc-reply>
]]>]]>
get-config
The <get-config>
operation retrieves data from the running or
candidate configuration datastores.
Parameter | Description | Comment |
---|---|---|
<source>
|
Specifies the configuration datastore to be queried. Valid options:
|
Mandatory |
<filter>
|
Limits the data returned. SR Linux supports the subtree filter type. For related information, see NETCONF filtering. |
Optional If no filter is specified, the response includes all configuration and state data from the specified datastore. |
<with-defaults> |
Specifies how the NETCONF server handles the retrieval of default
data. Supported options are explicit and
report-all . For details, see with-defaults option. |
Optional |
RPC request and reply messages for the <get-config>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
<filter>
<system xmlns="urn:nokia.com:srlinux:general:system">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh">
<name>mgmt</name>
</ssh-server>
</system>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<system xmlns="urn:nokia.com:srlinux:general:system">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh">
<name>mgmt</name>
<admin-state>enable</admin-state>
<network-instance>mgmt</network-instance>
</ssh-server>
</system>
</data>
</rpc-reply>
]]>]]>
get-data
The <get-data>
operation is the NMDA version of the
<get>
operation.
The <get-data>
operation is defined in the
ietf-netconf-nmda
YANG module and exists in the
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
namespace,
which must be correctly provided to the <get-data>
operation.
Parameter | Description | Comment |
---|---|---|
<datastore> |
Identifies the datastore to be queried. The datastore is an identity
reference (identityref) located in the ietf-datastores
(or any other module that augments itself into this field) YANG module
in the namespace
urn:ietf:params:xml:ns:yang:ietf-datastores . As
these are identityrefs, the value must be provided with a namespace
prefix declaration
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
and this declared namespace must be used in the value of the datastore
field, for example ds:candidate , where
ds is the declared XML namespace prefix.
Available options:
|
Mandatory No default The |
<subtree-filter> |
Limits the returned data in subtree filter format. The filter provided must be a correctly namespaced filter restricting the data returned from the server. For details, see Subtree filtering. |
Optional By default, all data from the specified datastore is returned. |
<config-filter>
|
The |
Not supported |
<origin-filter>
|
The |
Not supported |
<negated-origin-filter> |
The |
Not supported |
<max-depth>
|
Restricts the data returned to the provided maximum number of subtrees. |
Optional By default, all data from the specified datastore is returned. |
<with-origin> |
Outputs the If |
Optional By default, all data from the specified datastore is
returned without any |
<with-defaults>
|
For the |
Optional |
The following example shows an RPC request and reply message for the
<get-data>
operation performed against the operational
datastore, with the with-origin
and with-defaults
arguments configured.
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda" xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">report-all</with-defaults>
<with-origin/>
<subtree-filter>
<system xmlns="urn:nokia.com:srlinux:general:system">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh">
<name>mgmt</name>
</ssh-server>
</system>
</subtree-filter>
</get-data>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
<system xmlns="urn:nokia.com:srlinux:general:system" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh" or:origin="or:intended">
<name>mgmt</name>
<admin-state>enable</admin-state>
<oper-state>up</oper-state>
<network-instance>mgmt</network-instance>
<port>22</port>
<disable-shell>false</disable-shell>
<timeout>0</timeout>
<rate-limit>20</rate-limit>
<protocol-version>2</protocol-version>
<host-key>
<preserve>true</preserve>
</host-key>
</ssh-server>
</system>
</data>
</rpc-reply>
]]>]]>
get-schema
The <get-schema>
operation is defined in the IETF NETCONF monitoring
specifications, as described in RFC 6022.
The SR Linux NETCONF server advertises the
urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
capability for
the <get-schema>
operation to be available.
The <get-schema>
operation allows the NETCONF server to provide the
requested YANG modules to the NETCONF client. Management systems typically use this
operation to build the correct YANG schema for the device using the set of YANG modules
advertised by the node. The <get-schema>
operation serves a single
YANG module to the client. NETCONF clients typically request all YANG modules that they
require. For related information, see NETCONF IETF monitoring.
Parameter | Description | Comment |
---|---|---|
<identifier>
|
Specifies the name of the YANG module. This value must match exactly any module name or identifier described by the node in any of the IETF YANG library or IETF NETCONF monitoring trees. |
Mandatory No default value |
<version>
|
Specifies the version and revision of the YANG module. If provided, the value must match exactly any version or revision described by the node. | Optional No default |
<format>
|
Specifies the format of the YANG schema output. SR Linux only
supports the |
Optional If format is specified, the value is always
|
If the operation is successful, the RPC reply includes a <data>
node
containing the requested YANG module.
If the requested YANG module does not exist, the <error-tag>
field is
set to invalid-value
.
If more than one YANG module matches the requested parameters, the
<error-tag>
field reports operation-failed
and
the <error-app-tag>
field is set to
data-not-unique
.
RPC request and response for a <get-schema>
operation
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>ietf-datastores</identifier>
</get-schema>
</rpc>
]]>]]>
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"><![CDATA[module ietf-datastores {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
prefix ds;
organization
"IETF Network Modeling (NETMOD) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Phil Shafer
<mailto:phil@juniper.net>
Author: Kent Watsen
<mailto:kwatsen@juniper.net>
Author: Rob Wilton
<rwilton@cisco.com>";
description
"This YANG module defines a set of identities for identifying
datastores.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8342
(https://www.rfc-editor.org/info/rfc8342); see the RFC itself
for full legal notices.";
revision 2018-02-14 {
description
"Initial revision.";
reference
"RFC 8342: Network Management Datastore Architecture (NMDA)";
}
/*
* Identities
*/
identity datastore {
description
"Abstract base identity for datastore identities.";
}
identity conventional {
base datastore;
description
"Abstract base identity for conventional configuration
datastores.";
}
identity running {
base conventional;
description
"The running configuration datastore.";
}
identity candidate {
base conventional;
description
"The candidate configuration datastore.";
}
identity startup {
base conventional;
description
"The startup configuration datastore.";
}
identity intended {
base conventional;
description
"The intended configuration datastore.";
}
identity dynamic {
base datastore;
description
"Abstract base identity for dynamic configuration datastores.";
}
identity operational {
base datastore;
description
"The operational state datastore.";
}
/*
* Type definitions
*/
typedef datastore-ref {
type identityref {
base datastore;
}
description
"A datastore identity reference.";
}
}
]]></data>
</rpc-reply>
]]>]]>
edit-config
The <edit-config>
operation is used to change the configuration of
the SR Linux device. You can use it to make full or partial changes to configurations
from a local file, remote file, or in-line to the node.
<edit-config>
operation has the
following characteristics:- A single
<edit-config>
operation can include multiple configuration changes. The changes can be made in and from multiple YANG modules (whether augmented or top-level). For additional restrictions, see Operations and mixed module author groups. - An
<edit-config>
operation is atomic, meaning that all of the configuration applies or none of it does. - Within a single transaction, the order of the data is not important with the exception of leaf-lists and user-ordered lists. SR Linux will reorder the provided data as required for the system.
- SR Linux supports configuration from URLs and advertises the
:url
capability. The<url>
parameter can be used instead of the<config>
parameter.
Each XML node in the specified configuration can have an optional
operation
attribute that defines the behavior of the configuration
change. For supported options, see Options for the operation attribute. If the operation
attribute is not present, the NETCONF server uses
the option specified in the <default-operation>
parameter. If the
<default-operation>
parameter absent, the merge
option is used.
<default-operation>
and
operation
parameters have subtle but important differences in
behaviour.Parameter | Description | Comments |
---|---|---|
<target>
|
Specifies the configuration datastore being edited. SR Linux
supports only the candidate datastore as the target for an
|
Mandatory No default value |
<default-operation>
|
Specifies the default operation for the configuration change.
Note: The options available as the
default-operation are more limited than on
a per XML node basis and have slightly different
behaviors.Supported values:
|
Optional
|
<test-option>
|
Select from the following options:
set option where
a test is performed without a validation test first. |
Optional Default: |
<error-option> |
Specifies how errors are handled for the
<edit-config> operation:
Note:
continue-on-error is not
supported on SR Linux. |
Optional
|
<config>
|
Provides the configuration to be applied to the system. It is formatted as the complete hierarchy of configuration data as defined by the device's data models. The contents must be correctly namespaced, to allow the device to detect the appropriate data model, and the contents must follow the constraints of that data model, as defined by its capability definition. The value is encoded in YANG as |
No default |
<url> |
The URL to a local or remote file that contains a complete hierarchy of configuration data to be applied as defined by the device's data models. The file is written in XML format. The contents must be correctly namespaced, to allow the device to detect the appropriate data model and the contents must follow the constraints of that data model, as defined by its capability definition. URL types that SR Linux supports are advertised in the
The value is encoded in YANG as |
No default |
RPC request and reply for the <edit-config>
operation
<rpc message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<acl xmlns="urn:nokia.com:srlinux:acl:acl">
<acl-filter>
<name>1</name>
<type>ipv4</type>
</acl-filter>
</acl>
</config>
</edit-config>
</rpc>
]]>]]>
<rpc-reply message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
edit-data
The <edit-data>
operation changes the configuration of a datastore.
It is similar to the <edit-config>
operation, except it is designed
as part of the NMDA specification to be extensible for any writeable NMDA datastore.
The <edit-data>
operation differs from the
<edit-config>
operation in the following areas:
- The
<test-option>
parameter from the<edit-config>
operation is not supported. The behavior is that of the defaulttest-then-set
approach of<edit-config>
operation. - The
<error-option>
parameter from<edit-config>
is not supported. The behavior is that ofrollback-on-error
option in<edit-config>
operation.
Each XML node in the specified configuration can have an optional
operation
attribute that defines the behavior of the configuration
change. For supported options, see Options for the operation attribute. If the operation
attribute is not present, the NETCONF server uses
the option specified in the <default-operation>
parameter. If the
<default-operation>
parameter absent, the merge
option is used.
<default-operation>
and
operation
parameters have subtle but important differences in
behaviour.Nokia recommends using the <edit-data>
operation instead of the
<edit-config>
operation.
Parameter | Description | Comment |
---|---|---|
<datastore>
|
Specifies the datastore to be targeted; for SR Linux, the only option
is ds:candidate . The datastore is an identity reference
(identityref) located in the ietf-datastores (or
any other module that augments itself into this field) YANG module in
the urn:ietf:params:xml:ns:yang:ietf-datastores
namespace. As these are identityrefs, the value must be provided with a
namespace declaration
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
and this declared namespace must be used in the value of the datastore
field, for example, ds:candidate where
ds is the declared XML namespace. |
Mandatory No default value. |
<default-operation>
|
Specifies the default operation of the configuration change. Note: The options available for the
Supported values:default-operation option are more limited than
on a per XML node basis and have slightly different
behaviors.
|
Optional
|
<config>
|
Provides the configuration to be applied to the system. It is
formatted as the complete hierarchy of configuration data as defined by
the device's data models. The contents must be correctly namespaced, to allow the device to detect the appropriate data model, and the contents must follow the constraints of that data model, as defined by its capability definition. The value is encoded in YANG
using the YANG 1.1 <config> and <url>
parameters are mutually exclusive. |
No default |
<url>
|
The URL to a local or remote file that contains a complete hierarchy of configuration data to be applied as defined by the device's data models. The file is written in XML. The contents must be correctly namespaced, to allow the device to detect the appropriate data model, and the contents must follow the constraints of that data model, as defined by its capability definition. The value is esncoded in YANG using the YANG 1.1
URL types that SR Linux
supports are advertised in the <config> and
<url> parameters are mutually exclusive. |
No default |
RPC request and reply messages for the <edit-data>
operation
<rpc message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda" xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:candidate</datastore>
<config>
<acl xmlns="urn:nokia.com:srlinux:acl:acl">
<acl-filter>
<name>1</name>
<type>ipv4</type>
</acl-filter>
</acl>
</config>
</edit-data>
</rpc>
]]>]]>
<rpc-reply message-id="10" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
copy-config
Use the <copy-config>
operation to create or replace the entire
configuration datastore with that of another datastore (a datastore in this situation
may be a file stored at a local/remote URL). If the destination
(target
) configuration datastore already exists, it is overwritten
completely. If the target configuration datastore does not exist, it is created.
SR Linux does not support the following uses of the <copy-config>
operation and returns an <rpc-error>
with the
error-tag
set to invalid-value
:
- using the running configuration datastore as a destination (
target
) for the copy - performing remote-to-remote copy operations where the node itself is not the source or destination of the copy
- performing URL-to-URL copy operations (either local-to-remote, remote-to-local, or local-to-local)
- using the identical source and destination (
target
) - using formats other than XML for the
<url>
of a<source>
or<target>
file
Performing a <copy-config>
operation from the running configuration
datastore to the startup
configuration datastore is the same as saving
the configuration.
<commit>
operation, perform a
<copy-config>
operation with the <source>
set to <running/>
and the <target>
set to
<startup/>
. If the /system configuration auto-save
true
configuration has been applied, SR Linux will automatically perform a
<copy-config>
operation between the running and startup
datastores following a successful change to the running configuration datastore.Parameter | Description | Comment |
---|---|---|
<source>
|
The source configuration datastore. Supported options are:
The data read from the file is the entire contents of the required configuration datastore, encoded in XML format. For supported<target> and <source>
combinations, see Supported source and target combinations. |
Mandatory No default value |
<target>
|
The target configuration datastore. Supported options are:
The data written to the file is the entire
contents of the <target> and <source>
combinations, see Supported source and target combinations. |
Mandatory No default value |
<with-defaults> |
See with-defaults option. The
|
Optional |
Supported source and target combinations
Source | Target | Supported |
---|---|---|
<candidate/>
|
<candidate/>
|
No |
<candidate/> |
<startup/>
|
No |
<candidate/> |
<running/>
|
No |
<candidate/> |
<url>
|
Yes |
<startup/>
|
<candidate/>
|
Yes |
<startup/>
|
<startup/>
|
No |
<startup/>
|
<running/>
|
No |
<startup/>
|
<url>
|
Yes |
<running/>
|
<candidate/>
|
No |
<running/>
|
<startup/>
|
Yes |
<running/>
|
<running/>
|
No |
<running/>
|
<url>
|
Yes |
<url>
|
<candidate/>
|
Yes |
<url>
|
<startup/>
|
Yes |
<url>
|
<running/>
|
No |
<url>
|
<url>
|
No |
RPC request and reply message for the <copy-config>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<source>
<url>https://user:password@example.com/cfg/new.xml</url>
</source>
<target>
<candidate/>
</target>
</copy-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
discard-changes
The <discard-changes>
operation, as described in RFC 6241, discards
all changes in the shared candidate configuration datastore. This operation discards all
changes made in the shared candidate configuration datastore, not just those changes
made by the current NETCONF session.
<discard-changes>
operation may also
discard changes performed by users in another interface such as CLI or gNMI.This operation reverts the candidate configuration datastore to the contents of the current running configuration datastore.
RPC request and reply for the <discard-changes>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
commit
The <commit>
operation copies the configuration from the candidate
datastore to the running datastore, overwriting anything previously in it. Additionally,
the <commit>
operation allows the configuration to be rolled back
(automatically or manually) when used in conjunction with the
<confirmed>
parameter.
<commit>
operation
activates the configuration.If the configuration cannot be committed, the commit operation fails and the running configuration datastore remains in the same state that it was in before the initiating the commit operation. The running configuration remains unchanged and the configuration integrity is ensured.
If the running configuration datastore is locked when the <commit>
operation is issued, the operation fails with an <rpc-error>
containing the <error-tag>
with value of
in-use
.
An implicit lock is placed on the running configuration datastore for the duration of the
<commit>
operation. After a <commit>
is
successfully completed, confirmed, rolled back, or cancelled using the
<cancel-commit>
operation, the implicit lock on the running
datastore is released.
<commit>
operation, a
<copy-config>
operation should be performed with the
<source>
set to <running/>
and the
<target>
set to <startup/>
. If the
/system configuration auto-save true
configuration has been
applied, SR Linux will automatically perform a <copy-config>
operation between the running and startup datastores following a successful change to
the running configuration datastore.Parameter | Description | Comment |
---|---|---|
<confirmed>
|
Allows you to review and verify the configuration on the router
before confirming (or cancelling) the committed changes. If the commit is not confirmed within the confirm-timeout duration, the changes are automatically rolled back and the candidate configuration is reinstated with the proposed changes. If the<confirmed> parameter is absent, the commit
takes effect immediately. |
Optional |
<confirm-timeout>
|
Specifies the time in seconds to wait for the commit to be confirmed before automatically rolling back the changes. By default, the confirmed commit timeout is 600 seconds (10 minutes). | Optional |
<persist>
|
Specifies a client-provided ID, a string of client-created characters. This ID is used to confirm the commit from another session. The |
Optional |
<persist-id>
|
Specifies a previously chosen persist ID. This parameter is used
to confirm a commit from another NETCONF session. If the value
provided does not match a previously provided ID, the NETCONF
operation fails with an The |
Optional |
- Immediate commit: commit the configuration from the candidate datastore without
waiting for confirmation.
Use the
<commit/>
tag without theconfirmed
parameter to commit without confirmation. - Confirmed commit: wait for confirmation before committing the candidate to the
running datastore. Use the
confirmed
parameter and optionally,confirm-timeout
:<commit> <confirmed/> </commit>
<commit> <confirmed/> <confirm-timeout>30</confirm-timeout> </commit>
If the
<commit>
is not confirmed within the timer, the original contents of the running datastore (before the commit) are restored into the running datastore and the proposed configuration changes remain in thecandidate
datastore. If the configuration changes disconnect the session and the<persist>
option has not been set, the only way to revert them is to wait for the timer to expire. To confirm confirmed-commit, issue another<commit/>
operation from the same session. - Persistent confirmed commit: similar to a confirmed commit, except, if the
<persist>
parameter is present, you can confirm the commit using the commit operation from the current session or using the<persist-id>
value from another session. If the configuration changes disconnect the session, you can revert them using the<persist-id>
from another session.
RPC request and reply for a persistent <commit>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<confirmed/>
<persist>IQd4668</persist>
</commit>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
<!-- confirm the persistent confirmed-commit, possibly from another session -->
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit>
<persist-id>IQd4668</persist-id>
</commit>
</rpc>
]]>]]>
<rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
cancel-commit
The <cancel-commit>
operation cancels an ongoing confirmed commit.
Parameter | Description | Comment |
---|---|---|
<persist-id>
|
Use this parameter to cancel a commit from another NETCONF session. If the |
Optional |
RPC request and reply for a <cancel-commit>
operation
<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<cancel-commit/>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
lock
The <lock>
operation locks the configuration datastore and
restricts other users or sessions from writing to it. Locking the running
configuration datastore restricts other users or sessions from issuing a
<commit>
operation.
When the <lock>
operation locks the shared candidate
configuration datastore, no other session is allowed to use the
<edit-config>
operation. No other interface (including CLI,
gNMI, or SNMP) can make changes to the locked configuration datastore. A lock on a
configuration datastore remains in place until either it is unlocked using the
<unlock>
operation or until the NETCONF session closes
(irrespective of whether the client or server closed the session).
While the <lock>
operation explicitly locks the targeted
configuration datastore, a configuration datastore may also be implicitly locked by
the system. This occurs during a <commit>
operation where SR
Linux locks the running configuration datastore (if it is not already locked) for
the duration of the <commit>
.
The <lock>
operation fails in the following situations:
- NETCONF session or another entity (such as CLI) already has a lock in place for that datastore.
- The target configuration is
<candidate/>
and the shared candidate configuration has already been modified, and these changes have not been committed or discarded. - The target configuration is
<running/>
and another NETCONF session has an ongoing confirmed commit.
Parameter | Description | Comments |
---|---|---|
<target> |
Specifies the configuration datastore to lock. Available options
are:
|
Mandatory No default value |
RPC request and reply messages for the <lock>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
unlock
The <unlock>
operation releases a configuration lock previously
obtained using the <lock>
operation.
For the <unlock>
operation to succeed:
- the specified lock must be active
- the
<unlock>
operation must be issued in the same session that issued the lock
Locks held by a session are released when that session is terminated.
Parameter | Description | Comment |
---|---|---|
<target> |
Specifies the configuration datastore to lock:
|
Mandatory |
RPC request and reply for an <unlock>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
delete-config
The <delete-config>
operation deletes the contents of a target
configuration datastore. The running configuration datastore cannot be deleted.
Although the :url
capability is supported by SR Linux, the
<delete-config>
operation on SR Linux does not support it.
<discard-changes>
operation
instead.Parameter | Description | Comment |
---|---|---|
<target> |
Specifies the configuration datastore to delete. The only
supported value is |
Mandatory |
A successful RPC results in an <rpc-reply>
with an
<ok/>
XML node. An unsuccessful RPC results in an
<rpc-error>
containing the appropriate error information for the
detected issue.
RPC request and reply message for the <delete-config>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
close-session
<close-session>
operation closes the active session. The NETCONF
server takes the following actions:- releases any locks and resources associated with the session
- gracefully closes any associated connections
- rejects any additional NETCONF requests
Any currently accepted NETCONF requests, including the
<close-session>
operation, are completed before closing the
active session.
RPC request and reply for the <close-session>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
validate
The <validate>
operation checks the contents of a specified
configuration against the underlying YANG data model. The operation checks for
syntax-errors, missing parameters, references to undefined configuration data.
<validate>
operation does not gaurantee that a subsequent
<commit>
operation will succeed. Platform restrictions such as
available memory are evaluated at the point of configuration commit.Parameter | Description | Comment |
---|---|---|
<source>
|
Specifies the source configuration datastore or the URL of configuration file to validate.
|
Mandatory No default value |
RPC request and response for the <validate>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
kill-session
The <kill-session>
operation terminates any NETCONF session, except
the current session. To close the current session, use the
<close-session>
operation; see close-session
for details. You cannot use the <kill-session>
operation to
terminate a session from another interface such as CLI or gRPC.
When a session is terminated, operations that are pending in that session are discarded
and any locks held by that session are released. When a NETCONF server receives a
<kill-session>
request while processing a confirmed commit, it
restores the running configuration to its state before the confirmed commit was issued.
Parameter | Description | Comment |
---|---|---|
<session-id> |
Specifies the session ID of the NETCONF session to be terminated. | Mandatory |
RPC request and reply for the <kill-session>
operation
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>146</session-id>
</kill-session>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>
NETCONF options
This section outlines the SR Linux NETCONF implementation for the following options:
with-defaults
with-oritin
- options for the
operation
attribute
with-defaults option
with-defaults
option specifies how the NETCONF server handles the
retrieval of default data. SR Linux NETCONF server supports the following behaviors for
the with-defaults
option:- In
explicit
mode, the default behavior for SR Linux, the output contains all data that is not a system default. It returns all data where the value is the same as the system default but was explicitly set by the operator. -
In
report-all
mode, the output includes all data, including system defaults (whether explicit, implicit or system calculated).
The following SR Linux NETCONF operations support the with-defaults
option:
- get
- get-config
- get-data
- copy-config (where the
target
is a URL)
urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all
urn:ietf:params:netconf:capability:with-operational-defaults:1.0
For the with-defaults
option to function on the
operational
datastore, the
with-operational-defaults
capability is advertised by SR Linux
along with the with-defaults
capability. If either of these is missing
and the operator attempts to use the with-defaults
tag with the
operational
datastore, the RPC returns an
rpc-error
with the invalid-value
error-tag
.
basic-mode
and
also-supported
parameters are attached to the
with-defaults
capability. These detail what the default behavior of
the system is and what other behavior is available for use by an operator. RPC request and reply for the <get-config>
operation using
the <with-defaults>
option in report-all
mode
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
<with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">report-all</with-defaults>
<filter>
<system xmlns="urn:nokia.com:srlinux:general:system">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh">
<name>mgmt</name>
</ssh-server>
</system>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<system xmlns="urn:nokia.com:srlinux:general:system">
<ssh-server xmlns="urn:nokia.com:srlinux:linux:ssh">
<name>mgmt</name>
<admin-state>enable</admin-state>
<network-instance>mgmt</network-instance>
<port>22</port>
<disable-shell>false</disable-shell>
<timeout>0</timeout>
<rate-limit>20</rate-limit>
<host-key>
<preserve>true</preserve>
</host-key>
</ssh-server>
</system>
</data>
</rpc-reply>
]]>]]>
with-origin
option
The with-origin
option details, for each configuration node (except
non-presence containers which do not have an origin), where the data came from as
described in RFC 8342. The with-origin
option is only supported in
conjunction with the operational datastore.
The following are the possible values for an elements origin:
origin
: Not used in SR Linux.intended
: represents configuration provided by the intended configuration datastore. Most configuration elements are typically marked asintended
.dynamic
: represents configuration provided by a dynamic configuration datastore. No dynamic configuration datastores are provided in SR Linux.system
: represents configuration provided by the system itself. Examples of system configuration include applied configuration for an always-existing loopback interface, or interface configuration that is auto-created because of the hardware currently present in the device.learned
: represents configuration that has been learned via protocol interactions with other systems, including such protocols as link-layer negotiations, routing protocols, and DHCP.default
: represents configuration using a default value specified in the data model, using either values in the "default" statement or any values described in the "description" statement. The default origin is only used when the configuration has not been provided by any other source.unknown
: represents configuration for which the system cannot identify the origin.
The following example shows the origin is provided in the
urn:ietf:params:xml:ns:yang:ietf-origin
namespace from the
ietf-origin
YANG module. Any origin is referenced using the
correct namespace.
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda" xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> <datastore>ds:operational</datastore> <with-origin/> <subtree-filter> <system xmlns="urn:nokia.com:srlinux:general:system"> <control-plane-traffic/> </system> </subtree-filter> </get-data> </rpc> ]]>]]> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"> <system xmlns="urn:nokia.com:srlinux:general:system" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> <control-plane-traffic> <output> <qos xmlns="urn:nokia.com:srlinux:qos:qos"> <management-protocols-dscp or:origin="or:intended">32</management-protocols-dscp> </qos> </output> <input> <acl xmlns="urn:nokia.com:srlinux:acl:acl"> <acl-filter or:origin="or:intended"> <name>cpm</name> <type>ipv4</type> </acl-filter> <acl-filter or:origin="or:intended"> <name>cpm</name> <type>ipv6</type> </acl-filter> </acl> </input> </control-plane-traffic> </system> </data> </rpc-reply> ]]>]]>
The <origin>
tag reflects the source of the configuration that is
in use by the system; this applies only to the configuration data (and only in the
operational datastore), not state.
If the origin is ambiguous, such as when the same data node value has originated from
multiple sources, SR Linux selects the most appropriate origin that node. If the
node contains a protocol-negotiated value that does not override an explicitly
configured value, the origin is reported as intended
.
Options for the operation attribute
operation
attribute:Option | Description |
---|---|
merge
|
Merges the configuration data provided in this attribute with the
configuration at the corresponding level in the configuration
datastore identified by the <target>
parameter. |
replace
|
Replaces any related configuration in the configuration datastore
identified by the <target> parameter with the
configuration data identified by the element containing this
attribute. If no such configuration data exists in the
configuration datastore, it is created. Unlike the
|
create
|
Adds the configuration data identified by the element containing
this attribute to the configuration only if the configuration data
does not already exist in the configuration datastore. If the
configuration data exists, an <rpc-error>
element is returned with an <error-tag> value of
data-exists . |
delete
|
Deletes the configuration data identified by the element
containing this attribute from the configuration, if the
configuration data currently exists in the configuration datastore.
If the configuration data does not exist, an
<rpc-error> element is returned with an
<error-tag> value of
data-missing . |
remove
|
Deletes from the configuration datastore configuration data
identified by the element containing the remove attribute. If
the configuration data to be removed does not exist, the
|
NETCONF filtering
NETCONF filtering is a mechanism that allows an application to select which YANG subtrees to include in the RPC reply message for those operations that support filtering. SR Linux supports subtree filtering.
XPath filtering is not supported on SR Linux.
Subtree filtering
Subtree filtering allows you to select which YANG subtrees (encoded in XML) to include in
the <rpc-reply>
message for operations that support filtering.
Subtree filtering is described in RFC 6241.
A subtree filter includes zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and the paths of elements to the root are included in the filter output. All elements present in a particular subtree within a filter must match associated nodes present in the server's YANG schema.
xmlns
declarations) if required
within the filter data model. The namespace must exactly match a namespace supported by
the server. Each node specified in a subtree filter represents an inclusive filter. Only associated
nodes in underlying data model within the specified configuration datastore on the
server are selected by the filter. A node must match the namespace exactly and hierarchy
of elements specified in the filter data, except that the filter absolute path name is
adjusted to start from the layer below the <filter>
context.
Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Some elements expressed in the filter as leaf nodes are expanded (that is, subtrees included) in the filter output. Specific data instances are not duplicated in the response if that request contains multiple filter subtree expressions that select the same data.
Namespace selection and wildcarding
The filter output includes only elements from the specified namespace. A namespace is
considered match if the content of the xmlns
attribute is the same in the
filter and the underlying data model. At least one element must be specified in the filter any
elements to be included in the filter output.
module foo {
namespace "urn:nokia.com:foo";
container top {
container my-container {
leaf my-leaf { type string; }
}
}
}
module bar {
namespace "urn.nokia.com:bar";
container top {
container my-container {
leaf my-leaf { type string; }
}
}
}
Filter with a specified namespace
<get>
<filter>
<top xmlns="urn:nokia.com:foo"/>
</filter>
</get>
]]>]]>
<rpc-reply>
<top xmlns="urn:nokia.com:foo">
<my-container>
<my-leaf>data from foo</my-leaf>
</my-container>
</top>
</rpc-reply>
]]>]]>
All data starting from the <top>
node in the
"urn:nokia.com:foo"
namespace is returned. No data is returned from the
"urn.nokia.com:bar"
namespace as it has not been selected.
Filter with multiple namespaces
<get>
<filter>
<top xmlns="urn:nokia.com:foo">
<my-container xmlns="urn.nokia.com:bar"/>
</top>
</filter>
</get>
]]>]]>
<rpc-reply>
<top xmlns="urn:nokia.com:foo">
</top>
</rpc-reply>
]]>]]>
The data requested is from the <top>
element in the
"urn:nokia.com:foo"
namespace and the <my-container>
element in the "urn.nokia.com:bar"
namespace. As there is no
<my-container>
element in the "urn.nokia.com:bar"
namespace under the <top>
container in the
"urn:nokia.com:foo"
namespace, no data is returned, however, the
<top>
container does exist in the requested
"urn:nokia.com:foo"
namespace so that is returned.
Omitting namespace on top element
<get>
<filter>
<top/>
</filter>
</get>
]]>]]>
<rpc-reply>
<top xmlns="urn:nokia.com:foo">
<my-container>
<my-leaf>data from foo</my-leaf>
</my-container>
</top>
<top xmlns="urn:nokia.com:bar">
<my-container>
<my-leaf>data from bar</my-leaf>
</my-container>
</top>
</rpc-reply>
]]>]]>
All data under the <top>
element in both namespaces is returned. As no
specific namespace was requested, the server treats this request as if the client requested
xmlns=""
and therefore evaluates against all namespaces.
Explicitly requesting an empty (wildcard) namespace
<get>
<filter>
<top xmlns=""/>
</filter>
</get>
]]>]]>
<rpc-reply>
<top xmlns="urn:nokia.com:foo">
<my-container>
<my-leaf>data from foo</my-leaf>
</my-container>
</top>
<top xmlns="urn:nokia.com:bar">
<my-container>
<my-leaf>data from bar</my-leaf>
</my-container>
</top>
</rpc-reply>
]]>]]>
Requesting the network-instance
node defined in the SR Linux
namespace
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
<filter>
<network-instance xmlns="urn:nokia.com:srlinux:net-inst:network-instance"/>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<network-instance xmlns="urn:nokia.com:srlinux:net-inst:network-instance" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
<name>mgmt</name>
<type>ip-vrf</type>
<admin-state>enable</admin-state>
<description>Management network instance</description>
<interface>
<name>mgmt0.0</name>
</interface>
<protocols>
<linux xmlns="urn:nokia.com:srlinux:linux:linux">
<import-routes>true</import-routes>
<export-routes>true</export-routes>
<export-neighbors>true</export-neighbors>
</linux>
</protocols>
</network-instance>
</data>
</rpc-reply>
]]>]]>
Requesting the network-instance
node using a wildcard
namespace
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
<filter>
<network-instance xmlns=""/>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<network-instance xmlns="urn:nokia.com:srlinux:net-inst:network-instance" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
<name>mgmt</name>
<type>ip-vrf</type>
<admin-state>enable</admin-state>
<description>Management network instance</description>
<interface>
<name>mgmt0.0</name>
</interface>
<protocols>
<linux xmlns="urn:nokia.com:srlinux:linux:linux">
<import-routes>true</import-routes>
<export-routes>true</export-routes>
<export-neighbors>true</export-neighbors>
</linux>
</protocols>
</network-instance>
</data>
</rpc-reply>
]]>]]>
Containment nodes
A containment node in a subtree filter is a node that contains one or more child elements
(that may themselves be containment nodes). In the following example,
system
and logging
would be considered containment
nodes.
Filtering using containment nodes
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
<filter>
<system xmlns="urn:nokia.com:srlinux:general:system">
<logging xmlns="urn:nokia.com:srlinux:log:logging">
<file/>
</logging>
</system>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<system xmlns="urn:nokia.com:srlinux:general:system">
<logging xmlns="urn:nokia.com:srlinux:log:logging">
<file>
<file-name>messages</file-name>
<rotate>3</rotate>
<size>10000000</size>
<facility>
<facility-name>local6</facility-name>
<priority>
<match-above>warning</match-above>
</priority>
</facility>
</file>
</logging>
</system>
</data>
</rpc-reply>
]]>]]>
Selection nodes
An empty leaf node within a filter is called a selection node. It represents an explicit
selection filter on the underlying data model. Presence of any selection nodes within a set of
sibling nodes causes the filter to select the specified subtrees and suppresses automatic
selection of the entire set of sibling nodes in the underlying data model. For filtering
purposes, an empty leaf node can be declared either with an empty tag (for example,
<example/>
or with explicit start and end tags (for example,
<example> </example>
. Any white space character is ignored.
Filtering using selection nodes
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
<filter>
<system xmlns="urn:nokia.com:srlinux:general:system">
<logging xmlns="urn:nokia.com:srlinux:log:logging">
<buffer>
<buffer-name/>
</buffer>
</logging>
</system>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<system xmlns="urn:nokia.com:srlinux:general:system">
<logging xmlns="urn:nokia.com:srlinux:log:logging">
<buffer>
<buffer-name>messages</buffer-name>
</buffer>
<buffer>
<buffer-name>system</buffer-name>
</buffer>
</logging>
</system>
</data>
</rpc-reply>
]]>]]>
Content match nodes
A leaf node that contains content is called a content match node. It is used to select some or all of its sibling nodes for filter output, and it represents an exact-match filter on the leaf node element content. The following constraints apply to content match nodes:
- A content match node must not contain nested elements.
- Multiple content match nodes (that is, sibling nodes) are logically combined in an "AND" expression.
- Filtering of mixed content is not supported.
- Filtering of list content is not supported.
- Filtering of whitespace-only content is not supported.
- A content match node must contain non-whitespace characters. An empty element (for
example,
<example> </example>
) is interpreted as a selection node (that is,<example/>
). - Leading and trailing whitespace characters are ignored, but any whitespace characters within a block of text characters are not ignored or modified.
If all specified sibling content match nodes in a subtree filter expression are true, the filter output nodes are selected in the following manner:
- Each content match node in the sibling set is included in the filter output.
- If any containment nodes are present in the sibling set, they are processed further and are included if any nested filter criteria are also met.
- If any selection nodes are present in the sibling set, all of them are included in the filter output.
- If there are no selection or containment nodes in the filter sibling set, all the nodes defined at this level in the underlying data model (and their subtrees, if any) are returned in the filter output. If any of the sibling content match node tests are 'false', no further filter processing is performed on that sibling set, and none of the sibling subtrees are selected by the filter, including the content match nodes.
Filtering using content match nodes
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
<filter>
<system xmlns="urn:nokia.com:srlinux:general:system">
<logging xmlns="urn:nokia.com:srlinux:log:logging">
<buffer>
<buffer-name>messages</buffer-name>
</buffer>
</logging>
</system>
</filter>
</get-config>
</rpc>
]]>]]>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<system xmlns="urn:nokia.com:srlinux:general:system">
<logging xmlns="urn:nokia.com:srlinux:log:logging">
<buffer>
<buffer-name>messages</buffer-name>
<rotate>3</rotate>
<size>10000000</size>
<facility>
<facility-name>local6</facility-name>
<priority>
<match-above>informational</match-above>
</priority>
</facility>
</buffer>
</logging>
</system>
</data>
</rpc-reply>
]]>]]>
Subtree filter processing
After a filter output is applied, the filter output (the set of selected nodes) is initially empty. Each subtree filter can contain one or more data model fragments, which represent portions of the data model that should be selected (with all child nodes) in the filter output.
- Each subtree data fragment is compared by the server to the internal data models supported by the server.
- If the entire subtree data- fragment filter (starting from the root to the innermost element specified in the filter) exactly matches a corresponding portion of the supported data model, the node and all its children are included in the result data.
- The server processes all nodes with the same parent node (sibling set) together, starting from the root to the leaf nodes. The root elements in the filter are considered in the same sibling set (assuming they are in the same namespace), even though they do not have a common parent.
- For each sibling set, the server determines which nodes are included (or potentially included) in the filter output, and which sibling subtrees are excluded from the filter output. The server first determines which types of nodes are present in the sibling set and processes the nodes according to the rules for their type.
- If any nodes in the sibling set are selected, the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed.