Table of Contents
In 2025, more and more customers have been asking: “Do your campus SONiC switches support NETCONF?” The good news is that in AsterNOS V6.1R1, released in Q3 2025, we officially added support for NETCONF! So, what’s the “magic” behind this feature that attracts the attention of so many large customers? In fact, NETCONF is not just an ordinary network management function. It is an IETF-standardized network configuration protocol designed specifically for device configuration, status monitoring, and automated management. Simply put, it allows network administrators to manage switches and routers with the same precision, security, and programmability as software.
Today, let’s take a closer look at the power of NETCONF—how it is implemented on SONiC campus switches, and how to configure and use it to make your network operations more efficient and reliable.
What is NETCONF ？
NETCONF (Network Configuration Protocol) is a standard protocol defined by the IETF (RFC 6241) for managing network devices. It provides network engineers and automation systems with a unified way to remotely configure switches, routers, firewalls, and other devices, query their operational status, and perform automated management tasks in a more secure and reliable manner. Unlike traditional approaches, NETCONF supports transactional changes—you can modify multiple configurations at once, validate them, and commit them as a whole, with the ability to quickly roll back if something goes wrong. Essentially, NETCONF is a modern, programmable network management interface that makes network operations more controllable, automated, and aligned with the demands of the cloud era.
Why the Network Automation Era Left CLI and SNMP Behind for NETCONF
In the era of cloud computing, large-scale data centers, and 5G, networks are expected to provide “instant service deployment and automated fault resolution.” Traditional methods—CLI (Command Line Interface) and SNMP—simply can’t keep up. That’s where NETCONF comes in, quickly becoming the mainstream choice for network automation.
Why CLI and SNMP fall short?
CLI’s major pain points:
- Every vendor has its own commands: Huawei uses
display, Cisco usesshow, Juniper usesshow | display xml… impossible to memorize them all. - Even the same vendor keeps changing syntax:
interface GigabitEthernet0/0/1today,interface GigabitEthernet0/0/01tomorrow—scripts break overnight. - Output is unstructured text: machines can’t parse it, leaving engineers to rely on eyeballs + Ctrl+F. Automation? Forget it.
SNMP’s fatal flaws:
- No transactional support: if you try to change 100 parameters and it fails at 67, the first 66 changes are already applied—chaos guaranteed.
- Uses UDP: packet loss, out-of-order delivery, no encryption—security is nearly zero.
- Only supports one object at a time; you can’t configure a full service in one shot.
- Single-device management only; cross-device orchestration is impossible.
In short: CLI is like “hand-embroidering,” and SNMP is like “hammering nails by hand”—totally unfit for the automation era.
Why NETCONF became a game-changer？
NETCONF is essentially a modern operating system for network devices, solving all the above problems:
- Structured data with XML + YANG Configuration and status data are fully structured, like a spreadsheet. Programs can read it directly, and scripts work across vendors as long as they follow the same YANG model.
- True transactional support
- Make changes on a “draft” configuration (candidate), leaving the running network untouched.
- Validate syntax and semantics before committing.
- Commit changes in one step: either all succeed or all rollback—no half-baked configuration.
- Discard changes anytime and revert in seconds.
- Automation-ready by design All operations are standard RPC calls. With a few lines of Python, you can manage thousands of devices in bulk.
- Top-tier security Enforced SSH/TLS, full authentication, authorization, and encryption—far beyond SNMP’s plain-text UDP.
- Extensible and flexible Standard models are shared, but vendors can add proprietary extensions without conflict.
In plain words: CLI and SNMP are like manually operating a bulldozer, while NETCONF is a bulldozer with autopilot, anti-collision system, and one-click rollback.
How NETCONF Works ?
When customers ask why NETCONF matters and how it actually works under the hood, the simplest way to understand it is to see NETCONF as a standardized, transaction-safe, model-driven way for controllers to configure network devices. Below is a clear breakdown of how NETCONF operates internally.
NETCONF System Architecture
A NETCONF-based system typically includes one or more network management systems (NMS) acting as NETCONF clients, and a set of NETCONF-enabled network devices functioning as servers.
Two major roles exist in every NETCONF deployment:
NETCONF Client
- Orchestrates and manages device configurations
- Sends RPC (Remote Procedure Call) operations to devices
- Retrieves operational/state data
- Receives event notifications and alarms
NETCONF Server
- Runs on the network device (e.g., switch, router)
- Maintains local configuration and state
- Parses and executes RPC requests
- Sends back structured replies
- Pushes notifications to the client when faults or events occur
This client–server model enables consistent, predictable configuration management across multi-vendor networks.
NETCONF Basic Session Establishment Process
NETCONF uses an RPC-based communication model, where the NETCONF client and server exchange operations through remote procedure calls. Before any configuration or status retrieval can take place, the client must establish a secure, connection-oriented session with the server. Once the session is active, the client sends RPC requests, and the server returns the corresponding responses.
Below is an overview of the typical NETCONF session establishment and teardown workflow:
- Session Initialization
The client initiates a NETCONF session by establishing an SSH connection to the server, completing authentication and authorization. - Capability Exchange
After the secure channel is established, the client and server negotiate their NETCONF capabilities to determine the operations and data models supported by each side. - RPC Communication
Once the session is active, the client can send one or more RPC requests to the server, such as:- Editing and committing configuration changes
- Querying configuration data or operational status
- Performing maintenance or device management tasks
- Session Termination
When operations are complete, the client closes the NETCONF session. - SSH Disconnect
The SSH connection is closed after the NETCONF session ends.
NETCONF Protocol Stack (Layered Architecture)
NETCONF is designed as a layered architecture, allowing each layer to focus on a single responsibility. This separation reduces interaction complexity between components.
Layer 1 — Secure Transport Layer
- Provides the reliable, encrypted channel
- SSH is the industry standard for NETCONF transport
- Ensures integrity, confidentiality, and authentication
Layer 2 — Message Layer
- Defines the framing of RPC messages
- Encodes requests using
<rpc>, and responses using<rpc-reply> - Not dependent on the transport protocol
Layer 3 — Operations Layer
- Defines the set of standardized RPC operations such as:
<get>,<get-config><edit-config><commit><lock>/<unlock>
- Operations are always expressed in XML
Layer 4 — Content Layer
- This is where data models live
- Models describe configuration structure and constraints
- Supported formats:
- YANG (modern, industry standard)
- XML Schema (legacy)
YANG is the dominant modeling language today and is commonly paired with NETCONF or gNMI.
NETCONF Communication Model
NETCONF uses XML-encoded RPC messages for communication between the client and server. All client requests and server responses follow a structured XML format, making the RPC framework independent of the underlying transport protocol. The core RPC elements include:
| XML Element | Purpose |
| <rpc> | Client → Device request |
| <rpc-reply> | Device → Client response |
| <ok> | Operation succeeded |
| <rpc-error> | Operation failed (details included) |
NETCONF Configuration Datastores
A datastore represents a complete set of configuration parameters associated with a network device. NETCONF defines one or more datastores and provides standardized operations to manage them.
In the basic NETCONF model, only the <running/> datastore is mandatory. Additional datastores may exist depending on the device’s advertised capabilities.
<running/> — Running Configuration
The active configuration currently applied on the device.
- Only one running datastore exists on a device.
- It is always present and directly reflects the device’s real-time operational state.
<candidate/> — Candidate Configuration
A staging area for configuration changes before they are committed to <running/>.
- Administrators can freely modify the
<candidate/>datastore without affecting the live system. - Changes take effect only when a
<commit>operation is issued. - Supported only if the device advertises the Candidate Configuration capability.
<startup/> — Startup Configuration
Stores the configuration that the device loads during boot, similar to a saved configuration file.
- Available only on devices that support the Distinct Startup Configuration capability.
Why Customers Care About NETCONF?
From the explanations above, it’s easy to see the ultimate reason why customers choose NETCONF： because it offers capabilities that traditional CLI or REST APIs often can’t guarantee. It provides model-driven configuration using YANG, ensures transaction safety with commit and rollback mechanisms, maintains consistency across multi-vendor environments, represents device state in a structured, machine-readable way, supports event notifications, and delivers secure, session-based management—all of which make network operations more reliable, automated, and scalable.
Comparison of NETCONF, CLI, SNMP, REST API, gNMI, OpenConfig, and RESTCONF
As everyone knows, there are many technologies with functionalities similar to NETCONF, such as CLI (traditional), SNMP (monitoring), REST API, gNMI, OpenConfig, RESTCONF, and NETCONF over gRPC. Let’s take a closer look and compare these technologies.
| Technology | Core Purpose | Configuration Capability | Transaction Support | Data Modeling | Security | Pros | Cons | Best Use Cases |
| NETCONF | Standardized network configuration protocol (IETF RFC 6241) | ✔ Full configuration | ✔ Native commit & rollback | ✔ YANG | ✔ SSH-based | Strong transaction model; vendor-neutral; structured XML; reliable | XML verbose; requires YANG investment | Large-scale automation, multi-vendor networks, service provisioning |
| CLI | Vendor-specific command interface | ✔ Full configuration | ✘ None | ✘ None | Depends on SSH/Telnet | Easy to use manually; full device functionality available | Not structured; unstable output; hard to automate; no atomicity | Manual operations, troubleshooting, small networks |
| SNMP | Monitoring & limited config | △ Limited configuration | ✘ None | MIB | Weak (UDP-based) | Lightweight; widely supported; ideal for monitoring | Unreliable transport; poor for config; object-by-object update | Monitoring, telemetry, NMS systems |
| REST API | Web-style device API | ✔ Yes | △ Depends on backend | JSON/REST schemas | HTTPS | Easy to integrate with web systems; human-friendly JSON | Fragmented implementations; inconsistent operations | Cloud platforms, SDN controllers, northbound APIs |
| gNMI / gRPC | Streaming telemetry & config | ✔ Yes | △ Can support atomicity depending on vendor | ✔ YANG | TLS | High performance; efficient encoding; real-time telemetry | Requires controller ecosystem; not always consistent across vendors | Telemetry-heavy environments, controllers, AI/NFV networks |
| OpenConfig | Vendor-neutral data models | ✔ Yes (usually via gNMI/NETCONF) | Depends on transport | ✔ YANG | Transport dependent | Standardizes models across vendors | Requires vendors to fully adopt models | Multi-vendor config, automation requiring consistent YANG models |
| RESTCONF | RESTful interface for YANG models | ✔ Yes | △ Partial | ✔ YANG | HTTPS | Easier than NETCONF; uses JSON/XML | Not as robust as NETCONF; no full commit/rollback | Lightweight automation, cloud-native network tools |
| NETCONF over gRPC | Modern transport for NETCONF | ✔ Full | ✔ Yes | ✔ YANG | TLS | High performance + NETCONF reliability | Not widely supported yet | Next-generation controllers, high-scale automation |
With so many management and monitoring options, how do you choose?
- For large-scale automation and multi-vendor unified management → go with NETCONF / gNMI (often used with OpenConfig)
- For lightweight automation or web-based system calls → choose REST API / RESTCONF
- For manual device operations → use CLI
- For device monitoring → use SNMP / gNMI telemetry
Asterfusion AsterNOS V6.1 already supports NETCONF.
How can NETCONF be configured on the Asterfusion Enterprise SONiC distribution?
<get-config>
Description
AsterNOS support to retrieve all or part of a specified configuration datastore via <get-config>.
Parameters
- source: Name of the configuration datastore being queried, such as <running/>.
- filter: This parameter identifies the portions of the device configuration datastore to retrieve. If this parameter is not present, the entire configuration is returned.
NOTE ：The AsterNOS ONLY support filter type as subtree, the <filter> element MUST contain a “type” attribute and set it to “subtree”.
Otherwise, an “unsupported-filter-type” error is returned. For more detail about subtree filter, user may refer to Subtree Filtering
Positive Response
If the device can satisfy the request, the server sends an <rpc-reply> element containing a <data> element with the results of the query.
Negative Response
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
Example
To retrieve the entire <vlans> subtree:
<filter type="subtree">
<top>
<vlans xmlns="http://asterfusion.com/ns/yang/asternos-vlan"/>
</top>
</filter>
Reply:
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<top>
<vlans xmlns="http://asterfusion.com/ns/yang/asternos-vlan">
<vlan>
<vlanid>100</vlanid>
<mac-limit>10000</mac-limit>
<description>this is a test1</description>
<unknown-unicast-action>flood</unknown-unicast-action>
<unknown-multicast-action>drop</unknown-multicast-action>
</vlan>
<vlan>
<vlanid>200</vlanid>
<mac-limit>20000</mac-limit>
<description>this is a test2</description>
<unknown-unicast-action>flood</unknown-unicast-action>
<unknown-multicast-action>drop</unknown-multicast-action>
</vlan>
<vlan>
<vlanid>4000</vlanid>
<mac-limit>20000</mac-limit>
<description>test</description>
<unknown-unicast-action>flood</unknown-unicast-action>
<unknown-multicast-action>drop</unknown-multicast-action>
</vlan>
</vlans>
</top>
</data><edit-config>
Description
AsterNOS support <edit-config> operation to <running/>/<startup>/<candidate/>.
The <edit-config> operation loads all or part of a specified configuration to the specified target configuration datastore.
This operation allows the new configuration to be expressed in xml format data. If the target configuration datastore does not exist, it will be created.
If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear instead of the <config> parameter. The device analyzes the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced, as with the <copy-config> message. Instead, the target configuration is changed in accordance with the source’s data and requested operations.
If the <edit-config> operation contains multiple sub-operations that apply to the same conceptual node in the underlying data model, then the result of the operation is undefined (i.e., outside the scope of the NETCONF protocol).
Attributes:
operation
Elements in the <config> subtree MAY contain an “operation” attribute. The attribute identifies the point in the configuration to perform the operation and MAY appear on multiple elements throughout the <config> subtree.
If the “operation” attribute is not specified, the configuration is merged into the configuration datastore.
The “operation” attribute has one of the following values:
- merge
- The configuration data identified by the element containing this attribute is merged with the configuration at the corresponding level in the configuration datastore identified by the <target> parameter. This is the default behavior.
- replace
- The configuration data identified by the element containing this attribute replaces any related configuration in the configuration datastore identified by the <target> parameter. If no such configuration data exists in the configuration datastore, it is created. Unlike a <copy-config> operation, which replaces the entire target configuration, only the configuration actually presents in the <config> parameter is affected.
NOTE
- AsterNOS currently DON’T support to replace whole list nodes.
- If user specified operation as ‘replace’ in a list node, an rpc-error is returned by server or unexpected action done by server.
- create
The configuration data identified by the element containing this attribute is added to the configuration if and only if the configuration data does not already exist in the configuration datastore. If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of “data-exists”.
- delete
- The configuration data identified by the element containing this attribute is deleted from the configuration if and only if the configuration data currently exists in the configuration datastore. If the configuration data does not exist, an <rpc-error> element is returned with an <error-tag> value of “data-missing”.
Parameters
- target:
- Name of the configuration datastore being edited, such as <running/> or <candidate/>.
- config:
- A hierarchy of configuration data as defined by one of the device’s data models.
- The contents MUST be placed in an appropriate namespace, to allow the device to detect the appropriate data model, and the contents MUST follow the constraints of that data model, as defined by its capability definition.
- Capabilities are discussed in Capabilities.
Positive Response
If the device was able to satisfy the request, an <rpc-reply> is sent containing an <ok> element.
Negative Response
An <rpc-error> response is sent if the request cannot be completed for any reason.
Example
The <edit-config> examples in this section utilize a simple data model, in which multiple vlans of the <vlan> element can be present, and an instance is distinguished by the <vlanid> element within each <vlan> element.
Set the description to “test netconf” on a vlan “100” in the running configuration:
The <edit-config> examples in this section utilize a simple data model, in which multiple vlans of the <vlan> element can be present, and an instance is distinguished by the <vlanid> element within each <vlan> element.
Set the description to “test netconf” on a vlan “100” in the running configuration:
<config>
<top>
<vlans xmlns="http://asterfusion.com/ns/yang/asternos-vlan">
<vlan operation="merge">
<vlanid>100</vlanid>
<description>test netconf</description>
</vlan>
</vlans>
</top>
</config>
Create a new vlan with vlanid=200:
<config>
<top>
<vlans xmlns="http://asterfusion.com/ns/yang/asternos-vlan">
<vlan operation="create">
<vlanid>200</vlanid>
</vlan>
</vlans>
</top>
</config>
Delete vlan 100:
<config>
<top>
<vlans xmlns="http://asterfusion.com/ns/yang/asternos-vlan">
<vlan operation="delete">
<vlanid>100</vlanid>
</vlan>
</vlans>
</top>
<config>
replace vlan 100:
<config>
<top>
<vlans xmlns="http://asterfusion.com/ns/yang/asternos-vlan">
<vlan operation="replace">
<vlanid>100</vlanid>
<description>this is a replaced vlan 100</description>
</vlan>
</vlans>
</top>
<config><copy-config>
Description
AsterNOS support <copy-config>, source can be <running/>/<startup/>/<uri/>, target can be /<startup/><uri/>.
<copy-config> can create or replace an entire configuration datastore with the contents of another complete configuration datastore.
If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed.
AsterNOS currently DON’T <url>, that means device don’t support remote-to-remote copy operations, where both the <source> and <target> parameters use the <url> element.
NOTE
User can’t use same datastore as source and target in a <copy-config> rpc.
Parameters
- target:
- Name of the configuration datastore to use as the destination of the <copy-config> operation. Support <startup/>/<uri/>.
- source:
- Name of the configuration datastore to use as the source of the <copy-config> operation. Support <running/>/<startup/>/<uri/>.
Positive Response
If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
Negative Response
An <rpc-error> element is included within the <rpc-reply> if the request cannot be completed for any reason.
<get>
Description
AsterNOS support <get> to obtain config and state( defined with ‘config false’ in YANG model).
<get> is used to retrieve running configuration and device state information.
Parameters
- filter:
- This parameter specifies the portion of the system configuration and state data to retrieve.
- If this parameter is not present, all the device configuration and state information is returned.
The <filter> element MUST contain a “type” attribute with value ‘subtree’.
User may refer to Subtree Filtering` for more detailed info about subtree filter on AsterNOS.
Positive Response
If the device was able to satisfy the request, an <rpc-reply> is sent.
The <data> section contains the appropriate subset.
Negative Response
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
Example
Request:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>
Reply:
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply><delete-config>
Not Supported.
<lock>
Not supported.
<unlock>
Not Supported.
<get>
Description
AsterNOS support <get> to obtain config and state( defined with ‘config false’ in YANG). <get> is used to retrieve running configuration and device state information.
Parameters
filter: This parameter specifies the portion of the system configuration and state data to retrieve.
If this parameter is not present, all the device configuration and state information is returned. The <filter> element MUST contain a “type” attribute with value ‘subtree’.
User may refer to Subtree Filtering for more detailed info about subtree filter on AsterNOS.
Positive Response
If the device was able to satisfy the request, an <rpc-reply> is sent. The <data> section contains the appropriate subset.
Negative Response
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
Example
This example shows how to get PTP instance <current-ds> under a specified PTP instance.
<filter type="subtree">
<top xmlns="http://www.asterfusion.com/asternos-schema/1.0/config">
<ptp>
<instances>
<instance>
<instance-number>0</instance-number>
<current-ds/>
</instance>
</instances>
</ptp>
</top>
</filter>
Reply:
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<top xmlns="http://www.asterfusion.com/asternos-schema/1.0/config">
<ptp>
<instances>
<instance>
<instance-number>0</instance-number>
<current-ds>
<offset-from-master>0</offset-from-master>
<mean-path-delay>0</mean-path-delay>
<servo-state>unlocked</servo-state>
</current-ds>
</instance>
</instances>
</ptp>
</top>
</data>For more subtree info, user may refer to Subtree Filtering
<close-session>
Description
AsterNOS support to use <close-session> to request graceful termination of a NETCONF session.
When NETCONF server receives a <close-session> request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections.
Any NETCONF requests received after a <close-session> request will be ignored.
Positive Response
If the device was able to satisfy the request, an <rpc-reply> is sent that includes an <ok> element.
Negative Response
An <rpc-error> element is included in the <rpc-reply> if the request cannot be completed for any reason.
Example
Request:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
Reply:
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply><kill-session>
Not Supported.
Capabilities
This section defines a set of capabilities that AsterNOS has implemented.
AsterNOS NETCONF capability is identified with a URI. The base capabilities are defined using URNs following the method described in RFC 3553[RFC3553]. Capabilities defined in this document have the following format:
urn:ietf:params:netconf:capability:{name}:1.x
where {name} is the name of the capability.
Capabilities Exchange
AsterNOS NETCONF Capabilities are advertised in messages sent by each peer during session establishment.
When the NETCONF session is opened, AsterNOS Netconf Server will send a <hello> element containing a list of peer’s capabilities.
For example:
urn:ietf:params:netconf:base:1.1
urn:ietf:params:netconf:capability:writable-running:1.0
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:startup:1.0
urn:ietf:params:xml:ns:yang:ietf-yang-metadata?module=ietf-yang-metadata&revision=2016-08-05
urn:ietf:params:xml:ns:yang:1?module=yang&revision=2021-04-07
urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&revision=2013-07-15
urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&revision=2013-07-15
urn:ietf:params:netconf:capability:yang-library:1.1?revision=2019-01-04&content-id=27
urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2013-09-29&features=writable
running,candidate,confirmed-commit,rollback-on-error,validate,startup,url,xpath
urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&revision=2018-02-14
urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=trim,report-all
urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&revision=2012-02-06
urn:ietf:params:xml:ns:netmod:notification?module=nc-notifications&revision=2008-07-14
urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&revision=2008-07-14If no protocol version capability in common is found, the Netconf Server will not continue the session.
Writable-Running Capability
Description
The :writable-running capability indicates that the AsterNOS device supports direct writes to the <running> configuration datastore.
In other words, the device supports <edit-config> operations where the <running> configuration is the target.
Capability Identifier
The :writable-running capability is identified by the following capability string:
urn:ietf:params:netconf:capability:writable-running:1.0
New Operations
NOTE: AsterNOS currently not support lock/unlock, please use this with cautious if there are multiple users edit candidate datastore. AsterNOS currently not support discard-changes operation, user may need a <edit-config> to revert changes in candidate as setting target=’candidate’. AsterNOS currently not support <commit> rpc, please use <copy-config> and set source to ‘candidate’ and target as ‘target’.
Modifications to Existing Operations
The candidate configuration can be used as a source or target of any <get-config>, <edit-config>, <copy-config> operation as a <source> or <target> parameter. <validate> is not supported. The <candidate> element is used to indicate the candidate configuration:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<candidate/>
</source>
</get-config>
</rpc>
<source> <candidate/> </source> </get-config> </rpc>Confirmed Commit Capability
ot Supported.
Rollback-on-Error Capability
Description
AsterNOS support an internal-integrated rollback-on-error mechanism.
When any node in a user request fails, all modifications made to that request will be rolled back, which means that any failed request will not have any actual impact on the device state.
Dependencies
None.
Capability Identifier
The :rollback-on-error capability is identified by the following capability string:
urn:ietf:params:netconf:capability:rollback-on-error:1.0
New Operations
None.
Modifications to Existing Operations
Users do not need to specify <error option>rollback on error</error option> in edit config, as the server will force the cancellation of all changes in this request.
Validate Capability
Description
Validation consists of checking a complete configuration for syntactical and semantic errors before applying the configuration to the device.
AsterNOS support an internal-integrated validate operation and checks syntax errors and business logic verification.
NOTE
AsterNOS DON’T supports the <validate> rpc and <test-option> parameter to the <edit-config> operation.
Dependencies
None.
Capability Identifier
The :validate:1.1 capability is identified by the following capability string:
urn:ietf:params:netconf:capability:validate:1.1
New Operations
None.
Modifications to Existing Operations
None.
Distinct Startup Capability
Description
AsterNOS supports separate running and startup configuration datastores. The startup configuration is loaded by the device when it boots. Operations that affect the running configuration will not be automatically copied to the startup configuration. An explicit <copy-config> operation from the <running> to the <startup> is used to update the startup configuration to the current contents of the running configuration. NETCONF protocol operations refer to the startup datastore using the <startup> element.
Dependencies
None.
The :startup capability is identified by the following capability string:
Capability Identifier
urn:ietf:params:netconf:capability:startup:1.0
New Operations
None.
Modifications to Existing Operations
AsterNOS support :startup capability. To save the startup configuration, use the <copy-config> operation to copy the <running> configuration datastore to the <startup> configuration datastore.
<source> <running/>
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<copy-config>
<target>
<startup/>
</target>
<source>
<running/>
</source>
</copy-config>
</rpc>URL Capability
Not Supported.
XPath Capability
Not Supported.
NETCONF Monitoring Capability
Description
AsterNOS partly support RFC6022 netconf monitoring. Currently, only part of this module is supported:
| Type | Description |
| /netconf-state/capabilities | Support to get capabilities via <get>. |
| /netconf-state/datastores | Support to get all supported datastores name via <get>. |
| /netconf-state/schemas | Support to get all supported and valid schemas via <get>.<br/>return a list of schemas, contain:<br/>‘identifier’/‘version’/‘format’/‘location’ |
| RPC <get-schema> | Support to get schema content via <get-schema> rpc,<br/>need to specify ‘identifier’, ‘version’, ‘format’. |
Dependencies
None.
Capability Identifier
The : ietf-netconf-monitoring capability is identified by the following capability string:
urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
Contact US !
- To find a product or product family, visit Asterfusion-cloudswit.ch
- To request a proposal, send an E-Mail to bd@cloudswit.ch
- To receive timely and relevant information from Asterfusion, sign up at AsterNOS Community Portal
- To submit a case, visit Support Portal
- To find user manuals for a specific command or scenario, access AsterNOS Documentation
