08-22-2017 02:32 PM - edited 03-01-2019 03:58 AM
Hi
I added a device (vcv1) to NSO with NETCONF NED. Can successfully sync-from the device, but the following check-sync command returns "result unsupported". What is unsupported and why?
admin@ncs> request devices device vcv1 sync-from
result true
[ok][2017-08-22 15:19:24]
admin@ncs> request devices device vcv1 check-sync
result unsupported
From logs:
==> logs/devel.log <==
<DEBUG> 22-Aug-2017::15:21:46.285 ncs[7246]: ncs Requestor {'check-sync',50,<0.3481.0>} tries to acquire lock for device <<"vcv1">>
<DEBUG> 22-Aug-2017::15:21:46.978 ncs[7246]: ncs Device <<"vcv1">> is unlocked
Solved! Go to Solution.
08-23-2017 02:01 AM
This is because the device doesn't support any mechanism for retrieving a transaction id or timestamp known by NSO, at least not in the set of YANG modules included in the NETCONF NED. If the device implements something like this, it would be interesting to see a pointer to some documentation. What device type is this?
You will have to use the compare-config operation instead of check-sync for now.
08-23-2017 02:01 AM
This is because the device doesn't support any mechanism for retrieving a transaction id or timestamp known by NSO, at least not in the set of YANG modules included in the NETCONF NED. If the device implements something like this, it would be interesting to see a pointer to some documentation. What device type is this?
You will have to use the compare-config operation instead of check-sync for now.
08-23-2017 04:51 PM
Device is virtual ASR9K (IOS-XR) Version 6.1.2.
I downloaded yang directly from device and built the NETCONF NED using pioneer.
Same "unsupported" result with Cisco NCS5001 (IOS-XR 6.2.2).
Can you please elaborate a bit more on the issue? Timestamp is defined in yang modules?
Thanks Jan.
08-29-2017 02:56 AM
There is no quick standards based mechanism for detecting whether the device configuration has changed or not. So unless the device implements one of the proprietary mechanisms that NSO knows about, NSO will only be able to see if the device is in sync by doing a full compare-config.
If you know the device implements a mechanism where NSO could find out, I'd be interested to hear. Maybe we could add this mechanism to NSO.
02-19-2018 07:11 PM
Hey Jan
I encountered this again and this time I enabled raw trace to find more information. Basically, upon issuing check-sync, NSO initiates hello to device, and the device returns its full capabilities.
Then NSO suddenly closes the session with this:
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<close-session/></rpc>
My guess is that NSO was looking for something special in the returned capabilities from the device, and since it didn't find it, then it killed the session. Is my understanding correct? If so, what was it that NSO was looking for in the list of capabilities from the device? A special yang?
Device is IOS-XR 6.1.3.
Thanks
04-03-2020 05:29 PM - edited 04-03-2020 05:34 PM
Hello,
Is there any news about how to fix this issue.
I have the same problem in 5.2.2 NSO version.
Thx
04-06-2020 01:04 AM - edited 04-06-2020 02:34 AM
Check-sync for IOS-XR NETCONF devices will be supported from NSO 5.4 in June.
08-29-2017 04:37 PM
Unfortunately I don't. But given these devices are ios-xr, maybe an internal effort within Cisco could be the answer?
By the way, what are these proprietary mechanisms to detect configuration changes? Is there a pointer to a general documentation on them?
Thanks Jan.
08-13-2018 04:20 PM
reopening this thread from last year...
Hi @Jan Lindblad - Do you have any more info to share regarding this issue? Particularly, I'm interested to know more about the 'mechanisms' that NSO uses for detecting whether the device configuration has changed or not (netconf NED).
I recently worked with Cisco to fix the detection mechanism in CLI NED for iosxr devices. The CLI NED was using commit-id on iosxr device as transaction-id to detect configuration changes and when it was not available it was failing. Cisco fixed this by adding the fallback mechanism that now compares config hashes when the primary method is not available.
I wonder, how different the detection methods are when it comes to netconf NED? Wouldn't comparing config hashes still be a standard fallback mechanism when other methods are not available?
08-30-2018 10:00 AM
Hi
There currently is no default fallback mechanism for a transaction id for NETCONF devices. (Which is why it says unsupported). As more and more NETCONF devices become available NSO will add something.
/Sebastian
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide