Browsing NX-OS 9k installed yang models with RESTconf

[jean-christophe-manciot]

NX-OS 9kv 7.0(3)I6(1)

Hello @einarnn
I'm having a hard time figuring out the URI(s) which must be used to attain the openconfig resources supported by this device.
Using yang-explorer, I can confirm that it does support openconfig:

urn:ietf:params:netconf:base:1.0
urn:ietf:params:netconf:base:1.1
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:confirmed-commit:1.1
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:writable-running:1.0

http://cisco.com/ns/yang/cisco-nx-os-device?revision=2017-05-16&module=cisco-nx-os-device&deviations=cisco-nx-os-device-deviations
http://openconfig.net/yang/bgp-multiprotocol?revision=2016-06-06&module=openconfig-bgp-multiprotocol&deviations=openconfig-bgp-multiprotocol-deviations
http://openconfig.net/yang/bgp?revision=2016-06-06&module=openconfig-bgp&deviations=openconfig-bgp-deviations
http://openconfig.net/yang/interfaces/ip?revision=2016-05-26&module=openconfig-if-ip&deviations=openconfig-if-ip-deviations
http://openconfig.net/yang/interfaces?revision=2016-05-26&module=openconfig-interfaces&deviations=openconfig-interfaces-deviations
http://openconfig.net/yang/local-routing?revision=2016-05-11&module=openconfig-local-routing&deviations=openconfig-local-routing-deviations
http://openconfig.net/yang/routing-policy?revision=2016-05-12&module=openconfig-routing-policy&deviations=openconfig-routing-policy-deviations
http://openconfig.net/yang/vlan?revision=2016-05-26&module=openconfig-vlan&deviations=openconfig-vlan-deviations

I can also GET all vendor specific data returned by http://ip_address/restconf/data/Cisco-NX-OS-device:System?content=config: Cisco-NX-OS-device:System.yml

But what URI should I use to GET the openconfig data?
I tried all sorts of URIs, including

• http://ip_address/restconf/data/Cisco-NX-OS-device:Openconfig?content=config
• http://ip_address/restconf/data/Openconfig?content=config

Each time, I receive a 400: Bad Request.

Generally speaking, is there a method to automatically discover the URI of any Yang resource on any Cisco platform?

• NX-OS
• IOS-XE
• IOS-XR
• ASA

[einarnn]

Jean-Christophe,

Apologies for the long delay in getting back to you. Unfortunately, I was on vacation when this query arrived, so getting back to it now.

The general form for a URL for a query against the openconfig-interfaces model for config content should look like:

https://ip_address/restconf/data/openconfig-interfaces:interfaces?content=config

The YANG module name is used to scope the top-level node interfaces in the openconfig-interfaces model.

I can confirm that the two examples you show above would, indeed, generate 400: Bad request.

With respect to host discovery, we try to support what you see defined in Section 3.1 of RFC 8040. For example, on a CSR1Kv running IOS-XE 16.6.1, I can do a query like:

GET /.well-known/host-meta?depth=unbounded HTTP/1.1
Authorization: Basic dmFncmFudDp2YWdyYW50
Host: **********
Connection: close
User-Agent: Paw/3.1.5 (Macintosh; OS X/10.12.6) GCDHTTPRequest

...and get back:

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 12 Jul 2017 23:13:49 GMT
Content-Type: application/xrd+xml
Content-Length: 107
Connection: close
Vary: Accept-Encoding

<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
    <Link rel='restconf' href='/restconf'/>
</XRD>

I can then dispatch a query such as:

GET /restconf?depth=unbounded HTTP/1.1
Authorization: Basic dmFncmFudDp2YWdyYW50
Accept: application/yang-data+json
Host: **********
Connection: close
User-Agent: Paw/3.1.5 (Macintosh; OS X/10.12.6) GCDHTTPRequest

And see:

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 12 Jul 2017 23:14:48 GMT
Content-Type: application/yang-data+json
Transfer-Encoding: chunked
Connection: close
Cache-Control: private, no-cache, must-revalidate, proxy-revalidate
Vary: Accept-Encoding
Pragma: no-cache

{"restconf":{"data":{},"operations":{},"yang-library-version":"2016-06-21"}}

This tells me that the device, under /restconf, supports the data and operations subtrees, along with supporting the IETF YANG Library model. To discover more details of model support, I then need to use the IETF YANG Library together data. For example, if I wanted to get a list of the modules the device claims to support, I might use the query:

GET /restconf/data/ietf-yang-library:modules-state/module?content=nonconfig&fields=name HTTP/1.1
Authorization: Basic dmFncmFudDp2YWdyYW50
Accept: application/yang-data+json
Host: **********
Connection: close
User-Agent: Paw/3.1.5 (Macintosh; OS X/10.12.6) GCDHTTPRequest

...which would give me a response something like (again, from a CSR1Kv as I don't have a NX-OS device to hand):

(PS partial response only)

HTTP/1.1 200 OK
Server: nginx
Content-Type: application/yang-data+json
Pragma: no-cache
Transfer-Encoding: Identity
Date: Wed, 12 Jul 2017 23:24:05 GMT
Cache-Control: private, no-cache, must-revalidate, proxy-revalidate
Connection: close

{
  "ietf-yang-library:module": [
    {
      "name": "ATM-FORUM-TC-MIB"
    },
    {
      "name": "ATM-MIB"
    },
    {
      "name": "ATM-TC-MIB"
    },
    {
      "name": "BGP4-MIB"
    },
    [...elided...]

Hope this helps. Please feel free to get back to me with any further queries.

Cheers,

Einar

[jean-christophe-manciot]

Thanks a lot for your clear & detailed answer @einarnn

• Some ?options_keywords work on IOS-XE 16.5.1 but not on NX-OS 7.x; for instance, ?deep. Is there a way to list the supported ?options_keywords and their values on each platform?
• also I find it quite strange that IOS-XR platforms do not support RESTconf when IOS-XE & NX-OS do. Is there a reason why they consider gRPC more important than the former?

[einarnn]

Jean-Christophe,

After talking to the NX-OS team, only the "content" option is supported. We are looking at what the roadmap may be for the others, namely:

           4.8.2. The "depth" Query Parameter ........................54
           4.8.3. The "fields" Query Parameter .......................55
           4.8.4. The "filter" Query Parameter .......................56
           4.8.5. The "insert" Query Parameter .......................57
           4.8.6. The "point" Query Parameter ........................57
           4.8.7. The "start-time" Query Parameter ...................58
           4.8.8. The "stop-time" Query Parameter ....................58
           4.8.9. The "with-defaults" Query Parameter ................59

IIRC, the start-time and stop-time options apply to RFC5277, which is not currently supported on NX-OS.

I'm afraid at this time I don't have a timescale for when we will have a public roadmap. Are there any of the above URL options that are particularly interesting to you for your use cases?

Cheers,

Einar

[jean-christophe-manciot]

@einarnn
The depth and fields options are definitely needed.
I don't have enough Yang/RESTconf experience to prioritize the importance of the other query parameters.

[jean-christophe-manciot]

@einarnn

On IOS-XE 16.6.1, GET /.well-known/host-meta?depth=unbounded is successful.

However, on NX-OS 7.0(3)I7(6) & 9.2(3)
GET /.well-known/host-meta and GET /.well-known/host-meta?depth=unboundedboth lead to:
HTTP Error 404: Not Found

This is a fundamental issue as this feature must be supported, according to RFC 6415.

Is /.well-known/host-meta replaced by another URI or is it just not implemented?

[einarnn]

@jean-christophe-manciot, I’ve passed this issue on to the NX-OS engineering team responsible for RESTCONF.