NETCONF YANG Beginners Course - Book

KNET Solutions (Online Training Centre),

http://knetsolutions.in

knetsolutions2@gmail.com

Phone/WhatsApp: +919445042007

Online Training, Consulting & Academic SDN Project assistance.


1. Course Introduction

This Book is (NETCONF YANG Beginners Course book), prepared by KNET Solutions. This Book is used as Course material for UDEMY - LEARN NETCONF YANG Course.

The Online Training link is here UDEMY NETCONF YANG Course

This Course covers network automation, yang, netconf theory, pyang, netconf operations, lab with cisco devnet, capabilities, notifications etc.

Some book contents (IMAGE/Text) are copied from Freely available resources from internet / RFCs/ Opensource materials. Thanks to the original authors.

This Book is free to use.


2. Network Automation Introduction

Network automation is the process of automating the configuration, management, testing, deployment, and operations of physical and virtual devices within a network.

Recently we start hearing netconf,yang for network automation. Simply Netconf is a protocol to configure/manage the device.

So far, how we configure the devices using.

1. CLI/UI

2. SNMP


CLI

CLI scripting is the primary approach to making automated configuration changes to the network.

Cisco CLI

CLI

Using Perl, TCL/TK, Expect, Python scripts.

Lack of transaction management

Configuring a device maybe a complex task, involving multiple actions

Example: OSPF Protocol configuration in the Cisco router

https://study-ccna.com/ospf-configuration/

Usually these multiple actions can not be done partially, as this would leave the device in an undefined state.

In case one action fails, we need to rollback. This requires extensive programming when transaction management is not supported and this is the case with CLI.

Syntax changes

Usually whenever a new device software is released, new CLI commands are added but unfortunately in some cases existing commands are modified or deleted. This means that every other software that was using CLI as an application programming interface (API) will fail

CLIs are designed to be used by humans and not an API for programmatic access.


SNMP

SNMP was developed to be used for both monitoring and management, i.e. it has the capability to write changes. So why is SNMP mostly used for fault and performance monitoring and not configuration changes?

No discovery

lack of a standard automatic discovery process that finds the (correct) MIB modules that the device is using.

This means that the discovery work must be done by the users or operators and as it is complex, configuration management with SNMP has been abandonded.

SNMP does not distinguish between the operational and configuration data stored within a device.

Its harder to program.

SNMP


Netconf Key features

The key with NETCONF protocol is that it was designed to address the shortcomings of existing practices and protocols for configuration management including:

  • Distinction between configuration and state data

  • Multiple configuration data stores (candidate, running, startup)

  • Configuration testing and validation support (validation, confirmed commit,rollback on error)

  • Selective data retrieval with filtering

  • Streaming and playback of event notifications (filter the notifications with date)

  • Extensible procedure call mechanism (additional operations)


Current SDN/NFV Industry trends

  • NETCONF is one of the key APIs used by SDN Controller on the Southbound to control network devices

  • OpenDay Light, ONOS SDN Controller Supports Netconf in South bound Interface

  • Automatic provisioning/orchestration

Automatic Service Deployment & Provisioning

NETCONF/YANG is a key enabler of the new paradigm of NFV,where services can be designed at a high level, independent of the complexities and device dependencies of the underlying infrastructure.

-Assembled "on the fly" from a range of virtualized functions from multiple vendors

-These services will be provisioned in minutes and their operation highly automated.

Zero touch provisioning:

Zero touch provisioning (ZTP) is a feature that allows the devices to be provisioned and configured automatically, eliminating most of the manual labor involved with adding them to a network.

Netconf plays a major role in the ZTP.

https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/


Current Network Automation Trends

Automation

Ansible, Chef, Puppet, Salt,


3. NetConf

Introduction

Ref: https://www.rfc-editor.org/rfc/rfc6241.txt

The NETCONF protocol defines a simple mechanism through which

  • a network device can be managed,
  • configuration data information can be retrieved,
  • and new configuration data can be uploaded and manipulated.

The protocol allows the device to expose application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets.

The NETCONF protocol uses a remote procedure call (RPC) paradigm.

A client encodes an RPC in XML and sends it to a server using a secure, connection-oriented session.

The server responds with a reply encoded in XML.

Netconf overview

The server is typically a network device. The client can be a script or application typically running as part of a network manager.

Messages:

  1. Server & Client exchanges its capabilities in Hello Message (Session establishment)
  2. Client sends RPC Message and get the RPC Reply Message

HELLO Message:

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability: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:with-defaults:1.0?basic-mode=explicit&amp;also-supported=report-all-tagged</capability>
.................SKIPPED
</capabilities>
<session-id>324</session-id>
</hello>

Operations Message:

RPC

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname/>
</native>
</filter>
</get-config>
</rpc>

Response

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<data>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname>csr1000v</hostname>
</native>
</data>
</rpc-reply>

Transport

NetConf Port Number: TCP 830

  1. Connection-Oriented Operation (TCP)

  2. Authentication, Integrity, and Confidentiality

connections could be encrypted using Transport Layer Security (TLS) or Secure Shell (SSH) depending on the underlying protocol.

NETCONF connections MUST be authenticated. The transport protocol is responsible for authentication of the server to the client and authentication of the client to the server.

For example, a NETCONF server on a device that supports RADIUS might allow the use of RADIUS to authenticate NETCONF sessions

The access permissions of a given client, identified by its NETCONF username, are part of the configuration of the NETCONF server.


Layers

NETCONF can be conceptually partitioned into four layers as shown in the below Figure.

Netconf layer

The Secure Transport layer provides a communication path between the client and server.

The Messages layer provides a simple, transport-independent framing mechanism for encoding RPCs and notifications.

The Operations layer defines a set of base protocol operations invoked as RPC methods with XML-encoded parameters.

The YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models and protocol operations, covering the Operations and the Content layers of Figure .


Messages

XML

XML serves as the encoding format for NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and tools specific to XML.

All NETCONF protocol elements are defined in the following namespace:

urn:ietf:params:xml:ns:netconf:base:1.0

RPC

The NETCONF protocol uses an RPC-based communication model.

NETCONF peers use

<rpc> and <rpc-reply>

elements to provide transport protocol-independent framing of NETCONF requests and responses.


Datastores

NETCONF defines the existence of one or more configuration datastores and allows configuration operations on them.

Running DataStore

This is always present. The running configuration datastore holds the complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present.

capability

urn:ietf:params:netconf:capability:writable-running:1.0


Startup DataStore

This is optional capability. stores the startup config. The device supports separate running and startup configuration datastores.

The startup configuration is loaded by the device when it boots. Operations that affect the running configuration will not be automatically copied to the startup configuration. An explicit copy-config operation from the running to the startup is used to update the startup configuration to the current contents of the running configuration.

capability

urn:ietf:params:netconf:capability:startup:1.0

Candidate DataStore

This is optional capability. The candidate configuration is a full configuration data set that serves as a work place for creating and manipulating configuration data. Additions, deletions, and changes can be made to this data to construct the desired configuration data.

capability

urn:ietf:params:netconf:capability:candidate:1.0

A commit operation MAY be performed at any time that causes the device's running configuration to be set to the value of the candidate configuration.

datastore


4. Netconf Basic operations

The NETCONF protocol provides a small set of low-level operations to manage device configurations and retrieve device state information. The base protocol provides operations to retrieve, configure, copy, and delete configuration datastores.

Additional operations are provided, based on the capabilities advertised by the device(such as initialize the device etc).

  • get
  • get-config
  • lock
  • edit-config
  • unlock
  • close-session
  • kill-session
  • copy-config
  • delete-config

get

Retrieve running configuration and device state information.

filter: This parameter specifies the portion of the system configuration and state data to retrieve.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<get>
</get>
</rpc>

get-config

Retrieve all or part of a specified configuration datastore.

source: Name of the configuration datastore being queried, such as running.

filter: optional.we can specify the filter for the response.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>

lock

The lock operation allows the client to lock the entire configuration datastore system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>

edit-config

The edit-config operation updates the specified configuration to the specified target configuration datastore. In simplet term, configuring the device.

-target: Name of the configuration data store -default-operation: optional. merge(default),replace,none -test-option: optional. test-only, set, test-then-set -error-option: optional. stop-on-error, continue-on-error, rollback-on-error -config: A hierarchy of configuration data

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>1500</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>

unlock

Description: The unlock operation is used to release a configuration lock, previously obtained with the lock operation.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>

close-session

Request graceful termination of a NETCONF session.

The server will release any locks and resources associated with the session and gracefully close any associated connection

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>

kill-session

Description: Force the termination of a NETCONF session.

When a NETCONF entity receives a kill-session request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<kill-session>
<session-id>4</session-id>
</kill-session>
</rpc>

Other Important Operations

Rollback

During Configuration of the device, If an error condition occurs such that an error severity rpc-error element is generated, the server will stop processing the edit-config operation and restore the specified configuration to its complete state at the start of this edit-config operation. This option requires the server to support the :rollback-on-error capability

capability

urn:ietf:params:netconf:capability:rollback-on-error:1.0

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>

Validate Operation.

Validation consists of checking a complete configuration for syntactical and semantic errors before applying the configuration to the device.

capability

urn:ietf:params:netconf:capability:validate:1.1

1.1 test-only" option in the test-option parameter of the edit-configoperation.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<test-option> test-only</test-option>
<config>
<top xmlns="http://example.com/schema/1.2/config">
<interface>
<name>Ethernet0/0</name>
<mtu>100000</mtu>
</interface>
</top>
</config>
</edit-config>
</rpc>

1.0 (Old format)

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<validate>
<source>
<candidate/>
</source>
</validate>
</rpc>

Candidate datastore operations

capability

urn:ietf:params:netconf:capability:candidate:1.0

Commit

To commit the candidate configuration as the device's new current configuration, use the commit operation.

If the device is unable to commit all of the changes in the candidate configuration store, then the running configuration MUST remain unchanged

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>

discard-changes

If the client decides that the candidate configuration is not to be committed, the discard-changes operation can be used to revert the candidate configuration to the current running configuration.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<discard-changes/>
</rpc>

other datastore operations

capability

urn:ietf:params:netconf:capability:startup:1.0

To save the startup configuration, use the copy-config operation to copy the running configuration datastore to the startup configuration datastore.

copy-config

Create or replace an entire configuration datastore with the contents of another complete configuration datastore. If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>

delete-config

Description: Delete a configuration datastore. The running configuration datastore cannot be deleted.

"startup" config can be removed.

<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>

5. Netconf Lab Demo

This session demonstates the basic netconf operations using SSH client.


LAB overview

Device

Cisco CSR 1000v

Cisco provides free Lab environment(Device) called Devnet learning labs. In this Lab Cisco CSR Router 1000v is part of it, which can be used for Netconf demonstrations/practices.

Cisco IOS Sofware XE - 16.8.1

The device details can be collected from this below link

Netconf clients

-Netconf over SSH - openssh client

-Python Netconf Client(ncclient)

-Ansible Netconf modules

-Opendaylight Netconf Connector

My System/VM OS is Ubuntu 18.04 .

Netconf over SSH

Netconf protocol over SSH is standard available in RFC 6242.

we can use OpenSSH Client as Netconf Client for quick testing.

ssh username@IP -p portnumber -s netconf

Python Netconf Client(ncclient)

Install the python netconf client

sudo pip install ncclient

Ansible Netconf modules

Ansible netconf modume

Opendaylight Netconf connector

The NETCONF southbound plugin is capable of connecting to remote NETCONF devices and exposing their configuration/operational datastores, RPCs and notifications as MD-SAL mount points. These mount points allow applications and remote users (over RESTCONF) to interact with the mounted devices.

https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide.html


Exercises

Connection establishment

HELLO Message will be sent from both Client and Server with its capabilities.

ssh root@64.103.37.51 -p 10000 -s netconf

$ ssh root@64.103.37.51 -p 10000 -s netconf
root@64.103.37.51's password:
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability: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:with-defaults:1.0?basic-mode=explicit&amp;also-supported=report-all-tagged</capability>
.................SKIPPED
</capabilities>
<session-id>324</session-id></hello>]]>]]

Now we need to send the Client HELLO Message . Copy & Paste the below text in the SSH console.

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

Now connection establishment is over.

GET CONFIG Message

Reference: https://tools.ietf.org/html/rfc6241#section-7

Copy & Paste the below text in the SSH console.

<?xml version="1.0" ?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
]]>]]>

Reply

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"><data><native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native"><version>16.8</version><boot-start-marker/><boot-end-marker/><banner><motd><banner>^C</banner></motd></banner><service><timestamps><debug>
......OUTPUT SKIPPED............
</data></rpc-reply>]]>]]>

GET Message

<?xml version="1.0" ?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
</get>
</rpc>
]]>]]>

Dont try. it will return plenty of stats and take lot of time to complete.

Edit config

Copy & Paste the below text in the SSH console.

<?xml version="1.0" ?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname>CISCOROUTER-SURESH</hostname>
</native>
</config>
</edit-config>
</rpc>
]]>]]>

Reply

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

To verify the changes, query the getconfig with filter :

<?xml version="1.0" ?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname/>
<version/>
</native>
</filter>
</get-config>
</rpc>
]]>]]>

Lock

<?xml version="1.0" ?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<lock>
<target>
<running/>
</target>
</lock>
</rpc>
]]>]]>

Reply

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

UnLock

<?xml version="1.0" ?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<unlock>
<target>
<running/>
</target>
</unlock>
</rpc>
]]>]]>

Reply:

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

Edit config with Validate option

Case1:

<?xml version="1.0" ?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<test-option>test-only</test-option>
<config>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname>CISCOROUTER-SURESH123</hostname>
</native>
</config>
</edit-config>
</rpc>
]]>]]>

Reply

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

Case2:

<?xml version="1.0" ?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<test-option>test-only</test-option>
<config>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname>&-+***</hostname>
</native>
</config>
</edit-config>
</rpc>
]]>]]>

Edit config with Rollback option

<?xml version="1.0" ?>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<error-option>rollback-on-error</error-option>
<config>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname>CISCOROUTER-SURESH</hostname>
<version>&-+***</version>
</native>
</config>
</edit-config>
</rpc>
]]>]]>

6. Subtree Filtering

XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the rpc-reply for a get or get-config operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms.

Namespace Selection

A namespace is considered to match (for filter purposes) if the XML namespace associated with a particular node within the filter element is the same as in the underlying data model.

<filter type="subtree">
<top xmlns="http://example.com/schema/1.2/config"/>
</filter>

Get Config

<?xml version="1.0" ?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
]]>]]>

Get Config with namespace filter

<?xml version="1.0" ?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
</native>
</filter>
</get-config>
</rpc>
]]>]]>

Get Config with element filter

<?xml version="1.0" ?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<hostname/>
</native>
</filter>
</get-config>
</rpc>
]]>]]>

--

Get SNMP Stats with Filter

The SNMP MIB data that can be returned with NETCONF GET operations. All supported SNMP MIBs that are converted into structured data defined by YANG data models are part of the IOS-XE software.

urn:ietf:params:xml:ns:yang:smiv2:ENTITY-MIB

<?xml version="1.0" ?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
</get>
</rpc>
]]>]]>
<filter type="subtree">
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native"/>

XPATH filter

The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the filter element

capability:

urn:ietf:params:netconf:capability:xpath:1.0

iii). Get Config with XPATH filter

<?xml version="1.0" ?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
<filter xmlns:t="http://cisco.com/ns/yang/Cisco-IOS-XE-native" type="xpath" select="/t:native/hostname">
</filter>
</get-config>
</rpc>
]]>]]>

7. Capabilities Introduction

https://tools.ietf.org/html/rfc6241

NETCONF allows a client to discover the set of protocol extensions supported by a server. These "capabilities" permit the client to adjust its behavior to take advantage of the features exposed by the device.

A NETCONF capability is a set of functionality that supplements the base NETCONF specification. A NETCONF capability is identified with a URI.

Capabilities defined in this document have the followingformat:

! urn:ietf:params:netconf:capability:{name}:1.x

where {name} is the name of the capability.

Capabilities augment the base operations of the device, describing both additional operations and the content allowed inside operations. The client can discover the server's capabilities and use any additional operations, parameters, and content defined by those capabilities.

Capabilities Exchange

Capabilities are advertised in messages sent by each peer during session establishment. When the NETCONF session is opened, each peer (both client and server) MUST send a hello element containing a list of that peer's capabilities

Each peer MUST send at least the base NETCONF capability, "urn:ietf:params:netconf:base:1.1".

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>
urn:ietf:params:netconf:base:1.1
</capability>
<capability>
urn:ietf:params:netconf:capability:startup:1.0
</capability>
<capability>
http://example.net/router/2.3/myfeature
</capability>
</capabilities>
<session-id>4</session-id>
</hello>

A. Writable-Running Capability

The :writable-running capability indicates that the device supports direct writes to the running configuration datastore. In other words, the device supports edit-config and copy-config operations where the running configuration is the target.

urn:ietf:params:netconf:capability:writable-running:1.0

B.Candidate Configuration Capability

The candidate configuration capability, :candidate, indicates that the device supports a candidate configuration datastore, which is used to hold configuration data that can be manipulated without impacting the device's current configuration.

urn:ietf:params:netconf:capability:candidate:1.0

C.Rollback-on-Error Capability

This capability indicates that the server will support the "rollback-on-error" value in the error-option parameter to the edit-config operation.

urn:ietf:params:netconf:capability:rollback-on-error:1.0

D.Validate Capability

Validation consists of checking a complete configuration for syntactical and semantic errors before applying the configuration to the device.

urn:ietf:params:netconf:capability:validate:1.1

E.Distinct Startup Capability

The device supports separate running and startup configuration datastores. The startup configuration is loaded by the device when it boots. Operations that affect the running configuration will not be automatically copied to the startup configuration. An explicit copy-config operation from the running to the startup is used to update the startup configuration to the current contents of the running configuration. NETCONF protocol operations refer to the startup datastore using the startup element.

urn:ietf:params:netconf:capability:startup:1.0

F. XPath Capability

The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the filter element.

urn:ietf:params:netconf:capability:xpath:1.0


Demo & Analysis

HELLO Message will be sent from both Client and Server with its capabilities.

ssh root@64.103.37.51 -p 10000 -s netconf

$ ssh root@64.103.37.51 -p 10000 -s netconf
root@64.103.37.51's password:
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability: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:with-defaults:1.0?basic-mode=explicit&amp;also-supported=report-all-tagged</capability>
.................SKIPPED
</capabilities>
<session-id>324</session-id></hello>]]>]]

Now we need to send the Client HELLO Message . Copy & Paste the below text in the SSH console.

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

In the capabilties, we can see the features supported by the Server as well as YANG Models supported.

Device discovery happens based on this information.



8. Custom RPCs or Additional Operations

Custom RPCs or Additional Operations are defined in the YANG Models as RPC definitions. Netconf monitoring is one of the YANG Model, which supports get-schema rpc operation.

https://tools.ietf.org/html/rfc6022

xmlnamespace : urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring


Get the schemas List

Make sure establish the session with hello.

<?xml version="1.0" ?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<schemas/>
</netconf-state>
</filter>
</get>
</rpc>
]]>]]>

The NETCONF server returns a list of schema available for retrieval.


Get Schema RPC

Example1:

<?xml version="1.0" ?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>Cisco-IOS-XE-platform</identifier>
</get-schema>
</rpc>
]]>]]>

Example2:

<?xml version="1.0" ?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>cisco-xe-ietf-ospf-deviation</identifier>
</get-schema>
</rpc>
]]>]]>

Example3:

<?xml version="1.0" ?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>Cisco-IOS-XE-native</identifier>
</get-schema>
</rpc>
]]>]]>

Save Config RPC

Further RPCs exeamples for Cisco XE Platform : https://www.cisco.com/c/en/us/support/docs/storage-networking/management/200933-YANG-NETCONF-Configuration-Validation.html

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<cisco-ia:save-config xmlns:cisco-ia="http://cisco.com/yang/cisco-ia"/>
</rpc>
]]>]]>

Reply

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"><result xmlns='http://cisco.com/yang/cisco-ia'>Save running-config
successful</result>
</rpc-reply>]]>]]>

9. Notifications

  • NETCONF client indicates interest in receiving event notifications from a NETCONF server by creating a subscription to receive event notifications.

  • The NETCONF server replies to indicate whether the subscription request was successful and, if it was successful, begins sending the event notifications to the NETCONF client as the events occur within the system.

  • These event notifications will continue to be sent until either the NETCONF session is terminated or the subscription terminates for some other reason.

create-subscription

This operation initiates an event notification subscription that will send asynchronous event notifications to the initiator of the command until the subscription terminates.

capability

urn:ietf:params:netconf:capability:notification:1.0

Demo

My System/VM OS is Ubuntu 18.04 .

Here we use python netconf client to for listening the notifications,

Install the python netconf client

sudo pip install ncclient

Register the subscription for notifications and print the notification details when it occurs.

  1. Run the notification script to continuously listening for notifications
  2. open another terminal, and connect to the Netconf server using SSH Client
  3. see the output in notification script.
$ python notifications.py
Waiting for next notification
<?xml version="1.0" encoding="UTF-8"?>
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"><eventTime>2019-06-12T06:37:59.730733+00:00</eventTime>
<netconf-session-start xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-notifications'>
<username>root</username>
<session-id>238</session-id>
<source-host>84.39.53.130</source-host>
</netconf-session-start>
</notification>
Waiting for next notification
  1. Another terminal, connect to the netconf server using SSH client.

ssh root@64.103.37.51 -p 10000 -s netconf


10. YANG

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.

In simple terms, Device Configuration/Stats is represented in YANG Data Models. In Cisco terms Running Configuration(Configuration), State / Statistics (Show commands) are represented in YANG Model. This can be accessed by the CLI or Network Programming API such as NETCONF or RESTCONF.

YANG models the hierarchical organization of data as a tree in which each node has a name, and either a value or a set of child nodes. YANG provides clear and concise descriptions of the nodes, as well as the interaction between those nodes.

  • Module that is a self-contained top-level hierarchy of nodes
  • Uses containers to group related nodes
  • Lists to identify nodes that are stored in sequence
  • Each individual attribute of a node is represented by a leaf
  • Every leaf must have an associated type

Standards

RFC 6020 -Yang 1.0 RFC 7950 -Yang 1.1 RFC 6991 - Common Yang Datatypes RFC 7277 - IP Management RFC 7224 - IANA Interface type RFC 7223 - Interface Management

Industry standard yang models:

IETF, ITU, OpenConfig, etc

Some of the Yang models are available in the below links,

The model can be displayed and represented in any number of formats depending on needs at the time. Some options include:

• YANG Language • Clear Text • XML • JSON • HTML/JavaScript


Yang file and Yang Data types

Lets edit the ietf-interfaces.yang file in text editor.

Module Header

yang-version, namespace, prefix, import, org, contact, description, revision......

module_header

Namespace

All YANG definitions are specified within a particular XML Namespace. Each module defines an XML namespace as a globally unique URI. A NETCONF client or server uses the namespace during XML encoding of data

Container

An interior data node that exists in at most one instance in the data tree - yang model. A container has no value, but rather a set of child nodes. Example: Any Yang data tree, atleast one container will be present. Example in IETF- Interfaces yang module, interfaces is a Container.

container1

LIST Statement

  • Defines a interior data node (multiple instances in the data tree).
  • Collection of entries/child nodes (Example: List of Interfaces.)

list

Leaf Statement

The "leaf" statement is used to define a leaf node in the schema tree. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed leaf information. A leaf node has a value, but no child nodes, in the data tree.

YANG Data types (Built -in – types) -Integer, -decimal64 -String -boolean -enumeration -bits -binary -leafref -identifyref -empty


Tools (Browser/Library)

pyang - python library

pyang is a YANG validator, transformator and code generator, written in python. It can be used to validate YANG modules for correctness, to transform YANG modules into other formats such as TREE, HTML etc.

As a user, we use for tranforming the YANG module to easily understandable format such as TREE, HTML format.

How to install

sudo pip install pyang

Ref: https://github.com/mbj4668/pyang

Demo

  1. Download the standard yang models

    git clone https://github.com/YangModels/yang

  2. Install the pyang as above

  3. Display the YANG MODEL in XML Skeleton (used by Netconf Program GET/GET-CONFIG Filter):

pyang -f sample-xml-skeleton yang/standard/ietf/RFC/ietf-interfaces.yang

cloud@u18:~$ pyang -f sample-xml-skeleton yang/standard/ietf/RFC/ietf-interfaces.yang
<?xml version='1.0' encoding='UTF-8'?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name/>
<description/>
<type/>
<link-up-down-trap-enable/>
<admin-status/>
<oper-status/>
<last-change/>
<if-index/>
<phys-address/>
<higher-layer-if>
<!-- # entries: 0.. -->
</higher-layer-if>
<lower-layer-if>
<!-- # entries: 0.. -->
</lower-layer-if>
<speed/>
<statistics>
<discontinuity-time/>
<in-octets/>
<in-unicast-pkts/>
<in-broadcast-pkts/>
<in-multicast-pkts/>
<in-discards/>
<in-errors/>
<in-unknown-protos/>
<out-octets/>
<out-unicast-pkts/>
<out-broadcast-pkts/>
<out-multicast-pkts/>
<out-discards/>
<out-errors/>
</statistics>
</interface>
</interfaces>
<interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name/>
<type/>
<admin-status/>
<oper-status/>
<last-change/>
<if-index/>
<phys-address/>
<higher-layer-if>
<!-- # entries: 0.. -->
</higher-layer-if>
<lower-layer-if>
<!-- # entries: 0.. -->
</lower-layer-if>
<speed/>
<statistics>
<discontinuity-time/>
<in-octets/>
<in-unicast-pkts/>
<in-broadcast-pkts/>
<in-multicast-pkts/>
<in-discards/>
<in-errors/>
<in-unknown-protos/>
<out-octets/>
<out-unicast-pkts/>
<out-broadcast-pkts/>
<out-multicast-pkts/>
<out-discards/>
<out-errors/>
</statistics>
</interface>
</interfaces-state>
</data>

we mainly require this XML format, to populate the FILTER in GET and GET-CONFIG operations in NETCONF protocol.

  1. Display the yang model in tree format

pyang -f tree yang/standard/ietf/RFC/ietf-interfaces.yang

cloud@u18:~$ pyang -f tree standard/ietf/RFC/ietf-interfaces.yang
module: ietf-interfaces
+--rw interfaces
| +--rw interface* [name]
| +--rw name string
| +--rw description? string
| +--rw type identityref
| +--rw enabled? boolean
| +--rw link-up-down-trap-enable? enumeration {if-mib}?
| +--ro admin-status enumeration {if-mib}?
| +--ro oper-status enumeration
| +--ro last-change? yang:date-and-time
| +--ro if-index int32 {if-mib}?
| +--ro phys-address? yang:phys-address
| +--ro higher-layer-if* interface-ref
| +--ro lower-layer-if* interface-ref
| +--ro speed? yang:gauge64
| +--ro statistics
| +--ro discontinuity-time yang:date-and-time
| +--ro in-octets? yang:counter64
| +--ro in-unicast-pkts? yang:counter64
| +--ro in-broadcast-pkts? yang:counter64
| +--ro in-multicast-pkts? yang:counter64
| +--ro in-discards? yang:counter32
| +--ro in-errors? yang:counter32
| +--ro in-unknown-protos? yang:counter32
| +--ro out-octets? yang:counter64
| +--ro out-unicast-pkts? yang:counter64
| +--ro out-broadcast-pkts? yang:counter64
| +--ro out-multicast-pkts? yang:counter64
| +--ro out-discards? yang:counter32
| +--ro out-errors? yang:counter32
x--ro interfaces-state
x--ro interface* [name]
x--ro name string
x--ro type identityref
x--ro admin-status enumeration {if-mib}?
x--ro oper-status enumeration
x--ro last-change? yang:date-and-time
x--ro if-index int32 {if-mib}?
x--ro phys-address? yang:phys-address
x--ro higher-layer-if* interface-state-ref
x--ro lower-layer-if* interface-state-ref
x--ro speed? yang:gauge64
x--ro statistics
x--ro discontinuity-time yang:date-and-time
x--ro in-octets? yang:counter64
x--ro in-unicast-pkts? yang:counter64
x--ro in-broadcast-pkts? yang:counter64
x--ro in-multicast-pkts? yang:counter64
x--ro in-discards? yang:counter32
x--ro in-errors? yang:counter32
x--ro in-unknown-protos? yang:counter32
x--ro out-octets? yang:counter64
x--ro out-unicast-pkts? yang:counter64
x--ro out-broadcast-pkts? yang:counter64
x--ro out-multicast-pkts? yang:counter64
x--ro out-discards? yang:counter32
x--ro out-errors? yang:counter32
  1. Display the yang model in tree format
pyang -f jstree yang/standard/ietf/RFC/ietf-interfaces.yang > tmp.html
  1. Open the tmp.html file in browser to see it.

RPC Data

Lets check the yang model cisco-bridge-domain.yang

pyang -f sample-xml-skeleton cisco-bridge-domain.yang

urn:cisco:params:xml:ns:yang:cisco-bridge-domain

Now lets query the getconfig with filter

<?xml version="1.0" ?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<bridge-domain-config xmlns="urn:cisco:params:xml:ns:yang:cisco-bridge-domain">
</bridge-domain-config>
</filter>
</get-config>
</rpc>
]]>]]>

RPC Name: clear-bridge-domain Lets call the RPC

<?xml version="1.0" ?>
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<clear-bridge-domain xmlns="urn:cisco:params:xml:ns:yang:cisco-bridge-domain">
<all/>
</clear-bridge-domain>
</rpc>
]]>]]>

reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"><rpc-error>
<error-type>application</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:bd="urn:cisco:params:xml:ns:yang:cisco-bridge-domain" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
/nc:rpc/bd:clear-bridge-domain
</error-path><error-message xml:lang="en">not yet implemented</error-message><error-info><bad-element>clear-bridge-domain</bad-element>
</error-info>
</rpc-error>
</rpc-reply>]]>]]>

Further RPCs exeamples for Cisco XE Platform : https://www.cisco.com/c/en/us/support/docs/storage-networking/management/200933-YANG-NETCONF-Configuration-Validation.html

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<cisco-ia:save-config xmlns:cisco-ia="http://cisco.com/yang/cisco-ia"/>
</rpc>
]]>]]>

Reply

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"><result xmlns='http://cisco.com/yang/cisco-ia'>Save running-config successful</result>
</rpc-reply>]]>]]>

11. Netconf with OpenDaylight

This session demonstates the basic netconf operations using Opendaylight SDN controller.

Device

Cisco CSR 1000v

Cisco provides free Lab environment(Device) called Devnet learning labs. In this Lab Cisco CSR Router 1000v is part of it, which can be used for Netconf demonstrations/practices.

Cisco IOS Sofware XE - 16.8.1

The device details can be collected from this below link

OpenDdayLight(ODL) SDN Controller

will use ODL NEON release

https://www.opendaylight.org/

Cisco CLI


ODL Installation

I prefer Linux Ubuntu Version.

Ubuntu versions : Ubuntu 18.04 (Desktop or Server) Java - 8+ version

i). Installation Procedure

Java installation :

sudo apt install openjdk-8-jre-headless

https://www.digitalocean.com/community/tutorials/how-to-install-java-with-apt-on-ubuntu-18-04

we use "curl" tool for REST API access and "jq" tool for JSON pretty print format.

sudo apt-get install jq curl

ODL Installation

OpenDayLight Version : NEON

wget https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/opendaylight/0.10.1/opendaylight-0.10.1.tar.gz

tar xvzf opendaylight-0.10.1.tar.gz

cd opendaylight-0.10.1/

./bin/karaf

you will see the karaf shell

Netconf plugins Installation

Install the netconf feature in OpenDayLight karaf shell as below,

feature:install odl-netconf-connector-all odl-netconf-topology odl-netconf-console odl-restconf odl-mdsal-apidocs

Cisco CLI

we have installed the following packages

  • odl-netconf-connector-all
  • odl-netconf-topology
  • odl-restconf
  • odl-netconf-console
  • odl-mdsal-apidocs

In this, odl-mdsal-apidocs provides the API documents, which can be accessed via the UI.

Enable logs:

In the karaf shell,

log:set TRACE org.opendaylight.controller.sal.connect.netconf

ii). Quick verification

Verify it using REST API

Request the netconf topology from the operation datastore, and expect to get empty list.

API:

curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/

Result:

"topology":[{"topology-id":"topology-netconf"}]}

Verify it using UI

  1. Open the below URL in your browser. (localhost means ODL IP. i have installed in my laptop, hence i use localhost)

http://localhost:8181/apidoc/explorer/index.html

username: admin password: admin

Cisco CLI


Connecting/Configuring the Device

i). Configure the Cisco Device in the ODL Netconf

nc_create.xml file contents are below,

<node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
<node-id>cisco-netconf-device</node-id>
<host xmlns="urn:opendaylight:netconf-node-topology">x.x.x.x</host>
<port xmlns="urn:opendaylight:netconf-node-topology">xxxxx</port>
<username xmlns="urn:opendaylight:netconf-node-topology">xxxx</username>
<password xmlns="urn:opendaylight:netconf-node-topology">xxxxxx</password>
<tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
<keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">10</keepalive-delay>
</node>

Make sure, you update the correct credentials(host,port,username, password) in the nc_create.xml file.

API:

curl --user "admin":"admin" -H "Content-type: application/xml" -X PUT http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device -d '@nc_create.xml'

ii). Verify the Configured Device Status in Netconf topology

This step is same as step1, we are verifying the status of the topology. (Here we direct the output to "jq ." for pretty print. you can ignore it if you want, its a optional tool)

API:

curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/ | jq .

Response:

{"topology":
[{"topology-id":"topology-netconf",
"node":[{
"node-id":"cisco-netconf-device",
"netconf-node-topology:host":"x.x.x.x",
"netconf-node-topology:connection-status":"connecting",
"netconf-node-topology:port":10000}]
}]
}

We can observe, the status is connecting. Usually it takes a few seconds to min (depends on the device).

Repeat this step again, after few seconds.

cloud@u18:~$ curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/ | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 64019 0 64019 0 0 4809k 0 --:--:-- --:--:-- --:--:-- 4809k
{
"topology": [
{
"topology-id": "topology-netconf",
"node": [
{
"node-id": "cisco-netconf-device",
"netconf-node-topology:unavailable-capabilities": {},
"netconf-node-topology:available-capabilities": {
"available-capability": [
{
"capability-origin": "device-advertised",
"capability": "urn:ietf:params:netconf:base:1.1"
},
{
"capability-origin": "device-advertised",
"capability": "(http://cisco.com/ns/yang/cisco-xe-routing-policy-deviation?revision=2017-03-30)cisco-xe-openconfig-routing-policy-deviation"
}
]
},
"netconf-node-topology:host": "x.x.x.x",
"netconf-node-topology:connection-status": "connected",
"netconf-node-topology:port": 10000
}
]
}
]
}

Now the device is connected, and we could able to see the capabilities. and YANG models supported by the device.

Now, the mount point yang-ext:mount will be available for both CONFIG and Operational data store. /topology-netconf/node/{node name}/yang-ext:mount/

Now our device is mounted.


ODL API Docs - UI

  1. Open the below URL in your browser. (localhost means ODL IP. i have installed in my laptop, hence i use localhost)

http://localhost:8181/apidoc/explorer/index.html

username: admin password: admin

Cisco CLI

In Controller Resources tab, we can all the yang data models available in Opendaylight in all projects.

In Mounted Resources tab, we can see our NETCONF device got mounted,click that link to get all the modules and APIs.

Cisco CLI Cisco CLI

  1. In Controller Resources tab, network-topology module is used for netconf operations.

Get the Topology operational data Cisco CLI

Get the Topology configuration data

Cisco CLI


Get the Modules

All YANG models exposed by the NETCONF device can be accessed through RESTConf using the netconf-connector instance (aka mount point) for the device

curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/modules/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/ | jq .

cloud@u18:~$ curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/modules/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/ | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 52173 0 52173 0 0 1340k 0 --:--:-- --:--:-- --:--:-- 1340k
{
"modules": {
"module": [
{
"name": "ietf-diffserv-target",
"revision": "2015-04-07",
"feature": [
"target-inline-policy-config"
],
"namespace": "urn:ietf:params:xml:ns:yang:ietf-diffserv-target"
},
{
"name": "CISCO-EMBEDDED-EVENT-MGR-MIB",
"revision": "2006-11-07",
"namespace": "urn:ietf:params:xml:ns:yang:smiv2:CISCO-EMBEDDED-EVENT-MGR-MIB"
},
{
"name": "Cisco-IOS-XE-zone",
"revision": "2017-11-27",
"namespace": "http://cisco.com/ns/yang/Cisco-IOS-XE-zone"
},
...... OUTPUT SKIPPED

Get Config

Get the Config data

Method: GET

/restconf/config/network-topology:network-topology/topology/{topology-name}/node/{device-name}/yang-ext:mount/

Example:

cloud@u18:~$ curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/ | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 16595 0 16595 0 0 5886 0 --:--:-- 0:00:02 --:--:-- 5884
{
"ietf-interfaces:interfaces": {
"interface": [
{
"name": "Loopback12232",
"enabled": true,
"description": "Pod Number 12232",
"ietf-ip:ipv4": {
"address": [
{
"ip": "10.12.232.1",
"netmask": "255.255.255.255"
}
]
},
"ietf-ip:ipv6": {},
"type": "iana-if-type:softwareLoopback"
},
{
...... OUTPUT SKIPPED

Get the Config data with specific yang model & container

IETF-INTERFACES Model/interfaces container

curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/ietf-interfaces:interfaces | jq

loud@u18:~$ curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/con
fig/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/ietf-interfa
ces:interfaces | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1491 100 1491 0 0 7417 0 --:--:-- --:--:-- --:--:-- 7417
{
"interfaces": {
"interface": [
{
"name": "Loopback2",
"enabled": true,
"description": "New loopback added",
"ietf-ip:ipv4": {
"address": [
{
"ip": "10.15.16.16",
"netmask": "255.255.255.255"
}
]
},
"ietf-ip:ipv6": {},
...... OUTPUT SKIPPED

Cisco-IOS-XE-native Model/Native container

curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/Cisco-IOS-XE-native:native | jq

cloud@u18:~$ curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/con
fig/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/Cisco-IOS-XE
-native:native | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3295 100 3295 0 0 10732 0 --:--:-- --:--:-- --:--:-- 10732
{
"native": {
"service": {
"timestamps": {
"debug": {
"datetime": {
"msec": {}
}
},
"log": {
"datetime": {
"msec": [
null
]
}
}
}
},
"hostname": "csr1000v",
"crypto": {
...... OUTPUT SKIPPED

Get Stats(Operational Data)

Get the Statistic data with specific yang model & container

curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/Cisco-IOS-XE-interfaces-oper:interfaces

cloud@u18:~$ curl --user "admin":"admin" -H "Content-type: application/xml" -X GET http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/Cisco-IOS-XE-interfaces-oper:interfaces | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6446 100 6446 0 0 10601 0 --:--:-- --:--:-- --:--:-- 10584
{
"interfaces": {
"interface": [
{
"name": "GigabitEthernet3",
"v4-protocol-stats": {
"in-octets": 0,
"in-pkts": 0,
"out-forwarded-pkts": 0,
"out-octets": 0,
"in-error-pkts": 0,
"out-forwarded-octets": 0,
"out-pkts": 0,
"in-discarded-pkts": 0,
"in-forwarded-pkts": 0,
...... OUTPUT SKIPPED

RPC Operations

we can use "operations" endpoint to call custom RPCs.

Example API for get-schema RPCs

POST Operation

/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/ietf-netconf-monitoring:get-schema

input file

<input xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>Cisco-IOS-XE-native</identifier>
</input>
cloud@u18:~$ curl --user "admin":"admin" -H "Content-type: application/xml" -X POST http://localhost:8181/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device/yang-ext:mount/ietf-netconf-monitoring:get-schema -d '@get_schema.xml'
{"output":{"data":"module Cisco-IOS-XE-native {\n namespace \"http://cisco.com/ns/yang/Cisco-IOS-XE-native\";\n prefix ios;\n\n import ietf-inet-types {\n prefix inet;\n }\n\n\n import Cisco-IOS-XE-types {\n prefix ios-types;\n }\n\n import Cisco-IOS-XE-features {\n prefix ios-features;\n }\n\n import Cisco-IOS-XE-interface-common {\n prefix ios-ifc;\n }\n\n include Cisco-IOS-XE-parser;\n include Cisco-IOS-XE-license;\n include Cisco-IOS-XE-line;\n include Cisco-IOS-XE-logging;\n include Cisco-IOS-XE-ip;\n include Cisco-IOS-XE-ipv6;\n include Cisco-IOS-XE-interfaces;\n\n organization\n \"Cisco Systems, Inc.\";\n\n contact\n \"Cisco Systems, Inc.\n Customer Service\n\n Postal: 170 W Tasman Drive\n San Jose, CA 95134\n\n Tel: +1 1800 553-NETS\n\n E-mail: cs-yang@cisco.com\";\n\n description\n \"NED YANG module for IOS-XE\n Copyright (c) 2016-2017 by Cisco Syste
...... OUTPUT SKIPPED

Delete the Node

curl --user "admin":"admin" -H "Content-type: application/xml" -X DELETE http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/cisco-netconf-device