Using Subagents (User Guide: Chapter 26)

I’m interested in exploring Subagents, and trying to start by following the example in 26.2.

I’ve build simple “service”, “smtp”, and “equipment” yang models, and I can include the “equipment” as a sub-agent mounted in “/” of the master node, but if I try to mount one of my “smtp” agent as shown in the example, I get this from confd:

    <CRIT> 6-Apr-2017::13:51:10.941 confd confd[10441]: - Internal error: Startup failed; probably due to incorrect installation
    "Internal error: Startup failed; probably due to incorrect installation\n"

I’m guessing that there is some way I need to reference the “smtp-config” sub-agent node in the service.yang other than a strait “uses smtp:smtp-config”?

Is there any more documentation on how to build the yang model the “master agent”?

I managed to get a yang module with the right container hierarchy, that my sub-agent shows up in confd (at least confd_cli).

But I’ve noticed that the confd doesn’t advertise the submodules that aren’t mounted at “/”. Which means that netconf clients do’nt know about the “submodule” heirarchy. I guess the proper way is to make a “smtp types” module that the smtp module and my “master” agent can both include? Is there a better way?

I think I’m going to have to give up on sub-agents for now. I like the idea, but it seems like there is no way to get netconf/yang clients to properly understand what confd has mounted where, and the client’s can’t understand the resulting model confd is representing.

It looksl ike eventually something like this may become “standard” (I see draft-clemm-netmod-mount is at version 6 is still plodding along?). It looks like with yang 1.1, we might be able to a standard “subagent” type schema-mount working?

Is ConfD planning to go that direction?

When you use the subagent feature, the YANG module to be used by the NETCONF clients should be the single integrated YANG module being exposed through the Master agent that you need to manually put together integrating the subagent’s YANG structure as part of the master YANG module. The subagents are considered internal implementation detail and are not visible from the NETCONF clients.

waitai, Thanks for pushing me in the right direction. I finally got it to mostly work. I had been working already with separate “compiled for confd” and “publish to client” yang models, but I had missed how to configure the netconf hello “capabilities” part.

In case anyone else stumbles trying this like I did, the secret is to get confd to advertise all the modules you need clients to be aware of by hard-coding them in the confd conf:

/confdConfig/netconf/capabilities/capability (xs:anyURI)
       capability is a parameter can be given multiple times. It specifies a URI string which the NETCONF agent will report as a capability in the hello message sent to the client.

If a module is “mounted” into the namespace using subagents, confd doesn’t advertise that module on it’s own. It will list all it’s “top level” modules, including subagents mounted at /. But for subagents mounted not at /, setting it manually in confd.conf allows the clients to know it needs that module(s).

I haven’t been able to get confd to list that module in netconf-state/schemas yet, but at least if I install that module at the client, I can use it. But I want the module to be available in netconf-state/schemas, and get-schema RPC so I don’t have to force hand-installation on any netconf client that wants to interact with the server.

Is there a similar way to the confdCofnig/netconf/capabilities/capability config to force confd to expose modules that it things are “internal” sub-agent modules?

a.

One option is to configure ConfD to allow the superset YANG module to be in a single file to be returned from the get-schema call. This will allow the NETCONF client to see the entire YANG module, including the ones supported by both the master and subagents, being supported by ConfD.

What you do is to compile and build your projects using the separate YANG modules for the master and subagents. You then place the superset YANG module in ConfD’s loadpath in order to allow that file to be returned from the get-schema call.

You can refer to How to configure get-schema call for more information on how get-schema works in ConfD.

waitai, I did try a single schema “service.yang” which included the complete sub-agent portion directly in it.

But the XML returned by confd/netconf explicitly has another namesapce in it, which means the client needs to know that namespace (and thus how/where to retrieve it from):

<config xmlns="http://tail-f.com/ns/config/1.0">
  <system xmlns="http://example.com/service/3.3">
    <services>
      <service>
        <name>smtp01</name>
        <type>smtp</type>
        <smtp-config xmlns="http://example.com/smtp/1.0">        <===================
          <name>smtp01</name>
          <enabled>true</enabled>
          <server>
            <ip>1.2.3.4</ip>
            <port>25</port>
          </server>
        </smtp-config>
      </service>
    </services>
  </system>
</config>

I’ve not found a way to get the xmlns reference out of the sub-agent piece. And I’ve not found a way to make confd/netconf give out a “smtp.yang” at all, even if the files are in the load path, and requested directly:

[aidan@confd 10:59:36 master]$ netconf-console-tcp --get-schema=smtp 
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <rpc-error>
    <error-type>application</error-type>
    <error-tag>invalid-value</error-tag>
    <error-severity>error</error-severity>
    <error-path xmlns:ncm="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    /nc:rpc/ncm:get-schema
  </error-path>
    <error-message xml:lang="en">/get-schema/identifier: inconsistent value</error-message>
    <error-info>
      <bad-element>get-schema</bad-element>
    </error-info>
  </rpc-error>
</rpc-reply>

I can get any other yang module referenced in any part, just not a module that has the NS that the subagent data came from.