RUGGEDCOM NETCONF
Reference Guide
For RX1400, RX1500, RX1501, RX1510, RX1511,
RX1512, RX5000, MX5000, MX5000RE
06/2017
RC1065-EN-03
Preface
Introduction 1
NETCONF Capabilities and
Namespaces 2
NETCONF Sessions 3
Getting Data 4
Changing Configuration
Data 5
RUGGEDCOM ROX II Actions 6
Examples 7
NETCONF XML Elements 8
RUGGEDCOM NETCONF
Reference Guide
ii
Copyright © 2017 Siemens Canada Ltd
All rights reserved. Dissemination or reproduction of this document, or evaluation and communication of its contents, is not authorized
except where expressly permitted. Violations are liable for damages. All rights reserved, particularly for the purposes of patent application or
trademark registration.
This document contains proprietary information, which is protected by copyright. All rights are reserved. No part of this document may be
photocopied, reproduced or translated to another language without the prior written consent of Siemens Canada Ltd.
Disclaimer Of Liability
Siemens has verified the contents of this document against the hardware and/or software described. However, deviations between the product
and the documentation may exist.
Siemens shall not be liable for any errors or omissions contained herein or for consequential damages in connection with the furnishing,
performance, or use of this material.
The information given in this document is reviewed regularly and any necessary corrections will be included in subsequent editions. We
appreciate any suggested improvements. We reserve the right to make technical improvements without notice.
Registered Trademarks
RUGGEDCOM™ and ROS™ are trademarks of Siemens Canada Ltd.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a
world-wide basis.
Other designations in this manual might be trademarks whose use by third parties for their own purposes would infringe the rights of the
owner.
Open Source
RUGGEDCOM ROX II is based on Linux®. Linux® is made available under the terms of the GNU General Public License Version 2.0 [http://
www.gnu.org/licenses/gpl-2.0.html].
RUGGEDCOM NETCONF contains additional Open Source Software. For license conditions, refer to the associated License Conditions
document.
Security Information
Siemens provides products and solutions with industrial security functions that support the secure operation of plants, machines, equipment
and/or networks. They are important components in a holistic industrial security concept. With this in mind, Siemens' products and solutions
undergo continuous development. Siemens recommends strongly that you regularly check for product updates.
For the secure operation of Siemens products and solutions, it is necessary to take suitable preventive action (e.g. cell protection concept) and
integrate each component into a holistic, state-of-the-art industrial security concept. Third-party products that may be in use should also be
considered. For more information about industrial security, visit http://www.siemens.com/industrialsecurity.
To stay informed about product updates as they occur, sign up for a product-specific newsletter. For more information, visit http://
support.automation.siemens.com.
Contacting Siemens
Address
Siemens Canada Ltd
Industry Sector
300 Applewood Crescent
Concord, Ontario
Canada, L4K 5C7
Telephone
Toll-free: 1 888 264 0006
Tel: +1 905 856 5288
Fax: +1 905 856 1995
E-mail
ruggedcom.info.i-ia@siemens.com
Web
www.siemens.com/ruggedcom
RUGGEDCOM NETCONF
Reference Guide
Table of Contents
iii
Table of Contents
Preface ............................................................................................................ ix
How This Guide Is Organized ............................................................................................................... ix
Alerts .................................................................................................................................................. x
Related Documents .............................................................................................................................. x
Accessing Documentation ..................................................................................................................... x
Training .............................................................................................................................................. xi
Customer Support ............................................................................................................................... xi
Chapter 1
Introduction ..................................................................................................... 1
1.1What is NETCONF? ........................................................................................................................ 1
1.2What Can NETCONF Do? ............................................................................................................... 3
1.3Who Should Use This Guide ........................................................................................................... 3
1.4Supported IETF RFCs ..................................................................................................................... 3
1.5Sample NETCONF sessions ............................................................................................................ 3
1.5.1Sample Session: Getting Data ............................................................................................. 4
1.5.2Sample Session: Performing an Action ................................................................................. 6
1.5.3Sample Session: Editing Data .............................................................................................. 9
Chapter 2
NETCONF Capabilities and Namespaces ........................................................... 15
2.1IETF Capabilities .......................................................................................................................... 15
2.2Vendor-Defined Capabilities ......................................................................................................... 17
2.3IETF Namespaces ........................................................................................................................ 17
2.4Vendor-Defined Namespaces ....................................................................................................... 18
2.5RUGGEDCOM Namespaces ........................................................................................................... 18
2.6Viewing the Capabilities on a Device ............................................................................................ 20
Chapter 3
NETCONF Sessions .......................................................................................... 23
3.1Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF ......................................................... 23
3.2Connecting to the NETCONF Service ............................................................................................ 23
3.3Saying Hello ............................................................................................................................... 24
3.3.1RUGGEDCOM ROX II NETCONF <hello> Message ................................................................. 25
3.4Closing the Session ..................................................................................................................... 26
Table of Contents
RUGGEDCOM NETCONF
Reference Guide
iv
3.5Killing a Session .......................................................................................................................... 26
Chapter 4
Getting Data ................................................................................................... 29
4.1Using the <get> Command .......................................................................................................... 29
4.2Using the <get-config> Command ................................................................................................ 30
4.3Using XPaths with <get> and <get-config> ................................................................................... 31
4.4Getting Information for a Specific Object ...................................................................................... 33
4.4.1Specifying Objects with Hierarchical XML Elements ............................................................. 33
4.4.2Specifying Objects with XPaths ......................................................................................... 34
4.5Getting Default Values ................................................................................................................ 34
4.6Getting Data Models from the Device ........................................................................................... 35
4.6.1Getting Schemas from the Device ..................................................................................... 36
4.6.2Getting YIN and YANG Files from the Device ...................................................................... 37
4.6.3Using pyang .................................................................................................................... 38
4.6.3.1Using the Text-Based Tree ...................................................................................... 39
Chapter 5
Changing Configuration Data .......................................................................... 41
5.1Changing Data in the Running Configuration ................................................................................ 41
5.2Changing Data in the Candidate Configuration .............................................................................. 42
5.2.1Locking Data Stores ......................................................................................................... 43
5.2.2Copying Data ................................................................................................................... 44
5.2.3Replacing Data ................................................................................................................. 46
5.2.4Deleting Data ................................................................................................................... 48
5.2.5Validating Changes .......................................................................................................... 50
5.2.6Committing Changes ........................................................................................................ 51
Chapter 6
RUGGEDCOM ROX II Actions ............................................................................ 53
6.1Admin Namespace Actions .......................................................................................................... 54
6.1.1snmp-discover .................................................................................................................. 55
6.1.2launch-upgrade ................................................................................................................ 55
6.1.3decline-upgrade ............................................................................................................... 56
6.1.4rollback-reboot ................................................................................................................. 56
6.1.5roxflash ........................................................................................................................... 57
6.1.6clear-all-alarms ................................................................................................................. 57
6.1.7acknowledge-all-alarms .................................................................................................... 57
6.1.8shutdown ........................................................................................................................ 58
6.1.9reboot ............................................................................................................................. 58
6.1.10set-system-clock ............................................................................................................. 58
RUGGEDCOM NETCONF
Reference Guide
Table of Contents
v
6.1.11restore-factory-defaults ................................................................................................... 59
6.1.12delete-logs ..................................................................................................................... 59
6.1.13install-files ..................................................................................................................... 59
6.1.14backup-files (Backup Files) .............................................................................................. 60
6.1.15full-configuration-save .................................................................................................... 60
6.1.16full-configuration-load .................................................................................................... 61
6.2Interfaces Namespace Actions ...................................................................................................... 61
6.2.1reset (Modem) ................................................................................................................. 62
6.2.2at (Modem) ..................................................................................................................... 62
6.2.3reset (Cellular Modem) ..................................................................................................... 63
6.2.4at (Cellular Modem) ......................................................................................................... 63
6.2.5reset (Serial Port) ............................................................................................................. 64
6.2.6clear-serial-port-stats ........................................................................................................ 64
6.2.7restart-serserver ............................................................................................................... 65
6.2.8reset-port (Switch Port) .................................................................................................... 65
6.2.9clear-port-stats (Switch Port) ............................................................................................. 66
6.2.10start-cable-test (Switch Port) ........................................................................................... 66
6.2.11clear-cable-stats-port (Switch Port) .................................................................................. 67
6.3Services Namespace Actions ........................................................................................................ 67
6.3.1ntp-status ........................................................................................................................ 67
6.3.2log (Link-Failover) ............................................................................................................ 68
6.3.3start-test (Link Failover) .................................................................................................... 68
6.3.4cancel-test (Link Failover) ................................................................................................. 69
6.3.5show-active-leases (DHCP Server) ...................................................................................... 69
6.4Switch Namespace Actions .......................................................................................................... 69
6.4.1clear-stp-stats (Switch) ..................................................................................................... 70
6.4.2flush-dynamic-rules (Switch) ............................................................................................. 70
6.4.3reset-all-switch-ports (Switch) ........................................................................................... 70
6.4.4clear-all-switch-stats (Switch) ............................................................................................ 71
6.4.5clear-cable-stats-all (Switch) .............................................................................................. 71
6.5Tunnel Namespace Actions .......................................................................................................... 71
6.5.1display-public-key (IPSEC) ................................................................................................. 72
6.5.2status (IPSEC) .................................................................................................................. 72
6.5.3install-certificate (IPSEC) ................................................................................................... 72
6.5.4install-ca-certificate (IPSEC) ............................................................................................... 73
6.5.5install-crl-file (IPSEC) ........................................................................................................ 74
6.5.6remove-ca-certificate (IPSEC) ............................................................................................. 75
6.5.7remove-certificate (IPSEC) ................................................................................................. 75
6.5.8remove-crl (IPSEC) ............................................................................................................ 76
Table of Contents
RUGGEDCOM NETCONF
Reference Guide
vi
Chapter 7
Examples ........................................................................................................ 77
7.1Getting the System Name ........................................................................................................... 80
7.2Getting the ROX Release ............................................................................................................. 80
7.3Getting the Chassis Status ........................................................................................................... 81
7.4Setting the System Clock ............................................................................................................. 81
7.5Acknowledging Alarms ................................................................................................................ 81
7.6Clearing All Alarms ..................................................................................................................... 82
7.7Viewing Alarms ........................................................................................................................... 82
7.8Restoring Factory Defaults ........................................................................................................... 82
7.9Changing the System Name by Locking and Committing ............................................................... 83
7.10Changing the System Name Directly ........................................................................................... 84
7.11Creating a Static VLAN .............................................................................................................. 85
7.12Assigning a PVID on a Port ........................................................................................................ 86
7.13Disabling Spanning Tree on a Specific Port .................................................................................. 87
7.14Configuring an IP Address on a Specific Port ............................................................................... 88
7.15Deleting an IP Address .............................................................................................................. 90
7.16Setting a Static Route ................................................................................................................ 91
7.17Disabling Spanning Tree Globally ............................................................................................... 92
7.18Retrieving all IP Addresses from the Running Configuration .......................................................... 94
7.19Retrieving the Active Routes on a Device .................................................................................... 94
7.20Configuring Static Multicast Routing on a Layer 3 Device ............................................................. 95
7.21Enabling Static Multicast Routing on a Layer 3 Device .................................................................. 96
7.22Retrieving Static Multicast Status on a Layer 3 Device .................................................................. 97
7.23Replacing an IP Address ............................................................................................................. 98
7.24Configuring a Port to Dynamically Obtain an IP Address ............................................................... 99
7.25Configuring OSPF Area and Network on a Layer 3 Device ........................................................... 100
7.26Enabling the OSPF Passive-Default Option ................................................................................. 102
7.27Configure an OSPF Non-Passive Port ......................................................................................... 103
7.28Configuring OSPF Parameters ................................................................................................... 104
7.29Enabling the OSPF redistribute-connected Option ...................................................................... 106
7.30Enabling OSPF on a Layer 3 Device .......................................................................................... 107
7.31Retrieving OSPF Status ............................................................................................................ 108
7.32Retrieving All Data from the Routing Namespace ....................................................................... 109
7.33Configuring DHCP Server ......................................................................................................... 109
7.34Configure the DHCP Server Port Listening for DHCP Client Requests ............................................. 110
7.35Enabling the DHCP Server Service ............................................................................................. 112
7.36Disabling an Ethernet Port ....................................................................................................... 113
7.37Enabling an Ethernet Port ........................................................................................................ 114
7.38Checking an IP Address on a Specific Port using the Interfaces Namespace ................................... 115
RUGGEDCOM NETCONF
Reference Guide
Table of Contents
vii
7.39Retreiving All Data From Running Database Including Default Values ........................................... 116
7.40Retreiving All Data From Running Database Including Default Tags and Values ............................. 116
7.41Changing a User's Password ..................................................................................................... 117
7.42Displaying the Status of the IPsec Service ................................................................................. 118
7.43Selecting a Certificate for an IPSec Tunnel ................................................................................ 118
7.44Installing a CA Certificate ......................................................................................................... 120
7.45Configuring a Signed CA Certificate .......................................................................................... 121
7.46Installing a Private Key to a Signed CA Certificate ...................................................................... 121
7.47Installing a CRL File ................................................................................................................. 122
7.48Removing a Certificate ............................................................................................................ 123
7.49Removing a CA certificate ........................................................................................................ 123
7.50Removing a CRL File ................................................................................................................ 124
Chapter 8
NETCONF XML Elements ................................................................................ 125
8.1]]>]]> ....................................................................................................................................... 125
8.2<close-session/> ........................................................................................................................ 126
8.3<commit> ................................................................................................................................. 126
8.4<copy-config> ........................................................................................................................... 127
8.5<data> ..................................................................................................................................... 127
8.6<discard-changes> .................................................................................................................... 128
8.7<edit-config> ............................................................................................................................ 128
8.8<error-info> .............................................................................................................................. 128
8.9<get-config> ............................................................................................................................. 129
8.10<hello> ................................................................................................................................... 129
8.11<kill-session> .......................................................................................................................... 131
8.12<lock> .................................................................................................................................... 131
8.13<ok/> ..................................................................................................................................... 132
8.14<rpc> ..................................................................................................................................... 132
8.15<rpc-error> ............................................................................................................................. 132
8.16<rpc-reply> ............................................................................................................................. 133
8.17<target> ................................................................................................................................. 134
8.18<unlock> ................................................................................................................................ 134
8.19<validate> .............................................................................................................................. 135
Table of Contents
RUGGEDCOM NETCONF
Reference Guide
viii
RUGGEDCOM NETCONF
Reference Guide
Preface
How This Guide Is Organized ix
Preface
This guide describes how to use RUGGEDCOM NETCONF – the Network Configuration Protocol – to manipulate
configuration data on RUGGEDCOM devices running RUGGEDCOM NETCONF v.
CONTENTS
•“How This Guide Is Organized”
•“Alerts”
•“Related Documents”
•“Accessing Documentation”
•“Training”
•“Customer Support”
How This Guide Is Organized
•Chapter1, Introduction introduces RUGGEDCOM NETCONF and demonstrates what a typical NETCONF session
with RUGGEDCOM NETCONF looks like. Read this section for a quick introduction to RUGGEDCOM NETCONF on
RUGGEDCOM NETCONF.
•Chapter2, NETCONF Capabilities and Namespaces describes the RUGGEDCOM NETCONF functions and data
models supported by RUGGEDCOM NETCONF. Read this section to learn about the RUGGEDCOM NETCONF
functions supported by RUGGEDCOM NETCONF.
•Chapter3, NETCONF Sessions describes how to connect to and communicate with a device with RUGGEDCOM
NETCONF. Read this section to learn about connecting to your device, responding to the device's initial
NETCONF message, locking and unlocking datastores, and signing off from the device.
•Chapter4, Getting Data describes how to retrieve configuration data from RUGGEDCOM NETCONF. Read this
section to learn how to retrieve individual configuration elements, subsections of configuration data, or the
entire configuration from the device.
•Chapter5, Changing Configuration Data describes how to change RUGGEDCOM NETCONF configuration data.
Read this section to learn how to set configuration data and perform actions.
•Chapter6, RUGGEDCOM ROX II Actions describes how to activate NETCONF actions on a device. Read this
section to learn how to activate NETCONF commands, such as rebooting and clearing statistics, on the device.
•Chapter7, Examples describes many examples of how to configure RUGGEDCOM NETCONF data. Read this
section to learn how to perform common network configuration tasks through RUGGEDCOM NETCONF.
•Chapter8, NETCONF XML Elements describes the XML elements unique to NETCONF commands. Read this
section to learn about the XML elements used to build NETCONF commands and for information on what the
elements mean when they are returned in a message from the server.
Preface
RUGGEDCOM NETCONF
Reference Guide
x Alerts
Alerts
The following types of alerts are used when necessary to highlight important information.
DANGER!
DANGER alerts describe imminently hazardous situations that, if not avoided, will result in death or
serious injury.
WARNING!
WARNING alerts describe hazardous situations that, if not avoided, may result in serious injury and/or
equipment damage.
CAUTION!
CAUTION alerts describe hazardous situations that, if not avoided, may result in equipment damage.
IMPORTANT!
IMPORTANT alerts provide important information that should be known before performing a procedure
or step, or using a feature.
NOTE
NOTE alerts provide additional information, such as facts, tips and details.
Related Documents
Other documents that may be of interest include:
•RUGGEDCOM NETCONF Web Interface User Guide for the RUGGEDCOM RX1400
•RUGGEDCOM NETCONF Web Interface User Guide for the RUGGEDCOM RX1500/RX1501/RX1510/RX1511/
RX1512
•RUGGEDCOM NETCONF Web Interface User Guide for the RUGGEDCOM RX5000
•RUGGEDCOM NETCONF CLI User Guide for the RUGGEDCOM RX1400
•RUGGEDCOM NETCONF CLI User Guide for the RUGGEDCOM RX1500/RX1501/RX1510/RX1511/RX1512
•RUGGEDCOM NETCONF CLI User Guide for the RUGGEDCOM RX5000
Most documents are available on Siemens' Industry Online Support portal [https://support.industry.siemens.com]
or mobile application. For all others, contact a Siemens Sales representative or Siemens Customer Support.
Accessing Documentation
The latest user documentation for RUGGEDCOM NETCONF v is available online at www.siemens.com/ruggedcom.
To request or inquire about a user document, contact Siemens Customer Support.
RUGGEDCOM NETCONF
Reference Guide
Preface
Training xi
Training
Siemens offers a wide range of educational services ranging from in-house training of standard courses on
networking, Ethernet switches and routers, to on-site customized courses tailored to the customer's needs,
experience and application.
Siemens' Educational Services team thrives on providing our customers with the essential practical skills to make
sure users have the right knowledge and expertise to understand the various technologies associated with critical
communications network infrastructure technologies.
Siemens' unique mix of IT/Telecommunications expertise combined with domain knowledge in the utility,
transportation and industrial markets, allows Siemens to provide training specific to the customer's application.
For more information about training services and course availability, visit www.siemens.com/ruggedcom or
contact a Siemens Sales representative.
Customer Support
Customer support is available 24 hours, 7 days a week for all Siemens customers. For technical support or general
information, contact Siemens Customer Support through any of the following methods:
Online
Visit http://www.siemens.com/automation/support-request to submit a Support Request (SR) or check on the status of an
existing SR.
Telephone
Call a local hotline center to submit a Support Request (SR). To locate a local hotline center, visit http://
www.automation.siemens.com/mcms/aspa-db/en/automation-technology/Pages/default.aspx.
Mobile App
Install the Industry Online Support app by Siemens AG on any Android, Apple iOS or Windows mobile device and be able to:
• Access Siemens' extensive library of support documentation, including FAQs and manuals
• Submit SRs or check on the status of an existing SR
• Contact a local Siemens representative from Sales, Technical Support, Training, etc.
• Ask questions or share knowledge with fellow Siemens customers and the support community
Preface
RUGGEDCOM NETCONF
Reference Guide
xii Customer Support
RUGGEDCOM NETCONF
Reference Guide
Chapter 1
Introduction
What is NETCONF? 1
Introduction
Welcome to the RUGGEDCOM NETCONF Reference Guide. This document aims to describe the Network
Configuration Protocol (NETCONF) and how it can be used to control the configuration of a device running
RUGGEDCOM ROX II.
All versions of RUGGEDCOM ROX II supports NETCONF sessions.
CONTENTS
•Section1.1, “What is NETCONF?”
•Section1.2, “What Can NETCONF Do?”
•Section1.3, “Who Should Use This Guide”
•Section1.4, “Supported IETF RFCs”
•Section1.5, “Sample NETCONF sessions”
Section1.1
What is NETCONF?
The Network Configuration Protocol (NETCONF) is a network configuration protocol developed by the Internet
Engineering Task Force (IETF). NETCONF provides functions to download, upload, change, and delete the
configuration data on network devices. Devices running the RUGGEDCOM ROX II operating system also support
the ability to collect data and perform direct actions on the device, such as rebooting the device, clearing statistics,
and restarting services.
NETCONF actions and data are described using Extensible Markup Language (XML). NETCONF uses a collection
of XML elements to identify functions and operations. Configuration data is represented as a hierarchy of XML
elements that describe the path to a configurable setting and its data.
The NETCONF protocol can be thought of as having four conceptual layers:
Chapter 1
Introduction
RUGGEDCOM NETCONF
Reference Guide
2 What is NETCONF?
Figure1:NETCONF Concepts and Implementation
• The Transport Protocol layer provides connectivity between the device and the NETCONF client. RUGGEDCOM
ROX II supports the use of Secure Shell (SSH) for the connection.
• The Remote Procedure Call layer represents NETCONF requests and responses. Requests from the client to the
device are wrapped within <rpc> elements in the XML query text. Responses from the device to the client are
wrapped within <rpc-reply> elements in the XML response text.
• The Operations layer represents actions and functions performed on the RUGGEDCOM ROX II server. The
operations available for use are defined by the NETCONF capabilities advertised by the device.
• The Content layer represents the configuration data on the device. NETCONF can query, manipulate,
and monitor the configuration data on the device. The configuration data is defined by the RUGGEDCOM
namespaces. The configuration data is structured in NETCONF in the same way as it is in the RUGGEDCOM ROX
II web interface and command line interface (CLI).
The NETCONF protocol is defined in several Internet Engineering Task Force Request For Comment (RFC)
documents. It is not necessary to read the RFCs to use NETCONF with devices, but this guide provides links to the
RFCs for those interested in the design details of the NETCONF protocol.
For more general background information on NETCONF, refer to the Internet Engineering Task Force RFC 6241
[http://tools.ietf.org/html/rfc6241]. This RFC, published in June 2011, is the current main defining document for
the NETCONF protocol.
For historical interest, refer to Internet Engineering Task Force RFC 4741 [http://tools.ietf.org/html/rfc4741]. This
RFC, published in 2006, contains the initial definition of the NETCONF protocol. Note that RFC 6241 obsoletes RFC
4741.
Several additional RFCs define the NETCONF capabilities and namespaces. Links to these documents appear
throughout Chapter2, NETCONF Capabilities and Namespaces, where this guide discusses the capabilities and
namespaces supported by devices.
RUGGEDCOM NETCONF
Reference Guide
Chapter 1
Introduction
What Can NETCONF Do? 3
Section1.2
What Can NETCONF Do?
NETCONF provides an easy-to-use application programming interface (API) for RUGGEDCOM NETCONF. It provides
the ability to view and manipulate configuration data, monitor device status, and perform device management
commands.
Use NETCONF to develop custom configuration management tools and applications, such as:
• shell scripts for common device management tasks
• custom device management interfaces
• custom configuration management applications and databases
• integrating devices into existing configuration management applications and databases
Section1.3
Who Should Use This Guide
This guide is for network administrators and programmers tasked with the configuration management of network
devices.
Readers should be familiar with the following:
• general use and function of the RUGGEDCOM ROX II software.
• network design and network management concepts and tasks.
• using Secure Shell (SSH) to connect to RUGGEDCOM ROX II.
• how to create well-formed and valid XML documents.
Section1.4
Supported IETF RFCs
RUGGEDCOM ROX II supports the following IETF Request For Comments (RFC):
•Internet Engineering Task Force RFC 5277 [http://tools.ietf.org/html/rfc5277]
•Internet Engineering Task Force RFC 5717 [http://tools.ietf.org/html/rfc5217]
•Internet Engineering Task Force RFC 6021 [http://tools.ietf.org/html/rfc6021]
•Internet Engineering Task Force RFC 6022 [http://tools.ietf.org/html/rfc6022]
•Internet Engineering Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241]
•Internet Engineering Task Force RFC 6243 [http://tools.ietf.org/html/rfc6243]
Section1.5
Sample NETCONF sessions
This section provides a walk-through of three typical types of NETCONF sessions:
Chapter 1
Introduction
RUGGEDCOM NETCONF
Reference Guide
4 Sample Session: Getting Data
•Section1.5.1, “Sample Session: Getting Data” describes a simple session where you connect to a device, get
data from the device, and close the session
•Section1.5.2, “Sample Session: Performing an Action” describes a simple session where you connect to a device,
perform an action on the device, and close the session
•Section1.5.3, “Sample Session: Editing Data” describes a more complex session where you connect to a device,
prepare the device data-stores for editing, edit the data, commit the data, and close the session
Each sample provides an overview of the primary steps in the session, a schematic illustration of the primary steps,
and the actual NETCONF code sent to and received from the device.
Read these sections to become familiar with the general flow of typical NETCONF sessions. Also, review these
sections to become familiar with examples of working NETCONF XML code. The text in these examples can be
copied and tested on an operating RUGGEDCOM NETCONF device.
The XML code in these examples has been formatted for legibility. Line breaks and white space have been added
to the XML text to make the lines easier to read and to show the element hierarchy. When sending XML text to the
device, the line breaks and whitespace are not required. You can send XML text to the device in a single line, as
long as the XML is well-formed.
Text returned from the device has also been formatted for legibility. The text returned from the device typically
appears in a single line, without whitespace between the elements.
In these examples, the <hello> message from the device has been truncated for clarity.
CONTENTS
•Section1.5.1, “Sample Session: Getting Data”
•Section1.5.2, “Sample Session: Performing an Action”
•Section1.5.3, “Sample Session: Editing Data”
Section1.5.1
Sample Session: Getting Data
To retrieve data from a device, do the following:
Figure2:Getting Data
RUGGEDCOM NETCONF
Reference Guide
Chapter 1
Introduction
Sample Session: Getting Data 5
Basic Steps
1. Connect to the device and exchange <hello> messages.
2. Issue <get> or <get-config> commands to retrieve data from the device. You determine the data to
retrieve by stating the RUGGEDCOM namespace from which you want to retrieve the data, and then stating
the path through the data model to the information you want to return.
3. Close the session. Closing the session ensures that the NETCONF session closes gracefully without incomplete
processes or locked datastores.
Detailed Steps
1. Log in to the device via ssh:
$ ssh {user}@{ipAddress} -p 830 -s netconf
•{user} is a user name on the device. Typically, the user should be assigned the administrative user role.
•{ipAddress} is an address on the device listening for NETCONF activity. The -p parameter indicates the
port listening for NETCONF activity. Port 830 is the default NETCONF port. The -s parameter indicates the
subsystem. All NETCONF communication must be identified with -s netconf. You can configure the IP
addresses and ports on which RUGGEDCOM NETCONF listens for NETCONF. For more information, refer to
Section3.1, “Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF”.
The device responds with its <hello> statement:
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
.
.
.
</capabilities>
<session-id>797</session-id>
</hello>]]>]]>
2. Respond to the device with the client's <hello> statement. The client's <hello> statement can describe the
client's capabilities, or it can respond with just the base NETCONF capability. This example shows the minimal
<hello> response:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>]]>]]>
3. Issue an <rpc> request to retrieve data from the device:
<rpc message-id="1001" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<admin xmlns="http://ruggedcom.com/ns/rmf_admin">
<system-name></system-name>
</admin>
</filter>
</get-config>
</rpc>]]>]]>
Chapter 1
Introduction
RUGGEDCOM NETCONF
Reference Guide
6 Sample Session: Performing an Action
• All commands must be enclosed within <rpc> tags. The message-id attribute is not required but is
recommended. The message-id attribute is returned in the device response, allowing you to match
responses with requests.
• The <source> element indicates the datastore from which we are requesting data. In this example we are
requesting data from the running configuration database.
• The <filter> element encloses the data model tags. The type="subtree" attribute is mandatory.
• The <admin> element is the root of the RUGGEDCOM admin namespace. Within the <admin> element,
additional elements navigate down to the desired element. In this example, we are navigating to admin/
system-name in the RUGGEDCOM NETCONF data model.
• The ]]>]]> string indicates the end of the NETCONF message. Each NETCONF message must end with
]]>]]>
The device responds with the requested data:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1001">
<data>
<admin xmlns="http://ruggedcom.com/ns/rmf_admin">
<system-name>Substation Ethernet Switch 2</system-name>
</admin>
</data>
</rpc-reply>]]>]]>
• The <rpc-reply> element contains the response. Notice the message-id attribute returned with the
<rpc-reply> element; it corresponds to the <message-id> sent in the <rpc> request.
4. After receiving the data, close the session:
<rpc message-id="1002" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>]]>]]>
The device responds with the following and closes the session:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1002">
<ok/>
</rpc-reply>]]>]]
Section1.5.2
Sample Session: Performing an Action
To perform an action on a device, do the following:
RUGGEDCOM NETCONF
Reference Guide
Chapter 1
Introduction
Sample Session: Performing an Action 7
Figure3:Performing an Action
Basic Steps
1. Connect to the device and exchange <hello> messages.
2. Issue an <rpc> command with the action to perform. The <rpc> request must contain the <action>
element referring to the action namespace. You determine the action to perform by stating the RUGGEDCOM
namespace where the command is found, and then stating the path through the data model to the
command.
3. Close the session. Closing the session ensures that the NETCONF session closes gracefully without incomplete
processes or locked datastores.
Detailed Steps
1. Log in to the device via ssh:
$ ssh {user}@{ipAddress} -p 830 -s netconf
•{user} is a user name on the device. Typically, the user should be assigned the administrative user role.
•{ipAddress} is an address on the device listening for NETCONF activity. The -p parameter indicates the
port listening for NETCONF activity. Port 830 is the default NETCONF port. The -s parameter indicates the
subsystem. All NETCONF communication must be identified with -s NETCONF. You can configure the IP
addresses and ports on which RUGGEDCOM NETCONF listens for NETCONF. For more information, refer to
Section3.1, “Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF”.
The device responds with its <hello> statement:
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
.
.
.
</capabilities>
<session-id>797</session-id>
</hello>]]>]]>
Chapter 1
Introduction
RUGGEDCOM NETCONF
Reference Guide
8 Sample Session: Performing an Action
2. Respond to the device with the client's <hello> statement. The client's <hello> statement can describe the
client's capabilities, or it can respond with just the base NETCONF capability. This example shows the minimal
<hello> response:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>]]>]]>
3. Issue an <rpc> request with the action to perform:
<rpc message-id="1005" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="http://tail-f.com/ns/netconf/actions/1.0">
<data>
<admin xmlns="http://ruggedcom.com/ns/rmf_admin">
<set-system-clock>
<time>2012-03-26 18:00:00</time>
</set-system-clock>
</admin>
</data>
</action>
</rpc>]]>]]>
• All commands must be enclosed within <rpc> tags. The message-id attribute is not required but is
recommended. The message-id attribute is returned in the device response, allowing you to match
responses with requests.
• The <action> element indicates that this request is to perform an action on the device. The <action>
element must refer to the action namespace in the xmlns attribute.
• The <admin> element is the root of the RUGGEDCOM admin namespace. Within the <admin> element,
additional elements navigate down to the desired command. In this example, we are navigating to admin/
set-system-clock in the RUGGEDCOM NETCONF data model.
• The ]]>]]> string indicates the end of the NETCONF message. Each NETCONF message must end with
]]>]]>
The device responds with the results of the command:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1005">
<data>
<admin xmlns='http://ruggedcom.com/ns/rmf_admin'>
<set-system-clock>
<system-clock>Mon Mar 26 18:00:01 2012</system-clock>
</set-system-clock>
</admin>
</data>
</rpc-reply>]]>]]>
• The <rpc-reply> element contains the response. Notice the message-id attribute returned with the
<rpc-reply> element; it corresponds to the <message-id> sent in the <rpc> request.
4. After receiving the response, close the session:
<rpc message-id="1006" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>]]>]]>
The device responds with the following and closes the session:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1006">
RUGGEDCOM NETCONF
Reference Guide
Chapter 1
Introduction
Sample Session: Editing Data 9
<ok/>
</rpc-reply>]]>]]
Section1.5.3
Sample Session: Editing Data
To edit data on the device, do the following:
<hello>
Say <hello>
<close-session> *
<edit-config>
<validate>
<commit>
<unlock> datastores
<xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
</xml>
<xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
</xml>
<discard-changes/>
<xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
<xml>data</xml>
</xml>
<lock> datastores
Figure4:Session Schematic: Editing Data
Basic Steps
1. Connect to the device and exchange <hello> messages.
2. Issue an <rpc> command to discard changes. Discarding changes removes changes that are incomplete and
not yet committed to the datastores. It is strongly recommended that you discard any such stray changes
before making changes to the device configuration. Discarding changes helps to ensure that you are making
changes to a known state of the configuration.
3. Issue an <rpc> command to lock the candidate and running datastores. Locking the datastores prevents
other users in other sessions from editing the database while the NETCONF session is working with it. It is
strongly recommended that you lock the datastores before making changes to the device configuration.
Chapter 1
Introduction
RUGGEDCOM NETCONF
Reference Guide
10 Sample Session: Editing Data
4. Issue an <rpc> command to edit the configuration. You determine which data to edit by stating the
RUGGEDCOM namespace where the data to be changed is found, and then stating the path through the data
model to the items to change.
5. Issue an <rpc> command to validate the changes. Validating the changes ensures that the syntax of the
changes is correct.
6. Issue an <rpc> command to commit the changes. Committing the changes applies the changes to the
running configuration, making the changes take effect on the running device.
7. Issue an <rpc> command to unlock the datastores. Unlock the datastores to allow other users in other
sessions to modify the configuration data.
8. Close the session. Closing the session ensures that the NETCONF session closes gracefully without incomplete
processes or locked datastores.
Detailed Steps
The following procedure provides more details:
1. Log in to the device via ssh:
$ ssh {user}@{ipAddress} -p 830 -s netconf
•{user} is a user name on the device. Typically, the user should be assigned the administrative user role.
•{ipAddress} is an address on the device listening for NETCONF activity. The -p parameter indicates the
port listening for NETCONF activity. Port 830 is the default NETCONF port. The -s parameter indicates the
subsystem. All NETCONF communication must be identified with -s NETCONF. You can configure the IP
addresses and ports on which RUGGEDCOM NETCONF listens for NETCONF. For more information, refer to
Section3.1, “Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF”.
The device responds with its <hello> statement:
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
.
.
.
</capabilities>
<session-id>797</session-id>
</hello>]]>]]>
2. Respond to the device with the client's <hello> statement. The client's <hello> statement can describe the
client's capabilities, or it can respond with just the base NETCONF capability. This example shows the minimal
<hello> response:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>]]>]]>
3. Issue an <rpc> request to discard configuration changes:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1012">
<discard-changes/>
</rpc>
]]>]]>
RUGGEDCOM NETCONF
Reference Guide
Chapter 1
Introduction
Sample Session: Editing Data 11
• The <discard-changes> command discards any uncommitted changes that may be present in the
configuration. It is recommended that you perform this step to ensure that the changes you make are made
to a known state of the configuration.
The device responds with the following:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1012">
<ok/>
</rpc-reply>]]>]]>
Any uncommitted changes are removed from the configuration.
4. Issue an <rpc> request to lock the running configuration:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1010">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
]]>]]>
• All commands must be enclosed within <rpc> tags. The message-id attribute is not required but is
recommended. The message-id attribute is returned in the device response, allowing you to match
responses with requests.
• The <lock> element indicates that this request is to lock a configuration.
• The <target> element specifies the configuration to lock. In this <rpc>, the lock target is the
<running> configuration.
• The ]]>]]> string indicates the end of the NETCONF message. Each NETCONF message must end with
]]>]]>
The device responds with the following:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1010">
<ok/>
</rpc-reply>]]>]]>
The running configuration is now locked.
5. Issue an <rpc> request to lock the candidate configuration:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1011">
<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>]]>]]>
The device responds with the following:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1011">
<ok/>
</rpc-reply>]]>]]>
The candidate configuration is now locked.
6. Issue an <rpc> request to edit the candidate configuration:
Chapter 1
Introduction
RUGGEDCOM NETCONF
Reference Guide
12 Sample Session: Editing Data
<rpc message-id="1014" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<config>
<admin xmlns="http://ruggedcom.com/ns/rmf_admin">
<system-name>Substation Ethernet: Switch 01</system-name>
</admin>
</config>
</edit-config>
</rpc>]]>]]>
• The <edit-config> element indicates that this request is to edit the configuration.
• The <target> element specifies the configuration to be edited. In this example, the <candidate>
configuration is to be edited.
• The <config> element contains the path to the value to be edited.
• The <admin> element specifies that the value to be edited is in the RUGGEDCOM admin namespace. In this
example, the <system-name> value is being edited.
The device responds with the following:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1014">
<ok/>
</rpc-reply>]]>]]>
The edit is applied to the <candidate> configuration.
7. Issue an <rpc> request to validate the candidate configuration:
<rpc message-id="1015" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>]]>]]>
• The <validate> element indicates that this request is to validate a specified configuration.
• The <source> element specifies the configuration to be validated. In this example, the <candidate>
configuration is to be validated.
The device responds with the following:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1015">
<ok/>
</rpc-reply>]]>]]>
The candidate configuration is validated and its syntax is found to be correct. Had there been syntax errors,
the device would return a message with <error-type>, <error-tag>, <error-severity>, <error-
path>, <error-info>, and <bad-element> elements to describe and identify the syntax error.
8. Issue an <rpc> request to commit the changes:
<rpc message-id="1016" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>]]>]]>
The device responds with the following:
RUGGEDCOM NETCONF
Reference Guide
Chapter 1
Introduction
Sample Session: Editing Data 13
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1016">
<ok/>
</rpc-reply>]]>]]>
The changes made to the <candidate> configuration are committed and promoted to the <running>
configuration.
9. Issue an <rpc> request to unlock the candidate configuration:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1017">
<unlock>
<target>
<candidate/>
</target>
</unlock>
</rpc>]]>]]>
The device responds with the following:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1017">
<ok/>
</rpc-reply>]]>]]>
10. Issue an <rpc> request to unlock the running configuration:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1018">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>]]>]]>
The device responds with the following:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1018">
<ok/>
</rpc-reply>]]>]]>
11. Close the session:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1019" >
<close-session/>
</rpc>]]>]]>
The device responds with the following and closes the session:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1019">
<ok/>
</rpc-reply>]]>]]
Chapter 1
Introduction
RUGGEDCOM NETCONF
Reference Guide
14 Sample Session: Editing Data
RUGGEDCOM NETCONF
Reference Guide
Chapter 2
NETCONF Capabilities and Namespaces
IETF Capabilities 15
NETCONF Capabilities and
Namespaces
This section describes the NETCONF capabilities supported by RUGGEDCOM ROX II.
NETCONF capabilities describe the functions and namespaces supported by a NETCONF peer. When you connect
to the NETCONF service on a device, the device advertises its capabilities in a <hello> message.
Capabilities and namespaces are reported within <capability> elements in the <hello> message. A
<capability> element describes a capability or a namespace:
• a capability is a function or service provided by the device. For example, the ability to commit changes to the
database or to lock a portion of the database are capabilities.
• a namespace is a definition of data elements. For example, the definition of standard Internet address elements
and the definition of NETCONF configuration parameters are namespaces.
NETCONF supports both standard IETF NETCONF capabilities and vendor-defined capabilities that are unique to
the product platform.
NETCONF uses namespaces that define the NETCONF configuration data model and that support various
capabilities.
CONTENTS
•Section2.1, “IETF Capabilities”
•Section2.2, “Vendor-Defined Capabilities”
•Section2.3, “IETF Namespaces”
•Section2.4, “Vendor-Defined Namespaces”
•Section2.5, “RUGGEDCOM Namespaces”
•Section2.6, “Viewing the Capabilities on a Device”
Section2.1
IETF Capabilities
The following are the standard IETF capabilities supported by NETCONF. These capabilities define most of the
actions that can be performed through NETCONF on a device.
Capabilities Description
<capability>urn:ietf:params:netconf:base:1.0</capability> This is the base NETCONF capability. When replying to the <hello>
message from a device, the NETCONF client must respond with at
least this capability.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
Chapter 2
NETCONF Capabilities and Namespaces
RUGGEDCOM NETCONF
Reference Guide
16 IETF Capabilities
Capabilities Description
<capability>urn:ietf:params:netconf:capability:writable-
running:1.0</capability>
Supports writing to the running configuration: you can update
configuration data in the running configuration.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
<capability>urn:ietf:params:netconf:capability:candidate:1.0</
capability>
Supports a candidate configuration: you can make changes to a
candidate configuration, validate and review the changes, and then
commit the candidate to make it the running configuration.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
<capability>urn:ietf:params:netconf:capability:confirmed-
commit:1.0</capability>
Supports the confirmed commit operation: you can require that a
commit be confirmed before a candidate configuration is promoted
to become the running configuration.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
<capability>urn:ietf:params:netconf:capability:XPath:1.0</
capability>
Supports the use of XPath expressions: you can used XPath
expressions in the <filter> element to define the path to the
configuration item to be retrieved or set.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
<capability>urn:ietf:params:netconf:capability:url:1.0?
scheme=ftp,sftp,file</capability>
Supports file transfer for configuration data: you can upload or
download configuration data as a file through a specified protocol.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
<capability>urn:ietf:params:netconf:capability:validate:1.0</
capability>
Supports the validate operation: you can validate a specified
configuration for syntax errors.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
<capability>urn:ietf:params:netconf:capability:rollback-on-
error:1.0</capability>
Supports the rollback-on-error operation: you can require the
configuration to roll back to its previous state if a commit fails.
For more information on this capability, see Internet Engineering
Task Force RFC 6241 [http://tools.ietf.org/html/rfc6241].
<capability>urn:ietf:params:netconf:capability:notification:1.0</
capability>
Supports the notification operation: you can have the NETCONF
server advise a NETCONF client of changes to the configuration data
or device state.
For more information on this capability, see Internet Engineering
Task Force RFC 5277 [http://tools.ietf.org/html/rfc5277].
<capability>urn:ietf:params:netconf:capability:interleave:1.0</
capability>
Supports the interleave capability: the device handles NETCONF
notification messages and other NETCONF operations
asynchronously.
For more information on this capability, see Internet Engineering
Task Force RFC 5277 [http://tools.ietf.org/html/rfc5277].
<capability>urn:ietf:params:netconf:capability:partial-lock:1.0</
capability>
Supports the partial-lock capability: you can lock a specified portion
of the configuration database for updating.
For more information on this capability, see Internet Engineering
Task Force RFC 5717 [http://tools.ietf.org/html/rfc5717].
<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?
basic-mode=trim&also-supported=report-all-tagged</capability>
Supports the with-defaults capability: you can control how the
NETCONF server reports default data in the data model.
For more information on this capability, see Internet Engineering
Task Force RFC 6243 [http://tools.ietf.org/html/rfc6243].
RUGGEDCOM NETCONF
Reference Guide
Chapter 2
NETCONF Capabilities and Namespaces
Vendor-Defined Capabilities 17
Section2.2
Vendor-Defined Capabilities
The following capabilities are provided by the vendor of the development tools used to create the RUGGEDCOM
NETCONF software. These vendor-defined capabilities complement and extend the standard IETF capabilities.
Capabilities Description
<capability>http://tail-f.com/ns/netconf/with-defaults/1.0</
capability>
This vendor-defined capability extends the standard IETF with-
defaults capability.
<capability>http://tail-f.com/ns/netconf/actions/1.0</
capability>
This vendor-defined capability supports the execution of actions on
the device: you can issue direct commands through NETCONF, such
as reboot, clear-all-alarms, restore-factory-defaults, and others.
<capability>http://tail-f.com/ns/netconf/commit/1.0</
capability>
This vendor-defined capability extends the commit capability: you
can make changes to a candidate configuration and commit the
changes to promote them to the running configuration.
<capability>http://tail-f.com/yang/common-monitoring?
module=tailf-common-monitoring&revision=2013-06-14</
capability>
<capability>http://tail-f.com/yang/confd-monitoring?
module=tailf-confd-monitoring&revision=2013-06-14</
capability>
<capability>http://tail-f.com/yang/netconf-monitoring?
module=tailf-netconf-monitoring&revision=2012-06-14</
capability>
These vendor-defined capabilities support NETCONF monitoring on
the device.
Section2.3
IETF Namespaces
NETCONF uses several namespaces to data types and configuration data models. Some namespaces are associated
with and provide support for specific NETCONF capabilities.
The following are the standard IETF namespaces supported by NETCONF:
Capabilities Description
<capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-
inet-types&revision=2010-09-24</capability>
Defines data types for Internet addresses and related items.
For more information on this namespace, see Internet Engineering
Task Force RFC 6021 [http://tools.ietf.org/html/rfc6021].
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?
module=ietf-netconf-monitoring&revision=2010-10-04</capability>
Defines data types for NETCONF monitoring.
For more information on this namespace, see Internet Engineering
Task Force RFC 6022 [http://tools.ietf.org/html/rfc6022].
<capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?
module=ietf-yang-types&revision=2010-09-24</capability>
Defines data types for general YANG data types. YANG is the data
modeling language used to develop the RUGGEDCOM NETCONF
software.
For more information on this namespace, see Internet Engineering
Task Force RFC 6022 [http://tools.ietf.org/html/rfc6022].
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?
revision=2010-11-11&module=ietf-with-defaults</capability>
Defines items used by the with-defaults capability.
For more information on this namespace, see Internet Engineering
Task Force RFC 6243 [http://tools.ietf.org/html/rfc6243].
Chapter 2
NETCONF Capabilities and Namespaces
RUGGEDCOM NETCONF
Reference Guide
18 Vendor-Defined Namespaces
Section2.4
Vendor-Defined Namespaces
The following namespaces support vendor-defined NETCONF capabilities:
Namespace Description
<capability>http://tail-f.com/ns/netconf/with-defaults/1.0</
capability>
Supports and extends the IETF with-defaults capability.
<capability>http://tail-f.com/ns/netconf/actions/1.0</
capability>
Supports the vendor-defined actions capability.
<capability>http://tail-f.com/ns/netconf/commit/1.0</
capability>
Supports the vendor-defined commit capability.
Section2.5
RUGGEDCOM Namespaces
The RUGGEDCOM namespaces define the configuration data model on the device. Depending on the physical
configuration of your device, not all RUGGEDCOM namespaces may be present. For example, if your device does
not have switch interfaces, the switch namespace will not be present.
•<capability>http://ruggedcom.com/ns/rmf?module=rmf&revision=2012-11-28</capability>
The parent container for all RUGGEDCOM ROX II configuration data.
•<capability>http://ruggedcom.com/ns/rmf_admin?module=rmf_admin&revision=2012-11-28</capability>
The admin namespace contains administrative configuration data. The admin namespace is the equivalent
of the admin menu level in the RUGGEDCOM ROX II web user interface, and the admin command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_chassis?module=rmf_chassis&revision=2012-11-28</
capability>
The chassis namespace contains chassis configuration data. The chassis namespace is the equivalent of
the chassis menu level in the RUGGEDCOM ROX II web user interface, and the chassis command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_crossbow?module=rmf_crossbow&revision=2013-10-10</
capability>
The crossbow namespace contains CROSSBOW configuration data. The crossbow namespace is the equivalent of
the apps/crossbow menu level in the RUGGEDCOM ROX II web user interface, and the crossbow command in
the RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_elan?module=rmf_elan&revision=2012-11-28</capability>
The elan namespace contains ELAN configuration data. The elan namespace is the equivalent of the apps/elan
menu level in the RUGGEDCOM ROX II web user interface, and the elan command in the RUGGEDCOM ROX II
command line interface.
•<capability>http://ruggedcom.com/ns/rmf_events?module=rmf_events&revision=2012-11-28</capability>
The events namespace contains event configuration data.
•<capability>http://ruggedcom.com/ns/rmf_global?module=rmf_global&revision=2012-11-28</capability>
The global namespace contains global configuration data. The global namespace is the equivalent of the global
menu level in the RUGGEDCOM ROX II web user interface, and the global command in the RUGGEDCOM ROX
II command line interface.
RUGGEDCOM NETCONF
Reference Guide
Chapter 2
NETCONF Capabilities and Namespaces
RUGGEDCOM Namespaces 19
•<capability>http://ruggedcom.com/ns/rmf_if?module=rmf_if&revision=2012-11-28</capability>
The interface namespace contains interface configuration data. The interface namespace is the equivalent of
the interface menu level in the RUGGEDCOM ROX II web user interface, and the interface command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_ifs?module=rmf_ifs&revision=2012-11-28</capability>
The interfaces namespace contains interfaces read-only data. The interface namespace is the equivalent of the
interfaces menu level in the RUGGEDCOM ROX II web user interface, and the interfaces command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_ifswitch?module=rmf_ifswitch&revision=2012-11-28</
capability>
The switch namespace contains switch configuration data. The switch namespace is the equivalent of
the switch menu level in the RUGGEDCOM ROX II web user interface, and the switch command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_iftunnel?module=rmf_iftunnel&revision=2012-11-28</
capability>
The tunnel namespace contains tunnel configuration data. The tunnel namespace is the equivalent of
the tunnel menu level in the RUGGEDCOM ROX II web user interface, and the tunnel command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_ip?module=rmf_ip&revision=2012-11-28</capability>
The ip namespace contains ip address configuration data. The ip namespace is the equivalent of the ip menu
level in the RUGGEDCOM ROX II web user interface, and the ip command in the RUGGEDCOM ROX II command
line interface.
•<capability>http://ruggedcom.com/ns/rmf_mpls?module=rmf_mpls&revision=2012-11-28</capability>
The mpls namespace contains mpls configuration data. The mpls namespace is the equivalent of the mpls
menu level in the RUGGEDCOM ROX II web user interface, and the mpls command in the RUGGEDCOM ROX II
command line interface.
•<capability>http://ruggedcom.com/ns/rmf_qos?module=rmf_qos&revision=2012-11-28</capability>
The qos namespace contains quality of service configuration data. The qos namespace is the equivalent of the
qos menu level in the RUGGEDCOM ROX II web user interface, and the qos command in the RUGGEDCOM ROX
II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_routing?module=rmf_routing&revision=2012-11-28</
capability>
The routing namespace contains routing configuration data. The routing namespace is the equivalent of
the routing menu level in the RUGGEDCOM ROX II web user interface, and the routing command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_security?module=rmf_security&revision=2012-11-28</
capability>
The security namespace contains security configuration data. The security namespace is the equivalent of
the security menu level in the RUGGEDCOM ROX II web user interface, and the security command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rmf_services?module=rmf_services&revision=2012-11-28</
capability>
The services namespace contains services configuration data. The services namespace is the equivalent of
the services menu level in the RUGGEDCOM ROX II web user interface, and the services command in the
RUGGEDCOM ROX II command line interface.
•<capability>http://ruggedcom.com/ns/rox_apps?module=rox_apps&revision=2012-11-28</capability>
The apps namespace contains apps configuration data. The apps namespace is the equivalent of the apps
menu level in the RUGGEDCOM ROX II web user interface, and the apps command in the RUGGEDCOM ROX II
command line interface.
Chapter 2
NETCONF Capabilities and Namespaces
RUGGEDCOM NETCONF
Reference Guide
20 Viewing the Capabilities on a Device
•<capability>http://ruggedcom.com/ns/rmf_mpls?module=rmf_mpls&revision=2012-11-28</capability>
The mpls namespace contains mpls configuration data. The mpls namespace is the equivalent of the mpls
menu level in the RUGGEDCOM ROX II web user interface, and the mpls command in the RUGGEDCOM ROX II
command line interface.
Section2.6
Viewing the Capabilities on a Device
To view the capabilities on a device, do the following:
1. Log in to the device's NETCONF service via Secure Shell (SSH):
$ ssh {user}@{ipAddress} -p 830 -s netconf
•{user} is an administrative role user on the device.
•{ipAddress} is an address on the device listening for NETCONF activity. The -p parameter indicates the
port listening for NETCONF activity. Port 830 is the default NETCONF port. The -s parameter indicates the
subsystem. All NETCONF communication must be identified with -s NETCONF. You can configure the IP
addresses and ports on which RUGGEDCOM ROX II listens for NETCONF. For more information, refer to
Section3.1, “Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF”.
2. When prompted, provide the user's password.
3. The device responds with a <hello> message, listing its capabilities.
<?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:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
<capability>urn:ietf:params:netconf:capability:XPath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,sftp,file</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:rollback-on-error:1.0</capability>
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
<capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
<capability>urn:ietf:params:netconf:capability:partial-lock:1.0</capability>
<capability>http://tail-f.com/ns/netconf/with-defaults/1.0</capability>
<capability>http://tail-f.com/ns/netconf/actions/1.0</capability>
<capability>http://tail-f.com/ns/netconf/commit/1.0</capability>
<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=trim&also-
supported=report-all-tagged</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?
revision=2010-11-11&module=ietf-with-defaults</capability>
<capability>http://ruggedcom.com/ns/rmf?module=rmf&revision=2012-03-07</capability>
<capability>http://ruggedcom.com/ns/rmf_admin?module=rmf_admin&revision=2012-03-07</capability>
<capability>http://ruggedcom.com/ns/rmf_chassis?module=rmf_chassis&revision=2012-03-07</
capability>
<capability>http://ruggedcom.com/ns/rmf_events?module=rmf_events&revision=2012-03-07</
capability>
<capability>http://ruggedcom.com/ns/rmf_global?module=rmf_global&revision=2012-03-07</
capability>
<capability>http://ruggedcom.com/ns/rmf_if?module=rmf_if&revision=2012-03-07</capability>
<capability>http://ruggedcom.com/ns/rmf_ifs?module=rmf_ifs&revision=2012-03-07</capability>
RUGGEDCOM NETCONF
Reference Guide
Chapter 2
NETCONF Capabilities and Namespaces
Viewing the Capabilities on a Device 21
<capability>http://ruggedcom.com/ns/rmf_iftunnel?module=rmf_iftunnel&revision=2012-03-07</
capability>
<capability>http://ruggedcom.com/ns/rmf_ip?module=rmf_ip&revision=2012-03-07</capability>
<capability>http://ruggedcom.com/ns/rmf_qos?module=rmf_qos&revision=2012-03-07</capability>
<capability>http://ruggedcom.com/ns/rmf_routing?module=rmf_routing&revision=2012-03-07</
capability>
<capability>http://ruggedcom.com/ns/rmf_security?module=rmf_security&revision=2012-03-07</
capability>
<capability>http://ruggedcom.com/ns/rmf_services?module=rmf_services&revision=2012-03-07</
capability>
<capability>http://tail-f.com/yang/common-monitoring?module=tailf-common-
monitoring&revision=2011-09-22</capability>
<capability>http://tail-f.com/yang/confd-monitoring?module=tailf-confd-
monitoring&revision=2011-09-22</capability>
<capability>http://tail-f.com/yang/netconf-monitoring?module=tailf-netconf-
monitoring&revision=2011-09-22</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-
types&revision=2010-09-24</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-
monitoring&revision=2010-10-04</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-
types&revision=2010-09-24</capability>
</capabilities>
<session-id>1020</session-id>
</hello>]]>]]>
Chapter 2
NETCONF Capabilities and Namespaces
RUGGEDCOM NETCONF
Reference Guide
22 Viewing the Capabilities on a Device
RUGGEDCOM NETCONF
Reference Guide
Chapter 3
NETCONF Sessions
Configuring/Monitoring NETCONF in RUGGEDCOM
NETCONF 23
NETCONF Sessions
This section describes how to do the following:
• connect to the NETCONF service on a device via Secure Shell (SSH). You must do this each time you connect to
the device to start a NETCONF session.
• respond to the device's <hello> message. You must do this each time you start a NETCONF session.
• close the session gracefully with the <close-session> command. Closing the session with the <close-
session> command is recommended, but is optional.
• kill the session with the <kill-session> command. Closing the session with the <kill-session>
command is optional.
CONTENTS
•Section3.1, “Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF”
•Section3.2, “Connecting to the NETCONF Service”
•Section3.3, “Saying Hello”
•Section3.4, “Closing the Session”
•Section3.5, “Killing a Session”
Section3.1
Configuring/Monitoring NETCONF in RUGGEDCOM
NETCONF
Before sending NETCONF XML messages to any RUGGEDCOM NETCONF device, make sure NETCONF sessions are
enabled and configured. For more information, refer to either the RUGGEDCOM ROX II Web Interface or CLI User
Guides for the device.
The RUGGEDCOM ROX II User Guides also detail how to look up important statistics, such as the number of bad
hellos, the total number of dropped sessions, etc.
Section3.2
Connecting to the NETCONF Service
RUGGEDCOM ROX II supports the use of Secure Shell (SSH) to connect to the NETCONF service on the device. To
connect to the NETCONF service, specify an IP address, port, and subsystem:
$ ssh {user}@{ipAddress} -p 830 -s netconf