NETCONF YANG Tutorial ODLSummit2016 (1) -...

NETCONF/YANG Tutorial

Ryan Goulding, Senior Engineer, BrocadeGiles Heron, Principal Engineer, Cisco

Alexis de Talhouët, Software Developer, Inocybe Technologies

● NETCONF/YANG Overview

● YANG basics

● YANG advanced

● NETCONF basics

● NETCONF advanced

● OpenDaylight NETCONF/YANG and RESTCONF

● Troubleshooting

● Demo

● Tooling, References etc.

Agenda

NETCONF/YANG Overview

Why NETCONF/YANG – RFC3535

SNMP had failedFor configuration, that isExtensive use in fault handling and monitoring

CLI scripting“Market share” 70%+

AbstractThis document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA from June 4 thru June 6, 2002. The goal of the 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.

configuration

Cost and complexity • No well-defined protocols and

data-models• Lack of atomicity• Ordering problem

NETCONFManager

OSSNMSEMS

RFC3535 - legacy situation

RFC3535 - NETCONF/YANG solution

ReducedCost and

complexity

Cost/Value

NETCONFManager

OSSNMSEMS

TransactionsModelsStandardized 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…• …that is externally visible• Consistent and complete

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)

Data-Model

Protocol

NETCONFManager

NETCONF

YangModel

s

YANG ModelsYANG Models YANG Models

NETCONF & YANG “in the wild”

NETCONF

YANG Models

Transport

RemoteOperations

MgmtServices

Mgmt info(payload)

Mgmt info(definition)

XML-encoded content

YANG modules

Netconf operations<edit-config>, <get-config>, <get>

Netconf RPC<rpc>, <rpc-reply>

TLS, SSH

Manager (client)

XML content

per YANG

ConceptualData Store

Agent(server)

NETCONF/YANG ”Layer-Cake”

YANG Basics

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 structuresBuilt-in and derived types

YANG is extensible and modular

YANG modules are for NETCONF what MIBs are for SNMP

What is YANG?

YANG and XML

YANG assumes an XML encoding of instantiated informationDefines XML rendering rulesRelies on XML encoding for certain featuresFacilitates describing XML document hierarchiesNicely aligned with NETCONF ☺

YANG itself is not XMLEmphasis on readability

Familiar structure to C/C++ or Java programmersXML notation exists: YIN (Yang-Independent Notation)

Semantic equivalence Syntactic conversions YANG <-> YIN

Alternative encodings defined (e.g. JSON for RESTconf)

ODL

Transport

RemoteOperations

MgmtServices

Mgmt info(encoding)

Mgmt info(definition)

XML-encoded content

YANG modules

NETCONF operations

XMLRPC

TLS,SSH

JSON JAVA DTO

I2RS

gRPC

HTTP

RESTCONF

TCP

How does YANG go beyond NETCONF?

acme-box module

properties container

interfaces container

name: string, config

name: string, config

interface: list, key = name

oper-state: enum, config

How are YANG modules structured?

How are YANG modules structured?

Header informationImports & Includes

Type definitions

Configuration & Operationaldata declarations

Action (RPC) & Notification declarations

YANG Model - Header

YANG Model – Imports/Includes

Module Y NamespaceModule X Namespace

FragmentA.yang

FragmentB.yang

FragmentC.yang

FragmentD.yang

FragmentE.yang

Each included fragment is a complete YANG file; can never be included in any other module/namespace

include

includeinclude

import

Imported fragments are just referenced, not included

YANG Model – submodules

Attention: The submodule cannot reference definitions in main module

Each submodule belongs to one specific main module

• YANG leaves have a data type

• Type may be a base type or a derived type

• There are 20+ base types…

Type Name Meaningint8/16/32/64 Integeruint8/16/32/64 Unsigned integer

decimal64 Non-integer

string Unicode string

enumeration Set of alternativesboolean True or false

bits Boolean array

binary Binary BLOBleafref Reference “pointer”identityref Unique identityempty No value, void

…and more

YANG Types

percent

completed

Type is referenced by a new leaf XML Instance Data:

<completed>50</completed>

YANG Typedef – defines new simple type

• Commonly used YANG types defined in RFC 6021

• Use:

• And e.g:

counter32/64 ipv4-address

gauge32/64 ipv6-address

object-identifier ip-prefix

date-and-time ipv4-prefix

timeticks ipv6-prefix

timestamp domain-name

phys-address uri

ip-version mac-address

flow-label bridgeid

port-number vlanid

ip-address … and more

Common YANG Types

target

peer

addressport

destinationaddressport

XML Instance Data:<destination>

<address>192.168.0.1</address>

<port>80</port>

</destination>

YANG Grouping – defines structured type

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

• 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 – Leaf-List

user

name classfull-nameuidDefault

YANG Data Declarations – List Statement

user

name classfull-nameuidDefaultyang 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 accessingKey can be one leaf, or multipleIn RESTCONF key is URL element (after list name – e.g. “…/user/hawk”)

Where >1 key each key is a new URL element

YANG Lists - Keys

YANG Lists – “Unique” Statement

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)

user

name classfull-nameuidDefault

1010 yang Yan Goode admin

1152 hawk Ron Hawk oper

1202 ling Lin Grossman viewer

Groups related leafs and containers system

services

…

ssh

…

Presence

YANG Data Declarations – Containers

XML Instance Data:<system>

<services>

</services>

</system>

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

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

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

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.yangcar.yang:6: warning: imported module ietf-yang-types not used

YANG Basics

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

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

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.yangmodule: 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 Basics

YANG Advanced

YANG module structure - reminder

Header informationImports & Includes

Type definitions

Configuration & Operationaldata declarations

Action (RPC) & Notification declarations

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

Union - a value that represents one of its member types

Instance Data:

<threshold>50</threshold>

Or:

<threshold>disabled</threshold>

Advanced YANG Types - Unions

Choice - allows one of several alternatives

transfer-interval

transfer-on-commit

transfer-method

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

base identity defined

refer back to base

additional identities – same base

leaf refers to base identity

Advanced YANG Types - Identity

Original (augmented) YANG module

Namespace http://example.com/schema/interfaces

Namespace http://example.com/schema/ds0

New (augmenting) YANG module

Context node

Information to augment the context

node with

Advanced Data Definition - Augment

Effectively equivalentto the following

Instance Data:

<interfaces>

<ifEntry>

<ifIndex>1</ifIndex>

<ifType>ds0</ifType>

<ifMtu>1500</ifType>

<ds0ChannelNumber>13<ds0ChannelNumber>

</ifEntry>

</interfaces>

YANG Augment - Example

Restricts valid values byXpath 1.0 expression

Xpath expression to validate against data

YANG Constraints – must statement

Administrative actions with input and output parameters

image

status

activate-software-image

YANG RPCs

Notification with output parameters

operator-name

change

config-change

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

Instance-identifier values

YANG Notifications

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

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

Used to specify that a NETCONF server doesn’t support part of a model.

Arguments can be:1. not-supported2. delete3. replace4. add5. replace

YANG Conformance - Deviations

YANG Module“Interfaces”

A

if-feature individualStatsif-feature aggregatedStats

YANG Module“myInterfaces”

Feature“individualStats”

Deviation A

YANG Conformance - Illustrated

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

YANG Advanced

NETCONF Basics

What is NETCONF

Netconf is connection-orientatedSSH, 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 exchangeData model ID exchange

Framing• 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&module=ietf-inet-types</capability></capabilities><session-id>5</session-id></hello>

NETCONF get-config operation

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

Note use of subtree filter:YANG model identified using xmlns for module

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>

nc:test-option (:validate)test-then-set (default)settest-only

nc:error-optionstop-on-error (default)continue-on-errorrollback-on-error (:rollback-on-error)

nc:operationmergereplacecreatedelete remove (:base:1.1)

Error if item to delete does not exist

Ok if item to delete does not exist

NETCONF edit-config options

<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 copy-config operation

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


NETCONF delete-config operation

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


NETCONF lock/unlock operation

<rpc message-id="101” xmlns=”urn:ietf:param<get> <filter type="subtree"> <top xmlns="http://example.com/ns/dhc <interfaces> <interface> <ifName>eth0</ifName> </interface> </interfaces> </top> </filter></get>

<rpc-reply message-id="101” xmlns=“urn:ie <data> <top xmlns="http://example.com/ns/dhc <interfaces> <interface> <ifName>eth0</ifName> <ifInOctets>45621</ifInOctets> <ifOutOctets>774344</ifOutOctet </interface> </interfaces> </top> </data></rpc-reply>

NETCONF get operation

Returns both (running) config and operational data

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


Polite way to disconnect

NETCONF close-session operation



(Not so) polite way to disconnect (someone else)Releases any locks, aborts any confirmed commit related to session

NETCONF kill-session operation

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

Additional NETCONF Operations(by capabilities)

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

https://db.tt/ClWpS3qR

● 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: noUsing epoll: norunning modules: backplane,netconf,cdb,clistatus: startednamespaces: 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:carprefix: carexported 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-configSpecify 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 Basics

NETCONF Advanced

Definition language:YANG

Information model:YANG modules

Instantiated data:XML

Transport:Netconf

Definition language:SMIv2

Information model:MIB modules

Instantiated data:ASN.1 BER

Transport: SNMP

Import conversion rules exist(MIBs → YANG)“instant content”

Ability to express hierarchy(compare MIBs: flat + tables)Richer conditions, constraints

Facilities for easier reuseRPC/Action support

Human readabilityDynamic extensibility

B2B, Web toolkits

Bulk vs only incremental ops(manipulation of config files,

e.g. edit-config)Transaction support

Configuration vs monitoringor possibly other(no inherent dependency but

will require different bindings)

NETCONF/YANG vs SNMP

NETCONF Advance

Use Case SNMP NETCONFGet collection of status fields Yes Yes. Bulk xfer up to

10x faster.

Set collection of configuration fields Yes, up to 64kB YesSet configuration fields in transaction No YesTransactions across multiple network elements No Yes

Invoke administrative actions Well… YesSend event notifications Yes Yes, connectedBackup and restore configuration Usually not YesSecure protocol v3 is fair YesTest configuration before final commit No Yes

This is where the difference is:In the supported use cases!

What makes NETCONF better than SNMP?



All other operations are layered on NETCONF RPCBut ”naked” NETCONF RPC can be used to call a YANG RPC

NETCONF rpc operation

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


NETCONF create-subscription operation

Used to request notifications from a specific stream as per RFC5277Note that RFC5277 pre-dates YANG. 5277bis is on its way…

NETCONF Notification

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

Used to transport YANG-modelled notificationsUnsolicited (once subscription is created!) – no rpc/rpc-reply

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/shmesg=mediumecho "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.yanghttp://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

http://www.netconfcentral.org/modulereport/notifications

http://www.netconfcentral.org/modulereport/notifications

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

NETCONF Advanced

OpenDaylight NETCONF/YANG and RESTCONF

MD-SAL

NETCONF

RESTCONF

Node Inventory

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

Model Cache

XR1 XR2 OpenWRT

Mounting a NETCONF device in ODL

RESTCONF

RESTCONF URIs

RESTCONF to mounted NETCONF device

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


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


https://wiki.opendaylight.org/view/NETCONF:Karaf_CLI

https://wiki.opendaylight.org/view/NETCONF:Karaf_CLI

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


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

http://localhost:8181/index.html#/yangui/index

Mount through VPN a device from dCloud


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


Troubleshooting

Basic Process (flow chart)

● Basic troubleshooting for NETCONF mount process (flow chart)

● Example Case


Troubleshooting

● 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



● Break a model



Example Case

● Open “Terminal Emulator” from the VM Desktop.

Start the controller



● Break a model



Example Case



● Break a model



Example Case



● Break a model



Example Case



● Break a model



Example Case

● Basic troubleshooting for NETCONF mount process (flow chart)

● Example Case


Troubleshooting

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

ncclienta 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

Date post:	18-Mar-2018
Category:	Documents
Upload:	trannhan
View:	250 times
Download:	9 times

NETCONF YANG Tutorial ODLSummit2016 (1) -...

Documents