Change in <conformance-type> suddenly

NETCONF
1

We have a use-case where a netconf client sends the <get> to confd:
<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>httptail-f.com/ns/netconf/inactive/1.0</namespace>
</import-only-module>

and
<module>
<name>tailf-netconf-inactive</name>
<revision/>
<schema>httpslocalhost:443/restconf/tailf/modules/tailf-netconf-inactive(httpslocalhost/restconf/tailf/modules/tailf-netconf-inactive)</schema>
<namespace>httptail-f.com/ns/netconf/inactive/1.0</namespace>
<conformance-type>import</conformance-type>
</module>

After that <get-config> request was sent and confd replied correctly.

But, a confD re-installation (and no change whatsoever), caused a change in behaviour. Suddenly the <get> is now replied with

<module> -------> Was <import-only-module> before upgrade
<name>tailf-netconf-inactive</name>
<namespace>httptail-f.com/ns/netconf/inactive/1.0</namespace>
</module>

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

The <conformance-type> changed to implement now.

The netconf client now send <get-config> with <with-inactive>:
<get-config>
<source>
<running/>
</source>
<with-inactive xmlns=“httptail-f.com/ns/netconf/inactive/1.0”/>
</get-config>

Thus confd replied error:
Unsupported YANG module tailf-netconf-inactive, which we know how to correct is by setting the <enableInactive> flag in confD, but the whole issue is how come suddenly confD started replying with <conformance-type> as implement which causes the issue?

2

@cohult - Can you please look into this and guide on what could be the issue or what logs/action would help? Thanks… The confd version is 7.3.2

3

If your confd.conf set <enableInactive>false</enableInactive> the tailf-netconf-inactive module will be an <import-only-module>
If your confd.conf set <enableInactive>true</enableInactive> the tailf-netconf-inactive module will be a <module>

With <enableInactive>true</enableInactive> in your confd.conf, try:

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
    <with-inactive xmlns="http://tail-f.com/ns/netconf/inactive/1.0"/>
  </get-config>
</rpc>
4

hi @cohult - Thanks for the reply.

I know about the <enableInactive> flag in confD. We actually used that to solve the “Unsupported YANG module tailf-netconf-inactive” error.

But my question is something else. Let me explain.

  1. The confd.conf does not have the <enableInactive> flag set - there is NO entry for this, so it’s false by default.
  2. In the deployment, everything was running fine since as you explained, confd was replying with <import-only-module> only.
  3. But suddenly after re-deployment, (no patch, no change), confD started replying with <module> to the requests. The <enableInactive> flag is still NOT set.
  4. So, we know that setting <enableInactive> to true would help mitigate the error, but why confD is suddenly replying with <module> is the question.
  5. Also, further upgrade of our service (which includes confd) resolve the issue as it went back to <import-module> and still <enableInactive> flag is NOT set.
  6. We have seen this on many sites that suddenly without touching the <enableInactive> flag, confD start replying with <module>, so maybe there is a race condition in code that causes this.
5

You would need to have <enableInactive>true</enableInactive> set in confd.conf for ConfD to reply with <module> for the tailf-netconf-inactive module.

With ConfD running, check your confdConfig/enableInactive setting using something like:

$ confd --debug-dump dump.bin
$ confd --show-debug-dump dump.bin > dump.txt
$ grep 'enableInactive' dump.txt
  <enableInactive>true</enableInactive>
enableInactive = true
6

Thanks @cohult - Just a quick check, wouldn’t a check of confd.conf enough? I think you are trying to get a dump of the cache to be more deterministic, correct?

7

In this case, since you observe something that goes against what you have in your confd.conf, instead of checking the confd.conf you believe is loaded by ConfD, you can check the setting ConfD is actually using.

1 Like