check-sync pull full config or hash?

[samuel.coome@secunetics.com]

When performing a check-sync on devices, does NSO go out to the device, pull the full configuration, then compare them? Or is NSO capable of hashing the running config on the device without having to pull it for the comparison (and if they don't match pull the full config). We would just like to understand what is happening with a check-sync.

[vleijon · Accepted solution]

It depends on the device-type what happens. For some devices, in particular NETCONF devices, a cheap transaction-id is available for the device config, but for others what happens is that the entire config is pulled and a hash is made. Some NEDs support multiple different methods of calculating this.

This is described a little bit in the user guide, the section “Checking Device Configuration” has an overview of how it works.

[samuel.coome@secunetics.com]

Is there an easy way to view how each NED does it's check-sync? I would assume the cisco cli NEDs have to pull the full config before the hash is made.

[joepak]

As for the CLI NED within the NedConnectionBase.java:

• * @param transMode
       *  Indicates the mode of Transaction ID supported by the NED.
  

•      *     NONE if not supported. If supported, then getTransId()
  

•      *     should be implemented. Support for Transaction IDs is required
  

•      *     for check-sync action.
       */
  

  Now as for checking what capabilities NEDs may have, I would assume to check the tailf-ned-<ned>-meta.yang or in the java/src/com/tailf/ned/<package> directory should reveal some information regarding check-sync. It seems the location for what is performed varies on the NED.

For example, alu-sr has this in the alu-sr-meta.yang file:

    leaf trans-id-method {
      tailf:info "Configure how the NED shall calculate the transaction id. "
        +"Typically used after each commit and for check-sync operations";
      type enumeration {
        enum config-hash {
          tailf:info "Use a snapshot of the running config for calculation."
            +"(default)";
        }
        enum rollback-timestamp {
          tailf:info "Use the time stamp of the latest rollback checkpoint "
            +"for calculation. The system rollback feature must be on.";
        }
        enum last-modified-timestamp {
          tailf:info "Use the 'time last modified' time stamp generated by "
            + "the ALU device for calculation. Note, this time stamp "
            + "is not available on all ALU devices. See README";
        }
        enum last-saved-timestamp {
          tailf:info "Use the 'time last saved' time stamp generated by the "
            + "ALU device for calculation. Note, this method is not "
            + "reliable. See README";
        }
      }
      default "config-hash";
    }
  }

So I would assume the location for the information regarding check-sync varies per NED.

Hope this was helpful as well.

[samuel.coome@secunetics.com]

For NED specific, it can be found in the README of the NED

---------------------------------------------------

cisco-ios read transaction-id-method <enum>

The method to use by the NED for calculating transaction ID is a
configurable option. The default method is quite slow since it
uses output of show running-config and a software calculated
MD5. The advantage though is that it does not change even if the
device reboots. Another advantage is that it works on all
platforms. If you do not care about the transaction id changing if
the device reboots you may increase performance significantly by
changing the method the transaction id is calculated.

Five different methods are supported:

config-hash - Calculate MD5 on a snapshot of the entire running
config for calculation. (Default)

last-config-change - Use the 'Last configuration change' timestamp
in running config only (WARNING: changed at reboot)

config-id - Use the 'show configuration id' command to determine
if config changed. (WARNING: changed at reboot)

config-history - Use the 'show configuration history' command to
determine if config changed. (WARNING: changed at reboot)

config-hash-cached - Same as config-hash except that transaction
id method will reuse the last unmodified
config from show (sync-from).

Note: 'show config id|history' is not supported on some platforms,
e.g. 3550, cat4500, cat6500 etc. But if the option is not supported,
you will get to know this by use of an exception.

[joepak]

Hi Samuel,

Your understanding is correct as mentioned in the user guide:

The underlying mechanism for the cheap check-sync is to compare time-stamps, transaction-ids, hash- sums, etc depending on what the device supports. This in order not to have to read the full configuration to check if the NSO copy is in sync.

The transaction ids are store in CDB and can be viewed as:

ncs# show devices device state last-transaction-id NAME LAST TRANSACTION ID ----------------------------------------
ce0 ef3bbd344ef94b3fecec5cb93ac7458c

It will not read the full-config and will use a series of time-stamps/trans-ids/hash-sums, and so on.

I hope this was helpful.