<edit-config>
The <edit-config> operation loads all or some configurations to a specified target configuration database (<running/> or <candidate/>). The device authenticates the operation in <edit-config>. After the authentication succeeds, the device performs corresponding modification.
The <edit-config> operation supports multiple configuration loading modes. For example, local files and remote files can be loaded, and files can be edited online. If a NETCONF server supports the URL capability, the <url> parameter that identifies the local configuration file can be used to replace the <config> parameter.
<config>: A group of hierarchical configuration items defined in the data model.
<config> may contain the optional attribute <operation>, which is used to specify an operation type for a configuration item. If the <operation> attribute is not carried, the <merge> operation is performed by default. The <operation> attribute values are as follows:- merge: In the database, modify the existing data or create data that does not exist. This is the default operation.
- create: Add configuration data to the configuration database only when the configuration data to be created does not exist in the configuration database. If the configuration data exists, <rpc-error> is returned, in which the <error-tag> value is data-exists.
- delete: Delete a specified configuration data record from the configuration database. If the data record exists, the data record is deleted. If the data record does not exist, <rpc-error> is returned, in which the <error-tag> value is data-missing.
- remove: Delete a specified configuration data record from the configuration database. If the data record exists, the data record is deleted. If the data record does not exist, a success message is returned.
<target>: Configuration database to be edited. The configuration database can be set based on the scenario.
In immediate validation mode, set the database to <running/>.
In two-phase validation mode, set the database to <candidate/>. After editing the database, perform the <commit> operation to submit the configuration for the modification to take effect.
In the trial mode, set the database to <candidate/>.
<default-operation>: Set a default operation for the <edit-config> operation.
The <default-operation> parameter is optional. Its default value is merge. The values are as follows:
merge: Merge the configuration data in the <config> parameter with the configuration data in the target configuration database. This is the default operation.
none: Except that the operation specified by the <operation> attribute is performed, the configuration data in the target configuration database is not affected by other configuration data in <config>. If the <config> parameter contains the configuration data that does not exist at the corresponding data level in the target configuration database, <rpc-error> is returned, in which the <error-tag> value is data-missing. In this way, redundant elements are not created when a specified operation is performed. For example, when a specified child element is deleted, <config> contains the parent hierarchical structure of the child element but the target database does not contain the configuration of the parent element. If the <default-operation> value is not none, the configuration of the parent element is created in the database when the child element is deleted. If the <default-operation> value is none, the child element is deleted and the configuration of the parent element is not created.
<error-option>: Set a processing mode for subsequent instances after a configuration error of an instance occurs. The default value is stop-on-error. The values are as follows:
1. If the target configuration library is <running/>:
- stop-on-error: Stop the operation if an error occurs and roll back the configuration according to the rollback-on-error mode.
- continue-on-error: Record the error information and continue the execution if an error occurs. The NETCONF server returns an <rpc-reply> message indicating an operation failure to the client after an error occurs.
- rollback-on-error: Stop the operation if an error occurs and roll back the configuration to the state before the <edit-config> operation is performed. This operation is supported only when the device supports the <rollback-on-error> capability.
2. If the target configuration library is <candidate/>, set the value of <error-option> to rollback-on-error for subsequent instances after a configuration error of an instance occurs.
- RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="15"> <edit-config> <target> <running/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>GigabitEthernet0/0/1</name> <class>main-interface</class> <type>MEth</type> <number>0/0/1</number> <admin-status>up</admin-status> </interface> </interfaces> </ifm> </config> </edit-config> </rpc> - RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="15" nc-ext:flow-id="27"> <ok/> </rpc-reply>
- RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="844"> <edit-config> <target> <running/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"> <name>LoopBack1023</name> </interface> </interfaces> </ifm> </config> </edit-config> </rpc> - RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="844" nc-ext:flow-id="29"> <ok/> </rpc-reply>
If the <test-option> parameter value is test-then-set or the parameter is not specified, nodes at any layer support the <replace> operation that replaces the configuration in the target database with that in the current RPC request.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id=""> <edit-config> <target> <running/> </target> <config> <acl xmlns="urn:huawei:yang:huawei-acl"> <groups> <group nc:operation="replace" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <identity>2000</identity> <type>basic</type> <match-order>config</match-order> <step>5</step> </group> </groups> </acl> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="8"> <ok/> </rpc-reply>
If the <test-option> parameter value is test-then-set or the parameter is not specified, nodes at any layer support the <delete> and <remove> operations that delete all configuration data of a specified node in the configuration database.
Example of deleting the vplsInstances configuration.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="849"> <edit-config> <target> <running/> </target> <config> <l2vpn xmlns="urn:huawei:yang:huawei-l2vpn"> <instances xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"/> </l2vpn> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="849" nc-ext:flow-id="31"> <ok/> </rpc-reply>
