YangModels / yang

YANG modules from standards organizations such as the IETF, The IEEE, The Metro Ethernet Forum, open source such as Open Daylight or vendor specific modules
1.5k stars 1.19k forks source link

Cisco-IOS-XE-dhcp-oper doesn’t work as intended on Catalyst 8000v #1528

Open jastorino82 opened 8 months ago

jastorino82 commented 8 months ago

Hello,

I've been struggling trying to figure out how to use the RESTCONF IOS XE API against a Cat 8000v running 17.8.1 code. Problem is, a bunch of calls work fine, and I've used them successfully, but then others seem to be really half baked and don't return the data I expect or don’t work at all.

For example, this router runs DHCPv6 server which is working fine, and I want to be able to pull the DHCPv6 binding table. Digging around, it sure seems like the proper model would be Cisco-IOS-XE-dhcp-oper.yang, specifically dhcp-oper-data/dhcpv6-binding-vrf-oper

When I run the show command "show ipv6 dhcp binding" on the CLI it shows the binding table properly, but if I issue a GET to /restconf/data/Cisco-IOS-XE-dhcp-oper:dhcp-oper-data/dhcpv6-binding-vrf-oper/default I just get a 200 OK with this bizarre output back. Nothing fancy going on here, just a default vrf. It's almost like the API endpoint here is just half baked or doesn't really work. I would expect it to return to me JSON with my binding table!

I have also tried with yangsuite. The endpoints show up and I can make the same calls with the tool, but get the same results.

Is it normal that certain operational API calls just are not yet fully implemented or something? What am I missing

I also tried on 17.13.1 with both NETCONF and RESTCONF and get nothing and 404 not found for the same call.

{

"Cisco-IOS-XE-dhcp-oper:dhcpv6-binding-vrf-oper": [

{

"v6-vrf": "default",

"client-addr": "200::",

"duid": "��/.R",

"ppp-username": "",

"interface": "",

"iaid": 1622421294,

"t1": 1384054784,

"t2": 123096623,

"preferred-lifetime": 4283760640,

"valid-lifetime": 0,

"expiring-time": "1970-01-01T00:00:00+00:00"

}

]

}

einarnn commented 8 months ago

This is a vendor issue. I will see if i can forward this to an appropriate team in Cisco.

If you have a service contract with Cisco I strongly recommend you raise a case with the TAC as this should be addressed as a defect. On 27 Dec 2023 at 15:57 +0000, Joe Astorino @.***>, wrote:

Hello, I've been struggling trying to figure out how to use the RESTCONF IOS XE API against a Cat 8000v running 17.8.1 code. Problem is, a bunch of calls work fine, and I've used them successfully, but then others seem to be really half baked and don't return the data I expect or don’t work at all. For example, this router runs DHCPv6 server which is working fine, and I want to be able to pull the DHCPv6 binding table. Digging around, it sure seems like the proper model would be Cisco-IOS-XE-dhcp-oper.yang, specifically dhcp-oper-data/dhcpv6-binding-vrf-oper When I run the show command "show ipv6 dhcp binding" on the CLI it shows the binding table properly, but if I issue a GET to /restconf/data/Cisco-IOS-XE-dhcp-oper:dhcp-oper-data/dhcpv6-binding-vrf-oper/default I just get a 200 OK with this bizarre output back. Nothing fancy going on here, just a default vrf. It's almost like the API endpoint here is just half baked or doesn't really work. I would expect it to return to me JSON with my binding table! I have also tried with yangsuite. The endpoints show up and I can make the same calls with the tool, but get the same results. Is it normal that certain operational API calls just are not yet fully implemented or something? What am I missing I also tried on 17.13.1 with both NETCONF and RESTCONF and get nothing and 404 not found for the same call. { "Cisco-IOS-XE-dhcp-oper:dhcpv6-binding-vrf-oper": [ { "v6-vrf": "default", "client-addr": "200::", "duid": "��/.R�", "ppp-username": "", "interface": "", "iaid": 1622421294, "t1": 1384054784, "t2": 123096623, "preferred-lifetime": 4283760640, "valid-lifetime": 0, "expiring-time": "1970-01-01T00:00:00+00:00" } ] } — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>