cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
745
Views
2
Helpful
5
Replies

Unsupported YANG module tailf-netconf-inactive

sm000x
Level 1
Level 1

Hi:

I recently face a strange problem:
When I do a sync-from to a device, I got the following error
"unknown_element: for /rpc/get-config: Unsupported YANG module tailf-netconf-inactive"

The NSO version I am using is: NSO-5.7.3

Can anyone help please?

Thank you
sm000x

1 Accepted Solution

Accepted Solutions

huayyang
Cisco Employee
Cisco Employee

As you observed, it's the listing of the tailf-netconf-inactive module that triggered NSO to send <with-inactive>. Personally I don't think using module listing instead of capability advertisement is correct behavior, on both server and client sides.
But it's "more wrong" for the server to claim it supports this capability but later refuses to handle request using it, so I suggest you check with the vendor how to disable the listing of this module.

Since this is a Tail-F proprietary capability, I think the device is ConfD-based, so it's a matter of how to disable /confdConfig/enableAttributes and /confdConfig/enableInactive settings on the device.

View solution in original post

5 Replies 5

sm000x
Level 1
Level 1

Hi,

Here is more information.

I recently upgraded a device, after upgrade I found NSO send <get-config> with
<with-inactive> during sync-from then the device replied error saying: Unsupported YANG module tailf-netconf-inactive.

After further study the trace file,
I found that
(1) Before the OS upgrade, NSO sent the <get> to device for yang-library:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="1">
<get>
<filter>
<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
</filter>
</get>
</rpc>

And device replied with:
<import-only-module>
<name>tailf-netconf-inactive</name>
<revision/>
<namespace>http://tail-f.com/ns/netconf/inactive/1.0</namespace>
</import-only-module>

and
<module>
<name>tailf-netconf-inactive</name>
<revision/>
<schema>https://localhost:443/restconf/tailf/modules/tailf-netconf-inactive</schema>
<namespace>http://tail-f.com/ns/netconf/inactive/1.0</namespace>
<conformance-type>import</conformance-type>
</module>

NSO then sent get-config like the following:
<get-config>
<source>
<running/>
</source>
<filter>
<l3rm xmlns="http://affirmednetworks.com/ns/yang/l3rm"/>
<dpiAppProtoDefines xmlns="http://affirmednetworks.com/ns/yang/dpiAppProtoDefines"/>
<nrf-agent xmlns="http://affirmednetworks.com/ns/yang/cna/cna-nrf-agent"/>
<upfmonitor xmlns="http://affirmednetworks.com/ns/yang/cna-upfmonitor"/>
<routing xmlns="http://affirmednetworks.com/ns/yang/cna-routing"/>
<upf xmlns="http://affirmednetworks.com/ns/yang/cna-ppe"/>
<pfcp xmlns="http://affirmednetworks.com/ns/yang/cna-pfcp"/>
<no-pfcp xmlns="http://affirmednetworks.com/ns/yang/cna-pfcp"/>
<li-x1 xmlns="http://affirmednetworks.com/ns/yang/cna-li-x1"/>
<interface-manager xmlns="http://affirmednetworks.com/ns/yang/cna-interface-mgr"/>
<config-schema xmlns="http://affirmednetworks.com/ns/yang/cna-cfgmgr"/>
</filter>
</get-config>

(2) After OS was upgraded
NSO sent the <get> to device for yang-library:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="1">
<get>
<filter>
<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
</filter>
</get>
</rpc>

But now device replied with
<module> <<<<<<< Was <import-only-module> before upgrade
<name>tailf-netconf-inactive</name>
<namespace>http://tail-f.com/ns/netconf/inactive/1.0</namespace>
</module>

and
<module>
<name>tailf-netconf-inactive</name>
<revision/>
<schema>https://localhost:443/restconf/tailf/modules/tailf-netconf-inactive</schema>
<namespace>http://tail-f.com/ns/netconf/inactive/1.0</namespace>
<conformance-type>implement</conformance-type>
</module>

The <conformance-type> chnaged to implement now.

NSO now send <get-config> with <with-inactive>:
<get-config>
<source>
<running/>
</source>
<filter>
<dpiAppProtoDefines xmlns="http://affirmednetworks.com/ns/yang/dpiAppProtoDefines"/>
<upf xmlns="http://affirmednetworks.com/ns/yang/cna-ppe"/>
</filter>
<with-inactive xmlns="http://tail-f.com/ns/netconf/inactive/1.0"/>
</get-config>

Thus device replied error:
Unsupported YANG module tailf-netconf-inactive

I am not familiar with inactive, but it seems those differences between before and after upgrade trigger NSO send <with-inactive>.

My question is that is there a way to turn off NSO send <with-inactive>?

 

huayyang
Cisco Employee
Cisco Employee

Can you check the <hello> message from the device? Does it include "http://tail-f.com/ns/netconf/inactive/1.0"  ? If so, you need to tweak the device so that it doesn't advertise this capability in the server <hello>.

sm000x
Level 1
Level 1

Hi, Huayyang:

Thank you for the response.
I check the <hello> response from the device, it does not have
"http://tail-f.com/ns/netconf/inactive/1.0"

However, after receiving the <hello> response from the device, NSO sends the
following to device:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="1">
<get>
<filter>
<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
</filter>
</get>
</rpc>

The device then replies with:
<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set>
<name>common</name>
:
:
<module>
<name>tailf-netconf-inactive</name>
<namespace>http://tail-f.com/ns/netconf/inactive/1.0</namespace>
</module>
:
:

Does the above cause NSO to send <with-inactive ?

THX
sm000x

huayyang
Cisco Employee
Cisco Employee

As you observed, it's the listing of the tailf-netconf-inactive module that triggered NSO to send <with-inactive>. Personally I don't think using module listing instead of capability advertisement is correct behavior, on both server and client sides.
But it's "more wrong" for the server to claim it supports this capability but later refuses to handle request using it, so I suggest you check with the vendor how to disable the listing of this module.

Since this is a Tail-F proprietary capability, I think the device is ConfD-based, so it's a matter of how to disable /confdConfig/enableAttributes and /confdConfig/enableInactive settings on the device.

sm000x
Level 1
Level 1

Hi, Huayyang:

Thank you so very much for the help. I will discuss with the device vendor.

Really appreciate!!

sm000x