As I understand the Netconf 1.0 and 1.1 uses the same framing; the version 1.1 just has some additional capabilities. More info about differences you can find here. Please do not confuse Netconf version and IETF YANG model namespaces. The last all have '*:base:1.0' namespaces defined in RFC 6241. The CRUD and Netconf Services implementation in YDK currently use only Netconf 1.0 capabilities. However, the Netconf client, which is implemented in C and C++ code, does implement both 1.0 and 1.1 versions, meaning that the RPCs compliant with version 1.1 still can be successfully processed. The YDK also includes Executor Service, which allows to build and execute RPCs based on ietf_netconf.yang model. That means, you can include into RPC any constructs defined in the model. You can find multiple examples of how to use Executor Service in unit tests included in ydk-gen repository. ... View more

This is similar to XRv9K NETCONF 1.1. The issue that you are observing is not related to YDK. As I can see in the log, the YDK worked perfectly well. I believe you cannot configure BGP on Cisco routers using standard openconfig models. For this you should use proprietary Cisco models and/or openconfig-network-instance. It is also possible that your particular device does not include BGP routing as a feature. You can try to do the BGP configuration on your device using CLI just to see if it is supported. ... View more

The issue is not related to YANG-1.1 support. Look at the error message: ydk.errors.YServiceProviderError: RPC error occurred; check log file for details And details in the log: 2019-12-06 17:40:48,468 - ydk - INFO - ============= Received RPC from device ============= <?xml version="1.0"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> <rpc-error> <error-type>protocol</error-type> <error-tag>unknown-namespace</error-tag> <error-severity>error</error-severity> <error-info> <bad-element>bgp</bad-element> <bad-namespace>http://openconfig.net/yang/bgp</bad-namespace> </error-info> </rpc-error> </rpc-reply> This means that Netconf does not know how to translate 'bgp' node to router configuration commands. I think that BGP on Cisco routers can be configured only by using Cisco proprietary YANG models. The Cisco routers do not support openconfig models for device configuration; these models can be used only for reading configuration. ... View more

yanglint The yanglint is command line utility of Libyang. Please refer to Libyang documentation for details. The Libyang is a third party software, which is used by YDK to parse YANG models, load and output data, which are organized accordingly to the YANG models. The core YDK library - libydk - incorporates the Libyang library, which is compiled during libydk build. Therefore, in order to get yanglint utility you need compile the core YDK library from source. Please note that YDK uses private fork of libyang; its code is adjusted to YDK needs. The YDK code currently is not compatible with master branch due to recent significant change in API by Libyang developers. Device models In order to load YANG models to libyang we need create repository (directory) of *.yang files. It can be a  limited set of files, which is needed to resolve all the dependencies. By default the repository is organized in directory $HOME/.ydk/<device-IP>. The Netconf protocol has capability to retrieve YANG models from device. When there is a need to load a module to libyang, the YDK looks for that module in repository. If not found, it attempts to retrieve the module from device and puts it to repository. This algorithm allows to have in repository only those models that are needed for particular task, and significantly save time on repeated runs of user application.   ... View more

I tested the script on sandboxes for IOS-XR-6.5.3 and IOS-XE-16.9.3. It works perfectly well on IOS-XR including parsing of deviation file  cisco-xr-openconfig-acl-deviations.yang received from the device. But the script fails on IOS-XE while parsing deviation file  cisco-xe-openconfig-acl-deviation.yang (same internal error). Then I removed all 'deviation' statements in the failed file located in repository  under $HOME/.ydk/<device-IP> and repeated the test. This time it all worked fine. I am guessing that something is wrong with the deviation file for IOS-XE-16.9.3. Note. When YANG file in default repository is changed, it is not get overwritten by YDK when synchronizing repository with YANG models on device. I used Libyang utility yanglint to analyze cisco-xe-openconfig-acl-deviation.yang parsing . From your ydk-gen location run: cd sdk/cpp/core/build/project_libyang/src/ project_libyang-build ./yanglint -p /Users/ygorelik/.ydk/ios-xe-mgmt.cisco.com /Users/ygorelik/.ydk/ios-xe-mgmt.cisco.com/cisco-xe-openconfig-acl-deviation.yang   I found that some of the deviation statements are incorrect. Here is the module content with my comments: module cisco-xe-openconfig-acl-deviation { namespace "http://cisco.com/ns/cisco-xe-openconfig-acl-deviation"; prefix acl-devs; import openconfig-acl { prefix oc-acl; } import tailf-common { prefix tailf; } organization "Cisco Systems, Inc."; contact "Cisco Systems, Inc. Customer Service Postal: 170 W Tasman Drive San Jose, CA 95134 Tel: +1 1800 553-NETS E-mail: cs-yang@cisco.com"; description "This module defines deviation statements for openconfig-acl module."; revision 2017-08-25 { description "Added deviation to remove leafref from ingress/egress acls because of IOS allowing access-groups on interfaces when the access-group doesn't exit"; } revision 2017-08-22 { description "Remove deviation to require at least one ingress or egress acl on interface"; } revision 2017-05-04 { description "Add"; } deviation "/oc-acl:acl/oc-acl:acl-sets/oc-acl:acl-set" { deviate add { unique "oc-acl:name"; } } deviation "/oc-acl:acl/oc-acl:acl-sets/oc-acl:acl-set/oc-acl:acl-entries/oc-acl:acl-entry" { deviate add { unique "oc-acl:actions/oc-acl:config/oc-acl:forwarding-action " + "oc-acl:l2/oc-acl:config/oc-acl:source-mac " + "oc-acl:l2/oc-acl:config/oc-acl:destination-mac " + "oc-acl:l2/oc-acl:config/oc-acl:ethertype"; } } deviation "/oc-acl:acl/oc-acl:acl-sets/oc-acl:acl-set/oc-acl:acl-entries/oc-acl:acl-entry" + "/oc-acl:l2/oc-acl:config/oc-acl:source-mac" { deviate add { default 00:00:00:00:00:00; } } deviation "/oc-acl:acl/oc-acl:acl-sets/oc-acl:acl-set/oc-acl:acl-entries/oc-acl:acl-entry" + "/oc-acl:l2/oc-acl:config/oc-acl:source-mac-mask" { deviate add { must "../oc-acl:source-mac" { error-message "When source-mac-mask is set, source-mac must be set too"; } } } deviation "/oc-acl:acl/oc-acl:acl-sets/oc-acl:acl-set/oc-acl:acl-entries/oc-acl:acl-entry" + "/oc-acl:l2/oc-acl:config/oc-acl:destination-mac" { deviate add { default 00:00:00:00:00:00; } } deviation "/oc-acl:acl/oc-acl:acl-sets/oc-acl:acl-set/oc-acl:acl-entries/oc-acl:acl-entry" + "/oc-acl:l2/oc-acl:config/oc-acl:destination-mac-mask" { deviate add { must "../oc-acl:destination-mac" { error-message "When destination-mac-mask is set, destination-mac must be set too"; } } } /* WRONG STATEMENTS BELOW THIS LINE deviation "/oc-acl:acl/oc-acl:acl-sets/oc-acl:acl-set/oc-acl:acl-entries/oc-acl:acl-entry" + "/oc-acl:actions/oc-acl:config/oc-acl:log-action" { deviate add { must ". = 'oc-acl:LOG_NONE' or ../../../../../type != 'oc-acl:ACL_L2'" { error-message "Log action not supported for L2 ACL sets"; } } } deviation "/oc-acl:acl/oc-acl:interfaces/oc-acl:interface/oc-acl:ingress-acl-sets/oc-acl:ingress-acl-set" + "/oc-acl:config/oc-acl:set-name" { deviate replace { type leafref { tailf:no-leafref-check; path "../../../../../../acl-sets/acl-set/config/name"; } } } deviation "/oc-acl:acl/oc-acl:interfaces/oc-acl:interface/oc-acl:ingress-acl-sets/oc-acl:ingress-acl-set" + "/oc-acl:config/oc-acl:type" { deviate replace { type leafref { tailf:no-leafref-check; path "../../../../../../acl-sets/acl-set[name=current()/../set-name]" + "/config/type"; } } } deviation "/oc-acl:acl/oc-acl:interfaces/oc-acl:interface/oc-acl:egress-acl-sets/oc-acl:egress-acl-set" + "/oc-acl:config/oc-acl:set-name" { deviate replace { type leafref { tailf:no-leafref-check; path "../../../../../../acl-sets/acl-set/config/name"; } } } deviation "/oc-acl:acl/oc-acl:interfaces/oc-acl:interface/oc-acl:egress-acl-sets/oc-acl:egress-acl-set" + "/oc-acl:config/oc-acl:type" { deviate replace { type leafref { tailf:no-leafref-check; path "../../../../../../acl-sets/acl-set[name=current()/../set-name]" + "/config/type"; } } } */ }  You might consider opening a bug for this IOS-XE YANG model issue. ... View more

I could not find any published example for the path  Cisco-IOS-XR-ifmgr-cfg/interface-configurations/ interface-configuration/ ethernet-service The closest examples with the same YANG model can be found here. Are you experiencing any specific issue related to that YANG model and/or path? What YDK release are you using for your application? What is programming language?  Regards, Yan ... View more

Hi Pradeep I found that in the NX-OS 9.2.1 module Cisco-NX-OS-device.yang there is an error in description field in line 102933; it erroneously contains '\' at the end of the line, which confuses libyang YANG parser. This error in the model was fixed in release 9.2.3. In order to address this issue I copied corrected module file to default repository under $USER/.ydk/64.103.37.14/. Then I ran your script and it failed again, but this time due to RPC error. The issue with your script is that it requests entire system config and oper data, and apparently the device choked on it. Then I modified the script to get just one leaf 'systemuptime' and that worked well. Here is my script: #!/usr/bin/env python from ydk.models.cisco_nx_os import Cisco_NX_OS_device as device from ydk.services import CRUDService from ydk.providers import NetconfServiceProvider from ydk.filters import YFilter import logging logger = logging.getLogger('ydk') logger.setLevel(logging.INFO) ch = logging.StreamHandler() formatter = logging.Formatter(("%(asctime)s - %(name)s - %(levelname)s - %(message)s")) ch.setFormatter(formatter) logger.addHandler(ch) sp_instance = NetconfServiceProvider(address='64.103.37.14', port=10000, username='admin', password='Admin_1234!',) crud = CRUDService() system_time = device.System() system_time.systemuptime = YFilter.read system_time = crud.read(sp_instance, system_time) print("System uptime: %s" % system_time.systemuptime) And results: (venv) ygorelik@xenial:~/ydk-gen/scripts$ ./get-nx-system.py 2019-10-29 07:09:32,045 - ydk - INFO - Path where models are to be downloaded: /home/ygorelik/.ydk/64.103.37.14 2019-10-29 07:09:32,055 - ydk - INFO - Connected to 64.103.37.14 on port 10000 using ssh with timeout of -1 2019-10-29 07:09:32,288 - ydk - INFO - Executing CRUD read operation on [Cisco-NX-OS-device:System] 2019-10-29 07:09:32,288 - ydk - INFO - Executing 'get' RPC on [Cisco-NX-OS-device:System] 2019-10-29 07:09:34,067 - ydk - ERROR - Cannot find model with module name 'Cisco-NX-OS-device-deviations' 2019-10-29 07:09:34,112 - ydk - INFO - ============= Sending RPC to device ============= <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <filter><System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device"> <systemUpTime/> </System></filter> </get> </rpc> 2019-10-29 07:09:38,991 - ydk - INFO - ============= Received RPC from device ============= <?xml version="1.0" encoding="UTF-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> <data> <System xmlns="http://cisco.com/ns/yang/cisco-nx-os-device"> <systemUpTime>00:00:00:00.000</systemUpTime> </System> </data> </rpc-reply> System uptime: 00:00:00:00.000 2019-10-29 07:09:39,289 - ydk - INFO - Disconnected from device In future tests I encourage you to enable logging to see the details of script execution. Regards, Yan   ... View more

I am happy to report that the issue has been fixed. See details on the GitHub. In order to apply the fix you need to recompile and reinstall YDK-0.8.4 core library and Python core package. Here is the procedure: git clone -b 0.8.4 https://github.com/CiscoDevNet/ydk-gen.git cd ydk-gen/sdk/cpp/core mkdir build cd build cmake .. make sudo make install # Activate Python virtual environment if needed pip install -U ydk # Run your openconfig script Please let me know if you have any installation issue. Good luck! ... View more