- Are there different versions of ConfD?
- What is the main difference between ConfD Basic and Premium?
- Where can I download ConfD Basic?
- Is ConfD Basic support available?
- Where is the ConfD User Community Forum?
- Is ConfD training available?
- Where may I obtain additional information and who may I contact with any questions I may have?
- Core Engine
- Architectural highlights?
- What is a data-model?
- Is ConfD only useful for NETCONF/YANG agents?
- How are data-models defined?
- What are the main architectural modules?
- Which northbound interfaces are supported?
- How do I integrate ConfD into my system?
Yes. The two versions are ConfD Basic and ConfD Premium.
ConfD Basic is free to use subject to the terms of the ConfD Basic License Agreement and allows you to include NETCONF when embedded into your product based on standardized terms and conditions. If you want to use any other interfaces (REST, CLI, JSON-RPC API (for Web UI) WEB, SNMP, REST) or want to modify the ConfD Basic license terms you will still need a commercial license for ConfD Premium.
You can download the product here: https://developer.cisco.com/site/confD/.
ConfD Basic is community supported via the ConfD User Community Forum. Additionally, a support agreement can be purchased for ConfD Basic.
You can access the user community here: http://discuss.tail-f.com/.
Yes. A series of free ConfD training videos is available online. You can watch the training videos here: http://www.tail-f.com/confd-training-videos/.
You may contact your local account manager or send your questions to email@example.com.
Linux (for production and development use), Mac OS X (for development use only)
- ConfD Premium: x86, PowerPC, ARM, and MIPS
- ConfD Basic: x86, PowerPC (32-bit only)
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.
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.
No. Many customers use ConfD for classical systems with CLI, SNMP and Web UI only. ConfD is data-model centric, not NETCONF centric.
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.
- 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.
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
- 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.
Without transactions network operators run into several operational problems:
- Stale configurations are left in the network as a result of a best-effort configuration
- Management applications and network engineers need to know in which order to perform configuration tasks
- Complex analysis scenarios weeks after a configuration event. For example, in many cases bad network performance is a result of incomplete/incorrect configurations.
See RFC 3535 for a discussion of operator requirements on transactions: http://tools.ietf.org/html/rfc3535
Additionally, transactions simplify and shorten the code development cycle as less code needs to be written. In particular, most error recovery code is unnecessary when transactions are used.
The requirement for transactions moves a burden from the network service provider to the device vendor. The ConfD Core Engine provides transaction services. ConfD accepts configuration changes in any order over the north-bound interfaces. Internally, the device vendor can define ordering dependencies so that the database subscribers get called in proper order.
ConfD has built-in support for several kinds of validation:
- Syntactic validation: The configuration data adheres to the YANG model types, ranges and structure. This is done automatically by ConfD with no need to write and test code.
- Integrity constraints: Any uniqueness constraints are not violated and no YANG leafref references are left dangling. This is done automatically by ConfD with no need to write and test code.
- Model constraints: YANG must or when statement expressions are not violated. This is a very powerful mechanism whereby it’s possible to instruct ConfD to compute an XPath expression that must always remain true, e.g. value X must be larger than the sum of all the numbers in the third column of list Y. This is done automatically by ConfD with no need to write and test code.
- Application validation logic: All applications that registered as validators approve the new configuration.
- Operator policies: Any constraints specified by the operator are not violated, e.g. operator requires that encryption is always enabled on this device. These policies are entered and ConfD automatically enforces them.
ConfD can automatically generate YANG modules from MIBs and vice versa. You would then manage these YANG modules as in the general ConfD development case.
If you have defined YANG modules and want ConfD to expose a SNMP interface, you can have ConfD generate the corresponding MIBs. (The mapping is an IETF standard).
In some cases, both the MIBs and YANG modules are given and do not correspond to the defined YANG-SMI mapping. For example, manually designed modules to optimize the YANG and MIB “views”. In this case, you can use annotations to the MIBs to map MIB objects to corresponding YANG definitions. When a pure data-model annotation is not enough you can add transformation code.