4. NETCONF

Note:

This feature is only supported on the 7210 SAS-K 2F1C2T and 7210 SAS-K 2F6C4T.

This chapter describes the use of the Network Configuration Protocol (NETCONF) by the SR OS router to perform router management operations.

4.1. NETCONF overview

NETCONF is a standardized IETF configuration management and XML encoded protocol that can be used as an alternative to CLI or SNFMP to manage the SR OS routers. NETCONF is defined in RFC 6241, NETCONF Configuration Protocol (NETCONF). It is secure and connection-oriented, and can run over the SSHv2 transport protocol, in accordance with RFC 6242, Using the NETCONF Configuration Protocol over Secure Shell (SSH).

NETCONF uses Remote Procedure Call (RPC) messaging to facilitate communication between a NETCONF client and the NETCONF server that is running on the SR OS node. The RPC message and configuration data are 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 type of messaging interactions. The SR OS NETCONF interface supports both configuration support and retrieval of operational information.

The following figure shows a NETCONF RPC messaging request.

Figure 5:  NETCONF RPC request 

As defined in RFC 6241, NETCONF can be conceptually partitioned into four layers; these are shown in the following figure.

Figure 6:  NETCONF layers (RFC 6241) 

4.2. NETCONF in SR OS

The SR OS router can use NETCONF to perform the following router management operations:

  1. change the router configuration using the <edit-config> operation
  2. read the router configuration using the <get-config> operation (equivalent to the info command in CLI)
  3. read operational status, data, and associated configuration information using the <get> operation (equivalent to the show commands in CLI)

NETCONF is not used to generate notifications on an SR OS router; for example, log events, syslog, or SNMP notifications (traps).

The equivalent of some admin commands are available through the SR OS NETCONF interface:

  1. admin save can be done using the <copy-config> operation
  2. admin rollback commands are supported using a CLI content layer <cli-action> RPC.

The bof, debug, tools, and other general CLI operational commands (for example, telnet or ping) are not supported through NETCONF on an SR OS router.

The SR OS NETCONF server supports both the base 1.1 and base 1.0 capabilities.

SR OS NETCONF supports both a CLI content layer and an XML-based content layer.

4.2.1. YANG data models

The SR OS NETCONF XML content layer configuration schema is described in a set of Alcatel-Lucent proprietary YANG modules. The configuration modules are advertised in the SR OS NETCONF server hello.

The configuration YANG data model closely aligns to the SR OS CLI configuration tree structure and commands.

A set of YANG modules are published and distributed as part of an SR OS image in the cflash/support directory (along with files like dictionary-freeradius.txt and stats.dtd).

The following areas of CLI do not have equivalent YANG data models:

  1. bof
  2. admin, tools, debug, or show branches

4.2.2. Transport and sessions

SSH transport for NETCONF is supported on TCP port 830 with IPv4 or IPv6 in the “Base” routing instance.

NETCONF SSH sessions (similar to CLI, Secure Copy (SCP), and SSH File Transfer Protocol (sFTP) sessions) are subject to any configurable and non-configurable session limits; for example, inbound-max-sessions. The SSH server and NETCONF protocol must be enabled in the router configuration to use NETCONF.

Unlike CLI sessions, NETCONF sessions are not subject to automatic session timeout. Operators can manually disconnect sessions using the admin disconnect command.

NETCONF user accounts must exist on the SR OS to enable a client establishing a NETCONF session to log into the router. A new access type netconf is provided. The user must be configured with both console and netconf access.

Only authentication through the local user database is supported for NETCONF users (no RADIUS or TACACS+ authentication). Access to various CLI configuration and show commands (authorization) through NETCONF is controlled through the assigned user profile that is used to authenticate the underlying SSH session.

If a NETCONF request attempts to execute a CLI command that is outside the scope of its access profile, the system sends an error response.

The following example shows a user request where the show command usage is outside the scope of the user’s access profile.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get>
                <filter>
                        <oper-data-format-cli-block>
                                <cli-show>system security</cli-show>
                        </oper-data-format-cli-block>
                </filter>
        </get>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>cli-show</err-element>
        </error-info>
        <error-message>
            command failed - 'show system security'
            MINOR: CLI Command not allowed for this user.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

4.2.3. NETCONF operations

The following base protocol operations are supported:

  1. <get>
  2. <get-config>
  3. <edit-config>
  4. <copy-config>
  5. <delete-config>
  6. <validate>
  7. <close-session>
  8. <kill-session>

The <lock> and <unlock> base protocol operations are not supported.

The <error-option> operation is not supported. SR OS implements the stop-on-error behavior by default. The continue-on-error and rollback-on-error behaviors are not supported.

4.2.3.1. <get>

CLI content layer <get> operation is supported. XML content layer <get> operation is not supported.

A <get> request is analyzed for syntax errors before it is executed. If a syntax error is found, a single global <rpc-error> for the entire request is sent in the reply.

Responses are provided for each item in the request until the first item with an error is found. A <response> tag containing the error information, followed by an <rpc-error> tag (and sub-tags) is attached to the erroneous item. The reply is returned, and no subsequent items are not executed.

For a non-syntax error, the <rpc-error> for an individual item is placed after the </response> information and not included in the <response> tag.

The following example shows a <get> request with a non-syntax error in the second item.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get>
                <filter>
                        <oper-data-format-cli-block>
                                <cli-show>router interface "system"</cli-show>
                                <cli-show>router mpls lsp</cli-show>
                                <cli-show>system security ssh</cli-show>
                        </oper-data-format-cli-block>
                </filter>
        </get>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <oper-data-format-cli-block>
            <item>
                <cli-show>router interface "system"</cli-show>
                <response>
 
===============================================================================
Interface Table (Router: Base)
===============================================================================
Interface-Name                   Adm         Opr(v4/v6)  Mode    Port/SapId
   IP-Address                                                    PfxState
-------------------------------------------------------------------------------
system                           Up          Up/Down     Network system
   144.23.63.5/32                                                n/a
-------------------------------------------------------------------------------
Interfaces : 1
===============================================================================
                </response>
            </item>
            <item>
                <cli-show>router mpls lsp</cli-show>
                <response>
                    MINOR: CLI MPLS is not configured.
                </response>
                <rpc-error>
                    <error-type>application</error-type>
                    <error-tag>operation-failed</error-tag>
                    <error-severity>error</error-severity>
                    <error-info>
                        <err-element>cli-show</err-element>
                    </error-info>
                    <error-message>
                        command failed - 'show router mpls lsp'
                    </error-message>
                </rpc-error>
            </item>
        </oper-data-format-cli-block>
    </data>
</rpc-reply>
]]>]]>

4.2.3.2. <get-config>

The <get-config> operation returns non-default configuration by default (that is, the “trim” mode, as defined in RFC 6243).

4.2.3.3. <edit-config>

The following values for the <test-option> parameter under <edit-config> are supported:

  1. test-then-set
  2. set
  3. test-only

4.2.3.4. <copy-config> and <delete-config>

The <copy-config> and <delete-config> base protocol operations are supported for specific combinations of source and target datastores.

The <copy-config> operation is supported for the following combinations of sources and targets:

  1. <source>=<url> and <target>=<startup> (as long as both are not remote URLs)
  2. <source>=<startup> and <target>=<url> (as long as both are not remote URLs)
  3. <source>=<running> and <target>=<url>
    1. equivalent of admin save file-url
    2. an index file is also saved if persist on is configured in the BOF
  4. <source>=<running> and <target>=<startup>
    1. equivalent of admin save
    2. an index file is also saved if persist on is configured in the BOF

The <running> datastore cannot be a <target> for a <copy-config> operation.

Remote URL-to-remote URL copies are not supported. For example, if the primary-image is a remote URL, a <startup> to copy will fail with an error.

The <copy-config> operation uses the CLI content layer format. The format of the source and target is block CLI.

The <delete-config> operation is supported for the following targets:

  1. <url>
  2. <startup>

The <delete-config> operation is not allowed on the <running> datastore.

4.2.3.5. <validate>

The following support is available for the validate:1.1 capability:

  1. The validate:1.1 and 1.0 capabilities are advertised in the NETCONF server <hello> as the following:
    1. <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
    2. <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
  2. The <validate> request is supported for an XML content layer request, but not for a CLI content layer request. Detection of a <config-format-cli-block> or <oper-data-format-cli-block> tag in a <validate> request will result in an "operation not supported" error response.
  3. A <validate> operation is supported for a selection of config (<source><config>), or for the <running> datastore, which only returns 'OK'. The <validate> operation is not supported for URL sources or the <startup> datastore.

4.2.4. Datastores and URLs

The SR OS supports the following datastores:

  1. <running>
  2. <startup>
  3. <url>
Note:

<url> is not a datastore in itself.

The <candidate> datastore is not supported.

All configuration changes (<edit-config>) done to the <running> datastore through NETCONF take immediate operational effect.

The <startup> datastore and <url> tags can only be used with <copy-config> and <delete-config> and are not supported with any other operations (including <edit-config>, <get-config>, <get>, <validate>, and others).

The :startup capability is advertised in the SR OS NETCONF server <hello> as follows:

<capability>urn:ietf:params:netconf:capability:startup:1.0</capability>

The <url> tags support the same options as CLI <file-url>: local URLs (CF) and remote URLs (ftp and tftp).

The :url capability is advertised in the SR OS NETCONF server <hello> as follows:

<capability>urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,tftp,file</
capability>

The following examples show the format of each URL scheme:

Note:

  1. The examples use “///” for the file URL.
  2. The file://localhost/... format is not supported.
  1. <target><url>ftp://name:passwd@a.b.c.d/usr/myfiles/myfile.cfg</url></target>
  2. <target><url>tftp://name:passwd@a.b.c.d/usr/myfiles/myfile.cfg</url></target>
  3. <target><url>file:///cf3:/myfiles/myfile.cfg</url></target>
  4. <target><url>cf3:/myfiles/myfile.cfg</url></target>

The <startup> datastore is identified by using the bof primary-config, secondary-config, and tertiary-config paths configured by the operator. The <startup> datastore is an alias for a special URL used for system startup with some extra resiliency (primary, secondary, and tertiary).

The BOF is not considered to be part of any configuration datastore.

Debug configurations (such as debug mirrors, or configurations saved using the admin debug-save command) are not considered to be part of any configuration datastore.

Configuration changes made through NETCONF are subject to CLI rollback operations (revert, save, and so on) and are included in the configuration when an admin save operation is performed in the CLI.

4.2.5. General NETCONF behavior

Use Ctrl-C in a NETCONF session to immediately terminate the session.

The SR OS NETCONF implementation does not support XML namespaces (xmlns). Any XML namespace or prefix declarations in the RPC tag are accepted and returned in the <rpc-reply> tag, but are ignored and unused. Any XML namespace or prefix declarations in the rest of the request are ignored and unused. The SR OS NETCONF server puts the correct NETCONF namespace declaration (“urn:ietf:params:xml:ns:netconf:base:1.0”) in all replies. See the following sections for more information:

  1. Example: multiple use of standard NETCONF namespace
  2. Example: non-standard namespace defined in <rpc> tag
  3. Example: non-standard namespace not defined in <rpc> tag
  4. Example: non-standard namespace or prefix not defined in <rpc> tag

The chunked framing mechanism is supported in addition to the EOM mechanism. As described in RFC 6242, Section 4.1 - Framing Protocol, "... If the :base:1.1 capability is advertised by both peers, the chunked framing mechanism (see Section 4.2) is used for the remainder of the NETCONF session. Otherwise, the old end-of-message-based mechanism (see Section 4.3) is used." See Example: chunked frame mechanism for more information.

Default data handling (for example, info vs info detail) is supported in accordance with the mechanisms detailed in RFC 6243. The SR OS NETCONF server supports the “trim” method and advertises it in the <hello> as follows:

<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=trim</
capability>

Pseudo-transactional capabilities are supported. A user can save a rollback checkpoint (for example, prior to performing an <edit-config> or a series of <edit-config>) and, if required, later perform a rollback revert. See the following sections for more information:

  1. Example: two rollback items with responses
  2. Example: syntax error in the rollback request
  3. Example: error in processing the request
  4. Example: error in second item of the request

4.2.5.1. Example: multiple use of standard NETCONF namespace

The following example shows the standard NETCONF namespace “urn:ietf:params:xml:ns:netconf:base:1.0” used more than once in the <rpc> element.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source> <running/> </source>
<filter>
    <configure>
        <router>
            <interface>
               <interface-name>"system"</interface-name>
            </interface>
        </router>
    </configure>
</filter>
</get-config>
</rpc>
]]>]]>

In the following reply, the namespace is accepted and no error message is returned.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-
id="101" xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:
xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <router>
                <router-name>Base</router-name>
                <interface>
                    <interface-name>system</interface-name>
                    <address>
                        <ip-address-mask>144.23.63.5/32</ip-address-mask>
                    </address>
                    <shutdown>false</shutdown>
                </interface>
            </router>
        </configure>
    </data>
</rpc-reply>
]]>]]>

4.2.5.2. Example: non-standard namespace defined in <rpc> tag

The following example shows a non-standard NETCONF base namespace defined in the <rpc> tag.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
<get-config>
<source> <running/> </source>
<filter>
    <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
        <router>
            <interface>
              <interface-name>"system"</interface-name>
            </interface>
        </router>
    </configure>
</filter>
</get-config>
</rpc>
]]>]]>

In the following reply, the non-standard namespace used in the <rpc> tag is ignored.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-
id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:alu="urn:alcatel-
lucent.com:sros:ns:yang:conf-r13">
<data>
     <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
          <router>
               <router-name>Base</router-name>
               <interface>
                    <interface-name>system</interface-name>
                    <address>
                         <ip-address-mask>144.23.63.5/32</ip-address-mask>
                    </address>
                    <shutdown>false</shutdown>
               </interface>
          </router>
     </configure>
</data>
</rpc-reply>
]]>]]>

4.2.5.3. Example: non-standard namespace not defined in <rpc> tag

The following example shows a non-standard NETCONF namespace used in one of the tags, but not defined in the <rpc> tag.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source> <running/> </source>
<filter>
    <configure>
        <router>
            <interface xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                 <interface-name>"system"</interface-name>
            </interface>
        </router>
    </configure>
</filter>
</get-config>
</rpc>
]]>]]>

In the following reply, the non-standard namespace used in the tag is ignored.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-
id="101" xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:
xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <router>
                <router-name>Base</router-name>
                <interface>
                    <interface-name>system</interface-name>
                    <address>
                        <ip-address-mask>144.23.63.5/32</ip-address-mask>
                    </address>
                    <shutdown>false</shutdown>
                </interface>
            </router>
        </configure>
    </data>
</rpc-reply>
]]>]]>

4.2.5.4. Example: non-standard namespace or prefix not defined in <rpc> tag

The following example shows a non-standard NETCONF namespace or prefix used in one of the tags but not defined in the <rpc> tag.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source> <running/> </source>
<filter>
    <configure>
        <router>
            <interface xmlns:alu="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
                 <alu:interface-name>"system"</alu:interface-name>
            </interface>
        </router>
    </configure>
</filter>
</get-config>
</rpc>
]]>]]>

In the following reply, the non-standard namespace/prefix used in tag is ignored.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-
id="101" xmlns:alu="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:
xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <router>
                <router-name>Base</router-name>
                <interface>
                    <interface-name>system</interface-name>
                    <address>
                        <ip-address-mask>144.23.63.5/32</ip-address-mask>
                    </address>
                    <shutdown>false</shutdown>
                </interface>
            </router>
        </configure>
    </data>
</rpc-reply>
]]>]]>

4.2.5.5. Example: chunked frame mechanism

The following example shows a chunked message.

#302
<?xml version="1.0" encoding="UTF-8"?><rpc message-
id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-
config><source><running/></
source><filter><config><configure><router><interface><interface-name>system</
interface-name></interface></router></configure></config></filter></get-config></
rpc>
##

The following example shows the reply.

#38
<?xml version="1.0" encoding="UTF-8"?>
#85
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
#62
    <source><running/></source>
    <filter>
      <configure>
##79
        <system>
            <netconf>
            </netconf>
        </system>
##55
      </configure>
    </filter>
  </get-config>
</rpc>
##

4.2.5.6. Example: two rollback items with responses

The following example shows two rollback items with responses.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <cli-action>
    <admin>rollback compare active-cfg to 1</admin>
    <admin>rollback compare</admin>
  </cli-action>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <cli-action>
            <item>
                <admin>rollback compare active-cfg to 1</admin>
                <response>                                  
0.150 s
0.450 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-            lsp "test"
-                shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 0.720 s
                </response>
            </item>
            <item>
                <admin>rollback compare</admin>
                <response>                           
0.160 s
0.070 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-            lsp "test"
-                shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
     service
-        vpls "99" customer 1 create
-            shutdown
-            stp
-                shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 0.350 s
                </response>
            </item>
        </cli-action>
    </data>
</rpc-reply>
]]>]]>

4.2.5.7. Example: syntax error in the rollback request

The following example shows a syntax error in the request, which results in a global <rpc-error> reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="103" 
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <cli-action>  
      <admin>rollback compare active-cfg to 1</admin>
      <admin>rollback compare flee-fly</admin>
  </cli-action>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="103" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>admin</err-element>
        </error-info>
        <error-message>
            command failed - '/admin rollback compare flee-fly'
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

4.2.5.8. Example: error in processing the request

The following example shows an error processing the request.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="103" 
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <cli-action>  
      <admin>rollback compare active-cfg to 1</admin>
      <admin>rollback compare 1 to flee-fly</admin>
  </cli-action>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="103" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <cli-action>
            <item>
                <admin>rollback compare active-cfg to 1</admin>
                <response>                                                     
0.160 s
0.180 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 0.460 s
                </response>
            </item>
            <item>
                <admin>rollback compare 1 to flee-fly</admin>
                <response>
                </response>
                <rpc-error>
                    <error-type>application</error-type>
                    <error-tag>operation-failed</error-tag>
                    <error-severity>error</error-severity>
                    <error-info>
                        <err-element>admin</err-element>
                    </error-info>
                    <error-message>
                        command failed - '/admin rollback compare 1 to flee-fly'
                        MINOR: CLI No such file ('flee-fly').
                    </error-message>
                </rpc-error>
            </item>
        </cli-action>
    </data>
</rpc-reply>
]]>]]>

4.2.5.9. Example: error in second item of the request

The following example shows an error in the second item of the request, resulting in no third item in the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="104" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <cli-action>  
    <admin>rollback compare active-cfg to 1</admin>
    <admin>rollback compare 1 to xyz</admin>
    <admin>rollback compare active-cfg to 1</admin>
  </cli-action>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="104" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <cli-action>
            <item>
                <admin>rollback compare active-cfg to 1</admin>
                <response>                                                    
0.170 s
1.350 s
----------------------------------------------
  configure
     router
-        mpls
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
-        rsvp
-            shutdown
-            interface "system"
-                no shutdown
-            exit
-        exit
     exit
  exit
----------------------------------------------
Finished in 1.640 s
                </response>
            </item>
            <item>
                <admin>rollback compare 1 to xyz</admin>
                <response>
                </response>
                <rpc-error>
                    <error-type>application</error-type>
                    <error-tag>operation-failed</error-tag>
                    <error-severity>error</error-severity>
                    <error-info>
                        <err-element>admin</err-element>
                    </error-info>
                    <error-message>
                        command failed - '/admin rollback compare 1 to xyz'
                        MINOR: CLI No such file ('xyz').
                    </error-message>
                </rpc-error>
            </item>
        </cli-action>
    </data>
</rpc-reply>
]]>]]>

4.2.5.10. System provisioned configuration objects

There is a set of configurable objects that are provisioned (added to the <running> datastore) automatically by SR OS; for example, log-id 99.

Some of these SPC objects can be deleted or removed by a user (deletable system provisioned configuration (SPC) objects):

  1. In CLI, the SPC objects are removed by specifying the keyword no, which is then visible in an info command or in a saved configuration (admin save); for example, no log-id 99.
  2. The deletable SPC objects can be removed or recreated using NETCONF <edit-config> requests, but they are not visible in a <get-config> response if they are:
    1. set to their default values, including all child leaves and objects
    2. removed or deleted
  3. The deletable SPC objects are visible in a <get-config> response if a child leaf or object is changed from the default value; for example, changing log-99 to time-format local.
  4. The list of deletable SPC objects is as follows:
    Config system security profile default
    Config system security profile default entry 10-100
    Config system security profile administrative
    Config system security profile administrative entry 10-112
    Config system security user "admin"
    Config system security user console member "default"
    Config system security snmp access group  xyz (a set of access groups)
    Config system security ssh client-cipher-list protocol-version 1 cipher 200-210
    Config system security ssh client-cipher-list protocol-version 2 cipher 190-235
    Config system security ssh server-cipher-list protocol-version 1 cipher 200-205
    Config system security ssh server-cipher-list protocol-version 2 cipher 190-235
    Config log filter 1001
    Config log filter 1001 entry 10
    Config log log-id 99 & 100

Some SPC objects cannot be deleted (non-deletable SPC objects):

  1. Although they cannot be deleted, some of these non-deletable objects contain modifiable leaves.
  2. The non-deletable SPC objects are not visible in a <get-config> response when the SPC objects are set to their default values, including all child leaves and objects.
  3. The non-deletable SPC objects are visible in a <get-config> response if a child leaf or object is changed from the default value; for example, setting the card-type.
  4. The list of non-deletable SPC objects is as follows:
    Config system security user-template {tacplus_default|radius_default}
    Config system security snmp view iso …
    Config system security snmp view li-view …
    Config system security snmp view mgmt-view …
    Config system security snmp view vprn-view …
    Config system security snmp view no-security-view …Config log event-control …
    Config filter log 101
    Config qos … various default policies can’t be deleted
    Config qos queue-group-templates … these can’t be deleted
    Config card <x>  
    Config router network-domains network-domain “default”
    Config oam-pm bin-group 1
    Config call-trace trace-profile “default”

Some non-deletable SPC objects are visible in a <get-config> request, even if they are set to default values:

Config system security cpu-protection policy 254 and 255
Config router interface “system"
Config service customer 1

4.3. Establishing a NETCONF session

The following example shows a client on a Linux PC initiating a connection to an SR OS NETCONF server. In accordance with RFC 6242, the SSH session must be invoked using an SSH subsystem.

ssh -s my_username@a.b.c.d -p 830 netconf

The following example shows an exchange of hello messages that include advertisement of capabilities.

The following is a message from the SR OS server.

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
        <capability>urn:ietf:params:netconf:base:1.0</capability>
        <capability>urn:ietf:params:netconf:base:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:writable-running:1.0</
capability>
        <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
        <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
        <capability>urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,tftp,file<
/capability>
        <capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-
mode=trim</capability>
        <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-
netconf&amp;revision=2015-02-27&amp;features=writable-
running,validate,startup,url&amp;deviations=alu-netconf-deviations-r13</capability>
        <capability>urn:alcatel-lucent.com:sros:ns:yang:netconf-deviations-
r13?module=alu-netconf-deviations-r13&amp;revision=2015-02-27</capability>
        <capability>urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-
r13?module=alu-cli-content-layer-r13&amp;revision=2015-02-27</capability>
        <capability>urn:alcatel-lucent.com:sros:ns:yang:conf-r13?module=conf-
r13&amp;revision=2015-02-27</capability>
        <capability>urn:alcatel-lucent.com:sros:ns:yang:conf-aaa-r13?module=conf-
aaa-r13&amp;revision=2015-02-27</capability>
...
...
...
...
        <capability>urn:alcatel-lucent.com:sros:ns:yang:conf-vsm-r13?module=conf-
vsm-r13&amp;revision=2015-02-27</capability>
    </capabilities>
    <session-id>54</session-id>
</hello>
]]>]]>

The following is a reply from a NETCONF client.

<?xml version="1.0" encoding="UTF-8"?>
     <hello>
          <capabilities>
              <capability>urn:ietf:params:netconf:base:1.0</capability>
          </capabilities>
     </hello>
]]>]]>

4.4. XML content layer

XML is the default content layer format for the SR OS NETCONF server. When the XML format is used at the NETCONF content layer, configuration changes and configuration information retrieved are expressed as XML tags.

The XML formatted configuration information must be correctly ordered and has the same dependencies and behavior as the equivalent CLI commands.

4.4.1. <edit-config> with XML content layer

An <edit-config> operation is supported with the <running> datastore only. The following <edit-config> operation attribute values are supported:

  1. merge
  2. remove
  3. delete
    1. A “delete” operation for a leaf or a presence container will not return an error if the item is already deleted.
    2. An error is returned if attempting to delete a list node that does not exist.
    3. A “delete” operation for a container without presence will return an error
  4. create
    1. A “create” operation for a leaf or a presence container will not return an error if the item is being set to the same value.
    2. An error is returned if attempting to create a list node that already exists.
    3. A “create” operation for a container without presence will result in an "OK" response (no error) but will be silently ignored.

The “replace” operation is not supported as an attribute value for the <edit-config> operation.

Both “delete” and “remove” operations have the following behavior:

  1. Delete or remove operations are not supported for boolean leaves. For example, any of the following samples will return an error:
    1. <shutdown operation="delete"/>
    2. <shutdown operation="delete">false</shutdown>
    3. <interface operation="delete">
           <interface-name>abc</interface-name>
           <shutdown>true</shutdown>
      </interface>

For this last case <shutdown operation="merge">true</shutdown> can be used instead to make the request valid:

  1. A <delete> or <remove> operation is the equivalent of the no command in CLI. This no command is applied whether the default for the command is enabled, disabled (no), or a specific value. The delete operation is not aware of the default value of the object/leaf being deleted.
  2. A <delete> or <remove> operation for a leaf, where the request also specifies a value for the leaf, will result in an error.

The <edit-config> <default-operation> parameter is supported merge and none values. The “replace” value is not supported. An operation of "none" on a leaf node (inherited or direct) causes that leaf statement to be ignored. No error will be returned if the leaf does not exist in the data model.

For merge and create operations, the operations and tags specified in an <edit-config> request are order-aware and order-dependent, and the sequence of operations must follow the required sequence of the equivalent CLI commands. The <edit-config> is processed and executed in a top-down order. The same leaf can be enabled, disabled, or enabled and then disabled, and the final result is whatever was last specified for that leaf in the <edit-config> request.

For <delete> and <remove> operations, the SR OS NETCONF server will recursively unwind any children of the node being deleted or removed first before removing the node itself. The deepest child branch of the request is examined first and any leaves are processed, after which the server works backwards out of the deepest branches back up to the object where the delete operation was specified. If children branches of an object must be removed before deleting the object in CLI, the equivalent delete request in a NETCONF <edit-config> must contain all those children if they exist, such as if the children are configured in the config datastore).

In the following example, SR OS shuts down the test interface, deletes the interface, shuts down the VPLS, and removes it.

      <config>
          <configure>
              <service>
                  <vpls operation="delete">
                      <service-id>11</service-id>
                      <interface>
                          <ip-int-name>test</ip-int-name>
                          <shutdown operation="merge">true</shutdown>
                      </interface>
                      <shutdown operation="merge">true</shutdown>
                  </vpls>
              </service>
          </configure>
      </config>
Note:

The 'operation="merge"' is required in the shutdown nodes; otherwise, the inherited operation is <delete>, which is not supported on boolean leaves.

In the preceding example, if other children of vpls 11 exist in the config besides the interface test specified in the delete request, and it is required to delete those children in CLI before vpls 11 is removed, the deletion request fails. All configured children must be specified in the delete request.

4.4.2. <get-config> with XML content layer

A <get-config> operation is supported with the <running> datastore only.

Subtree filtering for basic subtree selection is supported for XML content layer <get-config> requests. Post-filtering of the selected subtrees is not supported.

The subtree filtering behavior is as follows:

  1. Attribute match expressions, as defined in section 6.2.2 of RFC 6241, are not supported.
  2. Only containers are supported as selection nodes, as defined in section 6.2.4 of RFC 6241. Empty leaf nodes or list name nodes are not supported as selection nodes.
    1. Nodes that represent lists must also include content match nodes for all keys of the list; for example, <configure><router><interface><interface-name>abc</interface-name>.
    2. A selection node that is a list, without also specifying the key, is not supported; for example, <configure><router><interface/> is not supported. An alternative is to request the parent containment node that contains the desired list node; for example, <configure><router> instead of <configure><router><interface/>.
  3. Content match nodes, as defined in section 6.2.5 of RFC 6241, are only supported for key leaves; for example, <configure><router><interface> <interface-name>abc</interface-name>.
    1. Content match nodes that are leaves but are not also keys will result in an error (not silently ignored).

A <get-config> request that specify a non-existent list node or presence container will result in a reply that contains no data for those list nodes or containers. An <rpc-error> is not sent in this case.

See the following sections for examples of <get-config> request and response messages:

  1. Example: request that returns an error
  2. Example: content match node on a list key
  3. Example: selection node that is a container
  4. Example: list name node as an invalid selection node
  5. Example: empty leaf node as invalid selection node
  6. Example: key repeated in the same instance of the list node
  7. Example: retrieving the full configuration

4.4.2.1. Example: request that returns an error

The following example shows a request that returns an error.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
                <source>
                        <running/>
                </source>
                <filter>
                        <configure>
                                <router>
                                        <interface>
                                                <interface-name>abc</interface-name>
                                                <delayed-enable>30</delayed-enable>
                                        </interface>
                                </router>
                        </configure>
                </filter>
        </get-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>get-config</err-element>
        </error-info>
        <error-message>
            command failed - 'configure router interface "abc" delayed-enable'
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

4.4.2.2. Example: content match node on a list key

Multiple key leaves for the same key cannot be requested inside the same instance of the list name node; for example, <interface-name>abc</interface-name> <interface-name>def</interface-name>. Each key value must be inside its own instance of the list name node; for example, <interface> <interface-name>abc</interface-name> </interface> <interface> <interface-name>def</interface-name> </interface>.

The following example shows a valid <get-config> request for a content match node on a list key.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
                <source>
                        <running/>
                </source>
   <filter>
    <configure>
        <router>
            <interface>
                <interface-name>abc</interface-name>
            </interface>
        </router>
    </configure>
   </filter>
        </get-config>
</rpc>
]]>]]>

4.4.2.3. Example: selection node that is a container

The following example shows a valid <get-config> request selection node that is a container.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
        <source>
             <running/>
        </source>
        <filter>
             <configure>
                 <router/>
             </configure>
         </filter>
    </get-config>
</rpc>
]]>]]>

The reply will contain the configuration for all child nodes of config>router.

4.4.2.4. Example: list name node as an invalid selection node

The following example shows an invalid <get-config> request for a list name node that is an invalid selection node.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
                <source>
                        <running/>
                </source>
                        <filter>
                                <configure>
                                        <router>
                                                <interface>
                                                </interface>
                                        </router>
                                </configure>
                        </filter>
        </get-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>get-config</err-element>
        </error-info>
        <error-message>
            command failed - 'configure router interface'
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

4.4.2.5. Example: empty leaf node as invalid selection node

The following example shows an invalid <get-config> request for an empty leaf node that is an invalid selection node.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
            <source>
                <running/>
            </source>
            <filter>
                <configure>
                <system>
                        <security>
                                    <ftp-server>
                                                </ftp-server>
                                    </security>
                         </system>
                 </configure>
            </filter>
        </get-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>protocol</error-type>
        <error-tag>bad-element</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <bad-element>ftp-server</bad-element>
        </error-info>
        <error-message>
            Element is not valid in the specified context.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

4.4.2.6. Example: key repeated in the same instance of the list node

The following example shows an invalid <get-config> request for a key that is repeated in the same instance of the list node.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
                <source>
                        <running/>
                </source>
                <filter>
                        <configure>
                                <router>
                                        <interface>
                                                <interface-name>abc</interface-name>
                                                <interface-name>def</interface-name>
                                        </interface>
                                </router>
                        </configure>
                </filter>
        </get-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>get-config</err-element>
        </error-info>
        <error-message>
            command failed - 'configure router interface "abc" "def"'
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

4.4.2.7. Example: retrieving the full configuration

The full configuration (equivalent to the CLI command admin display-config) can be retrieved using a <get-config> request:

  1. when the <filter> tag is not present
    For example:
    <get-config>
        <source>
             <running/>
        </source>
    </get-config>
  2. when only the <configure> tag is present inside a <filter> tag
    For example:
    <get-config>
         <source>
              <running/>
         </source>
         <filter>
              <configure/>
         </filter>
    </get-config>

4.5. XML content layer examples

The following examples can be used after a NETCONF session has been established including the exchange of the <hello> messages.

4.5.1. Example: checking NETCONF status

The following example shows a <get-config> request and response to check whether NETCONF is shut down on the router.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <get-config>
                <source> <running/> </source>
                <filter>
                        <configure>
                                <system>
                                        <netconf>
                                        </netconf>
                                </system>
                        </configure>
                </filter>
        </get-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:alcatel-lucent.com:sros:ns:yang:conf-r13">
            <system>
                <netconf>
                    <shutdown>false</shutdown>
                </netconf>
            </system>
        </configure>
    </data>
</rpc-reply>
]]>]]>

4.5.2. Example: creating a basic VPRN service

The following example shows a <edit-config> request and response to create a basic VPRN service.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
        <target>
            <running/>
        </target>
        <config>
            <configure>
                <service>
                    <vprn operation="create">
                        <service-id>200</service-id>
                        <customer>1</customer>
                    </vprn>
                </service>
            </configure>
        </config>
  </edit-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
</rpc-reply>
]]>]]>

4.5.3. Example: creating a VPRN service with a SAP

The following example shows a <edit-config> request and response to create a basic VPRN service with a SAP; the system creates the service/interface, but fails to create the SAP because the specified port encapsulation is invalid.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <edit-config>
                <target>
            <running/>
        </target>
        <config>
            <configure>
                <service>
                    <vprn operation="create">
                        <interface>
                            <ip-int-name>"test"</ip-int-name>
                            <sap>
                                <sap-id>"2/1/1"</sap-id>
                            </sap>
                        </interface>
                        <service-id>201</service-id>
                        <customer>1</customer>
                    </vprn>
                </service>
            </configure>
        </config>
  </edit-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <rpc-error>
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-info>
            <err-element>edit-config</err-element>
        </error-info>
        <error-message>
            command failed - 
'configure service vprn "201" customer 1 interface "test" sap "2/1/1"'
            MINOR: CLI SAP-id has an invalid port number or encapsulation value.
        </error-message>
    </rpc-error>
</rpc-reply>
]]>]]>

4.6. CLI content layer

When the CLI format is used at the NETCONF content layer, configuration changes and information retrieved are expressed as untagged (non-XML) CLI commands; for example, CLI script.

The script must be correctly ordered and has the same dependencies and behavior as CLI. The location of CR/LF (ENTER) within the CLI for an <edit-config> request is significant and affects the processing of the CLI commands, such as which CLI branch is considered the “working context”. In the following two examples the “working context” after the commands issued are different.

Example 1

exit all  [<-ENTER]
configure system time zone EST [<-ENTER]

Example 2

exit all [<-ENTER]
configure  [<-ENTER]
     system  [<-ENTER]
         time  [<-ENTER]
              zone EST [<-ENTER]

After example 1, the CLI working context is the root, and immediately sending “dst-zone CEST” would return an error. After example 2, the CLI working context is config>system>time and sending “dst-zone CEST” would work as expected.

Configuration changes made using NETCONF trigger the same “change” log events (for example, tmnxConfigCreate) as a normal CLI user doing the same changes.

The <with-defaults> tag, as defined in RFC 6243, is not supported in a CLI content layer request.

The operator can get a full configuration, including defaults for a CLI content layer, using an empty <cli-info-detail>. The full configuration (equivalent to the CLI command admin display-config [detail]) can be obtained using a <get-config> request in a CLI content layer format with an empty <cli-info> or <cli-info-detail> tag inside a <config-format-cli-block>. The <report-all> tag is not supported.

The following post-processing commands are ignored: "| match" (pipe match), "| count" (pipe count) and ">" (redirect to file). CLI ranges are not supported for any command; for example, show card [1..5].

See CLI content layer examples for more information.

4.7. CLI content layer examples

The following examples can be used after a NETCONF session has been established including the exchange of the <hello> messages.

4.7.1. Example: configuration change

The following example shows a configuration change request and response.

Note:

The exit all command is not required at the beginning of the CLI block; it is automatically assumed by the SR OS NETCONF server.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="104" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
     <edit-config>
     <target><running/></target>
         <config>
              <config-format-cli-block>
                   configure system
                       time zone EST
                       location over-here
                   exit all 
              </config-format-cli-block>
          </config>
    </edit-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
]]>]]>

4.7.2. Example: retrieving configuration information

The following example shows a <get-config> request and response to retrieve configuration information.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
         <source>
              <running/>
         </source>
         <filter>
             <config-format-cli-block>
                 <cli-info>router</cli-info>
                 <cli-info-detail>system login-control</cli-info-detail>
             </config-format-cli-block>
         </filter>
    </get-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <config-format-cli-block>
            <item>
                <cli-info>router</cli-info>
                <response>
----------------------------------------------
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
        interface "system"
            no shutdown
        exit
----------------------------------------------
                </response>
            </item>
            <item>
                <cli-info-detail>system login-control</cli-info-detail>
                <response>
----------------------------------------------
            ftp
                inbound-max-sessions 3
            exit
            ssh
                no disable-graceful-shutdown
                inbound-max-sessions 5
                outbound-max-sessions 5
                no ttl-security
            exit
            telnet
                no enable-graceful-shutdown
                inbound-max-sessions 5
                outbound-max-sessions 5
                no ttl-security
            exit
            idle-timeout 30
            no pre-login-message
            no motd
            login-banner
            no exponential-backoff
----------------------------------------------
                </response>
            </item>
        </config-format-cli-block>
    </data>
</rpc-reply>
]]>]]>

4.7.3. Example: retrieving full configuration information

The following example shows a <get-config> request and response to retrieve full configuration information.

Note:

The <cli-info-detail/> request can be used to get the fill configuration, including default settings.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
   <get-config>
          <source>
               <running/>
          </source>
          <filter>
              <config-format-cli-block>
                  <cli-info/>
              </config-format-cli-block>
          </filter>
    </get-config>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <config-format-cli-block>
            <item>
                <cli-info></cli-info>
                <response>
# TiMOS-C-0.0.I4301 cpm/x86_64 ALCATEL SR 7750 Copyright (c) 2000-2015 Alcatel-
Lucent.
# All rights reserved. All use subject to applicable license agreements.
# Built on Sun Jan 4 19:11:11 PST 2015 by builder in /rel0.0/I4301/panos/main
 
# Generated WED JAN 07 01:07:43 2015 UTC
 
exit all
configure
#--------------------------------------------------
echo "System Configuration"
#--------------------------------------------------
    system
        chassis-mode d
        dns
        exit
        load-balancing
            lsr-load-balancing lbl-ip
            system-ip-load-balancing
        exit
        netconf
            no shutdown
        exit
        snmp
            shutdown
            engineID "deadbeefdeadbeef"
        exit
        time
            ntp
                authentication-key 1 key "OAwgNUlbzgI" hash2 type des
                no shutdown
            exit
            sntp
                shutdown
            exit
            zone EST
        exit
        thresholds
            rmon
            exit
        exit
#--------------------------------------------------
echo "Cron Configuration"
#--------------------------------------------------
        cron
...
...
...
        exit
    exit
#--------------------------------------------------
echo "System Security Configuration"
#--------------------------------------------------
...
...
...
#--------------------------------------------------
echo "System Time NTP Configuration"
#--------------------------------------------------
    system
        time
            ntp
            exit
        exit
    exit
 
exit all
 
# Finished WED JAN 07 01:07:43 2015 UTC
----------------------------------------------
----------------------------------------------
                </response>
            </item>
        </config-format-cli-block>
    </data>
</rpc-reply>
]]>]]>

4.7.4. Example: <get> request

The following example shows a <get> request.

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get>
        <filter>
            <oper-data-format-cli-block>
                 <cli-show>system security ssh</cli-show>
            </oper-data-format-cli-block>
        </filter>
    </get>
</rpc>
]]>]]>

The following example shows the reply.

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data xmlns="urn:alcatel-lucent.com:sros:ns:yang:cli-content-layer-r13">
        <oper-data-format-cli-block>
            <item>
                <cli-show>system security ssh</cli-show>
                <response>
 
===============================================================================
SSH Server
===============================================================================
Administrative State      : Enabled
Operational State         : Up
Preserve Key              : Enabled
 
SSH Protocol Version 1    : Disabled
 
SSH Protocol Version 2    : Enabled
DSA Host Key Fingerprint  : ca:ce:37:90:49:7d:cc:68:22:b3:06:2c:11:cd:3c:8e
RSA Host Key Fingerprint  : 49:7c:21:97:42:35:83:61:06:95:cd:a8:78:4c:1e:76
 
-------------------------------------------------------------------------------
Connection                                Username
    Version Cipher                        ServerName  Status
-------------------------------------------------------------------------------
135.121.143.254                           admin
    2       aes128-cbc                    netconf     connected
-------------------------------------------------------------------------------
Number of SSH sessions : 1
===============================================================================
                </response>
            </item>
        </oper-data-format-cli-block>
    </data>
</rpc-reply>
]]>]]>