using ISIS get oper samples, if the router isis is configured for TE getting traceback:
$ ./nc-read-xr-clns-isis-oper-22-ydk.py ssh://cisco:email@example.com:830
/usr/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py:141: FutureWarning: CTR mode needs counter parameter, not IV
self._cipher = factory.new(key, *args, **kwargs)
Traceback (most recent call last):
File "./nc-read-xr-clns-isis-oper-22-ydk.py", line 146, in <module>
isis = crud.read(provider, isis)
File "/usr/local/lib/python2.7/dist-packages/ydk/services/crud_service.py", line 152, in read
return provider.decode(payload, read_filter)
File "/usr/local/lib/python2.7/dist-packages/ydk/providers/netconf_provider.py", line 91, in decode
return self.sp_instance.decode(payload, read_filter)
File "/usr/local/lib/python2.7/dist-packages/ydk/providers/_provider_plugin.py", line 132, in decode
XmlDecoder._bind_to_object(payload, entity, self._get_capabilities())
File "/usr/local/lib/python2.7/dist-packages/ydk/providers/_decoder.py", line 73, in _bind_to_object
ydk.errors.YPYModelError: Value 0 already in leaf-list: te_ext_admin_sub
This is similar to the issue seen in this thread: Please see that thread for potential ways to handle this.
The bug ID tracking this is CSCvd74932 and it should be fixed in the upcoming 6.3.1 release of XR.
Note that YDK is doing the right thing here (detecting duplicates in leaf lists). Some of these YDK scripts have help us identify issues in the NETCONF/YANG implementation in XR as you can see in this case.