hit counter script
Siemens RX1400 Reference Manual

Siemens RX1400 Reference Manual

Ruggedcom series
Hide thumbs Also See for RX1400:
Table of Contents

Advertisement

RUGGEDCOM NETCONF
Reference Guide
For RX1400, RX1500, RX1501, RX1510, RX1511,
RX1512, RX5000, MX5000, MX5000RE
06/2017
RC1065-EN-03
Preface
Introduction
NETCONF Capabilities and
Namespaces
NETCONF Sessions
Getting Data
Changing Configuration
Data
RUGGEDCOM ROX II Actions
Examples
NETCONF XML Elements
1
2
3
4
5
6
7
8

Advertisement

Table of Contents
loading

Summary of Contents for Siemens RX1400

  • Page 1 Preface Introduction NETCONF Capabilities and Namespaces RUGGEDCOM NETCONF NETCONF Sessions Getting Data Changing Configuration Data Reference Guide RUGGEDCOM ROX II Actions Examples NETCONF XML Elements For RX1400, RX1500, RX1501, RX1510, RX1511, RX1512, RX5000, MX5000, MX5000RE 06/2017 RC1065-EN-03...
  • Page 2: Open Source

    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.
  • Page 3: Table Of Contents

    RUGGEDCOM NETCONF   Reference Guide Table of Contents Table of Contents Preface ......................How This Guide Is Organized ....................... ix Alerts ..............................x Related Documents ..........................x Accessing Documentation ........................x Training .............................. xi Customer Support ..........................xi Chapter 1 Introduction .....................
  • Page 4   RUGGEDCOM NETCONF Table of Contents Reference Guide 3.5  Killing a Session .......................... 26 Chapter 4 Getting Data ....................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 .............
  • Page 5 RUGGEDCOM NETCONF   Reference Guide 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  Interfaces Namespace Actions ...................... 61 6.2.1  reset (Modem) ......................... 62 6.2.2  at (Modem) ........................62 6.2.3  reset (Cellular Modem) .....................
  • Page 6   RUGGEDCOM NETCONF Table of Contents Reference Guide Chapter 7 Examples ......................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 ........................
  • Page 7 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 ................
  • Page 8   RUGGEDCOM NETCONF Table of Contents Reference Guide viii...
  • Page 9: Preface

    RUGGEDCOM NETCONF   Reference Guide Preface 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”...
  • Page 10: Alerts

    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.
  • Page 11: Training

    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 •...
  • Page 12   RUGGEDCOM NETCONF Preface Reference Guide Customer Support...
  • Page 13: Introduction

    RUGGEDCOM NETCONF Chapter 1 Reference Guide Introduction 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.
  • Page 14: Netconf Capabilities And Namespaces

    Chapter 1 RUGGEDCOM NETCONF Introduction Reference Guide Figure 1: 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>...
  • Page 15: What Can Netconf Do

    RUGGEDCOM NETCONF Chapter 1 Reference Guide Introduction 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.
  • Page 16: Sample Session: Getting Data

    Chapter 1 RUGGEDCOM NETCONF Introduction 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 •...
  • Page 17: Examples

    RUGGEDCOM NETCONF Chapter 1 Reference Guide Introduction Basic Steps Connect to the device and exchange <hello> messages. 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.
  • Page 18: Sample Session: Performing An Action

    Chapter 1 RUGGEDCOM NETCONF Introduction Reference Guide • 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. •...
  • Page 19 RUGGEDCOM NETCONF Chapter 1 Reference Guide Introduction Figure 3: Performing an Action Basic Steps Connect to the device and exchange <hello> messages. 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.
  • Page 20 Chapter 1 RUGGEDCOM NETCONF Introduction Reference Guide 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>...
  • Page 21: Sample Session: Editing Data

    RUGGEDCOM NETCONF Chapter 1 Reference Guide Introduction <ok/> </rpc-reply>]]>]] Section 1.5.3 Sample Session: Editing Data To edit data on the device, do the following: <hello> <validate> Say <hello> <xml> <xml>data</xml> <xml>data</xml> <discard-changes/> <commit> <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>...
  • Page 22 Chapter 1 RUGGEDCOM NETCONF Introduction Reference Guide 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.
  • Page 23 RUGGEDCOM NETCONF Chapter 1 Reference Guide Introduction • 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"...
  • Page 24 Chapter 1 RUGGEDCOM NETCONF Introduction 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>]]>]]> • 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.
  • Page 25 RUGGEDCOM NETCONF Chapter 1 Reference Guide Introduction <?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. Issue an <rpc> request to unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1017"> <unlock>...
  • Page 26 Chapter 1 RUGGEDCOM NETCONF Introduction Reference Guide Sample Session: Editing Data...
  • Page 27: Netconf Capabilities And Namespaces

    RUGGEDCOM NETCONF Chapter 2 Reference Guide NETCONF Capabilities and Namespaces 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>...
  • Page 28 Chapter 2 RUGGEDCOM NETCONF NETCONF Capabilities and Namespaces Reference Guide Capabilities Description <capability>urn:ietf:params:netconf:capability:writable- Supports writing to the running configuration: you can update running:1.0</capability> 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].
  • Page 29: Vendor-Defined Capabilities

    RUGGEDCOM NETCONF Chapter 2 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 This vendor-defined capability extends the standard IETF with-...
  • Page 30: Vendor-Defined Namespaces

    Chapter 2 RUGGEDCOM NETCONF NETCONF Capabilities and Namespaces Reference Guide Section 2.4 Vendor-Defined Namespaces The following namespaces support vendor-defined NETCONF capabilities: Namespace Description Supports and extends the IETF with-defaults capability. <capability>http://tail-f.com/ns/netconf/with-defaults/1.0</ capability> Supports the vendor-defined actions capability. <capability>http://tail-f.com/ns/netconf/actions/1.0</ capability> Supports the vendor-defined commit capability. <capability>http://tail-f.com/ns/netconf/commit/1.0</ capability>...
  • Page 31 RUGGEDCOM NETCONF Chapter 2 Reference Guide NETCONF Capabilities and Namespaces • <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.
  • Page 32: Viewing The Capabilities On A Device

    Chapter 2 RUGGEDCOM NETCONF NETCONF Capabilities and Namespaces Reference Guide • <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.
  • Page 33 RUGGEDCOM NETCONF Chapter 2 Reference Guide NETCONF Capabilities and Namespaces <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>]]>]]> Viewing the Capabilities on a Device...
  • Page 34 Chapter 2 RUGGEDCOM NETCONF NETCONF Capabilities and Namespaces Reference Guide Viewing the Capabilities on a Device...
  • Page 35: Netconf Sessions

    RUGGEDCOM NETCONF Chapter 3 Reference Guide NETCONF Sessions 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.
  • Page 36: Saying Hello

    Chapter 3 RUGGEDCOM NETCONF NETCONF Sessions Reference Guide • {user} A user name on the device assigned the administrative user role. • {ipAddress} The IP address or hostname of the device. • -p 830 Specifies port 830. The default NETCONF port is port 830. •...
  • Page 37: Ruggedcom Rox Ii Netconf Message

    RUGGEDCOM NETCONF Chapter 3 Reference Guide NETCONF Sessions Section 3.3.1 RUGGEDCOM ROX II NETCONF <hello> Message The following is the hello message returned when you connect to the NETCONF service on a device running the RUGGEDCOM ROX II operating system: <?xml version="1.0" encoding="UTF-8"?> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">...
  • Page 38: Closing The Session

    Chapter 3 RUGGEDCOM NETCONF NETCONF Sessions Reference Guide <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> </capabilities> </hello>]]>]]> The device does not reply to the <hello> response unless there is an error. After issuing the <hello> response, you can begin sending NETCONF requests. Section 3.4 Closing the Session Closing a session requests the graceful termination of a NETCONF session.
  • Page 39 RUGGEDCOM NETCONF Chapter 3 Reference Guide NETCONF Sessions To kill a session, you need to know its <session-id>. To determine the <session-id> of another session, attempt to <lock> a configuration. If the configuration is already locked by another session, the <session-id> for the session is reported in the <rpc-error>...
  • Page 40 Chapter 3 RUGGEDCOM NETCONF NETCONF Sessions Reference Guide Killing a Session...
  • Page 41: Getting Data

    RUGGEDCOM NETCONF Chapter 4 Reference Guide Getting Data Getting Data This section describes how to use NETCONF to retrieve configuration data from RUGGEDCOM ROX II. NETCONF features two get commands to retrieve data from the device: • <get> retrieves device state data and information from the running configuration. For more information, refer Section 4.1, “Using the <get>...
  • Page 42: Using The Command

    Chapter 4 RUGGEDCOM NETCONF Getting Data Reference Guide • specify the <filter> element's type attribute as subtree • construct the path to the desired element within the <filter> element • specify the namespace for the root element in the path You can use an XPath in the <filter>...
  • Page 43: Using Xpaths With And

    RUGGEDCOM NETCONF Chapter 4 Reference Guide Getting Data • construct the path to the desired element within the <filter> element • specify the namespace for the root element in the path You can also use an XPath in the <filter> element, instead of the hierarchical XML element structure. For information on how to use an XPath, refer to Section 4.3, “Using XPaths with <get>...
  • Page 44 Chapter 4 RUGGEDCOM NETCONF Getting Data Reference Guide The following example shows how to return the state of the Developer Log Enabled setting using an XPath. In this example, the Developer Log is enabled, so the value for the Enabled setting is returned as true. <rpc message-id="3020"...
  • Page 45: Getting Information For A Specific Object

    RUGGEDCOM NETCONF Chapter 4 Reference Guide Getting Data Section 4.4 Getting Information for a Specific Object To retrieve information for a specific object, such as a user, an interface, or other identified object, specify the identification for the item item in the XML element hierarchy or XPath. CONTENTS •...
  • Page 46: Specifying Objects With Xpaths

    Chapter 4 RUGGEDCOM NETCONF Getting Data Reference Guide </users> </admin> </data> </rpc-reply>]]>]]> Section 4.4.2 Specifying Objects with XPaths When using XPath, use the following syntax in the select statement: select="{element}/.../{element}[{element}='{data}']/{element}"/> • {element} is an element in the data model. • ... represents multiple elements in the data model to the target element. •...
  • Page 47: Getting Data Models From The Device

    RUGGEDCOM NETCONF Chapter 4 Reference Guide Getting Data </rpc>]]>]]> The device returns the following: <?xml version="1.0" encoding="UTF-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3030"> <data> <admin xmlns="http://ruggedcom.com/ns/rmf_admin"> <logging> <diagnostics> <xpath-trace-log> </xpath-trace-log> </diagnostics> </logging> </admin> </data> </rpc-reply>]]>]]> Note that the <enabled> element is not returned. To return the default values for elements, add a with-defaults attribute to the <rpc>...
  • Page 48: Getting Schemas From The Device

    Chapter 4 RUGGEDCOM NETCONF Getting Data Reference Guide • RUGGEDCOM ROX II CLI Paths to parameters in the RUGGEDCOM ROX II CLI are a direct representation of the underlying data model. • YANG/YIN Files YANG and YIN files detail the RUGGEDCOM ROX II data model in formats that can be parsed and transformed as needed.
  • Page 49: Getting Yin And Yang Files From The Device

    RUGGEDCOM NETCONF Chapter 4 Reference Guide Getting Data Review the list and locate the <schema> entries for items you want to retrieve. For example, shown here are the <schema> entries for the rmf_admin namespace: <schema> <identifier>rmf_admin</identifier> <version>2012-03-07</version> <format>yin</format> <namespace>http://ruggedcom.com/ns/rmf_admin</namespace> <location>NETCONF</location> </schema>...
  • Page 50: Using Pyang

    Chapter 4 RUGGEDCOM NETCONF Getting Data Reference Guide <version>2012-03-07</version> <format>yin</format> </get-schema> </rpc>]]>]]> The device returns the text from the specified YIN or YANG file. Section 4.6.3 Using pyang pyang is an open-source utility used to validate and transform YANG and YIN files. pyang is particularly useful for transforming YANG and YIN files into text-based output that clearly illustrated the hierarchy of the elements in the RUGGEDCOM ROX II data model files.
  • Page 51: Using The Text-Based Tree

    RUGGEDCOM NETCONF Chapter 4 Reference Guide Getting Data +--rw key? leafref • rw indicates a read-write node. • ro indicates a read-only node. • [square braces] indicate an identifier or name for a data object. • text following the node name indicates the data type for the node, such as boolean, string, and so on. CONTENTS •...
  • Page 52 Chapter 4 RUGGEDCOM NETCONF Getting Data Reference Guide Again, refer to the text-based tree diagram to locate the services/ntp/server(name)/peer field in the tree: +--rw services +--rw time +--rw ntp +--rw enabled? boolean +--rw server [name] +--rw name inet:host +--rw enabled? empty +--rw peer? empty...
  • Page 53: Changing Configuration Data

    RUGGEDCOM NETCONF Chapter 5 Reference Guide Changing Configuration Data Changing Configuration Data This section describes how to change configuration data and perform actions on your device through NETCONF. You can edit configuration data in two ways: • You can edit the running configuration directly. In this approach, any changes you make to the running configuration take effect immediately.
  • Page 54: Changing Data In The Candidate Configuration

    Chapter 5 RUGGEDCOM NETCONF Changing Configuration Data Reference Guide <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> {path} </config> </edit-config> </rpc>]]>]]> • {path} The XML elements describing the path to and the data for the element to be edited. For example, to create a static VLAN: <rpc message-id="233"...
  • Page 55: Locking Data Stores

    RUGGEDCOM NETCONF Chapter 5 Reference Guide Changing Configuration Data This section describes how to lock the datastores, edit and delete data, validate the configuration, commit the changes, and lock the datastores. For instructions on how to initiate a NETCONF session, refer to Section 3.2, “Connecting to the NETCONF Service”.
  • Page 56: Copying Data

    Chapter 5 RUGGEDCOM NETCONF Changing Configuration Data Reference Guide </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. Section 5.2.2 Copying Data You can use the copy-config command to do the following: •...
  • Page 57 RUGGEDCOM NETCONF Chapter 5 Reference Guide Changing Configuration Data </source> </copy-config> </rpc>]]>]]> The file is saved to the /var/lib/config directory on the device. To overwrite a configuration with a configuration file, do the following: Upload an XML configuration file to the device. For instructions on how to upload a configuration file, refer to the RUGGEDCOM NETCONF v Web Interface User Guide or RUGGEDCOM NETCONF v CLI User Guide for the device.
  • Page 58: Replacing Data

    Chapter 5 RUGGEDCOM NETCONF Changing Configuration Data Reference Guide <running/> </target> <source> <url>file:///standard_config.xml</url> </source> </copy-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 59 RUGGEDCOM NETCONF Chapter 5 Reference Guide Changing Configuration Data <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]> Issue an <rpc> request with the replace operation: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <{root element} xmlns="{namespace URL}" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> {configuration data with nc:operation="replace" attribute} </{root element}>...
  • Page 60: Deleting Data

    Chapter 5 RUGGEDCOM NETCONF Changing Configuration Data Reference Guide <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the target configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock> </rpc>]]>]]> Section 5.2.4 Deleting Data To delete a specific configuration setting, do the following: Connect to and log in to the device. Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 61 RUGGEDCOM NETCONF Chapter 5 Reference Guide Changing Configuration Data </edit-config> </rpc>]]>]]> • {root element} The top level element in the data model under which the data is located. Note that you need to declare the xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" namespace at this point. •...
  • Page 62: Validating Changes

    Chapter 5 RUGGEDCOM NETCONF Changing Configuration Data Reference Guide Section 5.2.5 Validating Changes You can validate the syntax of a specified configuration with the validate comment. Validation confirms the syntax of the specified configuration. After making extensive changes to the candidate configuration, it is recommended that your validate the candidate configuration before committing it.
  • Page 63: Committing Changes

    RUGGEDCOM NETCONF Chapter 5 Reference Guide Changing Configuration Data • The <error-path> element indicates where in the configuration the syntax error is found. • The <error-message> element provides a message, when one is available, describing the error. • The <bad-element> element indicates the element related to the error. For more information on NETCONF errors, see Internet Engineering Task Force RFC 6241 Appendix A.
  • Page 64 Chapter 5 RUGGEDCOM NETCONF Changing Configuration Data Reference Guide Committing Changes...
  • Page 65: Ruggedcom Rox Ii Actions

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions RUGGEDCOM ROX II Actions This section describes how to activate RUGGEDCOM ROX II actions on the device with an <rpc> message through NETCONF. Actions perform functions directly on the device, such as shutting down the device, rebooting, clearing port statistics, and more.
  • Page 66: Admin Namespace Actions

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide Action Path to Action in RUGGEDCOM ROX II interfaces » switch{interface} » diagnostics » clear-cable-stats- Section 6.2.11, “clear-cable-stats-port (Switch Port)” port services » time » ntp » ntp-status Section 6.3.1, “ntp-status” services » link-failover{interface} » log Section 6.3.2, “log (Link-Failover)” Section 6.3.3, “start-test (Link Failover)” services »...
  • Page 67: Snmp-Discover

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions • Section 6.1.11, “restore-factory-defaults” • Section 6.1.12, “delete-logs” • Section 6.1.13, “install-files” • Section 6.1.14, “backup-files (Backup Files)” • Section 6.1.15, “full-configuration-save” • Section 6.1.16, “full-configuration-load” Section 6.1.1 snmp-discover This action discovers the SNMP engine ID for a given IP address and port. Parameters include the {ip address}, {port}, and {trap-port}.
  • Page 68: Decline-Upgrade

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide <software-upgrade> <launch-upgrade/> </software-upgrade> </admin> </data> </action> </rpc>]]>]]> Section 6.1.3 decline-upgrade This action declines a RUGGEDCOM ROX II software upgrade. After an upgrade occurs and while the system is awaiting a reboot to the upgraded partition, use the <decline-upgrade> action to cancel the attempt to run the upgraded partition.
  • Page 69: Roxflash

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions Section 6.1.5 roxflash This action flashes a RUGGEDCOM ROX II image to the alternate partition. On rebooting, the device boots from the flashed partition. Configurations are not transferred. This action takes a single parameter: {url}. <rpc message-id="101"...
  • Page 70: Shutdown

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide <data> <admin xmlns="http://ruggedcom.com/ns/rmf_admin"> <acknowledge-all-alarms/> </admin> </data> </action> </rpc>]]>]]> Section 6.1.8 shutdown This action shuts down the device. After using this action, the device shuts down and provides a time-out period during which you can remove power from the device. The default time-out period is 300 seconds (five minutes). At the end of the time-out period, the device reboots and restarts.
  • Page 71: Restore-Factory-Defaults

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions </admin> </data> </action> </rpc>]]>]]> • {time} The date and time in the format YYYY-MM-DD HH:MM:SS. Section 6.1.11 restore-factory-defaults This action restores the device to its factory default settings. This action does not take any parameters. <rpc message-id="101"...
  • Page 72: Backup-Files (Backup Files)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide </rpc>]]>]]> • {fileType} The type of file to copy to the device. Must be one of the following: config, featurekey, elancertificate, ipseccertificate, cacertificate, or crlfiles. • {url} The URL and filename of the RUGGEDCOM NETCONF file to copy. The file transfer supports SCP, SFTP, FTPS, and HTTP.
  • Page 73: Full-Configuration-Load

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions <rpc message-id="101" 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"> <full-configuration-save> <format>{format}</format> <file-name>{fileName}</file-name> </full-configuration-save> </admin> </data> </action> </rpc>]]>]]> • {format} The format for the configuration file: cli. • {fileName} The name for the configuration file. Section 6.1.16 full-configuration-load This action loads a configuration from the specified file found in the /var/lib/config directory on the device.
  • Page 74: Reset (Modem)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide • Section 6.2.2, “at (Modem)” • Section 6.2.3, “reset (Cellular Modem)” • Section 6.2.4, “at (Cellular Modem)” • Section 6.2.5, “reset (Serial Port)” • Section 6.2.6, “clear-serial-port-stats” • Section 6.2.7, “restart-serserver” • Section 6.2.8, “reset-port (Switch Port)” •...
  • Page 75: Reset (Cellular Modem)

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions </modem> </interfaces> </data> </action> </rpc>]]>]]> • {interfaceName} The name of the modem interface. • {atCommand} The AT command to send to the modem. The command must begin with the prefix AT. Section 6.2.3 reset (Cellular Modem) This action resets the cellular modem.
  • Page 76: Reset (Serial Port)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide </cellmodem> </interfaces> </data> </action> </rpc>]]>]]> • {module} The module number for the cellular modem. • {port} The port number for the cellular modem. • {atCommand} The AT command to send to the modem. The command must begin with the prefix AT. Section 6.2.5 reset (Serial Port) This action resets the specified serial port.
  • Page 77: Restart-Serserver

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions </serial> </interfaces> </data> </action> </rpc>]]>]]> • {module} The module number for the serial port. • {port} The port number for the serial port. Section 6.2.7 restart-serserver This action restarts the serial server. This action does not take any parameters. <rpc message-id="101"...
  • Page 78: Clear-Port-Stats (Switch Port)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide Section 6.2.9 clear-port-stats (Switch Port) This action clears the port statistics for the specified switch port. Specify the switch module and port in the <module> and <port> elements. This action does not take any parameters. <rpc message-id="101"...
  • Page 79: Clear-Cable-Stats-Port (Switch Port)

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions Section 6.2.11 clear-cable-stats-port (Switch Port) This action clears the cable test diagnostic statistics on the specified switch port. Specify the switch module and port in the <module> and <port> elements. This action does not take any parameters. <rpc message-id="101"...
  • Page 80: Log (Link-Failover)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide <time> <ntp> <ntp-status/> </ntp> </time> </services> </data> </action> </rpc>]]>]]> Section 6.3.2 log (Link-Failover) This action displays the link failover log. This action does not take any parameters. <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action xmlns="http://tail-f.com/ns/netconf/actions/1.0"> <data>...
  • Page 81: Cancel-Test (Link Failover)

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions • {crlFileName} The amount of time, in minutes, to wait before starting the link failover test. Section 6.3.4 cancel-test (Link Failover) This action stops the link failover test on the specified interface. Specify the name of the interface in the <name> element.
  • Page 82: Clear-Stp-Stats (Switch)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide • Section 6.4.2, “flush-dynamic-rules (Switch)” • Section 6.4.3, “reset-all-switch-ports (Switch)” • Section 6.4.4, “clear-all-switch-stats (Switch)” • Section 6.4.5, “clear-cable-stats-all (Switch)” Section 6.4.1 clear-stp-stats (Switch) This action clears the spanning-tree protocol statistics. This action does not take any parameters. <rpc message-id="101"...
  • Page 83: Clear-All-Switch-Stats (Switch)

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions </action> </rpc>]]>]]> Section 6.4.4 clear-all-switch-stats (Switch) This action clears all switch statistics. This action does not take any parameters. <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action xmlns="http://tail-f.com/ns/netconf/actions/1.0"> <data> <switch xmlns="http://ruggedcom.com/ns/rmf_ifswitch"> <clear-all-switch-stats/> </switch> </data> </action> </rpc>]]>]]>...
  • Page 84: Display-Public-Key (Ipsec)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide • Section 6.5.8, “remove-crl (IPSEC)” Section 6.5.1 display-public-key (IPSEC) This action displays the public RSA key. This action does not take any parameters. <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action xmlns="http://tail-f.com/ns/netconf/actions/1.0"> <data> <tunnel xmlns="http://ruggedcom.com/ns/rmf_iftunnel"> <ipsec> <display-public-key/>...
  • Page 85: Install-Ca-Certificate (Ipsec)

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions <user>{remoteUserName}</user> <password>{remoteUserPassword}</password> </install-certificate> </certificate> </ipsec> </tunnel> </data> </action> </rpc>]]>]]> • {remoteHost} The hostname or IP address of the remote host. • {remotePort} The remote host network port for the ssh protocol, •...
  • Page 86: Install-Crl-File (Ipsec)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide • {remotePort} The remote host network port for the ssh protocol, • {caCertFilePath} The absolute path and file name for the ca-certificate file on the remote host. • {remoteUserName} A user name on the remote host. •...
  • Page 87: Remove-Ca-Certificate (Ipsec)

    RUGGEDCOM NETCONF Chapter 6 Reference Guide RUGGEDCOM ROX II Actions Section 6.5.6 remove-ca-certificate (IPSEC) This action removes the specified ca-certificate from the IPSec configuration. Specify the certificate name in the <name> element. This action does not take any parameters. <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action xmlns="http://tail-f.com/ns/netconf/actions/1.0">...
  • Page 88: Remove-Crl (Ipsec)

    Chapter 6 RUGGEDCOM NETCONF RUGGEDCOM ROX II Actions Reference Guide Section 6.5.8 remove-crl (IPSEC) This action removes the specified crl file from the IPSec configuration. Specify the crl file name in the <name> element. This action does not take any parameters. <rpc message-id="101"...
  • Page 89: Examples

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Examples This section provides examples of how to set and retrieve data on a device. Each example shows how to set or retrieve a specific element or set of elements. Each example also demonstrates a general NETCONF concept, such as how to retrieve data from the running configuration, or how to use special attributes to delete or replace data.
  • Page 90 Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide NETCONF Example Example demonstrates these techniques: Section 7.22, “Retrieving Static Multicast Status on a Layer 3 Device” Querying for running configuration data. Section 7.23, “Replacing an IP Address” Recommended editing procedure. Replacing data with the nc:operation="replace" attribute. Section 7.24, “Configuring a Port to Dynamically Obtain an IP Recommended editing procedure.
  • Page 91 RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples NETCONF Example Example demonstrates these techniques: Section 7.50, “Removing a CRL File” Removing a CRL file from the device. CONTENTS • Section 7.1, “Getting the System Name” • Section 7.2, “Getting the ROX Release” • Section 7.3, “Getting the Chassis Status” •...
  • Page 92: Getting The System Name

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide • Section 7.35, “Enabling the DHCP Server Service” • Section 7.36, “Disabling an Ethernet Port” • Section 7.37, “Enabling an Ethernet Port” • Section 7.38, “Checking an IP Address on a Specific Port using the Interfaces Namespace” •...
  • Page 93: Getting The Chassis Status

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples <get> <filter type="subtree"> <chassis xmlns="http://ruggedcom.com/ns/rmf_chassis"> <chassis-status> <rox-release></rox-release> </chassis-status> </chassis> </filter> </get> </rpc>]]>]]> Section 7.3 Getting the Chassis Status In this example, a single <rpc> queries retrieves the chassis status information from the device. This example shows how to issue a query for state information directly from the device. <rpc message-id="2"...
  • Page 94: Clearing All Alarms

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide This example shows how to use a NETCONF action on a running device. <rpc message-id="101" 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"> <acknowledge-all-alarms/> </admin> </data> </action> </rpc>]]>]]> Section 7.6 Clearing All Alarms In this example, a single <rpc> clears all alarms on the device with the  clear-all-alarms action. This example shows how to use a NETCONF action on a running device.
  • Page 95: Changing The System Name By Locking And Committing

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples <rpc message-id="101" 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"> <restore-factory-defaults/> </admin> </data> </action> </rpc>]]>]]> Section 7.9 Changing the System Name by Locking and Committing In this example, multiple <rpc> requests change the system name in the candidate configuration and then commit the changes.
  • Page 96: Changing The System Name Directly

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock> </rpc>]]>]]>...
  • Page 97: Creating A Static Vlan

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Section 7.11 Creating a Static VLAN In this example, multiple <rpc> requests create a static VLAN in the candidate configuration and then commit the changes. The following shows the recommended procedure for making configuration changes on a device: Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 98: Assigning A Pvid On A Port

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the target configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock> </rpc>]]>]]> Section 7.12 Assigning a PVID on a Port In this example, multiple <rpc> requests assign a PVID to a port in the candidate configuration and then commit the changes.
  • Page 99: Disabling Spanning Tree On A Specific Port

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples <pvid>0086</pvid> <format>untagged</format> </vlan> </switch> </interface> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 100: Configuring An Ip Address On A Specific Port

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide Discard uncommitted changes: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]> Disable spanning tree with the nc:delete attribute: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <interface xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://ruggedcom.com/ns/ rmf_if"> <switch> <slot>lm4</slot> <port>6</port> <spanning-tree> <enabled nc:operation="delete"/> </spanning-tree>...
  • Page 101 RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="230"> <lock> <target> <running/> </target> </lock> </rpc>]]>]]> Lock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="231"> <lock> <target> <candidate/> </target> </lock> </rpc>]]>]]> Discard uncommitted changes: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]>...
  • Page 102: Deleting An Ip Address

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <target> <running/> </target> </unlock> </rpc>]]>]]> Section 7.15 Deleting an IP Address In this example, multiple <rpc> requests delete an IP address in the candidate configuration and then commit the changes. This example shows the recommended procedure for making configuration changes on a device. The following procedure shows how container elements need to be deleted for some elements.
  • Page 103: Setting A Static Route

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock>...
  • Page 104: Disabling Spanning Tree Globally

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide Define the static route: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <routing xmlns="http://ruggedcom.com/ns/rmf_routing"> <static> <ipv4> <route> <network>10.200.16.0/20</network> <via> <gw>172.30.128.1</gw> </via> </route> </ipv4> </static> </routing> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/>...
  • Page 105 RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples <lock> <target> <running/> </target> </lock> </rpc>]]>]]> Lock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="231"> <lock> <target> <candidate/> </target> </lock> </rpc>]]>]]> Discard uncommitted changes: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]> Disable spanning tree: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config>...
  • Page 106: Retrieving All Ip Addresses From The Running Configuration

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide Section 7.18 Retrieving all IP Addresses from the Running Configuration In this example, a single <rpc> request retrieves all IP addresses from the running configuration on a device. The following is the typical procedure for querying data from the running configuration. •...
  • Page 107: Configuring Static Multicast Routing On A Layer 3 Device

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Section 7.20 Configuring Static Multicast Routing on a Layer 3 Device In this example, multiple <rpc> requests enable static multicast routing in the candidate configuration and then commit the changes. The following is the recommended procedure for making configuration changes on a device. Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 108: Enabling Static Multicast Routing On A Layer 3 Device

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock> </rpc>]]>]]>...
  • Page 109: Retrieving Static Multicast Status On A Layer 3 Device

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Enable static multicast routing: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <routing xmlns="http://ruggedcom.com/ns/rmf_routing"> <multicast> <static> <enabled/> </static> </multicast> </routing> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 110: Replacing An Ip Address

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <static> <status></status> </static> </multicast> </routing> </filter> </get> </rpc>]]>]]> Section 7.23 Replacing an IP Address In this example, multiple <rpc> requests replace an IP address in the candidate configuration and then commit the changes. The following is the recommended procedure for making configuration changes on a device. This example also shows how to use the nc:operation="replace"...
  • Page 111: Configuring A Port To Dynamically Obtain An Ip Address

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock>...
  • Page 112: Configuring Ospf Area And Network On A Layer 3 Device

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide </lock> </rpc>]]>]]> Configure the <ip-address-src> setting for the port: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <interface xmlns="http://ruggedcom.com/ns/rmf_if"> <eth> <slot>lm4</slot> <port>1</port> <ip-address-src>dynamic</ip-address-src> </eth> </interface> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/>...
  • Page 113 RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples <lock> <target> <running/> </target> </lock> </rpc>]]>]]> Lock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="231"> <lock> <target> <candidate/> </target> </lock> </rpc>]]>]]> Discard uncommitted changes: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]> Configure the OSPF area and network: <rpc message-id="233"...
  • Page 114: Enabling The Ospf Passive-Default Option

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <running/> </target> </unlock> </rpc>]]>]]> Section 7.26 Enabling the OSPF Passive-Default Option In this example, multiple <rpc> requests configure the OSPF passive-default option in the candidate configuration and then commit the changes. The following is the recommended procedure for making configuration changes on a device. Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 115: Configure An Ospf Non-Passive Port

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock> </rpc>]]>]]> Section 7.27 Configure an OSPF Non-Passive Port In this example, multiple <rpc>...
  • Page 116: Configuring Ospf Parameters

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <candidate/> </target> <config> <routing xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://ruggedcom.com/ns/ rmf_routing"> <dynamic> <ospf> <interface> <ifname>switch.0022</ifname> <passive>false</passive> </interface> </ospf> </dynamic> </routing> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock>...
  • Page 117 RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Lock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="231"> <lock> <target> <candidate/> </target> </lock> </rpc>]]>]]> Discard uncommitted changes: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]> Configure the OSPF parameters: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <routing xmlns="http://ruggedcom.com/ns/rmf_routing">...
  • Page 118: Enabling The Ospf Redistribute-Connected Option

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide </rpc>]]>]]> Section 7.29 Enabling the OSPF redistribute-connected Option In this example, multiple <rpc> requests enable the OSPF redistribute-connected option in the candidate configuration and then commit the changes. The following is the recommended procedure for making configuration changes on a device. Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 119: Enabling Ospf On A Layer 3 Device

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock> </rpc>]]>]]> Section 7.30 Enabling OSPF on a Layer 3 Device In this example, multiple <rpc>...
  • Page 120: Retrieving Ospf Status

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <routing xmlns="http://ruggedcom.com/ns/rmf_routing"> <dynamic> <ospf> <enabled/> </ospf> </dynamic> </routing> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 121: Retrieving All Data From The Routing Namespace

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples Section 7.32 Retrieving All Data from the Routing Namespace In this example, a single <rpc> request retrieves all configuration data from the Routing namespace. The following is the typical procedure for querying data from the running configuration. •...
  • Page 122: Configure The Dhcp Server Port Listening For Dhcp Client Requests

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <config> <services xmlns="http://ruggedcom.com/ns/rmf_services"> <dhcpserver> <subnet> <name>192.168.3.0/24</name> <network-ip>192.168.3.0/24</network-ip> <options> <iprange> <start>192.168.3.30</start> <end>192.168.3.35</end> </iprange> </options> </subnet> </dhcpserver> </services> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock>...
  • Page 123 RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples </target> </lock> </rpc>]]>]]> Lock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="231"> <lock> <target> <candidate/> </target> </lock> </rpc>]]>]]> Discard uncommitted changes: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]> Configure the DHCP Server listen interface: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config>...
  • Page 124: Enabling The Dhcp Server Service

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide Section 7.35 Enabling the DHCP Server Service In this example, multiple <rpc> requests enable the DHCP server service in the candidate configuration and then commit the changes. The following is the recommended procedure for making configuration changes on a device. Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"...
  • Page 125: Disabling An Ethernet Port

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock> </rpc>]]>]]> Section 7.36 Disabling an Ethernet Port In this example, multiple <rpc> requests disable an Ethernet port in the candidate configuration and then commit the changes.
  • Page 126: Enabling An Ethernet Port

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide </eth> </interface> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock>...
  • Page 127: Checking An Ip Address On A Specific Port Using The Interfaces Namespace

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="232"> <discard-changes/> </rpc>]]>]]> Enable the Ethernet port: <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <interface xmlns="http://ruggedcom.com/ns/rmf_if"> <eth> <slot>lm4</slot> <port>1</port> <enabled/> </eth> </interface> </config> </edit-config> </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/>...
  • Page 128: Retreiving All Data From Running Database Including Default Values

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get> <filter type="subtree"> <interfaces xmlns="http://ruggedcom.com/ns/rmf_ifs"> <ip> <name>fe-4-1</name> <ipv4> <address> <local></local> </address> </ipv4> </ip> </interfaces> </filter> </get> </rpc>]]>]]> Section 7.39 Retreiving All Data From Running Database Including Default Values In this example, a single <rpc> request retrieves information (including default values) from a specified configuration on a running database.
  • Page 129: Changing A User's Password

    </rpc>]]>]]> IMPORTANT! The password must be provided in hash format. Use a utility such as mkpasswd (available on most Linux distributions) to generate a hashed password. For a Windows-based utility, contact Siemens Customer Service. Lock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="230">...
  • Page 130: Displaying The Status Of The Ipsec Service

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide </rpc>]]>]]> Commit the changes: <rpc message-id="234" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit/> </rpc>]]>]]> Unlock the candidate configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="235"> <unlock> <target> <candidate/> </target> </unlock> </rpc>]]>]]> Unlock the running configuration: <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="236"> <unlock> <target> <running/> </target> </unlock>...
  • Page 131 RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples <name>{name}</name> <startup>{startup}</startup> <authenticate>{authenticate}</authenticate> <connection-type>{connection type}</connection-type> <monitor-interface>{monitor interface}</monitor-interface> <left> <public-ip> <type>{ip type}</type> <value>{ip value}</value> </public-ip> <subnet> <network>{network}</network> </subnet> <key> <type>{key type}</type> <certificate>{certificate}</certificate> </key> <nexthop> <type>{nexthop type}</type> <value>{nexthop value}</value> </nexthop> </left> <right> <public-ip> <type>{ip type}</type> <value>{ip value}</value>...
  • Page 132: Installing A Ca Certificate

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide • {ip type} The public ip address type of the IPSec tunnel. Must be one of the following: address, any, default-route hostname, or none. • {ip value} The value is based on the selected {ip type} value. For example, if address is chosen as the ip type, an ip address is defined here.
  • Page 133: Configuring A Signed Ca Certificate

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples • {name} The name of the CA certificate. • {ca name} The name of the Certificate Authority. • {private key name} The name of the private key that corresponds to the CA certificate. Section 7.45 Configuring a Signed CA Certificate This action replaces an existing signed CA certificate on the device with the contents of a new CA certificate.
  • Page 134: Installing A Crl File

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide <rpc message-id="233" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <security xmlns="http://ruggedcom.com/ns/rmf_security"> <crypto> <private-key> <name>{name}</name> <algorithm>{algorithm}</algorithm> <contents> -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDCI7Xy6OF1XVcQNTSqTyLDKJ+knhYQawrgRoE4Q677q9taftee... dsCQmC2smAtdrfY/VaGJrX6ZdiUyRcxNLsDNBoNQcZQH -----END RSA PRIVATE KEY----- </contents> </private-key> </crypto> </security> </config> </edit-config> </rpc>]]>]]> • {name} The name of the private key.
  • Page 135: Removing A Certificate

    RUGGEDCOM NETCONF Chapter 7 Reference Guide Examples </crypto> </security> </config> </edit-config> </rpc>]]>]]> • {name} The name of the .crl file. Section 7.48 Removing a Certificate This action removes the specified certificate from the device. Specify the certificate name in the <name> element. This action does not take any parameters.
  • Page 136: Removing A Crl File

    Chapter 7 RUGGEDCOM NETCONF Examples Reference Guide xmlns="http://ruggedcom.com/ns/rmf_security"> <crypto> <ca nc:operation="delete"><name>{name}</name> <key-cert-sign-certificate> -----BEGIN CERTIFICATE----- MIID5zCCAs+gAwIBAgIJAK85lF/lcPaKMA0GCSqGSIb3DQEBCwUAMIGJMQswCQYD... SrCK8Rwp9S89hiwD5FNlQcIvYnjacNg8G9l8CNiLF71BK4lEroPk3ZVTpw== -----END CERTIFICATE----- </key-cert-sign-certificate> </ca> </crypto> </security></config> </edit-config> </rpc>]]>]]> • {name} The name of the CA certificate to remove. Section 7.50 Removing a CRL File This action removes the specified .crl file from the device. Specify the .crl file name in the <name> element. This action does not take any parameters.
  • Page 137: Netconf Xml Elements

    RUGGEDCOM NETCONF Chapter 8 Reference Guide NETCONF XML Elements NETCONF XML Elements This chapter details the individual XML elements that can be utilized when using NETCONF. CONTENTS • Section 8.1, “]]>]]>” • Section 8.2, “<close-session/>” • Section 8.3, “<commit>” • Section 8.4, “<copy-config>” • Section 8.5, “<data>”...
  • Page 138: Close-Session

    Chapter 8 RUGGEDCOM NETCONF NETCONF XML Elements Reference Guide Section 8.2 <close-session/> Description: Requests the graceful termination of a NETCONF session. When a NETCONF server receives a <close-session> request, it does the following: • gracefully closes the session • releases any locks and resources associated with the session •...
  • Page 139: Copy-Config

    RUGGEDCOM NETCONF Chapter 8 Reference Guide NETCONF XML Elements <rpc> <commit> <confirmed/> <confirm-timeout>30</confirm-timeout> </commit> </rpc> ]]>]]> Section 8.4 <copy-config> Description: Creates or replaces a specified <target> configuration with a specified <source> configuration. If the <target> configuration exists, it is overwritten. If the <target> configuration does not exist, a new configuration is created. Parameters: <target>...
  • Page 140: Discard-Changes

    Chapter 8 RUGGEDCOM NETCONF NETCONF XML Elements Reference Guide Section 8.6 <discard-changes> Description: Discards changes to the candidate configuration and reverts the candidate configuration to the currently running configuration. Example: To discard changes to the candidate configuration: <rpc> <discard-changes/> </rpc> ]]>]]> Section 8.7 <edit-config>...
  • Page 141: Get-Config

    RUGGEDCOM NETCONF Chapter 8 Reference Guide NETCONF XML Elements <bad-attribute>message-id</bad-attribute> <bad-element>rpc</bad-element> </error-info> </rpc-error> </rpc-reply> ]]>]]> Section 8.9 <get-config> Description: Requests all or part of a specified configuration. Parameters: <source> : the configuration to query: candidate or running. <filter> : identifies the configuration segments to retrieve. The filter element contains elements describing the configuration segment to return.
  • Page 142: Section 8.10, "

    Chapter 8 RUGGEDCOM NETCONF NETCONF XML Elements Reference Guide <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>...
  • Page 143: Kill-Session

    RUGGEDCOM NETCONF Chapter 8 Reference Guide NETCONF XML Elements Section 8.11 <kill-session> Description: Terminates a specified NETCONF session, cancelling any operations in progress and releasing all locks, resources, and connections for the session. <kill-session> does not roll back the configuration or state changes made by the configuration being terminated. If the session being terminated is performing a confirmed commit when the <kill-session>...
  • Page 144: Rpc

    Chapter 8 RUGGEDCOM NETCONF NETCONF XML Elements Reference Guide Section 8.13 <ok/> Description: Appears in an <rpc-reply> message to indicate successful completion of a NETCONF request. Example: An <rpc-reply> message indicating the successful completion of a NETCONF request: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="104"> <ok/>...
  • Page 145: Rpc-Reply

    RUGGEDCOM NETCONF Chapter 8 Reference Guide NETCONF XML Elements <error-message> : shows a human-readable error message describing the error condition. This element does not appear if no error message is available for the error condition. <error-info> : shows protocol or data-model error content. This element does not appear if no error content is available for the error condition.
  • Page 146: Target

    Chapter 8 RUGGEDCOM NETCONF NETCONF XML Elements Reference Guide <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="104"><rpc- error> <error-type>protocol</error-type> <error-tag>lock-denied</error-tag> <error-severity>error</error-severity> <error-info> <session-id>3216</session-id> </error-info> </rpc-error> </rpc-reply>]]>]]> Section 8.17 <target> Description: Specifies the configuration on which to perform on operation. <target> is used in the <copy-config>, <delete- config>, <edit-config>, <lock>, and <unlock>...
  • Page 147: Validate

    RUGGEDCOM NETCONF Chapter 8 Reference Guide NETCONF XML Elements ]]>]]> Section 8.19 <validate> Description: Validates the syntax of the specified configuration. After making changes to the candidate configuration, use <validate> to make sure the syntax is correct. Parameters: <source> : specifies the configuration to validate: <candidate/> or <running/>. Response: If the NETCONF device can complete the request, it sends an <rpc-reply>...
  • Page 148 Chapter 8 RUGGEDCOM NETCONF NETCONF XML Elements Reference Guide <validate>...

This manual is also suitable for:

Rx1500Rx1511Rx1512Rx5000Mx5000Mx5000re ... Show all

Table of Contents