NETCONF and YANG Automation for SONiC Switches

SONiCopen networkingdata centerAI fabricEthernetautomation

In brief

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.

Key takeaways

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.

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.

Feature	NETCONF	gNMI	RESTCONF
Transport	SSH (port 830)	gRPC (port 9339)	HTTPS (port 443)
Data Encoding	XML	Protobuf (JSON also supported)	JSON or XML
Data Models	YANG	YANG (via OpenConfig)	YANG
Streaming Telemetry	No (poll-based)	Yes (subscribe/push)	No (poll-based)
Configuration Commit	Yes (candidate/running)	No (set only)	Yes (candidate/running)
Industry Momentum	Established standard	Growing, cloud-native	REST-friendly alternative

For SONiC environments:

NETCONF is the appropriate 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

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

Phase 2: Read-Only Validation

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

Phase 3: Lab Testing with edit-config

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

Phase 4: Integration with Automation Tools

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

Phase 5: Production Rollout

Deploy to a staging environment that mirrors production topology.
Run parallel validation: apply changes via both NETCONF and existing methods, compare results.
Graduate to NETCONF-first workflows with manual approval gates.
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.

Engineering Evidence Floor

For campus and access switching topics, acceptance should be based on endpoint behaviour under real operating constraints. The evidence package should include endpoint classes, PoE budget, NAC/802.1X, LLDP-MED, voice VLANs, multicast, STP or MC-LAG behaviour, uplink capacity, monitoring, rollback, and help-desk workflow. A representative pilot should run at least 48 ports for 30 days, include one planned rollback inside 24 hours, and document support ownership before scale-out.

Evidence area	What to validate	Acceptance gate	Rework trigger
Endpoint mix	APs, phones, cameras, laptops, IoT, and printers	48 ports run mixed load for 24 hours	Only laptop traffic is tested
Power and uplinks	PoE budget, 1G/2.5G/5G/10G access, and 100G uplinks	No power or uplink bottleneck in pilot	Refresh ignores closet constraints
Resilience	STP, MC-LAG, link loss, member loss, and rollback	3 failure cases captured	Campus works only in steady state
Operations	Monitoring, logs, backup, restore, and help-desk runbook	Incident evidence ready within 2 hours	Support depends on informal notes
Rollout	Site selection, training, spares, and change windows	30 days pilot approved before estate rollout	Procurement scales before validation

Engineering FAQ

What should be tested before moving campus switching to SONiC or open networking? Test PoE behaviour, NAC integration, VLAN and policy design, STP or MC-LAG interaction, multicast, monitoring, upgrade rollback, and help-desk workflows. Campus readiness is an operations test, not only a forwarding test.

Where do campus refresh projects usually carry hidden risk? The risk often sits in closets: power budget, old cabling, undocumented uplinks, mixed endpoint types, voice devices, cameras, badge systems, and change windows. Those details should be inventoried before selecting switch models.

How should Australian campus teams structure a pilot? Choose one representative site or building, document endpoint classes, run PoE and failover tests, verify monitoring, train operations staff, and define rollback steps before expanding to the broader estate.

Sources Reviewed

Product fit

Where xSONiC fits

xSONiC can help validate the switch, optics, software image, telemetry, and support assumptions against the actual deployment before a production order is released.

datacenter aiXS-DC-64X800-AI-G164-port 800G AI fabric switch for large-scale GPU clusters, HPC backbones, and ultra-high-throughput data center networks.View product

datacenter aiXS-DC-32X400-SP-G232-port 400G spine/core switch for high-capacity data center fabrics and AI-ready backbones.View product