A network managing protocol to configure network elements.
It transports xml (json) via SSH.
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name>eth0</name>
<type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
<enabled>true</enabled>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<address>
<ip>2001:db8:c18:1::3</ip>
<prefix-length>128</prefix-length>
</address>
</ipv6>
</interface>
</interfaces>
</data>
</rpc-reply>
A data modeling language for the definition of data sent over the NETCONF network configuration protocol.
It is a schema to validate xml.
container interfaces {
description
"Interface configuration parameters.";
list interface {
key "name";
leaf name {
type string;
}
leaf type {
type identityref {
base interface-type;
}
mandatory true;
}
leaf enabled {
type boolean;
default "true";
}
} // list interface
} // container interfaces
NetConf was designed based on Operators Requirements, which are documented in RFC3535. It addresses security topics and operational and maintenance topics.
Protocol: | SNMP | NETCONF | SOAP | REST | RESTCONF | gRPC | What comes next ... |
Transport Stack | UDP | SSH | SSL | SSL | SSL | HTTP/2 TCP | |
Encoding | BER | XML (new JSON) | XML | XML, JSON | XML, JSON | binary | |
Resources | OIDs | Path | URLs | URLs | URLs | ||
Data models | MIBs | YANG modules | WSDL, XSD | YANG modules | Protocol Buffers | ||
Data Modeling Language | SMI | YANG | WSDL, XSD | Undefined, (WSDL), WADL, text… | YANG | Protocol Buffers | |
Management Operations | SNMP operations | NETCONF operations | In the XML Schema, not standardized | HTTP operations | HTTP operations | HTTP/2 operations | |
SDO (like) | IETF | IETF | W3C | W3C | IETF |
The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state.
running configuration datastore:
A configuration datastore holding the complete configuration currently active on the device. The running configuration datastore always exists.
candidate configuration datastore:
A configuration datastore that can be manipulated without impacting the device's current configuration and that can be committed to the running configuration datastore. Not all devices support a candidate configuration datastore.
startup configuration datastore:
The configuration datastore holding the configuration loaded by the device when it boots. Only present on devices that separate the startup configuration datastore from the running configuration datastore.
Operation | Description |
---|---|
get | Retrieve running configuration and device state information. |
get-config | Retrieve all or part of a specified configuration datastore. |
edit-config | Loads all or part of a specified configuration to the specified target (<running>, <candidate>) configuration datastore. operation-types: merge, replace, create, delete, remove |
copy-config | Create or replace an entire configuration datastore with the contents of another complete configuration datastore. |
delete-config | Delete a configuration datastore. The <running> configuration datastore cannot be deleted. |
(partly-) lock | It allows the client to lock the entire configuration datastore system of a device. |
(partly-) unlock | Releases a configuration lock, previously obtained with the <lock> operation. |
commit | Sets the running configuration to the current contents of the candidate configuration. |
validate | This protocol operation validates the contents of the specified configuration. |
close-session | Request graceful termination of a NETCONF session. |
kill-session | Force the termination of a NETCONF session. |
(hello-message) | (exchange of yang capabilities (yang modules) between server and client) |
(one of x possibilities)