netopeer2 vs OpenDaylight NETCONF vs Tail-f ConfD: Self-Hosted NETCONF/YANG Network Configuration Guide 2026

Network configuration management has evolved from manual CLI sessions to programmatic, model-driven automation. NETCONF (Network Configuration Protocol, RFC 6241) and YANG (data modeling language, RFC 6020) form the industry standard for programmatic network device management. This guide compares three open-source NETCONF server implementations: netopeer2, OpenDaylight NETCONF, and Tail-f ConfD.

What Are NETCONF and YANG?

NETCONF is a network management protocol that provides mechanisms to install, manipulate, and delete configuration on network devices. Unlike SNMP (which was designed for monitoring), NETCONF is designed for configuration — with transactions, validation, and rollback capabilities.

YANG is the data modeling language used by NETCONF to define the structure of configuration and state data. Think of YANG as the “schema” and NETCONF as the “API” for network devices.

Key advantages of NETCONF/YANG over traditional CLI-based management:

• Structured data — configuration is exchanged as XML/JSON, not parsed text
• Transactions — configurations are applied atomically; failed changes roll back
• Validation — YANG models enforce constraints before configuration is applied
• Capabilities negotiation — devices advertise what they support
• Locking — exclusive or shared locks prevent concurrent modification conflicts
• Candidate datastore — edit a candidate configuration, then commit it all at once

Comparison Table

netopeer2: The Open-Source NETCONF Server

netopeer2, developed by CESNET, is the most widely used open-source NETCONF server. It is built on top of sysrepo (a YANG-based configuration datastore) and libnetconf2 (a NETCONF protocol library). It is the reference implementation for IETF NETCONF/YANG standards.

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

version: "3.8"
services:
  netopeer2:
    image: cznetops/netopeer2:latest
    container_name: netopeer2-server
    restart: unless-stopped
    ports:
      - "830:830"    # NETCONF over SSH
      - "6513:6513"  # NETCONF over TLS
    volumes:
      - ./config:/etc/netopeer2
      - ./yang-modules:/usr/local/etc/sysrepo/yang
    networks:
      - mgmt-net

networks:
  mgmt-net:
    driver: bridge

1
2
3
4
5
6
7
8

# Connect to netopeer2 server using the CLI client
docker exec -it netopeer2-server netopeer2-cli

# Inside the CLI:
> connect --host 127.0.0.1 --port 830 --login admin
> get-config --source running
> edit-config --target candidate --config=config.xml
> commit

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

<!-- Example YANG-modeled configuration (ietf-interfaces) -->
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>eth0</name>
      <description>Management interface</description>
      <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
      <enabled>true</enabled>
      <ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
        <address>
          <ip>192.168.1.10</ip>
          <prefix-length>24</prefix-length>
        </address>
      </ipv4>
    </interface>
  </interfaces>
</config>

netopeer2’s strength is standards compliance — it implements the IETF NETCONF/YANG specifications faithfully and supports the standard ietf-interfaces, ietf-system, and ietf-netconf-monitoring YANG modules out of the box.

OpenDaylight NETCONF: The SDN Controller Approach

OpenDaylight (ODL) is an SDN controller platform with a NETCONF connector that can manage both NETCONF-capable devices and act as a NETCONF server itself. The NETCONF plugin in ODL provides northbound NETCONF access and southbound connectivity to network devices.

Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

version: "3.8"
services:
  opendaylight:
    image: opendaylight/core:latest
    container_name: opendaylight
    restart: unless-stopped
    ports:
      - "8181:8181"  # REST API / Karaf UI
      - "1830:1830"  # NETCONF southbound
      - "830:830"    # NETCONF northbound
    environment:
      - ODL_FEATURES=odl-netconf-all,odl-restconf-all
    volumes:
      - ./configuration:/opt/opendaylight/configuration
    networks:
      - mgmt-net

networks:
  mgmt-net:
    driver: bridge

1
2
3
4
5
6
7
8
9

# Access the Karaf console
docker exec -it opendaylight karaf

# Install NETCONF features
feature:install odl-netconf-connector-all
feature:install odl-restconf-all

# Connect to a network device via NETCONF
# The device configuration goes in XML under etc/opendaylight/

OpenDaylight’s advantage is multi-vendor support — the NETCONF connector can manage devices from Cisco, Juniper, Huawei, and others, translating their vendor-specific YANG models into a unified data model in the MD-SAL (Model-Driven Service Abstraction Layer).

Tail-f ConfD: The Reference Implementation

Tail-f ConfD (now part of Cisco after acquisition) was the original commercial NETCONF/YANG implementation. While the full product is proprietary, a free tier was available for development and evaluation. ConfD is known for its superior CDB (Configuration Database) with full transaction support, rollback, and notification capabilities.

Important: ConfD’s free tier has been discontinued by Cisco. The commercial product remains available but requires a license. We include it here for historical context — it remains the gold standard for NETCONF/YANG implementations and has influenced many open-source alternatives.

Architecture Overview

ConfD’s architecture centers around its CDB:

1
2
3
4
5
6
7
8

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ NETCONF CLI │────▶│  ConfD CDB  │◀────│ YANG Models │
└─────────────┘     └─────────────┘     └─────────────┘
                          │
                    ┌─────▼─────┐
                    │  Callback │
                    │  Agents   │
                    └───────────┘

ConfD separates the data model (YANG), the data store (CDB), and the business logic (callback agents). This architecture allows network equipment vendors to implement only the YANG models relevant to their hardware, with callbacks to apply configuration to the actual device.

Choosing the Right NETCONF/YANG Server

The Modern NETCONF Ecosystem

While netopeer2 remains the primary open-source NETCONF server, the broader ecosystem includes:

• sysrepo — The YANG datastore behind netopeer2, can be used standalone
• libyang — YANG data modeling library used by sysrepo and netopeer2
• pyang — YANG model validator and converter
• YANG Catalog — Public repository of YANG modules (yangcatalog.org)
• Nephio — Kubernetes-native network function automation (emerging)

Why Self-Host NETCONF/YANG Network Configuration?

Running your own NETCONF server enables:

• Programmatic network management — automate configuration changes via NETCONF RPC calls instead of manual SSH sessions
• Configuration validation — YANG models catch errors before they reach production devices
• Audit trails — every configuration change goes through NETCONF’s transaction log
• Multi-vendor abstraction — a unified API layer across Cisco, Juniper, Arista, and white-box switches
• CI/CD for networking — integrate network configuration changes into your GitOps pipeline

For teams managing network simulation labs or BGP routing infrastructure, NETCONF/YANG provides the programmatic foundation to automate testing and deployment of network configurations at scale.

FAQ

What is the difference between NETCONF and SNMP?

SNMP (Simple Network Management Protocol) is primarily designed for monitoring — reading device statistics and sending traps for alerts. NETCONF is designed for configuration — installing, modifying, and deleting device configuration with transaction support, validation, and rollback. SNMP uses a flat MIB structure; NETCONF uses hierarchical YANG models.

Can netopeer2 manage non-standard YANG models?

Yes. netopeer2 can load any YANG module into sysrepo. You install custom YANG modules using sysrepoctl:

1

sysrepoctl --install --yang=my-custom-module.yang

The module’s data then becomes available via NETCONF. However, netopeer2 only stores the configuration data — you need callback applications to actually apply the configuration to physical devices.

Is NETCONF secure?

NETCONF typically runs over SSH (port 830) or TLS (port 6513), providing transport-level security. NETCONF also supports username/password and public key authentication. For production deployments, always use TLS with certificate-based authentication and restrict NETCONF access to management networks.

How does YANG model validation work?

YANG models define constraints on configuration data: data types, ranges, mandatory fields, dependencies between fields, and list uniqueness. When you submit configuration via NETCONF, the server validates it against the YANG model before applying it. Invalid configuration is rejected with detailed error messages, preventing misconfigurations from reaching production devices.

What YANG modules are available?

The IETF maintains standard YANG modules at datatracker.ietf.org. Common modules include: ietf-interfaces (interface configuration), ietf-ip (IP addressing), ietf-routing (routing protocols), ietf-bgp (BGP configuration), ietf-ospf (OSPF configuration), and ietf-system (system management). Vendor-specific modules are available from equipment manufacturers and the YANG Catalog.

Can I use RESTCONF instead of NETCONF?

RESTCONF (RFC 8040) provides a RESTful HTTP/HTTPS API for YANG-modeled data. It is essentially NETCONF over HTTP with JSON or XML encoding. netopeer2 supports RESTCONF through the libnetconf2 library’s RESTCONF plugin. OpenDaylight includes full RESTCONF support. RESTCONF is easier to integrate with web applications and scripting languages that prefer HTTP over SSH.