cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6159
Views
18
Helpful
8
Replies
Highlighted

How to list all YANG modules used by the RESTCONF server on IOS-XE/NX-OS/IOS-XR devices

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?

  • IOS-XE
  • NX-OS
  • IOS-XR
8 REPLIES 8
Highlighted
Cisco Employee

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

Highlighted

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>

Highlighted
Cisco Employee

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.  Screen Shot 2017-10-10 at 9.34.40 AM.png

Screen Shot 2017-10-10 at 9.34.45 AM.png

Highlighted

@Harold Preston III

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:

  • I am unable to access the data with your constructs on IOS-XE 16.5.1 nor on NX-OS 9k 7.0(3)I6(1)
  • I am able to access the data with a completely different URI with a different data store keyword on IOS-XE 16.5.1

Hence the questions:

  1. Does that mean that your generic URIs only apply to IOS-XE 16.6.1+?
  2. What about other OS platforms such as NX-OS, IOS-XR, ASA? Should we be able to use your generic URI with those too?
Highlighted

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."

Highlighted
Beginner

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

Highlighted

(notice "https" and not http with port 443 must be provided in URI)

Why? (apart from the security point)

Highlighted
Beginner

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

This widget could not be displayed.