The main architectural idea behind ConfD is to have a running agent that can be easily extended with new functionality, in contrast to agents with stub generators. ConfD comes with an embedded configuration database and ready-to-go northbound interfaces. As a developer, you add functionality to ConfD by writing data-models. The models are loaded into ConfD and the database schema and northbound interfaces are rendered automatically. No stub implementations are needed for added data-models. Developers hook configuration changes to the instrumentation by subscribing to change notifications from the database. This process makes it easy to apply agile methods and keep all northbound interfaces in sync.
ConfD runs in a client-server model. ConfD runs as a server daemon process and your instrumentation applications run as client processes. This makes ConfD very flexible in that ConfD and your applications can run on one CPU or be easily distributed across multiple CPUs or VMs. ConfD also provides support for multi-core CPUs.
What is a data-model?
A data-model defines the configuration (R-W) data, operational (R-O) data, and administrative actions that are accessible for a management system and maintained by the device. SNMP MIBs and YANG models are examples of ways to express data-models. In the ConfD context, the data-model is generic across all northbound interfaces. The rendering engine takes care of mapping to API specific syntaxes.
Is ConfD only useful for NETCONF/YANG agents?
No. Many customers use ConfD for classical systems with CLI, SNMP and Web UI only. ConfD is data-model centric, not NETCONF centric.
How are data-models defined?
Data-models are defined in YANG (RFC6020) irrespective of northbound interfaces like REST, CLI, SNMP, NETCONF etc. One unified data-model keeps all northbound interfaces consistent. There are Tail-f specific annotations which can be added into the data-model for things such as CLI specific knowledge or instrumentation hook locations.
What are the main architectural modules?
- CDB, built-in database: ConfD comes with an embedded light-weight efficient database for configuration and operational data. The schema is automatically rendered from the data-model. CDB provides replication support for High Availability environments.
- Core Engine: Transaction management, AAA, validation, session management, rollback management, schema upgrades/downgrades and more.
- Database API: API to hook configuration change notifications to the actual instrumentation. Access from applications to database contents.
- Data Provider API: Provides data for operational (read-only) attributes such as statistics, alarms, counters etc. Can also be used to access external databases.
- Management Agent API, MAAPI: General northbound API that can be used for any northbound operation, e.g., integration of new northbound management interface.
Which northbound interfaces are supported?
The following northbound interfaces are automatically rendered from the data-model:
- NETCONF: ConfD implements the full NETCONF specification including all optional parts, including support for network-wide transactions, multiple data stores and XPATH queries. It runs over SSH with content encoded in XML.
- REST: XML and JSON encoding
- CLIs: Juniper-style, Cisco IOS-style, Cisco XR-style
- JSON-RPC API: Web UI development. An example of how to develop an auto-rendering Web UI is included.
- SNMP: SNMPv1, SNMPv2c, SNMPv3
How do I integrate ConfD into my system?
- You model your management data and administrative actions in YANG.
- For configuration data:
- CDB will manage the persistence and replication. You register a subscription callback to the data in CDB which will be invoked whenever the data is changed. Your code maps this to the application. ConfD takes care of transactions, persistence etc.
- For operational data:
- In most cases the data is not stored in CDB. You register a callback function which will be invoked when the data is requested. That function retrieves the data from the application.
- Some operational data might be calculated periodically. Applications can store this kind of data in the CDB database.
- For administrative actions:
- You register callback functions which will be invoked when the action is requested.