NETCONF/YANG Tutorial

Ryan Goulding, Senior Engineer, Brocade

Giles Heron, Principal Engineer, Cisco
Alexis de Talhouët, Software Developer, Inocybe
Technologies
Agenda

● NETCONF/YANG Overview
● YANG basics
● YANG advanced
● NETCONF basics
● NETCONF advanced
● OpenDaylight NETCONF/YANG and RESTCONF
● Troubleshooting
● Demo
● Tooling, References etc.
NETCONF/YANG Overview
 Why NETCONF/YANG – RFC3535

Abstract SNMP had failed

For configuration, that is
This document provides an overview of a
workshop held by the Internet Architecture Board Extensive use in fault handling and
(IAB) on Network Management. The workshop monitoring
was hosted by CNRI in Reston, VA, USA from CLI scripting
June 4 thru June 6, 2002. The goal of the “Market share” 70%+
workshop was to continue the important dialog
started between network operators and protocol
developers, and to guide the IETFs focus on
future work regarding network management.

configur
ation
RFC3535 - legacy situation

OSS
NMS
EMS
NETCONF
Manager

Cost and
complexity • No well-defined protocols and
data-models
• Lack of atomicity
• Ordering problem
RFC3535 - NETCONF/YANG solution

OSS
NMS
EMS
NETCONF
Manager

Reduced Cost/
Cost and Value
complexity Transactions
Models
Standardized
Protocols
So what is a data model anyway?

Data-Model (e.g. a YANG Model)

• A data-model explicitly and precisely determines the
structure, syntax and semantics of the data…
Prot • …that is externally visible
ocol • Consistent and complete

Data-Model Protocol (e.g. NETCONF or RESTCONF)

• Remote primitives to view and manipulate the data (e.g.
XML RPCs or HTTP methods)
• Encoding of the data as defined by the data-model (e.g.
XML or JSON)
NETCONF & YANG “in the wild”

YANG Models
Yang
Model
s
NETCONF
NETCONF
Manager

NETCONF

YANG Models YANG Models YANG Models

NETCONF/YANG ”Layer-Cake”

Mgmt info
YANG modules
(definition) Manager (client)

Mgmt info
XML-encoded content
(payload)

Mgmt Netconf operations

Agent
Services <edit-config>, <get-config>, <get> (server)

Remote Netconf RPC Conceptual

Operations <rpc>, <rpc-reply> Data XML
Store content
per
Transport TLS, SSH YANG
YANG Basics
What is YANG?

YANG is a modeling language defined in RFC 6020

Used by NETCONF to define objects and data in requests and replies
Analogous to XML schema and SMI for SNMP (but more powerful)
Models configuration, operational, and RPC data
Provides semantics to better define NETCONF data
Constraints (i.e., “MUSTs”)
Reusable structures
Built-in and derived types

YANG is extensible and modular

YANG modules are for NETCONF what MIBs are for SNMP
YANG and XML

YANG assumes an XML encoding of instantiated information

Defines XML rendering rules
Relies on XML encoding for certain features
Facilitates describing XML document hierarchies
Nicely aligned with NETCONF ☺

YANG itself is not XML

Emphasis on readability
Familiar structure to C/C++ or Java programmers
XML notation exists: YIN (Yang-Independent Notation)
Semantic equivalence
Syntactic conversions YANG <-> YIN
Alternative encodings defined (e.g. JSON for RESTconf)
How does YANG go beyond NETCONF?

Mgmt info
YANG modules
(definition)

Mgmt info XML-encoded JAVA

JSON gRPC
(encoding) content DTO
Mgmt NETCONF
RESTCONF
Services operations

Remote XML
HTTP I2RS ODL
Operations RPC

TLS,
Transport TCP
SSH
How are YANG modules structured?

acme-box module

properties container

name: string, config

interfaces container

interface: list, key = name

name: string, config

oper-state: enum, config

How are YANG modules structured?

Header information
Imports & Includes

Type definitions

Configuration & Operational

data declarations

Action (RPC) & Notification declarations

YANG Model - Header
YANG Model – Imports/Includes
Module X Namespace Module Y Namespace

Fragment import
A.yang
include Fragment
E.yang
Fragment
B.yang
Imported fragments are just
include include referenced, not included
Fragment Fragment
C.yang D.yang

Each included fragment is a

complete YANG file; can never
be included in any other
module/namespace
YANG Model – submodules
Each submodule belongs to one
specific main module

Attention: The submodule cannot

reference definitions in main module
YANG Types

• YANG leaves have a data type Type Name Meaning

int8/16/32/64 Integer
• Type may be a base type or a uint8/16/32/64 Unsigned integer
derived type decimal64 Non-integer
string Unicode string
• There are 20+ base types… enumeration Set of alternatives
boolean True or false
bits Boolean array
binary Binary BLOB
leafref Reference “pointer”
identityref Unique identity
empty No value, void
…and more
YANG Typedef – defines new simple type

percent

completed

Type is referenced by a new leaf

XML Instance Data:

<completed>50</completed
>
Common YANG Types

• Commonly used YANG types defined counter32/64 ipv4-address

in RFC 6021 gauge32/64 ipv6-address

object-identifier ip-prefix

• Use: date-and-time ipv4-prefix

timeticks ipv6-prefix
timestamp domain-name
phys-address uri
ip-version mac-address
• And e.g:
flow-label bridgeid
port-number vlanid
ip-address … and more
YANG Grouping – defines structured type

target
address
port
peer
destination
address
port

XML Instance Data:

<destination>
<address>192.168.0.1</address>
<port>80</port>
</destination>
 YANG Data Declarations – Leaf Statement
• Holds a single value of a particular type
• Has no children
• Can’t reference directly from RESTCONF host-name
cpu-temp

XML Instance Data:

<host—name>my-host</host-name
>

<cpu-temp>62</cpu-temp>
 YANG Data Declarations – Leaf-List
• Holds multiple values of a particular type
• Has no children
domain-search

XML Instance Data:

<domain-search>foo.com</domain-search
>
<domain-search>bar.com</domain-search
YANG Data Declarations – List Statement

user

name uid full-name class

Default
YANG Lists - Keys

user

name uid full-name class

Defaul
t
yang 1010 Yan Goode admin
hawk 1152 Ron Hawk oper
ling 1202 Lin Grossman viewer

The key field is used to specify which row we’re accessing

Key can be one leaf, or multiple
In RESTCONF key is URL element (after list name – e.g. “…/user/hawk”)
Where >1 key each key is a new URL element
YANG Lists – “Unique” Statement

user

uid name full-name class

Default
1010 yang Yan Goode admin
1152 hawk Ron Hawk oper
1202 ling Lin Grossman viewer

Non-key fields can also be declared unique.

Multiple leaves can be declared unique

separately or in combination

Note ODL doesn’t enforce this (or many

other constraints today)
YANG Data Declarations – Containers
Groups related leafs and containers system
services
ssh
Presence
…
…

XML Instance Data:

<system>
<services>
</services>
</system>
YANG Basics

Create our first YANG model

YANG Basics

Create first YANG model

● Open Eclipse (pre-provisioned workspace)
● Under src/main/yang
○ Right click → new → other
→ search for Yang
○ Give it a name: car
YANG Basics

● The file name and the module name must be the same
● The namespace is a global unique URI (Unique Resource Identifier)
● The prefix is to define the prefix associated with the module and its
namespace
● The revision define the date when this module was first created. You
would change the revision date after updating an existing yang file
YANG Basics

Create our first container:

● The container is used to
define an interior data
node in the schema tree
YANG Basics

● A container can have as much as sub-statement it needs

● In our example, we have defined two leaves. A leaf requires a type:
○ max-speed
■ uint8 (8-bit unsigned integer), this is enough to define the maximum
speed
○ gaz-tank-state
■ Enum: this means this leaf can be one values defined in the enum
■ Default: it corresponds to the default value assigned to this leaf
YANG Basics
YANG Basics

Import a dependency in YANG:

● Makes definitions from one module available inside another module or

submodule

● Import has two substatement to identify the module:

○ prefix
○ revision-date
YANG Basics

Import a dependency in YANG:

● Let’s import ietf-yang-types

● See more about this import content at

http://www.netconfcentral.org/modules/ietf-yang-types
YANG Basics

Import a dependency in the pom file:

● Tell Maven where to fetch the dependency

<dependencies>
<dependency>
<groupId>org.opendaylight.mdsal.model</groupId>
<artifactId>ietf-yang-types-20130715</artifactId>
</dependency>
</dependencies>
YANG Basics

Validate the model with Pyang

● Pyang is a tool to validate and convert YANG module to various format.

https://github.com/mbj4668/pyang/wiki
● Use the following command to validate your yang model
$ pyang car.yang
car.yang:6: warning: imported module ietf-yang-types not used
YANG Basics

Use our import

● Create a leaf date in our grouping using the ietf-yang-types

“date-and-time” definition
● Let’s re-validate our
model:
$ pyang car.yang
YANG Basics

View your model

● To see an overview of the data model schemas we can use tree:

$ pyang -f tree car.yang

module: car
+--rw car-info
+--rw max-speed? uint8
+--rw gaz-tank-state? enumeration
+--rw date? yang:date-and-time
YANG Basics
YANG Basics

● Yang notions covered:

○ Import
○ Namespace
○ Prefix
○ Revision
○ Container
○ Leaf
○ Enum
○ Default
YANG Basics

Create Java bindings (OpenDaylight)

● Get at the root of the project

$ cd ~/Training/yang/yang-tutorial; maven clean install

$ cd ~/Training/yang/yang-tutorial/target/generated-sources

● All the java bindings should be there

YANG Advanced
YANG module structure - reminder

Header information
Imports & Includes

Type definitions

Configuration & Operational

data declarations

Action (RPC) & Notification declarations

 Advanced YANG Types – Enumerations
Enumeration – a type that can take one of several defined values

Best used when set of values is known a-priori

Instance Data:

<connection-status>connected</connection-status
>
 Advanced YANG Types - Unions
Union - a value that represents one of its member types

Instance Data:

<threshold>50</threshold>

Or:

<threshold>disabled</threshold>
 Advanced YANG Types - Choice
Choice - allows one of several alternatives transfer-method
transfer-interval
transfer-on-commit

Instance Data:

<transfer-interval>120</transfer-interval
>

Or:
<transfer-on-commit/>
Advanced YANG Types - Choice
• Each alternative may consist of multiple definitions
• Use case statement to group them
• Note that choice and case do not appear in instance data

Instance Data:

<threshold>60</threshold>
<ignore-count>3</ignore-count>
<ignore-time>30</ignore-time>
<reset-time>120</reset-time>
Advanced YANG Types - Identity

base identity additional

defined identities –
same base

refer back
to base

leaf refers to
base identity
Advanced Data Definition - Augment

Context node

Information to
augment the context
node with

Original (augmented) YANG module New (augmenting) YANG module

Namespace Namespace
http://example.com/schema/interfaces http://example.com/schema/ds0
YANG Augment - Example

Instance Data:

<interfaces>
<ifEntry>
<ifIndex>1</ifIndex>
<ifType>ds0</ifType>
<ifMtu>1500</ifType>
<ds0ChannelNumber>13<ds0ChannelNumber>
</ifEntry>
</interfaces>

Effectively equivalent
to the following
 YANG Constraints – must statement

Restricts valid values by

Xpath 1.0 expression

Xpath expression to
validate against data
YANG RPCs

Administrative actions with input and output parameters

activate-software-image
image
status
YANG Notifications

Notification with output parameters

config-change
operator-name
change

Instance-identifier values

<change>/ex:system/ex:services/ex:ssh/ex:port</change>
<change>/ex:system/ex:user[ex:name='fred']/ex:type</change>
<change>/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80’]</change>
 YANG Extensions

• "extension" node allows definition of new

statements to use with YANG module
• Effectively, allow for extension of YANG
language
• Add a new keyword with arguments
• Escape mechanism to allow for
proprietary extensions
• Example usage: augmentation of YANG
modules with information to assist tools
with code generation
 YANG Conformance - Features

“if-feature” makes a statement

conditional on the presence of a
“feature”

Avoids “lowest common denominator”

as can define optional capabilities as
features
 YANG Conformance - Deviations

Used to specify that a NETCONF

server doesn’t support part of a model.

Arguments can be:

1. not-supported
2. delete
3. replace
4. add
5. replace
YANG Conformance - Illustrated

YANG Module YANG Module

“Interfaces” “myInterfaces”
Feature
“individualStats”

Deviation A
A

if-feature individualStats
if-feature aggregatedStats
YANG Advanced

Improve previously created model

YANG Advanced

Few changes to our model

● Define the enumeration as its own type instead of having it enclosed in the
gaz-tank-state. To do so we define a new type using typedef.

● Add car-id leaf to the car-info container so we can identify a car

YANG Advanced

Create an Remote Procedure Call

● Define a Remote Procedure Call using YANG

You will need:

● Operation’s name
● Input parameters
● Output parameters
YANG Advanced

Create an Remote Procedure Call

● Our RPC will be to get the trank state for a given car
● The implementation would look like
YANG Advanced

Create a Notification
● Notification allows you to get notify when a change occurs for a given path
in the module

● Let’s define a notification that will be send when we’re out of gaz
YANG Advanced

Create a Grouping
● The grouping statement is used to define a reusable block of nodes. In
this grouping, we will define characteristic for our augmentation.
YANG Advanced

Create a Augmentation
● Augment the car-info container with the created grouping
● The augmentation will add extra information to the existing container. This
augmentation will thus provide all the information provided by car-info plus
the information from sport-car.
YANG Advanced

● Yang notions covered:

○ Typedef
○ RPC
○ Notification
○ Grouping
○ Augmentation
NETCONF Basics
 What is NETCONF

Netconf is connection-orientated
SSH, TLS as underlying transport
Netconf client (“manager”) establishes session with server (“agent”)
Data is XML-encoded
Based on RPCs
• <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id=”100">
Defined in RFC4741 (NETCONF 1.0) and RFC6241 (NETCONF 1.1)
• ODL supports NETCONF 1.1
Call-home being standardised
• Enables managed device to contact server
 The NETCONF Hello

Capabilities exchange Framing

Data model ID exchange • NETCONF 1.0 EOM, ]]>]]>
• NETCONF 1.1 Chunked Framing

<?xml version="1.0" encoding="UTF-8"?>

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.1</capability>
</capabilities>
</hello>
 The NETCONF Hello – Agent Response

<?xml version="1.0" encoding="UTF-8"?>

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
<capabilities>
<capability>urn:ietf:params: netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability: writable-running:1.0</capability
<capability>urn:ietf:params:netconf:capability: candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability: confirmed-commit:1.0</capability
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability: validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability: rollback-on-error:1.0</capabilit
<capability>http://tail-f.com/ns/netconf/with-defaults/1.0</capability>
<capability>http://tail-f.com/ns/netconf/actions/1.0</capability>
<capability>http://tail-f.com/ns/netconf/commit/1.0</capability>
<capability> http://tail-f.com/ns/example/dhcpd?module=dhcpd</capability>
<capability>urn:ietf:params:xml:ns:yang: ietf-inet-types?revision=2010-09-24&amp;module=ietf-inet-typ
es</capability>
</capabilities>
<session-id>5</session-id>
</hello>
 NETCONF get-config operation

Note use of subtree filter:

YANG model identified using xmlns for module

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="1">

<get-config>
<source>
<running/>
</source>
<filter xmlns="http://tail-f.com/ns/aaa/1.1">
<aaa/>
</filter>
</get-config>
</rpc>
 NETCONF get-config response

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="1">

<data>
<aaa xmlns="http://tail-f.com/ns/aaa/1.1">
<authentication>
<users>
<user>
<name>admin</name>
<uid>9000</uid>
<gid>0</gid>
<password>$1$3ZHhR6Ow$acznsyClFc0keo3B3BVjx/</password>
<ssh_keydir>/var/confd/homes/admin/.ssh</ssh_keydir>
<homedir>/var/confd/homes/admin</homedir>
</user>
<user>
<name>oper</name>
…
</users>
</authentication>
</aaa>
</data>
</rpc-reply>
 NETCONF edit-config operation

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="1">

<edit-config>
<target><running/></target>
<config>
<dhcp xmlns="http://tail-f.com/ns/example/dhcpd"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1">
<defaultLeaseTime nc:operation="merge”>PT1H
</defaultLeaseTime>
</dhcp>
</config>
</edit-config>
</rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="1">

<ok/>
</rpc-reply>
 NETCONF edit-config options

nc:test-option (:validate) nc:operation

merge Error if item to delete does
test-then-set (default) not exist
set replace
create
test-only
delete
nc:error-option remove (:base:1.1)
stop-on-error (default)
continue-on-error
rollback-on-error Ok if item to delete does not
(:rollback-on-error) exist
 NETCONF copy-config operation

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<copy-config>
<target><running/></target>
<source>
<url>https://[email protected]:passphrase/cfg/new.txt
</url>
</source>
</copy-config>
</rpc>

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<ok/>
</rpc-reply>
 NETCONF delete-config operation

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<delete-config>
<target>
<startup/>
</target>
</delete-config>
</rpc>

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<ok/>
</rpc-reply>
 NETCONF lock/unlock operation

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<lock>
<target>
<candidate/>
</target>
</lock>
</rpc>

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<ok/>
</rpc-reply>
 NETCONF get operation

Returns both (running) config and operational data

<rpc message-id="101” <rpc-reply message-id="101” xmlns=“urn:ie

xmlns=”urn:ietf:param <data>
<get> <top xmlns="http://example.com/ns/dhc
<filter type="subtree"> <interfaces>
<top xmlns="http://example.com/ns/dhc <interface>
<interfaces> <ifName>eth0</ifName>
<interface> <ifInOctets>45621</ifInOctets>
<ifName>eth0</ifName> <ifOutOctets>774344</ifOutOctet
</interface> </interface>
</interfaces> </interfaces>
</top> </top>
</filter> </data>
</get> </rpc-reply>
 NETCONF close-session operation

Polite way to disconnect

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<close-session/>
</rpc>

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<ok/>
</rpc-reply>
 NETCONF kill-session operation

(Not so) polite way to disconnect (someone else)

Releases any locks, aborts any confirmed commit related to session

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<close-session/>
</rpc>

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<ok/>
</rpc-reply>
 Additional NETCONF Operations
(by capabilities)

<commit>, <discard-changes> (:candidate)

<validate> (:validate)
• Copy candidate to running
• Discard changes in candidate (copy running to candidate)

<create-subscription> (:notification)

<partial-lock>, <partial-unlock> (:partial-lock)

<commit>, <cancel-commit> (:commit)

<get-schema> (:ietf-netconf-monitoring)
NETCONF Basics

Use a NETCONF device: ConfD

NETCONF Basics

Setup the VM:

● Update all dependencies
$ sudo apt-get update

● Install an xml parser needed by netconf client

$ sudo apt-get install libxml2-utils
NETCONF Basics

● Get ConfD
$ sudo wget -O confd.tar.gz https://db.tt/ClWpS3qR
$ tar xvf confd.tar.gz
$ sudo mv confd /opt

● Start ConfD:
$ /opt/confd/bin/confd

● See existing models:

$ ls /opt/confd/etc/confd/

For each existing yang model, there is its associated .fxs file
NETCONF Basics

● Generate the .fxs file for the yang files (ConfD’s YANG binary)

$ cd /opt/confd/etc/confd
$ /opt/confd/bin/confdc -c /opt/confd/etc/confd/car.yang

$ ls | grep car
car.fxs car.yang

● We now have both our yang file and its associated ConfD’s binary
NETCONF Basics

● Stop and restart ConfD so it takes it in account:

$ /opt/confd/bin/confd --stop
$ /opt/confd/bin/confd --start-phase0
$ /opt/confd/bin/confd --start-phase1
$ /opt/confd/bin/confd --start-phase2
NETCONF Basics

● Watch ConfD status:

$ /opt/confd/bin/confd --status
--[cut]--
SMP support: no
Using epoll: no
running modules: backplane,netconf,cdb,cli
status: started
namespaces: urn:opendaylight:car prefix:car exported to: all
urn:ietf:params:xml:ns:yang:iana-crypt-hash prefix:ianach exported to: all
urn:ietf:params:xml:ns:yang:ietf-inet-types prefix:inet exported to: all
--[cut]--
YANG data models:
module: car revision: 2016-06-09
namespace: urn:opendaylight:car
prefix: car
exported to: all

--[cut]--
NETCONF Basics

● Use the netconf-console provided by Confd

● Help
$ /opt/confd/bin/netconf-console-tcp --help

● Hello Message
$ /opt/confd/bin/netconf-console-tcp --hello

● Get-schema
$ /opt/confd/bin/netconf-console-tcp --get-schema=car
NETCONF Basics

● Get-config
$ /opt/confd/bin/netconf-console-tcp --get-config
Specify the database:
$ /opt/confd/bin/netconf-console-tcp --get-config --db candidate

● Edit-config (use the interactive command line):

$ /opt/confd/bin/netconf-console-tcp -i

* Enter a NETCONF operation, end with an empty line

NETCONF Basics

● Lock Payload
<lock>
<target>
<running/>
</target>
</lock>

● Unlock Payload
<unlock>
<target>
<running/>
</target>
</unlock>
NETCONF Basics

● Edit-config Payload
<edit-config>
<target>
<candidate/>
</target>
<config>
<car-info xmlns="urn:opendaylight:car"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
nc:operation="merge">
<max-speed>220</max-speed>
<gaz-tank-state>low</gaz-tank-state>
<car-id>1</car-id>
</car-info>
</config>
</edit-config>
NETCONF Basics

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

● Exit the interactive command line (ctl+c)

NETCONF Basics

● Get-config
$ /opt/confd/bin/netconf-console-tcp --get-config --db candidate

● Response
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<data>
<car-info xmlns="urn:opendaylight:car">
<max-speed>220</max-speed>
<gaz-tank-state>low</gaz-tank-state>
<car-id>1</car-id>
</car-info>
</data>
</rpc-reply>
NETCONF Advanced
NETCONF/YANG vs SNMP
Ability to express hierarchy
Definition language: (compare MIBs: flat + tables) Definition language:
YANG Richer conditions, constraints SMIv2
Facilities for easier reuse
RPC/Action support
Information model: Import conversion rules exist Information model:
YANG modules (MIBs → YANG) MIB modules
“instant content”
Human readability
Instantiated data: Dynamic extensibility Instantiated data:
XML B2B, Web toolkits ASN.1 BER
Bulk vs only incremental ops
(manipulation of config files,
Transport: e.g. edit-config)
Transport:
Netconf Transaction support SNMP
or possibly other Configuration vs monitoring
(no inherent dependency but
will require different bindings)
 What makes NETCONF better than SNMP?
This is where the difference is:
In the supported use cases!
Use Case SNMP NETCONF
Get collection of status fields Yes Yes. Bulk xfer up to
10x faster.

Set collection of configuration fields Yes, up to 64kB Yes

NETCONF Advance
Set configuration fields in transaction No Yes
Transactions across multiple network elements No Yes

Invoke administrative actions Well… Yes

Send event notifications Yes Yes, connected
Backup and restore configuration Usually not Yes
Secure protocol v3 is fair Yes
Test configuration before final commit No Yes
 NETCONF rpc operation

All other operations are layered on NETCONF RPC

But ”naked” NETCONF RPC can be used to call a YANG RPC

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<close-session/>
</rpc>

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">

<ok/>
</rpc-reply>
 NETCONF create-subscription operation

Used to request notifications from a specific stream as per RFC5277

Note that RFC5277 pre-dates YANG. 5277bis is on its way…

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

<create-subscription xmlns=”urn:ietf:params:xml:ns:netconf:notification:1.0”/>
</rpc>

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

<ok/>
</rpc-reply>
 NETCONF Notification

Used to transport YANG-modelled notifications

Unsolicited (once subscription is created!) – no rpc/rpc-reply

<notification xmlns="urn:ietf:params:netconf:capability:notification:1.0">
<netconf-capability-change xmlns="urn:ietf:params:xml:ns:yang:. . . “>
<changed-by><server/></changed-by>
<added-capability>. . .</added-capability>
</netconf-capability-change>
<eventTime>2016-09-21T11:22:52-07:00</eventTime>
</notification>
NETCONF Advanced

Add functionalities to our NETCONF device

NETCONF Advanced

● RPC
Execute the RPC using the netconf-console in interactive mode
$ /opt/confd/bin/netconf-console-tcp -i

* Enter a NETCONF operation, end with an empty line

<get-tank-state xmlns="urn:opendaylight:car">
<car-id>1</car-id>
</get-tank-state>
NETCONF Advanced

● RPC response
“Not yet implemented”

● Implement RPC callback with ConfD

Use Tail-f exec callback

● Add this import in the car.yang

import tailf-common { prefix tailf; }

NETCONF Advanced

● Add the following lines to the RPC we created previously

rpc get-tank-state {
tailf:exec "/opt/confd/etc/confd/get-tank-state.sh" {
tailf:args "-c $(context)";
}
input {
leaf car-id {
type uint8;
}
}
output {
leaf current-trank-state {
type trank-state;
}
}
}
NETCONF Advanced

● Get into the schema folder

$ cd /opt/confd/etc/confd

● Create the callback script get-tank-state.sh

$ vi get-tank-state.sh

● Add the following into the file, “medium” will be the output
#!/bin/sh
mesg=medium
echo "current-trank-state $mesg"
NETCONF Advanced

● Regenerate car.fxs
$ rm car.fxs
$ /opt/confd/bin/confdc -c car.yang

● Stop and restart ConfD so it takes it in account:

$ /opt/confd/bin/confd --stop
$ /opt/confd/bin/confd --start-phase0
$ /opt/confd/bin/confd --start-phase1
$ /opt/confd/bin/confd --start-phase2
NETCONF Advanced

● Make the script executable

$ chmod +x get-tank-state.sh

● Execute the RPC again

$ /opt/confd/bin/netconf-console-tcp -i

* Enter a NETCONF operation, end with an empty line

<get-tank-state xmlns="urn:opendaylight:car">
<car-id>1</car-id>
</get-tank-state>
NETCONF Advanced

● RPC Response
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<current-trank-state xmlns="urn:opendaylight:car">medium</current-trank-state>
</rpc-reply>
NETCONF Advanced

● Notification (rfc5277)
Requires notifications.yang
http://www.netconfcentral.org/modulereport/notifications
Payload
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>YOUR-DEFINED-STREAM</stream>
</create-subscription>
NETCONF Advanced

● Notification definition (YANG)

notification out-of-gas {
description "This notification is sent to signal that the car is out of gas";
leaf temperature-alarm {
type leafref {
path "/car-info/gaz-tank-state";
}
mandatory true;
}
}
NETCONF Advanced

● Register the stream in ConfD

Modify the confd.conf

● Define the notification callback with ConfD

Create the callback (c)

OpenDaylight NETCONF/YANG and RESTCONF
 Mounting a NETCONF device in ODL

RESTCONF
Node Inventory Model Cache MD-SAL

NETCONF

XR1 XR2 OpenWRT

• Nodes added by through the config subsystem
• ODL connects to each node
• ODL learns capabilities (YANG modules) and stores to model cache
• Cache at ~/cache/schema (filenames of form [email protected])
RESTCONF
RESTCONF URIs
RESTCONF to mounted NETCONF device
OpenDaylight NETCONF/YANG and
RESTCONF

Mount your running ConfD instance

● Start OpenDaylight (Boron release)

$ sudo ./Training/opendaylight/distribution-karaf-0.5.0/bin/karaf

● Install the NETCONF CLI feature

opendaylight-user@root> feature:install odl-netconf-console

● Mount the ConfD device

opendaylight-user@root>netconf:connect-device --port 2022 --password admin

-id confd -U admin -t false -i 10.0.2.15
OpenDaylight NETCONF/YANG and
RESTCONF

Mount your running ConfD instance

● List all NETCONF devices

opendaylight-user@root>netconf:list-devices

● Show our NETCONF device attributes

opendaylight-user@root>netconf:show-device -id confd

● For more info on the CLI:

https://wiki.opendaylight.org/view/NETCONF:Karaf_CLI
OpenDaylight NETCONF/YANG and
RESTCONF

From YANG to APIs

● Use web interface apidoc

opendaylight-user@root>feature:install odl-mdsal-apidocs

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

● Use web interface yang-ui

opendaylight-user@root>feature:install odl-dlux-yangui

→ http://localhost:8181/index.html#/yangui/index
OpenDaylight NETCONF/YANG and
RESTCONF

Mount through VPN a device from dCloud

Troubleshooting
Troubleshooting

● Basic Process (flow chart)

● Example case and ask the audience how to go about troubleshooting
● Common NETCONF issues and solutions
Troubleshooting

● Basic Process (flow chart)

● Example case and ask the audience how to go about troubleshooting
● Common NETCONF issues and solutions
Basic Process (flow chart)
Troubleshooting

● Basic troubleshooting for NETCONF mount process (flow chart)

● Example Case
● Common NETCONF issues and solutions
Example Case

● Start the controller

● Mount the controller so it is accessible via RESTCONF
● Break a model
● Restart the controller
● Query the operational network-topology
Example Case

● Start the controller

● Mount the controller so it is accessible via RESTCONF
● Break a model
● Restart the controller
● Query the operational network-topology
Start the controller

● Open “Terminal Emulator” from the VM Desktop.

Example Case

● Start the controller

● Mount the controller so it is accessible via RESTCONF
● Break a model
● Restart the controller
● Query the operational network-topology
Example Case

● Start the controller

● Mount the controller so it is accessible via RESTCONF
● Break a model
● Restart the controller
● Query the operational network-topology
Example Case

● Start the controller

● Mount the controller so it is accessible via RESTCONF
● Break a model
● Restart the controller
● Query the operational network-topology
Example Case

● Start the controller

● Mount the controller so it is accessible via RESTCONF
● Break a model
● Restart the controller
● Query the operational network-topology
Troubleshooting

● Basic troubleshooting for NETCONF mount process (flow chart)

● Example Case
● Common NETCONF issues and solutions
Tooling, References etc.
 “Compile-Time” Tooling

Editor plug-ins:
• emacs (yang-mode.el)
• vim (yang.vim)
• sublime text (sublime-yang-syntax)

pyang
• an extensible YANG validator written in Python.
• can be used standalone to validate YANG modules, or to translate YANG to YIN, XSD,
DSDL etc.
• can be integrated into other applications

libsmi
• a library allowing the generation of YANG models from SMI/SMIv2 compliant MIBs
• has a variety of supporting tools available for generation, debug etc.
 “Run-Time” Tooling

ncclient
a Python library that facilitates client-side scripting and application development around the
NETCONF protocol

Postman
• a Chrome app for REST APIs, allowing for customized sets of REST snippets to be easily
built, maintained and shared
• Useful for accessing ODL RESTCONF APIs

OpenDaylight
• ODL auto-generates RESTCONF and NETCONF APIs from YANG models
• apidocs provides a way to explore both local and mounted YANG models
• YANG-UI provides a model-driven WEB UI for exploring YANG models
• YANGman is a YANG-aware Postman equivalent
Thanks