Sync

This capability indicates that the device allows the NMS to perform full or incremental data synchronization. Through data synchronization, the NMS or controller that manages network devices can have the same configuration data with NEs in real time.

Full Data Synchronization

<sync-full> synchronizes all data from the device to the destination folder. After the NMS connects to an NE for the first time, it synchronizes all data of the NE to the NMS.

The YANG model defines the capability in the huawei-netconf-sync.yang file.

After a NETCONF server receives an <rpc> element containing a <sync-full> element, the NETCONF server performs a syntax check on the element. If the element fails the syntax check, the NETCONF server returns an <rpc-reply> element containing an <rpc-error> element. If the syntax check succeeds, the NETCONF server returns an <rpc-reply> element and obtains data to be synchronized. The server encapsulates the data in XML format and writes data of each feature to a separate XML file. An XML file cannot exceed 300 MB. If the data exceeds 300 MB, it is written into multiple XML files. The XML files are compressed into a .zip file and then transferred to a specified directory using FTP or SFTP.

The following functions are supported:

Canceling a specific full data synchronization operation
Uploading a full data synchronization file
Querying the file upload progress

Example of a full data synchronization operation: The NETCONF server uses FTP to transfer AAA module configurations in the data to be synchronized to the home directory of user root (password is root) on the server whose IP address is 10.1.1.1. The storage file name is Multi_App_sync_full.zip.

RPC request:

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4">
  <sync-full xmlns="urn:huawei:yang:huawei-netconf-sync">
    <target>
      <user-name>root</user-name>
      <password>root</password>
      <target-addr>10.1.1.1</target-addr>
      <path>/home</path>
    </target>
    <transfer-protocol>ftp</transfer-protocol>
    <transfer-method>auto</transfer-method>
    <filename-prefix>Multi_App_sync_full</filename-prefix>
    <app-err-operation>stop-on-error</app-err-operation>
    <filter>
      <aaa xmlns="urn:huawei:yang:huawei-aaa"/>
    </filter>
  </sync-full>
</rpc>

RPC reply:

The RPC reply message carries a full data synchronization identifier assigned by the NETCONF server, which is returned using the <sync-full-id> parameter.

After full synchronization is triggered, the RPC reply message carries the nc-ext attribute.

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"
           xmlns:nc-sync="urn:huawei:yang:huawei-netconf-sync"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
           message-id="2"
           nc-ext:flow-id="32">
  <nc-sync:sync-full-id>185</nc-sync:sync-full-id>
</rpc-reply>

Example of a <cancel-synchronization> operation that cancels the full data synchronization operation whose <sync-full-id> is 185:

RPC request:

<rpc message-id="cancel" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <cancel-synchronization xmlns="urn:huawei:yang:huawei-netconf-sync">
    <sync-full-id>185</sync-full-id>
  </cancel-synchronization>
</rpc>

RPC reply:

Success reply
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="cancel" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

Example of an <upload-sync-file> operation that uploads a full data synchronization file:

RPC request:

<rpc message-id="upload" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <upload-sync-file xmlns="urn:huawei:yang:huawei-netconf-sync"> 
    <sync-full-id>185</sync-full-id>
    <result-save-time>1</result-save-time>        
  </upload-sync-file>
</rpc>

RPC reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="upload" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

Example of a <get> operation that queries the file upload progress:

RPC request:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="query_status185">
  <get>
    <filter type="subtree">
      <synchronization xmlns="urn:huawei:yang:huawei-netconf-sync">
        <file-transfer-statuss>
          <file-transfer-status>
            <sync-full-id>185</sync-full-id>
            <status></status>
            <progress></progress>
            <error-message></error-message>
          </file-transfer-status>
        </file-transfer-statuss>
      </synchronization>
    </filter>
  </get>
</rpc>

RPC reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="query_status12" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <synchronization xmlns="urn:huawei:yang:huawei-netconf-sync">
      <file-transfer-statuss>
        <file-transfer-status>
          <sync-full-id>12</sync-full-id>
          <status>In-Progress</status>
          <progress>50</progress>
        </file-transfer-status>
      </file-transfer-statuss>
    </synchronization>
  </data>
</rpc-reply>

Incremental Data Synchronization

<sync-increment> incrementally synchronizes data from a device to the destination folder. A client uses the configuration change identifier <flow-id> to know a configuration change. The configuration changes once, the <flow-id> value is incremented by 1. If the client needs to obtain configurations changed, it synchronizes data incrementally.

If the <sync-increment> operation succeeds, the NETCONF server replies an <rpc-reply> element that contains the <data> element. The <data> element contains the data changed between configuration submissions. If the <sync-inc> operation fails, the NETCONF server sends an <rpc-reply> element containing an <rpc-error> element.

<sync-increment> uses the <difference> attribute to specify a configuration data instance change. The YANG model defines <sync-inc> in the huawei-netconf-metadata.yang file.

Example of an incremental data synchronization operation that synchronizes IFM module configurations between change points 6 and 7:

RPC request:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <sync-increment xmlns="urn:huawei:yang:huawei-netconf-sync"> 
    <target> 
      <flow-id>7</flow-id> 
    </target> 
    <source> 
      <flow-id>6</flow-id> 
    </source> 
    <filter type="subtree"> 
      <ifm xmlns="urn:huawei:yang:huawei-ifm"/> 
    </filter> 
  </sync-increment> 
</rpc>

RPC reply:

<rpc-reply xmlns:nc-md="urn:huawei:yang:huawei-netconf-metadata"> 
  <data xmlns="urn:huawei:yang:huawei-netconf-sync"> 
    <ifm xmlns="urn:huawei:yang:huawei-ifm"> 
      <interfaces> 
        <interface nc-md:difference="create"> 
          <interfaceName>Gigabitethernet0/1/0.1</interfaceName> 
          <mtu>15000</mtu> 
          <adminStatus>down</adminStatus> 
        </interface> 
        <interface nc-md:difference="delete"> 
          <interfaceName>Gigabitethernet0/1/1.1</interfaceName> 
        </interface> 
        <interface nc-md:difference="modify"> 
          <interfaceName>Gigabitethernet0/2/0</interfaceName> 
          <mtu>15000</mtu> 
          <adminStatus>up</adminStatus> 
        </interface> 
        <interface nc-md:difference="modify"> 
          <interfaceName>Gigabitethernet0/2/1</interfaceName> 
          <ifAm4s> 
            <ifAm4 nc-md:difference="create"> 
              <ipAddress>10.164.11.10</ipAddress> 
              <netMask>255.255.255.0</netMask> 
              <addressType/> 
            </ifAm4> 
          </ifAm4s> 
        </interface> 
      </interfaces> 
    </ifm> 
  </data> 
</rpc-reply>