09-15-2023 08:56 AM
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
Solved! Go to Solution.
10-05-2023 06:31 AM
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.
09-25-2023 01:31 PM
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>?
10-04-2023 07:09 AM
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>.
10-04-2023 07:32 AM
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
10-05-2023 06:31 AM
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.
10-05-2023 06:40 AM
Hi, Huayyang:
Thank you so very much for the help. I will discuss with the device vendor.
Really appreciate!!
sm000x
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide