When blades on a chassis-based system may also ship as a standalone products, it is often desirable to have identical software on the blade regardless of whether the blade sits in a chassis or is shipped as a standalone product.
For the above use case, ConfD supports a master/subagent concept similar to that found in the AgentX protocol for SNMP. The idea is that there is one master agent running on the management controller of the chassis. It terminates the northbound interfaces such as NETCONF and CLI. The master agent is connected to a set of subagents which provide instrumentation of the subsystems.
A subagent has its own data store, separate from the master agent. A subagent is an essential part of the system, i.e. if the master agent cannot talk to the subagent, this is handled as a data provider failure.
In ConfD, NETCONF is used as master-to-subagent protocol. The subagent only has to provide a NETCONF interface. The master agent can provide any northbound interfaces, for example CLI and Web UI only. This is accomplished in ConfD by separating the northbound agents from the data providers. Somewhat simplified, the subagents are viewed and handled as any other data provider.
More details on the master/subagent feature of ConfD can be found in the “Subagents and Proxies” chapter of the ConfD User Guide.
An example of running the 1-2-3-start-query-model as the master and 6_c-config as the subagent, which can be found in the examples.confd folder, is being described here.
For the the 1-2-3-start-query-model master agent project, you will need to compile the yang model for the 6_c-config subagent called hst.yang as a subagent model as follows:
$confdc -c --subagent / -o hst.fxs hst.yang
Please note that you will need to remove the two callpoint annotation statements from hst.yang here as the external data provider implementation is hidden from the master agent and is only known to the subagent.
The next step is to modify the confd.conf file for the master agent to add information about the subagent as follows:
<subagents>
<enabled>true</enabled>
<subagent>
<name>A</name>
<enabled>true</enabled>
<tcp>
<ip>127.0.0.1</ip>
<port>2033</port>
<confdAuth>
<user>admin</user>
<group>admin</group>
</confdAuth>
</tcp>
<mount xmlns:sa="http://tail-f.com/ns/example/hst">
<path>/</path>
<node>sa:hosts</node>
</mount>
</subagent>
</subagents>
The above configuration assumes that both the master and subagent will be running on the same machine which requires the subagent’s default port numbers to be changed. All port number changes in this example assume that those ports aren’t being used on your system.
For the 6_c-config subagent project, you will need to make the following modifications to its confd.conf file.
The confdIpcAddress block will need to be added to allow the default CONFD IPC port to be changed:
<confdIpcAddress>
<ip>127.0.0.1</ip>
<port>5010</port>
</confdIpcAddress>
The default SSH & TCP port numbers for NETCONF will need to be modified from their default of 2022 and 2023 to 2032 and 2033 respectively as follows:
<transport>
<ssh>
<enabled>true</enabled>
<ip>0.0.0.0</ip>
<port>2032</port>
</ssh>
<tcp>
<enabled>true</enabled>
<ip>127.0.0.1</ip>
<port>2033</port>
</tcp>
</transport>
The default port number for the subagent’s CLI’s SSH port will be modified from its default of 2024 to 2034 as follows:
<cli>
<ssh>
<port>2034</port>
</ssh>
</cli>
Lastly for the subagent project, the source code for hosts.c will need to have its CONFD_PORT parameter changed to 5010 to match the above confd.conf file setting as follows:
addr.sin_port = htons(5010);
Given the above changes to both the master and subagent projects, you will now be able to run both projects on the same OS simultaneously.
After running “netconf-console cmd-set-subnet1.xml” to add some configuration data to the master agent and “default” on the local shell of the subagent to add some configuration data to the subagent, an interactive netconf-console session on the master agent will result in the following output:
$ netconf-console -i
* Enter a NETCONF operation, end with an empty line
<get>
<filter xmlns="http://tail-f.com/ns/example/hst">
<hosts/>
</filter>
</get>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<data>
<hosts xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://tail-f.com/ns/example/hst">
<host>
<name>buzz</name>
<domain>tail-f.com</domain>
<defgw>192.168.1.1</defgw>
<interfaces>
<interface>
<name>eth0</name>
<ip>192.168.1.61</ip>
<mask>255.255.255.0</mask>
<enabled>true</enabled>
</interface>
<interface>
<name>eth1</name>
<ip>10.77.1.44</ip>
<mask>255.255.0.0</mask>
<enabled>false</enabled>
</interface>
<interface>
<name>lo</name>
<ip>127.0.0.1</ip>
<mask>255.0.0.0</mask>
<enabled>true</enabled>
</interface>
</interfaces>
</host>
<host>
<name>earth</name>
<domain>tailf-com</domain>
<defgw>192.168.1.1</defgw>
<interfaces>
<interface>
<name>bge0</name>
<ip>192.168.1.61</ip>
<mask>255.255.255.0</mask>
<enabled>true</enabled>
</interface>
<interface>
<name>lo0</name>
<ip>127.0.0.1</ip>
<mask>255.0.0.0</mask>
<enabled>true</enabled>
</interface>
</interfaces>
</host>
</hosts>
</data>
</rpc-reply>
* Enter a NETCONF operation, end with an empty line
<get>
<filter xmlns="http://tail-f.com/ns/example/dhcpd">
<dhcp/>
</filter>
</get>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
<data>
<dhcp xmlns="http://tail-f.com/ns/example/dhcpd">
<SubNets>
<subNet>
<net>192.168.128.0</net>
<mask>255.255.255.0</mask>
<range>
<lowAddr>192.168.128.60</lowAddr>
<hiAddr>192.168.128.89</hiAddr>
</range>
</subNet>
</SubNets>
</dhcp>
</data>
</rpc-reply>