Siemens RX1400,RX1500,RX1511,RX1512,RX5000,MX5000,MX5000RE,RX1501,RX1510 Reference Manual

Preface

RUGGEDCOM NETCONF

Reference Guide

Introduction

NETCONF Capabilities and Namespaces

NETCONF Sessions

Getting Data

Changing Configuration Data

RUGGEDCOM ROX II Actions

Examples

NETCONF XML Elements

For RX1400, RX1500, RX1501, RX1510, RX1511, RX1512, RX5000, MX5000, MX5000RE

06/2017

RC1065-EN-03

RUGGEDCOM NETCONF

Reference Guide

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

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.1What is NETCONF? ........................................................................................................................ 1

1.2What Can NETCONF Do? ............................................................................................................... 3

1.3Who Should Use This Guide ........................................................................................................... 3

1.4Supported IETF RFCs ..................................................................................................................... 3

1.5Sample NETCONF sessions ............................................................................................................ 3

1.5.1Sample Session: Getting Data ............................................................................................. 4

1.5.2 Sample Session: Performing an Action ................................................................................. 6

1.5.3Sample Session: Editing Data .............................................................................................. 9

Chapter 2

NETCONF Capabilities and Namespaces ........................................................... 15

2.1IETF Capabilities .......................................................................................................................... 15

2.2Vendor-Defined Capabilities ......................................................................................................... 17

2.3IETF Namespaces ........................................................................................................................ 17

2.4Vendor-Defined Namespaces ....................................................................................................... 18

2.5RUGGEDCOM Namespaces ........................................................................................................... 18

2.6Viewing the Capabilities on a Device ............................................................................................ 20

Chapter 3

NETCONF Sessions .......................................................................................... 23

3.1Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF ......................................................... 23

3.2Connecting to the NETCONF Service ............................................................................................ 23

3.3 Saying Hello ............................................................................................................................... 24

3.3.1RUGGEDCOM ROX II NETCONF <hello> Message ................................................................. 25

3.4Closing the Session ..................................................................................................................... 26

iii



Table of Contents

RUGGEDCOM NETCONF

Reference Guide

3.5Killing a Session .......................................................................................................................... 26

Chapter 4

Getting Data ................................................................................................... 29

4.1Using the <get> Command .......................................................................................................... 29

4.2Using the <get-config> Command ................................................................................................ 30

4.3 Using XPaths with <get> and <get-config> ................................................................................... 31

4.4 Getting Information for a Specific Object ...................................................................................... 33

4.4.1Specifying Objects with Hierarchical XML Elements ............................................................. 33

4.4.2Specifying Objects with XPaths ......................................................................................... 34

4.5Getting Default Values ................................................................................................................ 34

4.6Getting Data Models from the Device ........................................................................................... 35

4.6.1Getting Schemas from the Device ..................................................................................... 36

4.6.2Getting YIN and YANG Files from the Device ...................................................................... 37

4.6.3Using pyang .................................................................................................................... 38

4.6.3.1Using the Text-Based Tree ...................................................................................... 39

Chapter 5

Changing Configuration Data .......................................................................... 41

5.1Changing Data in the Running Configuration ................................................................................ 41

5.2Changing Data in the Candidate Configuration .............................................................................. 42

5.2.1Locking Data Stores ......................................................................................................... 43

5.2.2Copying Data ................................................................................................................... 44

5.2.3Replacing Data ................................................................................................................. 46

5.2.4Deleting Data ................................................................................................................... 48

5.2.5Validating Changes .......................................................................................................... 50

5.2.6Committing Changes ........................................................................................................ 51

Chapter 6

RUGGEDCOM ROX II Actions ............................................................................ 53

6.1Admin Namespace Actions .......................................................................................................... 54

6.1.1snmp-discover .................................................................................................................. 55

6.1.2launch-upgrade ................................................................................................................ 55

6.1.3decline-upgrade ............................................................................................................... 56

6.1.4rollback-reboot ................................................................................................................. 56

6.1.5 roxflash ........................................................................................................................... 57

6.1.6clear-all-alarms ................................................................................................................. 57

6.1.7acknowledge-all-alarms .................................................................................................... 57

6.1.8 shutdown ........................................................................................................................ 58

6.1.9 reboot ............................................................................................................................. 58

6.1.10set-system-clock ............................................................................................................. 58

RUGGEDCOM NETCONF

Reference Guide

6.2Interfaces Namespace Actions ...................................................................................................... 61

6.3Services Namespace Actions ........................................................................................................ 67

6.4Switch Namespace Actions .......................................................................................................... 69

6.5Tunnel Namespace Actions .......................................................................................................... 71

Table of Contents



6.1.11restore-factory-defaults ................................................................................................... 59

6.1.12delete-logs ..................................................................................................................... 59

6.1.13install-files ..................................................................................................................... 59

6.1.14backup-files (Backup Files) .............................................................................................. 60

6.1.15full-configuration-save .................................................................................................... 60

6.1.16full-configuration-load .................................................................................................... 61

6.2.1reset (Modem) ................................................................................................................. 62

6.2.2at (Modem) ..................................................................................................................... 62

6.2.3reset (Cellular Modem) ..................................................................................................... 63

6.2.4at (Cellular Modem) ......................................................................................................... 63

6.2.5reset (Serial Port) ............................................................................................................. 64

6.2.6clear-serial-port-stats ........................................................................................................ 64

6.2.7restart-serserver ............................................................................................................... 65

6.2.8reset-port (Switch Port) .................................................................................................... 65

6.2.9clear-port-stats (Switch Port) ............................................................................................. 66

6.2.10start-cable-test (Switch Port) ........................................................................................... 66

6.2.11clear-cable-stats-port (Switch Port) .................................................................................. 67

6.3.1 ntp-status ........................................................................................................................ 67

6.3.2log (Link-Failover) ............................................................................................................ 68

6.3.3start-test (Link Failover) .................................................................................................... 68

6.3.4cancel-test (Link Failover) ................................................................................................. 69

6.3.5show-active-leases (DHCP Server) ...................................................................................... 69

6.4.1clear-stp-stats (Switch) ..................................................................................................... 70

6.4.2flush-dynamic-rules (Switch) ............................................................................................. 70

6.4.3reset-all-switch-ports (Switch) ........................................................................................... 70

6.4.4clear-all-switch-stats (Switch) ............................................................................................ 71

6.4.5clear-cable-stats-all (Switch) .............................................................................................. 71

6.5.1display-public-key (IPSEC) ................................................................................................. 72

6.5.2status (IPSEC) .................................................................................................................. 72

6.5.3install-certificate (IPSEC) ................................................................................................... 72

6.5.4install-ca-certificate (IPSEC) ............................................................................................... 73

6.5.5install-crl-file (IPSEC) ........................................................................................................ 74

6.5.6remove-ca-certificate (IPSEC) ............................................................................................. 75

6.5.7remove-certificate (IPSEC) ................................................................................................. 75

6.5.8remove-crl (IPSEC) ............................................................................................................ 76



Table of Contents

Chapter 7

RUGGEDCOM NETCONF

Reference Guide

Examples ........................................................................................................ 77

7.1Getting the System Name ........................................................................................................... 80

7.2Getting the ROX Release ............................................................................................................. 80

7.3Getting the Chassis Status ........................................................................................................... 81

7.4Setting the System Clock ............................................................................................................. 81

7.5Acknowledging Alarms ................................................................................................................ 81

7.6Clearing All Alarms ..................................................................................................................... 82

7.7Viewing Alarms ........................................................................................................................... 82

7.8Restoring Factory Defaults ........................................................................................................... 82

7.9Changing the System Name by Locking and Committing ............................................................... 83

7.10Changing the System Name Directly ........................................................................................... 84

7.11Creating a Static VLAN .............................................................................................................. 85

7.12Assigning a PVID on a Port ........................................................................................................ 86

7.13 Disabling Spanning Tree on a Specific Port .................................................................................. 87

7.14Configuring an IP Address on a Specific Port ............................................................................... 88

7.15Deleting an IP Address .............................................................................................................. 90

7.16Setting a Static Route ................................................................................................................ 91

7.17Disabling Spanning Tree Globally ............................................................................................... 92

7.18Retrieving all IP Addresses from the Running Configuration .......................................................... 94

7.19 Retrieving the Active Routes on a Device .................................................................................... 94

7.20Configuring Static Multicast Routing on a Layer 3 Device ............................................................. 95

7.21Enabling Static Multicast Routing on a Layer 3 Device .................................................................. 96

7.22Retrieving Static Multicast Status on a Layer 3 Device .................................................................. 97

7.23Replacing an IP Address ............................................................................................................. 98

7.24Configuring a Port to Dynamically Obtain an IP Address ............................................................... 99

7.25Configuring OSPF Area and Network on a Layer 3 Device ........................................................... 100

7.26 Enabling the OSPF Passive-Default Option ................................................................................. 102

7.27Configure an OSPF Non-Passive Port ......................................................................................... 103

7.28Configuring OSPF Parameters ................................................................................................... 104

7.29Enabling the OSPF redistribute-connected Option ...................................................................... 106

7.30Enabling OSPF on a Layer 3 Device .......................................................................................... 107

7.31Retrieving OSPF Status ............................................................................................................ 108

7.32Retrieving All Data from the Routing Namespace ....................................................................... 109

7.33Configuring DHCP Server ......................................................................................................... 109

7.34Configure the DHCP Server Port Listening for DHCP Client Requests ............................................. 110

7.35Enabling the DHCP Server Service ............................................................................................. 112

7.36Disabling an Ethernet Port ....................................................................................................... 113

7.37Enabling an Ethernet Port ........................................................................................................ 114

7.38Checking an IP Address on a Specific Port using the Interfaces Namespace ................................... 115

RUGGEDCOM NETCONF

Reference Guide

Table of Contents

7.39Retreiving All Data From Running Database Including Default Values ........................................... 116

7.40Retreiving All Data From Running Database Including Default Tags and Values ............................. 116

7.41Changing a User's Password ..................................................................................................... 117

7.42 Displaying the Status of the IPsec Service ................................................................................. 118

7.43 Selecting a Certificate for an IPSec Tunnel ................................................................................ 118

7.44Installing a CA Certificate ......................................................................................................... 120

7.45Configuring a Signed CA Certificate .......................................................................................... 121

7.46Installing a Private Key to a Signed CA Certificate ...................................................................... 121

7.47Installing a CRL File ................................................................................................................. 122

7.48Removing a Certificate ............................................................................................................ 123

7.49Removing a CA certificate ........................................................................................................ 123

7.50Removing 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



vii



Table of Contents

RUGGEDCOM NETCONF

Reference Guide

viii

RUGGEDCOM NETCONF

Reference Guide

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”



Preface

How This Guide Is Organized

• Chapter1, 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.

• Chapter2, 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.

• Chapter3, 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.

• Chapter4, 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.

• Chapter5, Changing Configuration Data describes how to change RUGGEDCOM NETCONF configuration data. Read this section to learn how to set configuration data and perform actions.

• Chapter6, 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.

• Chapter7, 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.

• Chapter8, 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.

How This Guide Is Organized ix



Preface

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.

RUGGEDCOM NETCONF

Reference Guide

NOTE

NOTE alerts provide additional information, such as facts, tips and details.

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.

x Alerts

RUGGEDCOM NETCONF

Reference Guide

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.



Preface

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

Training xi



Preface

RUGGEDCOM NETCONF

Reference Guide

xii Customer Support

RUGGEDCOM NETCONF

Reference Guide

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

• Section1.1, “What is NETCONF?”

• Section1.2, “What Can NETCONF Do?”

• Section1.3, “Who Should Use This Guide”

• Section1.4, “Supported IETF RFCs”

• Section1.5, “Sample NETCONF sessions”

Chapter 1

Introduction

Section1.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:

What is NETCONF? 1

Chapter 1

Introduction

Figure1:NETCONF Concepts and Implementation

RUGGEDCOM NETCONF

Reference Guide

• 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 Chapter2, NETCONF Capabilities and Namespaces, where this guide discusses the capabilities and namespaces supported by devices.

2 What is NETCONF?

RUGGEDCOM NETCONF

Reference Guide

Section1.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

Section1.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.

Chapter 1

Introduction

Section1.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]

Section1.5

Sample NETCONF sessions

This section provides a walk-through of three typical types of NETCONF sessions:

What Can NETCONF Do? 3

Chapter 1

Introduction

RUGGEDCOM NETCONF

Reference Guide

• Section1.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

• Section1.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

• Section1.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

• Section1.5.1, “Sample Session: Getting Data”

• Section1.5.2, “Sample Session: Performing an Action”

• Section1.5.3, “Sample Session: Editing Data”

Section1.5.1

Sample Session: Getting Data

To retrieve data from a device, do the following:

Figure2:Getting Data

4 Sample Session: Getting Data

RUGGEDCOM NETCONF

Reference Guide

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

Section3.1, “Configuring/Monitoring NETCONF in RUGGEDCOM NETCONF”.

The device responds with its <hello> statement:

Chapter 1

Introduction

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

Sample Session: Getting Data 5

Chapter 1

Introduction

• All commands must be enclosed within <rpc> tags. The message-id attribute is not required but is

• The <source> element indicates the datastore from which we are requesting data. In this example we are

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

• The ]]>]]> string indicates the end of the NETCONF message. Each NETCONF message must end with

The device responds with the requested data:

RUGGEDCOM NETCONF

Reference Guide

recommended. The message-id attribute is returned in the device response, allowing you to match responses with requests.

requesting data from the running configuration database.

additional elements navigate down to the desired element. In this example, we are navigating to admin/

system-name in the RUGGEDCOM NETCONF data model.

]]>]]>

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

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

Section1.5.2

Sample Session: Performing an Action

To perform an action on a device, do the following:

6 Sample Session: Performing an Action

RUGGEDCOM NETCONF

Reference Guide

Figure3:Performing an Action

Basic Steps

Chapter 1

Introduction

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

Section3.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>]]>]]>

Sample Session: Performing an Action 7

Chapter 1

Introduction

RUGGEDCOM NETCONF

Reference Guide

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

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

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

8 Sample Session: Performing an Action

RUGGEDCOM NETCONF

<hello>

Say <hello>

<close-session>

<edit-config>

<unlock> datastores

<discard-changes/>

<lock> datastores

Reference Guide

<ok/> </rpc-reply>]]>]]

Section1.5.3

Sample Session: Editing Data

To edit data on the device, do the following:

Chapter 1

Introduction

Figure4: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.

Sample Session: Editing Data 9

Chapter 1

Introduction

RUGGEDCOM NETCONF

Reference Guide

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

Section3.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>]]>]]>

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

10 Sample Session: Editing Data

RUGGEDCOM NETCONF

Reference Guide

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

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

Chapter 1

Introduction

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

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:

Sample Session: Editing Data 11

Chapter 1

Introduction

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

• 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

The device responds with the following:

RUGGEDCOM NETCONF

Reference Guide

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

configuration is to be edited.

example, the <system-name> value is being edited.

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

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

The device responds with the following:

12 Sample Session: Editing Data

RUGGEDCOM NETCONF

Reference Guide

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

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

Chapter 1

Introduction

10. Issue an <rpc> request to unlock the running 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="1018"> <ok/> </rpc-reply>]]>]]>

11. Close the session:

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

Sample Session: Editing Data 13

Chapter 1

Introduction

RUGGEDCOM NETCONF

Reference Guide

14 Sample Session: Editing Data

RUGGEDCOM NETCONF

Reference Guide

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.

Chapter 2

CONTENTS

• Section2.1, “IETF Capabilities”

• Section2.2, “Vendor-Defined Capabilities”

• Section2.3, “IETF Namespaces”

• Section2.4, “Vendor-Defined Namespaces”

• Section2.5, “RUGGEDCOM Namespaces”

• Section2.6, “Viewing the Capabilities on a Device”

Section2.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].

IETF Capabilities 15

Chapter 2

NETCONF Capabilities and Namespaces

Capabilities Description

RUGGEDCOM NETCONF

Reference Guide

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

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

<capability>urn:ietf:params:netconf:capability:confirmedcommit:1.0</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>

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

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

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

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

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

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-onerror: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>urn:ietf:params:netconf:capability:with-defaults:1.0? basic-mode=trim&also-supported=report-all-tagged</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].

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

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

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

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

16 IETF Capabilities

RUGGEDCOM NETCONF

Reference Guide

NETCONF Capabilities and Namespaces

Section2.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

Chapter 2

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

This vendor-defined capability extends the standard IETF withdefaults 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.

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.

These vendor-defined capabilities support NETCONF monitoring on the device.

Section2.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=ietfinet-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>

<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults? revision=2010-11-11&module=ietf-with-defaults</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].

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

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

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

Vendor-Defined Capabilities 17

Chapter 2

NETCONF Capabilities and Namespaces

Section2.4

Vendor-Defined Namespaces

The following namespaces support vendor-defined NETCONF capabilities:

Namespace Description

RUGGEDCOM NETCONF

Reference Guide

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

Section2.5

Supports and extends the IETF with-defaults capability.

Supports the vendor-defined actions capability.

Supports the vendor-defined commit capability.

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.

18 Vendor-Defined Namespaces

+ 118 hidden pages

Siemens RX1400,RX1500,RX1511,RX1512,RX5000,MX5000,MX5000RE,RX1501,RX1510 Reference Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

RUGGEDCOM NETCONF

Table of Contents

Preface

How This Guide Is Organized

Alerts

Related Documents

Accessing Documentation

Training

Customer Support

Introduction

What is NETCONF?

What Can NETCONF Do?

Who Should Use This Guide

Supported IETF RFCs

Sample NETCONF sessions

Sample Session: Getting Data

Sample Session: Performing an Action

Sample Session: Editing Data

NETCONF Capabilities and Namespaces

IETF Capabilities

Vendor-Defined Capabilities

IETF Namespaces

Vendor-Defined Namespaces

RUGGEDCOM Namespaces