NETCONF (Network Configuration Protocol) Network Configuration Protocol A protocol for communicating configuration and query data between a managing server and managed network devices. The modern alternative to polling with SNMP. introduced in ch. 5 configures devices instead of only reading them: every message is an XML (Extensible Markup Language) Extensible Markup Language The structured document format NETCONF encodes its messages and configurations in. introduced in ch. 5 document, it runs over a secure connection, and it can change a whole set of devices as one transaction.
Words you will meet
-
NETCONF netconf Simple Configure devices, do not just read them. Precise Network Configuration Protocol, RFC 6241. It runs between the managing server and the managed devices, providing messaging to retrieve, set and modify configuration data, to query operational data and statistics, and to subscribe to notifications. Messages and configurations are XML documents, exchanged in a remote-procedure-call style over a secure connection-oriented session such as TLS over TCP. introduced in ch. 5 — open in glossary — the Network Configuration Protocol, between a managing server and its managed devices.
-
YANG yang Simple The language the configuration is described in. Precise A data modelling language, RFC 6020, used to specify the structure, syntax and semantics of the network management data NETCONF carries — in much the same way SMI specifies MIBs for SNMP. All definitions live in modules, and an XML document describing a device and its capabilities can be generated from a module. It has a small set of built-in data types and lets a modeller express constraints a valid configuration must satisfy. introduced in ch. 5 — open in glossary — the data modelling language that describes what NETCONF is carrying.
-
RPC (Remote Procedure Call) Remote Procedure Call A style in which one machine invokes an operation on another as if calling a local function. NETCONF uses it. introduced in ch. 5 — remote procedure call: ask another machine to run an operation, as if calling a function.
-
Running configuration running configuration Simple The settings a device is actually using right now. Precise A device may hold several configurations. There is always a running configuration, which describes the device's current settings. A NETCONF <edit-config> naming the running configuration changes what the device is doing at that moment; on error the configuration state can be rolled back to its previous state. introduced in ch. 5 — open in glossary — the settings a device is actually using right now.
-
Capability netconf capability Simple An extra feature a NETCONF endpoint says it supports. Precise NETCONF functionality that supplements the base specification in RFC 6241. The managing server and the managed device declare their capabilities to each other in <hello> messages, immediately after a secure connection is established and before any other exchange. introduced in ch. 5 — open in glossary — an extra feature a NETCONF endpoint declares it supports.
Why this matters
Section 5.7.2 ended on a finding: in 2002 an IAB (Internet Architecture Board) Internet Architecture Board The body whose 2002 network-management workshop recorded the shortcomings of SNMP for configuration and for management at scale, which led to NETCONF and YANG. introduced in ch. 5 workshop recorded that the SNMP (Simple Network Management Protocol) Simple Network Management Protocol The Internet’s network-management protocol, typically run over UDP so that it still works when the network is under stress (§3.3, built in §5.7). introduced in ch. 3 and MIB (Management Information Base) Management Information Base The collection of managed objects in a device whose values reflect its status, and which SNMP reads and writes. introduced in ch. 5 approach was valuable for monitoring. It fell short for configuration and for management at scale.
This section is what was built in response. Everything in it answers one of those two complaints.
It is also the last new protocol in the chapter, and the last piece of a picture started in section 5.1: the control plane is not only about computing routes. It is about configuring and managing the devices that use them.
What NETCONF does
NETCONF operates between the managing server and the managed devices, and provides messaging for three things.
- Retrieve, set and modify configuration data at managed devices.
- Query operational data and statistics at managed devices.
- Subscribe to notifications generated by managed devices.
The managing server actively controls a device by sending it configurations, specified as a structured XML (Extensible Markup Language) Extensible Markup Language The structured document format NETCONF encodes its messages and configurations in. introduced in ch. 5 document, and then activating a configuration at the device.
NETCONF uses a remote procedure call style. Protocol messages are encoded in XML too, and they are exchanged over a secure, connection-oriented session, such as TLS (Transport Layer Security) Transport Layer Security Encryption, integrity and authentication added above TCP, in the application layer. introduced in ch. 2 over TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 . Chapter 8 covers TLS.
A session
Click any arrow to see what that message says and why it is sent.
Every message is an XML document. The three shapes are <rpc>/<rpc-reply> pairs, unsolicited <notification>s, and the <hello> and <close-session> that bracket them.
Read this diagram as text
- Managing server sends secure connection · TLS over TCP to Managed device. First the managing server establishes a secure, connection-oriented session to the managed device. Compare SNMP, which typically rides on UDP and repairs nothing. NETCONF starts from a reliable, encrypted channel.
- Managing server sends <hello> · my capabilities are… to Managed device. Capabilities are NETCONF functionality that supplements the base specification in RFC 6241. Each side declares what it supports before anything else happens.
- Managed device sends <hello> · and mine are… to Managing server. The exchange is symmetric. Neither side assumes what the other can do.
- Managing server sends <rpc message-id="101"> <get/> to Managed device. Interactions take the form of a remote procedure call. The managing server asks the device to run an operation, and the message carries an id so the reply can be matched to it.
- Managed device sends <rpc-reply message-id="101"> to Managing server. The reply carries the same message id. The whole configuration comes back inside it, in XML.
- Managing server sends <rpc message-id="102"> <edit-config> to Managed device. The same shape, but this one changes the device. Configuration is where NETCONF puts its emphasis.
- Managed device sends <rpc-reply message-id="102"> <ok/> to Managing server. If the device could satisfy the request it replies with an <ok> element. Otherwise it returns an <rpc-error>, and the configuration can be rolled back to its previous state.
- Managed device sends <notification> to Managing server. Device notifications are sent proactively from the managed device to the managing server, without a request. This is NETCONF’s equivalent of an SNMP trap, and a server subscribes to them with <create-subscription>.
- Managing server sends <close-session> to Managed device. And the session ends.
Lifelines, left to right: Managing server (server), Managed device (router).
NETCONF calls the managing server the “client”
The book flags this and then deliberately ignores it, and so does this page.
In NETCONF’s own vocabulary the managing server is the client, and the managed device is the server, because the managing server is the one that establishes the connection.
That is the opposite of the network-management terminology of Figure 5.20, which this chapter has used throughout. Both namings are correct in their own documents. If you read RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 6241 after this page, expect the words to swap.
The operations
| Operation | What it does |
|---|---|
Cells marked ⓘ have an explanation — click to read it.
Two of these have an SNMP counterpart. The other four are why NETCONF exists. Click a cell marked ⓘ.
Two of those have an SNMP counterpart: <get> retrieves state, and the
subscription pair delivers events. The other four —
<get-config>, <edit-config>, <lock> and <unlock> — are what demonstrate
NETCONF’s particular emphasis on device configuration.
In plain words
<lock> is the operation with no equivalent anywhere earlier in this chapter.
It lets a managing server lock the entire configuration datastore of a device. The server can then make a change without fear of interaction with other NETCONF, SNMP or CLI (Command Line Interface) Command Line Interface Typing commands directly at a device, on its console or over SSH. Vendor-specific, error-prone, and hard to scale — but still how much real configuration is done. introduced in ch. 5 commands arriving from elsewhere at the same instant. Locks are meant to be short-lived.
Think about what that admits. A real device is being configured by several tools at once, by different people, and until now nothing coordinated them.
And transactions across many devices
The basic operations can be composed into more sophisticated management transactions. Such a transaction either completes atomically on a set of devices, or is fully reversed, leaving every device in its pre-transaction state.
That is not a bonus feature. RFC 3535 recorded it as an operator requirement, in words worth keeping:
enable operators to concentrate on the configuration of the network as a whole rather than individual devices
| SNMP / MIBin use since the late 1980s | NETCONF / YANGRFC 6241, after the 2002 workshop | |
|---|---|---|
| Built mainly for | ||
| Message format | ||
| Transport | ||
| How many devices at a time | ||
| Language the data is defined in | ||
| Unsolicited events |
Cells marked ⓘ have a reason behind them — click to read it.
Both manage networks. Almost every design choice differs, and each difference traces back to what each was built to do. Click any cell.
The messages are XML documents
This is the first protocol in the book whose messages are XML documents. The traditional kind has header fields and a body, as Figure 5.21’s SNMP PDU (Protocol Data Unit) Protocol Data Unit The generic name for one message of a protocol. SNMPv3 defines seven PDU types. introduced in ch. 5 does.
Few people can parse XML completely by eye. But the book’s point is that a NETCONF command is relatively human-readable, and much more reminiscent of HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 and HTML (HyperText Markup Language) HyperText Markup Language The document format of the Web, created by Tim Berners-Lee at CERN between 1989 and 1991. introduced in ch. 1 than an SNMP PDU is.
Here is a <get> command asking for all of a device’s configuration and
operational data.
01 <?xml version="1.0" encoding="UTF-8"?>
02 <rpc message-id="101"
03 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
04 <get/>
05 </rpc>The RPC message itself spans lines 02–05, carries a message id of 101, and
contains a single NETCONF <get> command. The device’s reply carries the
matching id and all of the configuration data, in XML of course.
01 <?xml version="1.0" encoding="UTF-8"?>
02 <rpc-reply message-id="101"
03 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
04 <!-- . . . all configuration data returned... -->
. . .
</rpc-reply>A second example, read line by line
This one, adapted from RFC 6241, sets the
maximum transmission unit maximum transmission unit Simple The largest frame a link will carry. Precise The MTU: the length of the largest link-layer frame that can be sent on a given link. Ethernet and PPP both use 1,500 bytes. The path MTU is the largest frame that can cross every link from source to destination [RFC 1191]; discovering it lets a sender choose an MSS that never needs fragmenting.
introduced in ch. 3 — open in glossary
of an
interface named Ethernet0/0 to 1500 bytes.
01 <?xml version="1.0" encoding="UTF-8"?>
02 <rpc message-id="101"
03 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
04 <edit-config>
05 <target>
06 <running/>
07 </target>
08 <config>
09 <top xmlns="http://example.com/schema/1.2/config">
10 <interface>
11 <name>Ethernet0/0</name>
12 <mtu>1500</mtu>
13 </interface>
14 </top>
15 </config>
16 </edit-config>
17 </rpc>The RPC message itself spans lines 02 to 17 and has a message id of 101. The reply will carry the same id. Line 01 is the XML declaration and line 03 names the NETCONF namespace — neither is part of the call.
Adapted from RFC 6241. It sets the maximum transmission unit of the interface named Ethernet0/0 to 1500 bytes. The line numbers are the book’s own, added for teaching.
Read all steps as text
- Lines 02–17 · the remote procedure call — The RPC message itself spans lines 02 to 17 and has a message id of 101. The reply will carry the same id. Line 01 is the XML declaration and line 03 names the NETCONF namespace — neither is part of the call.
- Lines 04–15 · one NETCONF operation — Inside the call is exactly one command: <edit-config>. An RPC carries a single NETCONF operation, and Table 5.3 lists the ones the book covers.
- Line 06 · which configuration to change — A device may hold several configurations. <running/> names the one the device is actually using, so this change takes effect immediately rather than being staged.
- Lines 11–12 · and the actual change — The interface named Ethernet0/0 gets a maximum transmission unit of 1500 bytes. Everything above these two lines is addressing: which call, which operation, which configuration, which device model, which interface.
- What the device sends back — Once the device has changed the interface’s MTU in the configuration, it responds with an OK reply, again as an XML document: <rpc-reply message-id="101"> containing a single <ok/> element. Same id, so the server knows which call succeeded.
Everyday picture
Two ways to change what a shop sells.
The SNMP (Simple Network Management Protocol) Simple Network Management Protocol The Internet’s network-management protocol, typically run over UDP so that it still works when the network is under stress (§3.3, built in §5.7). introduced in ch. 3 way is to phone each branch and read out a new price, one branch at a time. If you are cut off halfway through the list, half the branches have the new price and half do not, and nothing tells you which.
The NETCONF way is to send every branch a signed instruction and wait for all of them to confirm they can do it. Only then do you tell them all to apply it. If one branch cannot, nobody changes anything.
Where the picture stops. A shop assistant would notice an absurd price and phone back. A device applies whatever a valid configuration says, which is why YANG lets a modeller write down constraints that a configuration must satisfy before anybody sends it.
YANG
YANG is the data modelling language used to specify the structure, syntax and semantics of the network management data NETCONF uses. The book gives the comparison directly: YANG is to NETCONF much as SMI smi Simple The language MIB objects are written in. Precise Structure of Management Information: the data description language in which MIB objects are specified, defined in RFCs 2578, 2579 and 2580. A formal definition language ensures that the syntax and semantics of network management data are well defined and unambiguous. The book notes that its name gives no hint of its function. introduced in ch. 5 — open in glossary is to MIBs in SNMP.
All YANG definitions live in modules, and an XML document describing a device and its capabilities can be generated from a module.
Two properties matter beyond that.
A small set of built-in data types, as SMI also has.
Constraints. A data modeller can express conditions that any valid NETCONF configuration must satisfy. The book calls this a powerful aid in ensuring that configurations meet specified correctness and consistency constraints, and it is the thing SMI has no equivalent for.
YANG is also used to specify NETCONF notifications.
In plain words
SMI let you say what a value is: this object is a 32-bit read-only counter.
YANG lets you say what a configuration must be true for: this interface’s maximum transmission unit must be within these bounds, this field is required when that one is present.
That is the difference between describing data and validating it, and it is why the newer pair is aimed at configuration while the older one settled into monitoring.
Check yourself
Check yourself
0 of 7 answered1.NETCONF and YANG exist because of a specific finding. What was it?
2.What does a NETCONF session begin with, after the secure connection is established?
3.Which NETCONF operation has no counterpart anywhere in SNMP, and why does it exist?
4.predictAn <edit-config> names <running/> as its target and sets an interface's MTU. When does the change take effect?
5.What is the relationship between YANG and SMI?
6.RFC 3535 recorded an operator requirement that NETCONF's multi-device transactions are meant to satisfy. What was it?
7.In NETCONF's own terminology, which end is called the "client"?
What to remember
- Every NETCONF message is an XML document, including the configurations themselves. It is a remote procedure call over a secure session — connection-oriented and encrypted from the start, unlike SNMP over UDP (User Datagram Protocol) User Datagram Protocol A simple transport protocol with no reliability, no flow control and no congestion control. introduced in ch. 1 .
- Four of the five operations are about configuration.
<get-config>,<edit-config>,<lock>and<unlock>have no SNMP counterpart, and<lock>exists because NETCONF, SNMP and CLI commands can arrive at one device together. - Transactions span devices. A group of operations either completes on all of them or is fully reversed, which is what RFC 3535’s operators asked for.