Overview
NETCONF is a standards-based protocol for managing network device configuration through structured operations and YANG data models. It is designed for automation workflows where configuration should be validated, applied, retrieved, and rolled back in a controlled way.
For xSONiC deployments, NETCONF can help network teams move from manual CLI changes to model-driven operations across data center and campus switching platforms.
NETCONF Operations
| Operation | Purpose | xSONiC Automation Use |
|---|---|---|
get | Retrieve running state and operational data. | Audit device state before and after changes. |
get-config | Retrieve configuration from a datastore. | Compare source of truth with device configuration. |
edit-config | Apply configuration changes. | Push interface, VLAN, routing, or policy updates. |
validate | Check candidate configuration. | Catch schema or logic errors before commit. |
commit | Make candidate configuration active. | Apply controlled changes after validation. |
discard-changes | Remove pending candidate changes. | Abort failed or unapproved updates. |
Datastore Workflow
Automation source of truth
|
v
Build candidate configuration
|
v
Validate candidate
|
v
Commit to device
|
v
Retrieve and compare running stateWhy Model-Driven Management Matters
| Manual Workflow Risk | NETCONF/YANG Benefit |
|---|---|
| CLI output changes break scripts. | Structured data model is easier to parse. |
| Partial changes create drift. | Candidate and commit workflow improves control. |
| Change rollback is manual. | Automation can store intended state and rollback paths. |
| Fleet-wide consistency is hard. | Same model can apply across many devices. |
Security and Access Controls
NETCONF should be treated as a privileged management interface.
- Use role-based credentials with least privilege.
- Restrict management reachability to trusted automation systems.
- Log configuration changes and automation job identity.
- Validate device certificates or SSH trust policy as part of onboarding.
- Separate read-only inventory workflows from write-capable deployment workflows.
Deployment Checklist
- Identify the configuration domains suitable for NETCONF automation.
- Confirm YANG model coverage for target features.
- Define source-of-truth data structures.
- Build validate-before-commit workflows.
- Add drift detection by comparing intended and running state.
- Test rollback behavior before broad rollout.
xSONiC Platform Fit
NETCONF is relevant across xSONiC data center and campus switching platforms. It is most valuable when teams manage repeated patterns: leaf/spine routing, VLAN and VRF policy, interface templates, telemetry configuration, and standard operational checks.
Engineering Position
NETCONF is useful only when it reduces configuration ambiguity. If the same change can be made by three scripts, two CLI snippets, and one undocumented manual procedure, adding NETCONF will not fix the operations model. The team should first define the source of truth, the YANG paths it expects to manage, the validation step, and the rollback contract.
The strongest workflows use read and write paths together. Before a change, automation retrieves current state and locks the target scope. During the change, it validates the candidate payload and records the job identity. After commit, it retrieves running state and telemetry to prove the intended behavior actually appeared on the device.
For a first production pilot, keep the scope deliberately small: 3 switch models, 5 interfaces per model, 2 VLAN or VRF changes, 1 invalid transaction, and 1 rollback event. That is enough to expose model coverage, transaction safety, and audit logging without turning the first test into a fleet-wide change.
If the environment has mixed roles, include 4 switches across leaf, spine, aggregation, and access profiles. Run 6 transactions: 2 read-only audits, 2 approved changes, 1 rejected invalid payload, and 1 rollback event. This gives the team enough evidence to compare behavior across roles without overloading the first change window.
Automation Acceptance Scope
| Scope | What To Validate | Evidence |
|---|---|---|
| Model coverage | Required interface, VLAN, routing, QoS, and telemetry paths. | YANG schema list and documented deviations. |
| Transaction safety | Lock, edit-config, validate, commit, discard, and rollback behavior. | Job log with timestamps and device response. |
| Drift detection | Intended state compared with running state. | Config diff and exception report. |
| Access control | Read-only and write-capable roles separated. | Credential policy and audit log. |
Engineering Validation Checkpoint
NETCONF and YANG should be accepted by transaction safety. Validate at least 3 models, 2 transactions, 1 invalid payload, and 1 rollback. Compare the intended config, running config, telemetry state, and device logs after every transaction.
| Check | Evidence to collect | Reject condition |
|---|---|---|
| Model support | YANG schema list, OpenConfig paths, and vendor deviations. | Required paths are absent or behave differently across switch models. |
| Transaction behavior | Lock, edit-config, validate, commit, discard, and rollback logs. | An invalid change can partially apply or cannot be rolled back. |
| Auditability | Config diff, user identity, timestamp, and post-change telemetry. | The team cannot reconstruct who changed what and why. |
Engineering FAQ
Should NETCONF replace the CLI immediately?
No. Use NETCONF first for repeated, well-modeled domains such as interfaces, VLANs, routing templates, telemetry, and standard compliance checks. Keep break glass procedures documented, but make the normal path model-driven and auditable.
What is the minimum production gate?
The minimum gate is one successful change, one rejected invalid payload, one rollback, and one drift-detection run across representative switch models. If any required YANG path is missing or behaves differently between models, record the deviation before scaling the workflow.
