07-05-2023 01:02 PM
Hi all,
So I have been playing some with ydk-gen.. I had my share of issues, but I am working slowly though them..
I though I had a working model for 17.6.1, but there are still a few hick-ups with inconsistencies.. anyways, Im trying the "old" 16.9.3.post1 version of the models.
Im reading out the access lists for one of my 9200 series switches like this:
from ydk.types import YList, Empty
from ydk.services import NetconfService, Datastore
from ydk.providers import NetconfServiceProvider
from ydk.models.cisco_ios_xe import (
Cisco_IOS_XE_native as xe_native
)
from ydk.filters import YFilter
from ydk.services import CodecService
from ydk.providers import CodecServiceProvider
import logging
if __name__ == "__main__":
logger = logging.getLogger("ydk")
logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
formatter = logging.Formatter(("%(asctime)s - %(name)s - "
"%(levelname)s - %(message)s"))
handler.setFormatter(formatter)
logger.addHandler(handler)
# create NETCONF provider
provider = NetconfServiceProvider(address="10.8.0.12",
port=830,
username="my-username",
password="my-super-long-password",
protocol="ssh")
# create NETCONF service
netconf = NetconfService()
access_list = xe_native.Native.Ip.AccessList()
access_list.yfilter = YFilter.read
object_groups = xe_native.Native.ObjectGroup()
object_groups.yfilter = YFilter.read
native = xe_native.Native()
ip = xe_native.Native.Ip()
ip.access_list = access_list
native.ip = ip
native.object_group = object_groups
result = netconf.get_config(provider, Datastore.running, read_filter=native) # read running config
This "sorta" works
and gives an output like this:
2023-07-04 21:16:40,288 - ydk - INFO - Path where models are to be downloaded: /home/eslau/.ydk/10.8.0.12
2023-07-04 21:16:40,298 - ydk - INFO - Connected to 10.8.0.12 on port 830 using ssh with timeout of -1
2023-07-04 21:16:45,849 - ydk - INFO - Executing 'get' RPC on [Cisco-IOS-XE-native:native] from running
2023-07-04 21:16:45,950 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "fwd" references obsolete definition "TwentyFiveGigabitEthernet". Path: '/Cisco-IOS-XE-native:native/ip/route/ip-route-interface-forwarding-list/fwd-list/fwd'
2023-07-04 21:16:45,951 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "fwd" references obsolete definition "TwentyFiveGigabitEthernet". Path: '/Cisco-IOS-XE-native:native/ip/route/ip-route-interface-forwarding-list/fwd-list-with-track/fwd'
2023-07-04 21:16:45,953 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "fwd" references obsolete definition "TwentyFiveGigabitEthernet". Path: '/Cisco-IOS-XE-native:native/ip/route/topology/ip-route-interface-forwarding-list/fwd-list/fwd'
2023-07-04 21:16:45,955 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "fwd" references obsolete definition "TwentyFiveGigabitEthernet". Path: '/Cisco-IOS-XE-native:native/ip/route/topology/ip-route-interface-forwarding-list/fwd-list-with-track/fwd'
2023-07-04 21:16:46,081 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "resync" references obsolete definition "encapsulation". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:interface/Cisco-IOS-XE-native:pseudowire/pseudowire-sequencing/sequencing-option/resync-case/resync'
2023-07-04 21:16:46,112 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-policy-map-case/police-policy-map/police/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,113 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-cir-percent-case/police-cir-percent/police/cir/percent/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,114 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-rate-unit-case/police-rate-unit/police/rate/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,114 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-rate-percent-case/police-rate-percent/police/rate/percent/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,116 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-rate-pdp-case/police-rate-pdp/police/rate/pdp/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,117 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-target-bitrate-case/police-target-bitrate/police/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,118 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-flow-case/police-flow/police/flow/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,119 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: A current definition "set-prec-transmit" references deprecated definition "set-dscp-transmit". Path: '/Cisco-IOS-XE-native:native/Cisco-IOS-XE-native:policy/policy-map/class/action-list/action-param/police-case/police-choice/police-catalyst-case/police-catalyst/police/actions/conform-set-prec-transmit/conform-action/set-prec-transmit'
2023-07-04 21:16:46,217 - ydk - INFO - ============= Sending RPC to device =============
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<source>
<running/>
</source>
<filter><native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<ip>
<access-list/>
</ip>
<object-group/>
</native></filter>
</get-config>
</rpc>
2023-07-04 21:16:46,372 - 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="2">
<data>
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<ip>
<access-list>
<extended xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-acl">
<name>TEST_LIST</name>
<access-list-seq-rule>
<sequence>5</sequence>
<ace-rule>
<action>permit</action>
<protocol>ip</protocol>
<any/>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
<access-list-seq-rule>
<sequence>6</sequence>
<ace-rule>
<action>deny</action>
<protocol>ip</protocol>
<any/>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
<access-list-seq-rule>
<sequence>10</sequence>
<ace-rule>
<action>permit</action>
<protocol>tcp</protocol>
<any/>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
<access-list-seq-rule>
<sequence>20</sequence>
<ace-rule>
<action>deny</action>
<protocol>udp</protocol>
<any/>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
</extended>
<extended xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-acl">
<name>TEST_TEST</name>
<access-list-seq-rule>
<sequence>10</sequence>
<ace-rule>
<action>permit</action>
<protocol>tcp</protocol>
<any/>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
<access-list-seq-rule>
<sequence>20</sequence>
<ace-rule>
<action>deny</action>
<protocol>udp</protocol>
<any/>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
<access-list-seq-rule>
<sequence>30</sequence>
<ace-rule>
<action>permit</action>
<protocol>ip</protocol>
<any/>
<dst-any/>
</ace-rule>
</access-list-seq-rule>
</extended>
</access-list>
</ip>
<object-group>
<network xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-object-group">
<name>ALLOWED_PUBLIC_DNS_SERVERS</name>
<obj-Mode-config-network-group>
<host>
<ipv4-host>1.0.0.1</ipv4-host>
</host>
<host>
<ipv4-host>1.1.1.1</ipv4-host>
</host>
<host>
<ipv4-host>8.8.4.4</ipv4-host>
</host>
<host>
<ipv4-host>8.8.8.8</ipv4-host>
</host>
<host>
<ipv4-host>9.9.9.9</ipv4-host>
</host>
<host>
<ipv4-host>83.136.89.4</ipv4-host>
</host>
<host>
<ipv4-host>89.136.89.6</ipv4-host>
</host>
<host>
<ipv4-host>149.112.112.112</ipv4-host>
</host>
<host>
<ipv4-host>208.67.220.220</ipv4-host>
</host>
<host>
<ipv4-host>208.67.222.222</ipv4-host>
</host>
</obj-Mode-config-network-group>
</network>
</object-group>
</native>
</data>
</rpc-reply>
The switch are running IOS 17.3.5
However if I use the same code and point it to a Cisco 1111-8p router running 17.6.5, it totally blows up..
Now the million $ questions is.. When YDK validates the data coming back from the device.. does it then use the .yang models as part of the python ydk-models-cisco-ios-xe package or does it actually download the models from the device and uses the models that the device are providing? The logs are suggesting that it does..
The reason I ask is that the 17.x models have soooo many faults and errors, its a complete nightmare.. But IF I manage to get some working models in ydk-gen and package that up, if it uses the device local copy it will not work for me anyways until "someone" in Cisco patches the models in the IOS-XE releases and I upgrade. That is a long long long process...
a little off topic..
- http://ydk.io is not working (see: https://github.com/CiscoDevNet/ydk-gen/issues/1088)
- and I also think I hit a bug in the encode/decode (see: https://github.com/CiscoDevNet/ydk-gen/issues/1089)
Thanks for your help!
Esben
07-06-2023 05:56 PM
1. The filter building is incorrect. You presented common error. You have to remember that only present containers need initialization. The rest of containers and lists are generated when you create top level container. You script (the lower part) should look like this:
# create NETCONF service
netconf = NetconfService()
native = xe_native.Native()
native.ip.access_list.yfilter = YFilter.read
native.object_group.yfilter = YFilter.read
2. I also had issues with XE release 17.x. They appear due to unresolved pyang issue. When needed I end up building the model API for the task, meaning very limited number of YANG models.
3. For the issue #1088. The GitHub pages are working just fine, but for some reason they do not pickup the CSS, hence the visible picture is somewhat simplified. The ydk-py is not supported anymore.
4. For the issue #1089. The same model building mistakes as in 1.
07-07-2023 02:41 AM
Hi Yan,
Many thanks for your reply. I tried to change the config to the one you suggested. it gives the same "filter RPC"
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<source>
<running/>
</source>
<filter><native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
<ip>
<access-list/>
</ip>
<object-group/>
</native></filter>
</get-config>
</rpc>
regardless of how its done, but thanks for the pointer I will be sure to do that doing forward.
I think the reason that it totally fails on an IOS-XE 17.6.5 is that the yang model is even more broken on that as I dont event get to sending the filter rpc to the device it just stops with this:
2023-07-07 11:27:02,749 - ydk - INFO - Path where models are to be downloaded: /home/eslau/.ydk/10.12.35.56
2023-07-07 11:27:02,755 - ydk - INFO - Connected to 10.12.35.56 on port 830 using ssh with timeout of -1
2023-07-07 11:27:10,920 - ydk - INFO - Executing 'get' RPC on [Cisco-IOS-XE-native:native] from running
2023-07-07 11:27:10,969 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Invalid keyword "+".
2023-07-07 11:27:10,970 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-native" parsing failed.
2023-07-07 11:27:11,026 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Invalid keyword "+".
2023-07-07 11:27:11,027 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-native" parsing failed.
2023-07-07 11:27:11,043 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Importing "Cisco-IOS-XE-native" module into "Cisco-IOS-XE-cts-routing-deviation" failed.
2023-07-07 11:27:11,043 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-cts-routing-deviation" parsing failed.
2023-07-07 11:27:11,088 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Invalid keyword "+".
2023-07-07 11:27:11,089 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-native" parsing failed.
2023-07-07 11:27:11,108 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Importing "Cisco-IOS-XE-native" module into "Cisco-IOS-XE-dialer-deviation" failed.
2023-07-07 11:27:11,108 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-dialer-deviation" parsing failed.
that indicates that the Cisco-IOS-XE-native.yang model is totally broken in the box and that YDK is actually using the downloaded models and not the models that is part of the python lib/package. Can you confirm that?
IF that is the case, is there any way that I can change the models? Eg. an option to say, dont use the downloaded models, but use these I have locally (where I have fixed the faults) I found this: https://ciscodevnet.github.io/ydk-gen/guides/validation.html to remove validation, but it does not seem to be available for the NetconfService only the CrudService
I think I am stuck, if I cannot use the models I have locally (that I fixed) and the models on the device is broken, ydk-gen is basically broken.. I mean YDK might be fine, but if it depends on working models, then it sorta is.. Do you agree on this? Or am I missing something.
Esben
07-07-2023 03:21 PM
Hi Esben
You definitely can use your model repository instead of the downloaded from device, but then you are not guarantee that the RPC payload will be treated well by device or response will be properly decoded.
To define your own model repository create directory, put all your YANG models to that directory, in the script define the repository as class: repo = Repository(<repo-dir>). Then use the repo in the NetconfServiceProvider or RestcofServiceProvider initialization. You can find multiple examples of Repository use in the unit tests, for example here or here. It is a bit more complicated, if you are not connecting to device and use the model API just for the codec operations.
You also can modify YANG models in the temporary repository located in the ~/.ydk/your-netconf-server-ip directory, which contains downloaded from the device files. The YDK will not overwrite your modified files! You also can use that repo to build the model API bundle for your particular task. That will assure that your model bundle is 100% compatible with the device.
To simplify model API building it is recommended to include into the bundle just limited number of YANG models that are needed for your specific tasks. This way the build process become more manageable and you can modify the YANG models in your repository to pass the pyang checks. For example, the ydk-gen GitHub repository includes build of XE bundle for specific test purposes; please check this profile and 16.9.3 models.
07-12-2023 11:31 AM
Hi Yan,
I tried to do a symlink like this to the "fixed" yang models.
eslau@N503476:~/.ydk$ ls -l 10.12.35.56
lrwxrwxrwx 1 eslau eslau 59 Jul 11 16:59 10.12.35.56 -> /home/eslau/repos-wsl/yang-utils/yang/vendor/cisco/xe/1761/
but I found that it downloaded some specific versions of the models.. I then tried to symlink those to the repo versions
eslau@N503476:~/.ydk/10.12.35.56$ ls -l *@*
lrwxrwxrwx 1 eslau eslau 28 Jul 11 18:03 Cisco-IOS-XE-interfaces@2019-11-01.yang -> Cisco-IOS-XE-interfaces.yang
lrwxrwxrwx 1 eslau eslau 28 Jul 12 17:20 Cisco-IOS-XE-interfaces@2021-07-01.yang -> Cisco-IOS-XE-interfaces.yang
lrwxrwxrwx 1 eslau eslau 20 Jul 11 18:03 Cisco-IOS-XE-ip@2019-11-01.yang -> Cisco-IOS-XE-ip.yang
lrwxrwxrwx 1 eslau eslau 20 Jul 12 17:20 Cisco-IOS-XE-ip@2021-07-01.yang -> Cisco-IOS-XE-ip.yang
lrwxrwxrwx 1 eslau eslau 22 Jul 11 18:03 Cisco-IOS-XE-ipv6@2019-11-01.yang -> Cisco-IOS-XE-ipv6.yang
lrwxrwxrwx 1 eslau eslau 22 Jul 12 17:20 Cisco-IOS-XE-ipv6@2021-07-01.yang -> Cisco-IOS-XE-ipv6.yang
lrwxrwxrwx 1 eslau eslau 25 Jul 11 18:03 Cisco-IOS-XE-license@2019-11-01.yang -> Cisco-IOS-XE-license.yang
lrwxrwxrwx 1 eslau eslau 25 Jul 12 17:20 Cisco-IOS-XE-license@2021-07-01.yang -> Cisco-IOS-XE-license.yang
lrwxrwxrwx 1 eslau eslau 22 Jul 11 18:03 Cisco-IOS-XE-line@2019-11-01.yang -> Cisco-IOS-XE-line.yang
lrwxrwxrwx 1 eslau eslau 22 Jul 12 17:20 Cisco-IOS-XE-line@2021-07-01.yang -> Cisco-IOS-XE-line.yang
lrwxrwxrwx 1 eslau eslau 25 Jul 11 18:03 Cisco-IOS-XE-logging@2019-11-01.yang -> Cisco-IOS-XE-logging.yang
lrwxrwxrwx 1 eslau eslau 25 Jul 12 17:20 Cisco-IOS-XE-logging@2021-07-01.yang -> Cisco-IOS-XE-logging.yang
lrwxrwxrwx 1 eslau eslau 24 Jul 11 18:07 Cisco-IOS-XE-native@2019-11-01.yang -> Cisco-IOS-XE-native.yang
lrwxrwxrwx 1 eslau eslau 24 Jul 11 18:03 Cisco-IOS-XE-parser@2019-11-01.yang -> Cisco-IOS-XE-parser.yang
lrwxrwxrwx 1 eslau eslau 24 Jul 12 17:20 Cisco-IOS-XE-parser@2021-07-01.yang -> Cisco-IOS-XE-parser.yang
but it does not really like that.. even yanglint is complaining about some version issues..
eslau@N503476:~/.ydk/10.12.35.56$ yanglint Cisco-IOS-XE-native.yang
libyang warn: File name "Cisco-IOS-XE-parser@2021-07-01.yang" does not match module revision "2019-07-01".
libyang warn: File name "Cisco-IOS-XE-license@2021-07-01.yang" does not match module revision "2020-11-01".
libyang warn: File name "Cisco-IOS-XE-logging@2021-07-01.yang" does not match module revision "2020-11-01".
Anyways, the error I am getting is actually quite strange, I cannot make yanglint give the same output here is a sample output from ydk
2023-07-12 17:21:02,195 - ydk - INFO - Path where models are to be downloaded: /home/eslau/.ydk/10.12.35.56
2023-07-12 17:21:02,203 - ydk - INFO - Connected to 10.12.35.56 on port 830 using ssh with timeout of -1
2023-07-12 17:21:05,958 - ydk - INFO - Executing 'get' RPC on [Cisco-IOS-XE-native:native] from running
2023-07-12 17:21:06,017 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Invalid keyword "+".
2023-07-12 17:21:06,018 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-native" parsing failed.
2023-07-12 17:21:06,072 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Invalid keyword "+".
2023-07-12 17:21:06,072 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-native" parsing failed.
2023-07-12 17:21:06,087 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Importing "Cisco-IOS-XE-native" module into "Cisco-IOS-XE-cts-routing-deviation" failed.
2023-07-12 17:21:06,087 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-cts-routing-deviation" parsing failed.
2023-07-12 17:21:06,127 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Invalid keyword "+".
2023-07-12 17:21:06,127 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-native" parsing failed.
2023-07-12 17:21:06,142 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Importing "Cisco-IOS-XE-native" module into "Cisco-IOS-XE-dialer-deviation" failed.
2023-07-12 17:21:06,142 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-dialer-deviation" parsing failed.
2023-07-12 17:21:06,182 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Invalid keyword "+".
2023-07-12 17:21:06,183 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-native" parsing failed.
2023-07-12 17:21:06,197 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Importing "Cisco-IOS-XE-native" module into "Cisco-IOS-XE-ethernet-deviation" failed.
2023-07-12 17:21:06,197 - ydk - ERROR - Data is invalid according to the yang model. Libyang error: Module "Cisco-IOS-XE-ethernet-deviation" parsing failed.
here is a few of the models that it complains about but checking with yanglint
eslau@N503476:~/.ydk/10.12.35.56$ yanglint Cisco-IOS-XE-native.yang
libyang warn: File name "Cisco-IOS-XE-parser@2021-07-01.yang" does not match module revision "2019-07-01".
libyang warn: File name "Cisco-IOS-XE-license@2021-07-01.yang" does not match module revision "2020-11-01".
libyang warn: File name "Cisco-IOS-XE-logging@2021-07-01.yang" does not match module revision "2020-11-01".
eslau@N503476:~/.ydk/10.12.35.56$
eslau@N503476:~/.ydk/10.12.35.56$
eslau@N503476:~/.ydk/10.12.35.56$ yanglint Cisco-IOS-XE-cts-routing-deviation.yang
libyang warn: File name "Cisco-IOS-XE-native@2019-11-01.yang" does not match module revision "2021-07-01".
libyang warn: File name "Cisco-IOS-XE-native@2019-11-01.yang" does not match module revision "2021-07-01".
libyang warn: File name "Cisco-IOS-XE-parser@2021-07-01.yang" does not match module revision "2019-07-01".
libyang warn: File name "Cisco-IOS-XE-license@2021-07-01.yang" does not match module revision "2020-11-01".
libyang warn: File name "Cisco-IOS-XE-logging@2021-07-01.yang" does not match module revision "2020-11-01".
eslau@N503476:~/.ydk/10.12.35.56$
eslau@N503476:~/.ydk/10.12.35.56$ yanglint Cisco-IOS-XE-dialer-deviation.yang
libyang warn: File name "Cisco-IOS-XE-native@2019-11-01.yang" does not match module revision "2021-07-01".
libyang warn: File name "Cisco-IOS-XE-native@2019-11-01.yang" does not match module revision "2021-07-01".
libyang warn: File name "Cisco-IOS-XE-parser@2021-07-01.yang" does not match module revision "2019-07-01".
libyang warn: File name "Cisco-IOS-XE-license@2021-07-01.yang" does not match module revision "2020-11-01".
libyang warn: File name "Cisco-IOS-XE-logging@2021-07-01.yang" does not match module revision "2020-11-01".
Could it be a bug in YDK? I have attached the entire debug log in case you want to give it a look.
I guess there are no really any other way around it, than downloading the yang models from the switches and routers, but with more than 2000 devices there are going to be different ios-xe versions that for sure that will use different revisions even though it is in the same major/minor (eg. 17.6.xx) train. Im also slightly afraid that different hardware models will also use different revisions eg. we use 9500, 9500 High performance, 9200L, 9300L & 9300 switches they should be the same but are they? We try and keep devices on the same versions, but with so many devices, hardware and featuresets its quite hard.
Do you see any other way that actually downloading the yang models from each of the ios-xe version. Then we painstakingly go over them one-by-one fixing the errors and then maintaining a script that will check the ios-xe version of the device before connecting and creating the necessary symlinks to make it work?
Again thanks for your feedback.. Im still new to this, so getting some guidance from you is awesome!
Esben
07-13-2023 08:54 AM
Regarding symlinks. I would suggest start using your defined repository instead of temporary directory. Make sure you copy to that directory all files needed for your task (you can get the list from temporary repo after running your script without specifying it). You must have all files with compatible revisions, otherwise you are going to get the above errors.
To support devices with multiple software versions. If you rely on downloaded from devices models, then you don't need to worry, because each device will create its own temporary repo and download the YANG models from the devices. Otherwise you have to create your own repositories for each device. The last is the only way if you are facing YANG model errors and fixing them manually.
07-13-2023 08:39 AM
Adding to your question "Now the million $ questions is.. When YDK validates the data coming back from the device.. does it then use the .yang models as part of the python ydk-models-cisco-ios-xe package or does it actually download the models from the device and uses the models that the device are providing?
The short answer is YES. But as I explained below, you have a capability to build and use your own repository as long as the received response from the device fits the YANG model(s) in your repository. If needed YANG module is not found in your repository the YDK will attempt to download it from the device. This feature works only with Netconf; for other protocols you must specify the repository.
Yan
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