cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2354
Views
5
Helpful
9
Replies

check-sync returns "unsupported"

Iman1
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

Jan Lindblad
Cisco Employee
Cisco Employee

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.

View solution in original post

9 Replies 9

Jan Lindblad
Cisco Employee
Cisco Employee

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.

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.

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.

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

Hello,
Is there any news about how to fix this issue.
I have the same problem in 5.2.2 NSO version.
Thx

Check-sync for IOS-XR NETCONF devices will be supported from NSO 5.4 in June.

Iman1
Level 1
Level 1

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.

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?

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

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the NSO Developer community: