ELEC3506

Topics

Application LayerLecture 8 PDF10 min

NETCONF and YANG

How NETCONF manages devices network-wide using XML remote procedure calls over a secure, reliable transport, the life of a NETCONF session, its selected operations, and how YANG models the data.

By the end of this page you should be able to

  • State the goals and the RPC and XML basis of NETCONF
  • Describe the three stages of a NETCONF session, from initiation to close
  • Match the selected NETCONF operations to what each does
  • Explain what YANG is for and how it relates to NETCONF messages

The idea

SNMP is good at reading counters and setting single values on one device. It is awkward when an operator wants to change the configuration of many devices and have the change succeed everywhere or not happen at all. NETCONF was designed for that kind of network-wide configuration, and YANG describes the data it moves so that a bad configuration can be caught before it is applied.

How it works

NETCONF

NETCONF (Network Configuration Protocol) has the goal of actively managing and configuring devices network-wide. It operates between a managing server and the managed network devices. The lecture lists its actions:

  • Retrieve, set, modify and activate configurations.
  • Atomic-commit actions over multiple devices.
  • Query operational data and statistics.
  • Subscribe to notifications from devices.

It follows the remote procedure call (RPC) paradigm. NETCONF protocol messages are encoded in XML and exchanged over a secure, reliable transport protocol.

How it works

Session: initialisation, exchange, close

A NETCONF session has three stages.

  1. Initiation and capabilities exchange: the two sides send <hello> messages.
  2. Exchange: the managing server sends <rpc> requests and the device answers each with an <rpc-reply>. The device can also send <notification> messages on its own.
  3. Close: the session ends with <close-session>.

Aside

The session diagram

The slide draws this as a message sequence between the managing server and the device. The arrows did not extract, only the message names and the ellipses between them. The three stages above follow the names on the slide, in the order they appear.

How it works

Selected NETCONF operations

The lecture lists these operations.

OperationDescription
<get-config>Retrieve all or part of a given configuration. A device may have multiple configurations.
<get>Retrieve all or part of both configuration state and operational state data.
<edit-config>Change the specified (possibly running) configuration at the managed device. The device <rpc-reply> contains <ok> or <rpc-error> with rollback.
<lock>, <unlock>Lock (unlock) the configuration datastore at the managed device, to lock out NETCONF, SNMP or CLI commands from other sources.
<create-subscription>, <notification>Enable event notification subscription from the managed device.
The slide prints the error element as rpcerror. It is written rpc-error here, the form used in the NETCONF messages.

How it works

YANG

YANG is a data modelling language used to specify the structure, syntax and semantics of NETCONF network management data.

  • It has built-in data types, like SMI.
  • An XML document describing the device and its capabilities can be generated from the YANG description. In the lecture’s picture, a NETCONF RPC carrying an <edit-config> message holds YANG-generated XML.
  • It can express constraints among the data that must be satisfied by a valid NETCONF configuration. That ensures configurations satisfy correctness and consistency constraints.

Where marks get lost

NETCONF and YANG are not interchangeable. NETCONF is the protocol that moves requests and replies. YANG is the language that defines what the data in those messages may look like.

In the exam

  • NETCONF basics: network-wide configuration, RPC paradigm, XML messages, secure and reliable transport, and atomic commit over multiple devices.
  • Session: <hello> for initiation and capabilities, <rpc> and <rpc-reply> pairs with optional <notification>, <close-session> to finish.
  • Operations: know what <get-config>, <get>, <edit-config>, <lock> and <create-subscription> each do, and that edit-config replies with ok or an error and rollback.
  • YANG: data modelling language for the structure, syntax and semantics of the data, with constraints for validity.

Check yourself

  • NETCONF manages and configures devices network-wide using XML RPCs over a secure, reliable transport.
  • Session: hello, then rpc and rpc-reply exchanges (plus notifications), then close-session.
  • get-config reads configuration, get reads configuration and operational state, edit-config changes it, lock stops other sources, create-subscription turns on notifications.
  • YANG models the data and its constraints, and XML can be generated from it.

Check yourself

  1. How are NETCONF messages encoded?
  2. Which message opens a NETCONF session and exchanges capabilities?
  3. A device rejects an edit-config request. What does its rpc-reply contain, according to the lecture?
  4. Which operation locks out commands arriving from SNMP and CLI sources?
  5. What is the role of YANG relative to NETCONF?