Blog

NETCONF and YANG Automation for SONiC Switches: A Practical Guide for Data Center and Campus Networks

Learn how NETCONF and YANG data models enable structured, vendor-neutral network automation on SONiC switches for data center and enterprise campus deployments in Australia.

By xSONiC Team · · SONiCopen networkingdata centerAI fabricEthernetautomation

Why NETCONF and YANG Matter for SONiC Switch Owners

Network teams running SONiC switches face a familiar tension: the platform offers powerful programmability through its Linux-based, containerized architecture, yet many organizations still manage configurations through CLI scripts or ad-hoc JSON edits. NETCONF and YANG provide a structured alternative that aligns with how SONiC itself is designed.

SONiC (Software for Open Networking in the Cloud) is an open-source network operating system built on Linux that runs on switches from multiple hardware vendors. According to the SONiC Foundation, the platform decouples hardware from software through the Switch Abstraction Interface (SAI), uses a modular Docker-container architecture, and supports a full suite of network functionality including BGP and RDMA. This architecture makes SONiC a strong candidate for NETCONF/YANG-driven automation, but the practical path requires understanding what NETCONF and YANG actually do, where they fit in SONiC environments, and where they do not.

This guide is for Australian network engineers and architects evaluating or already deploying SONiC switches in data center or campus roles. It covers the fundamentals, real-world use cases, and migration considerations without overpromising on capabilities that may require specific firmware or controller support.

What NETCONF and YANG Actually Are

Before connecting these standards to SONiC, it helps to clarify the terms.

YANG: The Data Model Language

YANG (Yet Another Next Generation) is a data modeling language defined in RFC 7950. It describes the structure of configuration and state data that a network device exposes. Think of YANG as a schema: it defines what configuration knobs exist, what their data types are, and how they relate to each other.

A YANG model for a switch might define:

  • Interface names, speeds, and admin states
  • VLAN assignments and trunk configurations
  • BGP neighbor parameters and route policies
  • ACL entries with match criteria and actions
  • QoS queue mappings and scheduling profiles

YANG models can be vendor-specific (native models) or standards-based (openconfig models). The openconfig initiative is particularly relevant for SONiC environments because it promotes vendor-neutral data models that work across multiple NOS platforms.

NETCONF: The Protocol

NETCONF (Network Configuration Protocol), defined in RFC 6241, is an XML-based protocol that uses YANG models to read and write device configuration. It provides four basic operations:

  • get-config: Retrieve running or startup configuration
  • edit-config: Push configuration changes to a datastore
  • commit: Apply candidate configuration to the running state
  • lock/unlock: Prevent conflicting changes during a maintenance window

NETCONF runs over SSH (port 830) and supports capabilities negotiation, so a management system can discover what YANG models a device supports at connection time.

SONiC Architecture and Programmability

SONiC’s containerized design is relevant to NETCONF/YANG automation because each network function runs in its own Docker container. According to the SONiC project repository, this provides better fault isolation, easier debugging, simplified upgrades, and enhanced scalability compared to monolithic switch software.

SONiC uses JSON-based configuration files and supports both CLI and programmatic configuration methods. The primary programmatic interfaces historically include:

  • Redis DB (ConfigDB and StateDB): SONiC stores its configuration in Redis databases. Tools and scripts can read and write configuration through the Redis interface.
  • sonic-utilities CLI: The familiar show and config commands that wrap Redis operations.
  • REST API and gNMI: Newer SONiC versions and enterprise distributions have added RESTCONF and gNMI support alongside or instead of NETCONF.

The critical point for NETCONF/YANG evaluation is that SONiC’s support for NETCONF as a management protocol depends on the specific SONiC distribution, version, and hardware platform. The open-source SONiC project has been evolving its management framework, with the Management Framework container providing NETCONF and RESTCONF capabilities using YANG models. However, the maturity and completeness of NETCONF support varies between community SONiC and commercial enterprise distributions.

Where NETCONF/YANG Fits in Data Center SONiC Deployments

For data center teams running SONiC switches in spine-leaf architectures, NETCONF/YANG automation addresses several operational challenges.

Consistent Configuration at Scale

A typical AI or HPC fabric might include dozens to hundreds of leaf and spine switches. Pushing consistent VLAN, BGP, and EVPN-VXLAN configurations through NETCONF ensures every switch receives the same structured data, validated against YANG models before deployment. This reduces drift and makes configuration audits straightforward.

Infrastructure as Code

NETCONF integrates with Ansible, Terraform, and Python libraries like ncclient (NETCONF client) and pyang (YANG validator). A network team can define their desired fabric state in version-controlled YANG-modeled data, validate it offline, and push it to switches through NETCONF with rollback capability.

This aligns with SONiC’s philosophy of treating switches as programmable infrastructure rather than manually managed appliances.

Telemetry and State Validation

Beyond configuration, NETCONF’s get and get-config operations allow management systems to read operational state and compare it against the intended configuration. For SONiC data center fabrics, this means automated drift detection across BGP sessions, interface states, and ACL counters.

For Australian data center operators managing distributed sites, this capability supports remote validation without SSH sessions to individual switches.

Where NETCONF/YANG Fits in Campus SONiC Deployments

Enterprise campus networks running SONiC-based access and aggregation switches present different automation challenges than data center fabrics, but NETCONF/YANG still applies.

Campus Configuration Templates

Campus switches typically need:

  • PoE configuration for access points, IP phones, and IoT devices
  • VLAN segmentation for users, devices, and management traffic
  • 802.1X port authentication policies
  • QoS marking for voice and video traffic
  • ACLs for inter-VLAN traffic control

YANG models can define these configuration blocks as reusable templates. NETCONF can push them to campus switches during provisioning or maintenance windows.

Policy Consistency Across Sites

For organizations with multiple campus locations across Australia, NETCONF/YANG enables a central management platform to enforce consistent security and QoS policies. Rather than relying on CLI scripts that vary between sites, YANG-validated configurations ensure every switch applies the same policy structure.

This connects to the concept of a centralized controller model, such as the xSONIC AIDC Controller, which can orchestrate configurations across distributed switch fleets.

NETCONF vs. gNMI vs. RESTCONF for SONiC

SONiC’s evolving management framework supports multiple programmability protocols. Understanding the trade-offs helps teams choose the right approach.

FeatureNETCONFgNMIRESTCONF
TransportSSH (port 830)gRPC (port 9339)HTTPS (port 443)
Data EncodingXMLProtobuf (JSON also supported)JSON or XML
Data ModelsYANGYANG (via OpenConfig)YANG
Streaming TelemetryNo (poll-based)Yes (subscribe/push)No (poll-based)
Configuration CommitYes (candidate/running)No (set only)Yes (candidate/running)
Industry MomentumEstablished standardGrowing, cloud-nativeREST-friendly alternative

For SONiC environments:

  • NETCONF is the best fit when teams need transactional configuration with commit, rollback, and candidate datastore semantics.
  • gNMI is preferred for streaming telemetry and operational state monitoring at scale.
  • RESTCONF appeals to teams with existing REST API tooling who want YANG model validation.

Many production SONiC deployments use a combination: gNMI for telemetry collection and NETCONF or RESTCONF for configuration management.

Practical Steps for Adopting NETCONF/YANG on SONiC Switches

For Australian network teams starting their NETCONF/YANG journey with SONiC switches, this phased approach reduces risk.

Phase 1: Inventory and Model Discovery

  1. Identify which switches in your fleet run SONiC and what version.
  2. Connect to each switch and retrieve the list of supported YANG models using netconf capability negotiation or the show yang CLI command if available.
  3. Document which models cover your critical configuration domains (interfaces, routing, VLANs, ACLs).

Phase 2: Read-Only Validation

  1. Use NETCONF get-config operations to pull running configurations from a test switch.
  2. Parse the XML output against the YANG models using pyang or YANG Explorer.
  3. Compare the structured output against your intended configuration templates.

Phase 3: Lab Testing with edit-config

  1. Set up a lab environment with at least two SONiC switches.
  2. Push test configurations using NETCONF edit-config to the candidate datastore.
  3. Validate the changes with get-config and operational show commands.
  4. Test rollback by discarding the candidate configuration.

Phase 4: Integration with Automation Tools

  1. Choose an automation platform (Ansible with netconf connection type, Python with ncclient, or a commercial NMS).
  2. Build playbooks or scripts for your top five configuration workflows.
  3. Add pre-check and post-check validation steps using NETCONF state reads.

Phase 5: Production Rollout

  1. Deploy to a staging environment that mirrors production topology.
  2. Run parallel validation: apply changes via both NETCONF and existing methods, compare results.
  3. Graduate to NETCONF-first workflows with manual approval gates.
  4. Gradually remove manual CLI gates as confidence builds.

Common Pitfalls and How to Avoid Them

Incomplete YANG Model Coverage

Not every configuration knob on a SONiC switch may be exposed through YANG models. Some platform-specific settings might only be available through CLI or Redis DB. Plan for hybrid automation where NETCONF handles the bulk of configuration and CLI covers edge cases.

Version Drift Between Switches

Different SONiC versions may expose different YANG models or model revisions. Standardize firmware versions across your fleet before deploying NETCONF automation at scale.

XML Verbosity

NETCONF uses XML encoding by default, which is more verbose than JSON. Teams accustomed to JSON-based REST APIs may find the payloads harder to read. Libraries like ncclient handle the XML parsing, but ensure your automation templates are well-documented.

Firewall and Security Policies

NETCONF runs over SSH on port 830. Ensure your management network firewall rules and jump-host configurations allow this traffic. Some Australian enterprise environments have strict SSH policies that may need exception requests.

Connecting NETCONF/YANG to the xSONIC Open Networking Stack

For teams evaluating xSONIC data center switches, campus switches, or bare-metal hardware, NETCONF/YANG support is one factor in a broader programmability assessment. The xSONIC open networking approach, built on Enterprise SONiC with SAI-based hardware abstraction, aligns with the NETCONF/YANG goal of structured, vendor-neutral automation.

Key evaluation questions for xSONIC buyers:

  • Does the specific xSONIC switch model and SONiC distribution include NETCONF server support in its management framework?
  • Which YANG models are validated for data center fabric configurations (EVPN-VXLAN, BGP, RDMA/QoS)?
  • Which YANG models cover campus use cases (PoE, 802.1X, VLANs, ACLs)?
  • Is there a centralized controller option, such as the xSONIC AIDC Controller, that uses NETCONF or gNMI for orchestration?
  • What is the support and update cadence for YANG models across SONiC releases?

Summary: NETCONF/YANG as an Automation Foundation

NETCONF and YANG provide a structured, standards-based automation layer for SONiC switches in both data center and campus roles. They are not a replacement for all other management methods, but they offer transactional configuration, model-validated data, and vendor-neutral interfaces that align with SONiC’s open networking philosophy.

For Australian network teams considering SONiC-based open networking, NETCONF/YANG readiness is a meaningful evaluation criterion. It signals that a platform can integrate with enterprise automation toolchains and support infrastructure-as-code workflows at scale.

The practical path starts small: discover YANG models, validate read-only operations, test in the lab, and build confidence before production deployment. Hybrid approaches that combine NETCONF with gNMI telemetry and CLI edge cases are normal and expected.

To discuss how xSONIC switches support NETCONF/YANG automation in your specific environment, contact the xSONIC team or explore the NETCONF solution guide.

Sources Reviewed