NETCONF

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.

The NETCONF protocol operates in the following distinct layers:

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.

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:

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.

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>

##

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

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

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

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.

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

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

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.

ssh -l admin -p 830 192.168.0.1 -s netconf

The <get> operation, as defined in RFC 6241, retrieves configuration and state data from the running configuration datastore.

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

The <get-config> operation retrieves data from the running or candidate configuration datastores.

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

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.

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

<rpc message-id="102" 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" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
        <datastore>ds:operational</datastore>
        <subtree-filter>
            <bgp xmlns="http://example.com/ns/bgp"/>
        </subtree-filter>
        <origin-filter>or:intended</origin-filter>
        <origin-filter>or:system</origin-filter>
        <with-origin/>
    </get-data>
</rpc>
 
<rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
        <bgp xmlns="http://example.com/ns/bgp" xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" or:origin="or:intended">
            <peer>
                <name>2001:db8::2:3</name>
                <local-port or:origin="or:system">60794</local-port>
                <state>established</state>
            </peer>
        </bgp>
    </data>
</rpc-reply

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.

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

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.

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.

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

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 default test-then-set approach of <edit-config> operation.
• The <error-option> parameter from <edit-config> is not supported. The behavior is that of rollback-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.

Nokia recommends using the <edit-data> operation instead of the <edit-config> 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>
]]>]]>

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.

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

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.

This operation reverts the candidate configuration datastore to the contents of the current running configuration datastore.

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

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.

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.

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

The <cancel-commit> operation cancels an ongoing confirmed commit.

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

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.

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

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.

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

Any currently accepted NETCONF requests, including the <close-session> operation, are completed before closing the active session.

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

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.

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

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.

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

The following SR Linux NETCONF operations support the with-defaults option:

• get
• get-config
• get-data
• copy-config (where the target is a URL)

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.

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

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.

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.