Junos check-sync options

[kjdhghsghsfg]

Hi

Question about juniper-junos (more specifically juniper-junos-nc-4.7) NED.

After I make and revert a config change on the Junos device the check-sync will report the device to be out-of-sync. compare-config reports difference in timestamp. After compare-config second check-sync reports in-sync. Is there anything I can do about this? I checked the NED README and tested "devices device PE1 ned-settings use-transaction-id false". No success.

Device trace file indicates that with check-sync NSO fetches junos:commit-seconds and junos:commit-localtime from the device

In our case it is possible that an event script running locally on the Junos device modifies the config and reverts the modifications outside NSO. This should not result in out-of-sync state on NSO. Why event-script? Because action is based on certain triggers available (only) on the device.

Or should we look into "commit no-out-of-sync-check no-overwrite" or something similar?

Example:

---NSO---
user@nso# devices device PE1 check-sync
result in-sync
---NSO---

---JUNOS---
[edit]
user@PE1# set interfaces xe-0/0/0 disable

[edit]
user@PE1# commit
commit complete

[edit]
user@PE1# del interfaces xe-0/0/0 disable

[edit]
user@PE1# commit
commit complete
---JUNOS---

---NSO---
user@nso# devices device PE1 check-sync
result out-of-sync
info got: 2023-05-12 09:23:34 EEST expected: 2023-05-12 08:56:22 EEST

user@nso# *** ALARM out-of-sync: got: 2023-05-12 09:23:34 EEST expected: 2023-05-12 08:56:22 EEST

user@nso# devices device PE1 compare-config
user@nso# devices device PE1 check-sync
result in-sync
---NSO---

[huayyang]

In this case, unless you do a sync-from/compare-config, which are considered "expensive" because NSO needs to check all config on device, NSO wouldn't be able to tell if the config has really changed or not. The timestamp is a "cheaper" way for NSO to know if the device config is in-sync, but it's not perfect, as your example shows.

If you know for sure the device is in sync, you can use "no-out-of-sync-check"; if you're uncertain but want to keep the config on device, use "no-overwrite". More details in https://developer.cisco.com/docs/nso/guides/#!life-cycle-operations-manipulating-existing-services-and-devices

[rogaglia]

I would add that the IETF is working on a better solution for this problem but it is still a draft: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-transaction-id-01