IOS-XE ipv6 YANG interfaces model failure

[IPBence]

Hi Community,

I am running in my lab 16.9 IOS-XE, and trying to work on automation to pull the interface data like IP addresses. And so far I was happily using the ietf-interfaces or the openconfig-interfaces yang models, they perfectly provided me the JSON structured data I needed.

But now as I am testing more and more use-cases, and added IPv6 addresses, the models, both of them fail. 

"error-message": "Bad return value",
"error-path": "/ietf-interfaces:interfaces/interface=GigabitEthernet3/ietf-ip:ipv6/address",
"error-tag": "operation-failed",
"error-type": "application"

Yang-SUITE also shows everything until it doesnt reach the interface with IPv6 address. Could anyone of you having a higher version IOS-XE test, if this is only a version error?

curl -X 'GET' 'https://[your-router-IP]:443/restconf/data/ietf-interfaces:interfaces' -H 'accept: application/yang-data+json' -k -u [yourusername]:[yourpassword]

Or do you have idea why does it fail?

Many thanks!

[M02@rt37]

Hello @IPBence,

What is the router model on your lab ?

[IPBence]

Hello, csr1000v

[bigevilbeard · Accepted solution]

Check the version running, i saw this here --> https://community.cisco.com/t5/devnet-sandbox/ncclient-get-config-error-when-configure-ipv6-on-interface/td-p/4464007

[IPBence]

Dear Team,

Thanks, I can confirm its a SW version related issue, I went to the Cisco official sandboy with newest IOS-XE:

https://devnetsandbox.cisco.com/RM/Diagram/Index/7b4d4209-a17c-4bc3-9b38-f15184e53a94?diagramType=Topology

And then I created an IPv6 address on a loopavk interface, and requested the ietf-interfaces json, and it received just fine.

curl -X 'GET' 'https://sandbox-iosxe-latest-1.cisco.com:443/restconf/data/ietf-interfaces:interfaces' -H 'accept: application/yang-data+json' -k -u admin:C1sco12345

{
"name": "Loopback6",
 "description": "ipv6 ietf-interfaces-yang test",
 "type": "iana-if-type:softwareLoopback",
 "enabled": true,
 "ietf-ip:ipv4": {
},
"ietf-ip:ipv6": {
"address": [
{
"ip": "fd0e:2043:6075:a2cb::1",
"prefix-length": 100
}
]
}
},

Thanks!

Now I am just wandering why the ietf and openconifg models doesnt contain the vrf attribute, while the native model does, but thats the topic for a different thread I guess

[bigevilbeard]

To my understanding, the VRF attribute is a feature that is specific to certain vendors and platforms, and may not be applicable or relevant to all device. In some cases the IETF and OpenConfig models may not include a VRF attribute by default, as they are designed to provide a generic representation of network configurations. From what i have seen though some vendors have chosen to include the VRF attribute in their implementations of the IETF or OpenConfig YANG models, either as an extension or as a vendor-specific attribute.

The native model, may include features and attributes that are unique to that system, including the VRF attribute. This reflects the fact that the native model is optimized for the specific capabilities and requirements of that vendor's devices, and may not be directly interoperable with other vendors or platforms without additional customization or translation.

Hope this helps.