Network Configuration Protocol (NETCONF) is an IETF standard protocol for installing, changing, deleting and reading the configuration of network devices such as routers, switches and firewalls. Instead of sending text commands, a management system sends structured requests encoded in XML, and the data follows YANG models that define what each setting looks like. NETCONF is commonly run over SSH. It was first published in 2006 and updated in 2011, and it is one of the main building blocks of model-driven network automation.
At a glance
- NETCONF manages device configuration through structured remote procedure calls, not command-line text.
- It usually runs over SSH, with TCP port 830 as the default.
- Data is encoded in XML and described by YANG models.
- It separates configuration into datastores, and where devices support it, changes can be staged, validated and committed as a unit.
- It is often paired with RESTCONF, an HTTP-based interface to the same kind of YANG data.
What problem it solves
Configuration changes are a common cause of network outages. When engineers or scripts type commands device by device, a change can fail halfway, leaving a device partly configured. Scripts that drive the command line also depend on output meant for people, which changes between software versions.
Network operators asked for something better. An IETF workshop in the early 2000s noted that SNMP was widely used for monitoring but seldom for configuration, and NETCONF was developed to fill that gap. It gives management systems a structured way to read the full configuration, send a change, have the device check it and apply it in one step, and get a clear success or error reply. That makes automated changes across many devices more predictable and easier to roll back.
How it works
Sessions and capabilities. A client, such as an automation platform or controller, opens a session to the device, typically over SSH. Both sides announce their capabilities, so the client knows which optional features and YANG models the device supports.
Operations. The base protocol defines operations including get-config (read configuration), get (read configuration and state), edit-config (change configuration), copy-config, delete-config, lock and unlock. Requests and replies are XML documents.
Datastores. Configuration lives in named datastores. The running datastore is the active configuration. Many devices also support a candidate datastore, a working copy where changes are staged before being committed, and a startup datastore loaded at boot. Support for candidate and startup is optional and varies by device.
Safer changes. Where supported, a client can lock a datastore so others can’t change it mid-edit, validate a change before committing, and use a confirmed commit that rolls back automatically unless the change is confirmed within a set time. That last feature helps when a change might cut off the management connection itself.
Notifications. An extension lets devices send event notifications to subscribed clients.
When it matters for buyers
- Managed network and SD-WAN services. Providers that automate changes with NETCONF or similar interfaces can make consistent, auditable changes across many sites. See our managed network services page for help comparing providers.
- Hardware refreshes. If you plan to automate, confirm NETCONF support and YANG model coverage for the specific platforms and software versions you are buying.
- Change control. Candidate configurations, validation and confirmed commits support the review-and-rollback discipline that IT change management depends on, where devices offer them.
- Multi-vendor estates. A common protocol helps, but models and optional features still differ by vendor.
Questions to ask vendors
- Which of our device platforms and software versions support NETCONF, and which YANG models do they expose?
- Do the devices support the candidate datastore, validation and confirmed commit?
- How do you roll back a failed change, and how long does it take?
- Is NETCONF access secured with keys or certificates, and who holds the credentials?
- Which features still require command-line configuration outside NETCONF?
- Will we keep the automation templates and configuration history if we change providers?
How it differs from SNMP
SNMP and NETCONF are both IETF network management protocols, but they grew up for different jobs. SNMP is used mostly for monitoring: polling devices for counters and status and receiving traps or informs when something happens. It does include a write operation, but in practice it was rarely used for configuration because changes are hard to coordinate across many objects and it lacks transaction-style controls. NETCONF was built for configuration: it reads and writes whole configurations, uses YANG models instead of MIBs, runs over SSH or TLS, and on supporting devices offers staged commits, validation and locking. Many networks run both, using SNMP for monitoring and NETCONF for changes, and some are moving monitoring to streaming telemetry based on YANG models.