09-08-2017 08:35 AM
The RFC 8040 states that "The server lists each YANG module it supports using the "ietf-yang-library" YANG module defined in [RFC7895]. The server MUST implement the "ietf-yang-library" module,which MUST identify all of the YANG modules used by the server, in the "modules-state/module" list.
On IOS-XEv 16.5.1b (172.21.200.231), I unsuccessfully tried a GET through the RESTCONF API with the following resources:
Each time, I received a "HTTP Error 404: Not Found".
I know I can access this device through RESTCONF, for instance at "http://172.21.200.231/restconf/api/running/interfaces?deep" with which I successfully get a list of all interfaces.
Does that mean that this IOS-XEv does not implement the "ietf-yang-library" module, or that the URL is yet to be found?
On a broader scale, how can we derive the URIs from the YANG models a particular Cisco platform supports once we are able to list them?
10-10-2017 01:56 AM
Hi Jean,
This url - Getting To Know YDK ,may help to answer your question. Moving your question under Network Programmability community for visibility of more support engineers.
Thanks and Regards,
Geevarghese
10-10-2017 06:16 AM
If we list the modules with Netconf instead, we see that:
On NX-OSv 9k 7.0(3)I6(1)
# ssh -p 830 admin@172.21.100.18 -s netconf
User Access Verification
<?xml version="1.0" encoding="UTF-8"?>
<hello>
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
<capability>http://cisco.com/ns/yang/cisco-nx-os-device?revision=2017-05-16&module=cisco-nx-os-device&deviations=cisco-nx-os-device-deviations</capability>
<capability>http://openconfig.net/yang/bgp?revision=2016-06-06&module=openconfig-bgp&deviations=openconfig-bgp-deviations</capability>
<capability>http://openconfig.net/yang/bgp-multiprotocol?revision=2016-06-06&module=openconfig-bgp-multiprotocol&deviations=openconfig-bgp-multiprotocol-deviations</capability>
<capability>http://openconfig.net/yang/interfaces?revision=2016-05-26&module=openconfig-interfaces&deviations=openconfig-interfaces-deviations</capability>
<capability>http://openconfig.net/yang/interfaces/ip?revision=2016-05-26&module=openconfig-if-ip&deviations=openconfig-if-ip-deviations</capability>
<capability>http://openconfig.net/yang/local-routing?revision=2016-05-11&module=openconfig-local-routing&deviations=openconfig-local-routing-deviations</capability>
<capability>http://openconfig.net/yang/routing-policy?revision=2016-05-12&module=openconfig-routing-policy&deviations=openconfig-routing-policy-deviations</capability>
<capability>http://openconfig.net/yang/vlan?revision=2016-05-26&module=openconfig-vlan&deviations=openconfig-vlan-deviations</capability>
</capabilities>
<session-id>1849769676</session-id>
</hello>
10-10-2017 06:35 AM
As RESTCONF was fully standardized in January 2017 so many implementations are still based on "Drafts" of RESTCONF.
The first version of IOS XE that supports standard RESTCONF is 16.6.1 for routing platforms (CSR, ISR, ASR, etc). This query works against a 16.6.1 CSR (or IOS XEv). (Updated with your devices credentials of course
curl -X GET \
https://<IP>/restconf/data/ietf-yang-library:modules-state/ \
-H 'authorization: Basic dmFncmFudDp2YWdyYW50'
For the question on
"how can we derive the URIs from the YANG models a particular Cisco platform supports once we are able to list them?"
This is a URI construction key that I use to help show how a RESTCONF URL is created based on YANG models.
10-13-2017 08:03 AM
Thanks a lot for your detailed, clear & colourful answer.
However, I have a few comments.
All the following GET return a '404 not found' on IOS-XEv 16.5.1b:
On the other hand, I was able to retrieve some configuration/operational data with a different datastore keyword than the ones which you suggested: api
ietf-interfaces:interfaces:
interface:
- enabled: true
ietf-ip:ipv4:
address:
- ip: 172.21.200.231
netmask: 255.255.0.0
ietf-ip:ipv6: {}
name: GigabitEthernet1
type: iana-if-type:ethernetCsmacd
- enabled: true
ietf-ip:ipv4:
address:
- ip: 10.3.111.31
netmask: 255.255.255.0
ietf-ip:ipv6: {}
name: GigabitEthernet2
type: iana-if-type:ethernetCsmacd
...
ietf-interfaces:interfaces-state:
interface:
- admin-status: up
if-index: 0
last-change: '2017-10-13T12:53:32.000105+00:00'
name: GigabitEthernet1
oper-status: up
phys-address: 00:00:16:05:01:31
speed: 1024000000
statistics:
discontinuity-time: '2017-10-13T12:51:31.000811+00:00'
in-broadcast-pkts: 0
in-discards: 0
in-errors: 0
in-multicast-pkts: 1633
in-octets: 142780
in-unicast-pkts: 1853
in-unknown-protos: 0
out-broadcast-pkts: 0
out-discards: 0
out-errors: 0
out-multicast-pkts: 0
out-octets: 221172
out-unicast-pkts: 742
type: iana-if-type:ethernetCsmacd
- admin-status: up
if-index: 0
last-change: '2017-10-13T12:53:32.000201+00:00'
name: GigabitEthernet2
oper-status: up
phys-address: 00:00:16:05:01:32
speed: 1024000000
statistics:
discontinuity-time: '2017-10-13T12:51:31.000804+00:00'
in-broadcast-pkts: 0
in-discards: 0
in-errors: 0
in-multicast-pkts: 0
in-octets: 0
in-unicast-pkts: 0
in-unknown-protos: 0
out-broadcast-pkts: 0
out-discards: 0
out-errors: 0
out-multicast-pkts: 0
out-octets: 194310
out-unicast-pkts: 540
type: iana-if-type:ethernetCsmacd
...
As a summary:
Hence the questions:
10-13-2017 11:48 AM
Yes, the URIs above are for 16.6. This is RFC-8040 compliant. RESTCONF (in 16.6) only uses 443. RFC excerpt --> " The RESTCONF protocol MUST NOT be used over HTTP without using the TLS protocol."
10-10-2017 08:09 AM
You can use the following URIs depending on the implementation: (e.g. on ASR/CSR etc.)
# Following will print details on all the yang modules present in the device
Python requests package or any other utility e.g. (curl/postman etc.) can be used to send the request.
(notice "https" and not http with port 443 must be provided in URI)
1) GET URI: https://1.1.1.1:443/restconf/data?fields=ietf-yang-library:modules-state/module
# Following will help to print limited information on all the modules in the device
2) GET URI: https://1.1.1.1:443/restconf/data?fields=ietf-yang-library:modules-state/module(name;revision;schema;namespace)
3) GET URI: https://1.1.1.1:443/restconf/data/ietf-restconf-monitoring:restconf-state/capabilities
4) GET URI: https://1.1.1.1:443/restconf/data/ietf-netconf-monitoring:netconf-state/capabilities
Cheers,
Samir
10-13-2017 08:27 AM
(notice "https" and not http with port 443 must be provided in URI)
Why? (apart from the security point)
10-10-2017 08:11 AM
You can use the following URIs depending on the implementation: (e.g. on ASR/CSR etc.)
# Following will print details on all the yang modules present in the device
Python requests package or any other utility e.g. (curl/postman etc.) can be used to send the request.
(notice "https" and not http with port 443 must be provided in URI)
1) GET URI: https://1.1.1.1:443/restconf/data?fields=ietf-yang-library:modules-state/module
# Following will help to print limited information on all the modules in the device
2) GET URI: https://1.1.1.1:443/restconf/data?fields=ietf-yang-library:modules-state/module(name;revision;schema;namespace)
3) GET URI: https://1.1.1.1:443/restconf/data/ietf-restconf-monitoring:restconf-state/capabilities
4) GET URI: https://1.1.1.1:443/restconf/data/ietf-netconf-monitoring:netconf-state/capabilities
Cheers,
Samir
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: