Netconf request based on YANG on Cisco-IOS-XE-native not returning all expected fields

[olmomezger]

Hi, 

I'm making a get request to the sandbox 

sandbox-iosxe-latest-1.cisco.com

with the following payload:

Sending:

#851
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:0357a54b-0c41-4a24-991a-6a238cba67a7"><nc:get>
    <nc:filter>
      <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
        <version/>
        <location>
          <civic-location>
            <identifier>
              <identifier/>
              <building/>
              <floor/>
              <landmark/>
              <name/>
              <number/>
            </identifier>
          </civic-location>
        </location>
        <hw-module>
          <sm/>
        </hw-module>
        <hostname/>
        <interface>
          <Ethernet>
            <name/>
            <description/>
            <mac-address/>
          </Ethernet>
        </interface>
      </native>
    </nc:filter>
  </nc:get>
</nc:rpc>

##

However, the response I'm getting contains only the version and the name. It does not contain all nested elements. 

Here is the response using YANGSuite:

<?xml version="1.0" ?>
<rpc-reply message-id="urn:uuid:0357a54b-0c41-4a24-991a-6a238cba67a7" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
      <version>17.3</version>
      <hostname>csr1000v-1</hostname>
    </native>
  </data>
</rpc-reply>

any idea why I'm not getting the missing information? 

[Alexander Stevenson]

Hi there,

Please have a look at these resources:

YANG Tools Knowledge Base

YANG Data Modelling and NETCONF - Cisco Live presentations slides

I also noticed the top-level of your YANG model contains 'nc:rpc' when every example I've been seeing uses 'rpc'.

Hope this helps!

[miott]

The nc: is valid.  "nc" is the prefix for the NETCONF namespace which is set in the same rpc tag:

xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"

[yusuf-baic]

Hello,

I am encountering a similar issue. Using Yang Suite, I send the following RPC:

Sending:

#343
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:2031c3d5-7fa8-4d41-b46b-870261be3f98">
  <nc:get>
    <nc:filter>
      <access-point-oper-data xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-wireless-access-point-oper">
        <ssid-counters/>
      </access-point-oper-data>
    </nc:filter>
  </nc:get>
</nc:rpc>

##

In response I receive an xml with no data:

<?xml version="1.0" ?>
<rpc-reply message-id="urn:uuid:2031c3d5-7fa8-4d41-b46b-870261be3f98" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data/>
</rpc-reply>

Other metrics in access-point-oper-data can be returned, such as ap-radio-neighbor and ap-name-mac-map, however ssid-counters returns nothing (as shown above). Any insight on how to address this issue?

[miott]

Not familiar with these statistics but what I usually do is make the query more general and then drill down.  For example, do a get on access-point-oper-data and see what it returns.  Try it a few times.  The ssid-counters may be a transient statistic.  If you are skeptical of what you get back, go to the device CLI and try the show command and see what ssid-counters returns.

[mgertsvo@cisco.com]

Greetings,

we had a similar inquiry about this same problem. CSCvy15288

Here is a response from the development organization:

"In order to have SSID stats being sent to receiver, bssid-stats should be enabled on the ap profile and disable stats traffic-distrbution first

no statistics traffic-distribution

ap profile default-ap-profile
bssid-stats bssid-stats-frequency 40
description "default ap profile"

All under the ap profile."

For further details please refer to:

http://cisco.com/c/en/us/td/docs/wireless/controller/9800/17-2/config-guide/b_wl_17_2_cg/bssid_counters.pdf

[miott]

Sorry for the long response time.  When I tried it on my device I also was confused why location and hw-module data was not being returned and it took some time to investigate.  Found out the location and hw-module coming back empty is a known issue and it is being addressed.

For the Ethernet interface query, do you actually have “Ethernet” interfaces on your device or are they some other type like “GigabitEthernet” or “TenGigabitEthernet”?

Best to shorten your query first, then drill down.  For example, do a get on native/interfaces and see what comes back.