Glossary

NETCONF

Network Configuration Protocol

What is NETCONF

NETCONF (Network Configuration Protocol) is an IETF standards-based protocol, first defined in RFC 3535 and later formalized in RFC 6241, for installing, manipulating, and deleting the configuration of network devices in a reliable, programmatic way. It was designed to address limitations that traditional CLI and SNMP show as networks grow more complex and dynamic: CLI output is unstructured and vendor-specific, while SNMP was built primarily for state monitoring rather than safe, transactional configuration changes.

NETCONF defines a client-server model. A management application (the client) connects to a network device (the server) over a secure, connection-oriented session and exchanges XML-encoded messages to retrieve and modify configuration data. NETCONF is commonly paired with YANG, a data modeling language that defines the structure and semantics of the configuration and state data carried over NETCONF — YANG is what gives NETCONF operations their machine-readable, cross-vendor consistency. NETCONF also supports a notification and subscription mechanism (formalized in RFC 5277 and later extended by RFC 8639–8641), allowing a client to receive asynchronous event notifications from a device rather than having to poll it.

Together, these capabilities let network engineers build repeatable, predictable automation workflows, rather than relying on manually scripted CLI sessions that vary from vendor to vendor.

How NETCONF Works

A NETCONF session between a client and server proceeds through the following stages:

  1. Secure connection and session setup: The client and server establish a secure, connection-oriented transport session. NETCONF is transport-agnostic in principle, but a compliant transport must be connection-oriented and provide mutual authentication, integrity, and confidentiality. In practice, SSH (RFC 6242) and TLS (RFC 7589) are the two mainstream transports, and NETCONF requires that a server support SSH.

  2. Capability exchange: Immediately after the session opens, client and server each send a <hello> message declaring which NETCONF capabilities they support (for example, whether the <candidate> datastore or notification subscriptions are supported). The server's <hello> also carries a unique session-id that the client later uses for operations like <lock> and <kill-session>.

  3. RPC request/response exchange: The client sends <rpc> messages, each carrying a message-id and wrapping a specific operation (such as <get-config> or <edit-config>). The server replies with a matching <rpc-reply> carrying the same message-id, containing either the requested data, an <ok> element for a successful operation with no return data, or one or more <rpc-error> elements describing what went wrong.

  4. Session termination: The client ends the session gracefully with <close-session>, or a session can be forcibly terminated with <kill-session> (typically used by an administrator to end another client's session by its session-id).

Underpinning this exchange is NETCONF's datastore model. A configuration datastore holds a complete set of configuration data — most notably <running>, the datastore representing the device's live, currently-active configuration, which always exists. Devices may optionally also support <startup> (the configuration loaded at boot) and <candidate> (a staging datastore where changes can be validated before being committed to <running>, without ever having affected the live device state). This separation is what allows NETCONF operations such as <edit-config> (load configuration into a target datastore, with merge/replace/create/delete/remove semantics per node) and <copy-config> (replace an entire datastore) to support safe, staged, and — when a server implements the Rollback-on-Error capability — atomic configuration changes: an <edit-config> either applies in full or is rolled back in full, rather than leaving a device in a partially-configured state.

Why NETCONF is Beneficial

The core value of NETCONF lies in turning device configuration into a structured, transactional, and vendor-neutral operation:

· Structured, machine-readable data: Configuration and state data are exchanged as XML modeled by YANG, replacing free-form CLI text that differs from vendor to vendor and is fragile to parse.

· Transactional, atomic changes: With Rollback-on-Error support, an <edit-config> operation either fully succeeds or is fully rolled back, so a failed push never leaves a device in an ambiguous half-configured state that's hard to recover from.

· Safe staging before commit: The optional <candidate> datastore lets a client validate a full set of changes before they ever touch the running configuration, reducing the risk of pushing a bad configuration straight to a live device.

· Cross-vendor consistency: Because the same NETCONF operations (<get-config>, <edit-config>, and so on) apply uniformly regardless of the underlying YANG model, a management application can automate multi-vendor environments using one consistent operational pattern, even though the specific configuration data itself still differs by vendor and YANG model.

· Event-driven visibility: Built-in notification and subscription support means a management system can react to device-side events as they happen, instead of relying purely on periodic polling.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements NETCONF as a standards-based automation interface for data center network configuration:

· Standard NETCONF operations: AsterNOS supports the core operation set — <get-config>, <get>, <edit-config>, <copy-config>, <delete-config>, <lock>/<unlock>, <close-session>, and <kill-session> — over an SSH-secured transport.

· Rollback-on-Error capability: AsterNOS supports the Rollback-on-Error capability, so a single <edit-config> request is applied atomically — either every change in the request takes effect, or none does — removing the risk of a device landing in an inconsistent intermediate state after a failed push and making failed changes straightforward to retry.

· YANG-modeled configuration: Configuration and state data exchanged over NETCONF are structured according to YANG models, giving management applications a consistent, machine-readable way to target specific configuration and state nodes on AsterNOS devices.

· Batch configuration in a single request: A management server can bundle multiple configuration changes into one or a few <edit-config> requests, rather than issuing them one at a time, which is well suited to bringing up or updating many switches in a data center fabric consistently.

· Typical deployment: In a leaf-spine data center topology, a management server sits on an out-of-band management network with reachability to every switch's management interface. From there, it can push configuration changes and pull state across the entire fabric through NETCONF, giving operators one consistent automation path for tasks like configuration changes and status checks — instead of scripting against each vendor's CLI separately.