The above is graphic is how YANG / NETCONF / RESTCONF flow like an OSI Model!
“Yet Another Next Generation” or YANG is defined in RFC 6020 as a “Data Modeling Language” used to model Configuration and State data manipulated by “Network Configuration Protocol” (NETCONF), NETCONF RPCs, and NETCONF notifications.
Though YANG generally describes Network Data Models, it can be used to describe any Data Model, with two flavors of Data Model shown at the bottom:
- Open YANG Model – Vendor Neutral models that are designed to be independent of the underlying platform / OS in use, with a standardized body for all vendors usage
- Native YANG Model – Vendor specific, this model will only be understood by the Vendor’s equipment that it is built to interact with (Like Cisco)
YANG is needed for standardization of communications while still allowing for further description / flexibility, allowing different devices to be mapped in a similar way, yet have different ways of describing devices / configs / states / objects / etc.
YANG was around before NETCONF or RESTCONF, so it is the Data Modeling Language of the Internet / Network Environments, it is not specific to ANY specific Protocol so if asked on Exam Day YANG is the Data Model Language of the Greater IT Ecosystem.
Note – I will not be reviewing gRPC (Google RPC) here, but it does exist, so wanted to say that đŸ™‚
Some important terms to know for YANG Data Modeling:
- anyxml – A data node that can contain an unknown chunk of XML Data
- augment – Adds new schema nodes to a previously defined schema node
- container – An interior node that exists within an instance of a Data Tree, it describes no data itself but rather contains a sub-set of child nodes with descriptions
- data model – A Data Model describes how data is represented and accessed
- data node – A node in the schema tree that can be represented in a data tree, like a container / leaf / leaf-list / list / anyxml
- data tree – The represented tree of configuration and state data on a device
- derived type – A type that is derived from a built-in type (inherited type such as unit32)
- grouping – A reusable set of schema nodes, used locally by models that include it or imported from other modules, the grouping statement is not a data definition statement, so it does not define any nodes in that schema tree
- identifier – Used to identify different kinds of YANG items by name
- leaf – A data node that exists in at most once in the data tree, defines a value but does not have any child nodes
- leaf-list – Like a leaf node but defines a set of uniquely identifiable nodes rather than a single node, each node has a value but contains no child nodes
- list – An interior data node that may exist in multiple instances in a data tree, a list has no value but defines a sub-set of child nodes
- module – A YANG Module defines a hierarchy of nodes the can be used for NETCONF-based operations, modules should be self-contained and “compilable”
- state data – The additonal data on a system the is not configuration data / read-only status info collected from a device statistics
- RPC – Remote Procedure Call as used in NETCONF
Of that big mess of definitions, YANG defines four types of “nodes” in Data Models:
- Leaf Nodes
- Leaf-List Nodes
- Container Nodes
- List Nodes
A statement with a YANG Data Model will have the following format:
statement = keyword [argument] (“;” / “{” *statement “}”)
There are four major statements in a YANG Module:
- Container – A grouping of other statements (which have no value)
- List – Multiple records containing at least one Leaf “Key” and an arbitrary hierarchy of other statements within the Module
- Leaf – A single Key/Value Pair
- Leaf-List – Multiple Key/Value pairs of the same type or commonality
To visually represent the structure described above of a YANG Module:
Modules will typically Root from a Container, branching out into the schema tree that extends into different Data Structures, with leafs or leaf-lists at the ends of branches.
A thorough demonstration of YANG model with explanations can be found here:
https://github.com/YangModels/yang/blob/master/standard/ietf/RFC/ietf-interfaces%402018-02-20.yang
Or like the Demo I had in another Post that was more Hank Prestons video material:
Though the GitHub example is much better, so I would suggest checking that one out!
A review of NETCONF – What it is, terminology, and how it operates!
NETCONF uses XML based Data Encoding fro both Configuration and Protocol messages, providing a small set of operations to retrieve / configure / copy / delete configs on Datastores of devices typically by using an RPC via SSH (22) and NETCONF (830) as its Transport Protocols.
NETCONF Protocol Operations include:
- get – Retrieve running config and state information
- get-config – Retrieve all or part of specified configuration
- edit-config – Edit a device configuration
- copy-config – Create or replace an entire configuration data store with another complete configuration data store
- delete-config – Delete a config in a datastore
- lock – Lock the entire config in the datastore system of a device
- unlock – Release a config lock, previously locked using ‘lock’ operation
- close-session – Request graceful termination of a NETCONF session
- kill-session – Force termination of a NETCONF session
NETCONF vs SNMP – A comparison of features of both protocols
Being there is often a contrast drawn between the two because they operate in a similar fashion, however SNMP being more limited in scope, lets go through the list of features!
SNMP:
- Uses “pull” model when retrieving data from device which doesn’t scale
- Does not have a discovery process for finding MIBs supported by a device
- Does not support the concept of transactions between NMS and Device
- Lacks backup / restore elements of configuration
- Limited industry support for configuration MIBs
NETCONF:
- Multiple config data stores (startup, running, candidate)
- Device-level and Network-wide Transactions available
- Configuration testing / validation
- Distinction between configuration and operational data
- Selective data retrieval with filtering
- Streaming and playback of even notifications
- Extensible RPCs
- Built-in capability exchange
Also those 3 data store types that can be the target of config reads / writes:
- Running – Mandatory – This is the current running configuration
- Candidate – Optional – Where changes can be pushed to without affecting the Running configuration, use a “commit” operation to commit change from Candidate to Running
- Startup – Optional – Same as an IOS Device, saving the Running config to the Startup
The “Candidate” Data store where changes are made is generally where a user will “Lock” that Data store while making configuration changes, otherwise another user may come in to begin making changes to that as well and over-write your changes IF NOT LOCKED!
Some good to know commands for NETCONF to a device for verification:
- “show netconf-yang datastores” – This will show you what type of datastores the target device has, which are “Locked” and by which session user they are locked
- “show netconf-yang sessions” – Shows all individual sessions with usernames / IPs / locked sessions / Transport Method / Session ID #
- “show netconf-yang sessions detail” – NOTE Sessions is plural and detail is singular in syntax! This shows further details about each session like connection time / locks / transport protocols / source IP / username / Etc
That is just a few good to know ones, I would lab this in Sandbox before sitting the the exam!
Last but not least – An overview of RESTCONF / What it is / Operations / Etc!
RESTCONF is defined by RFC # 8040 and defines a REST (Representation State Transfer) like configuration info and control, similar to NETCONF it uses Datastore Models and command ‘verbs’ defined in NETCONF, encapsulated in HTTP messages. It also uses the same YANG Data Construct to describe datastore configuration / state / events.
RESTCONF uses either XML or JSON data structures and YANG to provide REST-like APIs that enable programmatic access to devices, the HTTP Verbs like POST / GET / DELETE / etc are used within a RESTCONF API to access or configure Data Resources via YANG Data Models.
RESTCONF is not intended to replace NETCONF, but rather provide an HTTP interface that follow REST Principles, so that it is compatible with NETCONF Datastore Models allowing a device to serve both NETCONF and RESTCONF concurrently or one particular type.
RESTCONF vs NETCONF – A look at the difference between them!
NETCONF is more Comprehensive / Flexible / Complex in its capability, however RESTCONF is easier to learn for Engineers familiar with REST APIs, below are the main differences:
- NETCONFIG support running and candidate datastores, while RESTCONF only supports Running Datastores, which is a fairly huge difference to know!
- RESTCONF does not support the Lock / Unlock function, so if a NETCONF Session locks a Datastore, the RESTCONF operation to the Datastore will fail if it is Locked!
- RESTCONF edit is a transaction limited to a single RESTCONF call
- RESTCONF does not support transactions across multiple devices
- Validation is implicit in every RESTCONF edit operation, either succeeding or failing
Some mappings of NETCONF Operations to RESTCONF Methods:
Create Data Resource – <edit-config> – POST
Retrieve Data / Metadata – <get-config> – GET
Create / Replace Data – <edit-config> – PUT
Delete Data Resource – <edit-config> – DELETE
(NOTE – NETCONF <edit-config> maps to two RESTCONF Methods!)
Important Note – RESTCONF uses HTTPS to make connections to target devices, either by using a GUI like Postman which requires in the Headers the Key “Accept” and Value “application/yang-data+json” for it to make a successful connection.
Both NETCONF and RESTCONF connections can be scripted via Python, the different is that NETCONF return output will be in XML format, while RESTCONF will be returned in JSON when the connection to the Data Resource is scripted via Python!
That will conclude this overview of YANG / NETCONF / RESTCONF – Labbing to come soon!
Being I am a bit behind in my DevNet class material towards the end here, and a whole lot left to go with reviewing all Cisco Platforms (Firepower, ISE, UCS, Innersight, Etc) to go, I am putting the playing with AWS aside for now to make a full on DevNet blitz to make sure I follow through to lab this stuff and get that 200-901 Exam Certification nailed onto my wall! đŸ™‚
Until next time!!!
The DEVNET GRIND! 