FAQ

Are there different versions of ConfD?

Yes. The two versions are ConfD Basic and ConfD Premium.

What is the main difference between ConfD Basic and 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 (RESTCONF, CLI, JSON-RPC API (for Web UI), or SNMP) or want to modify the ConfD Basic license terms you will need a commercial license for ConfD Premium.

Where can I download ConfD Basic?

You can download the product here: https://developer.cisco.com/site/confD/.

Is support for ConfD Basic available?

ConfD Basic is community supported via the ConfD User Community Forum.

Where is the ConfD User Community Forum?

You can access the user community here: http://discuss.tail-f.com/.

Is ConfD training available?

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/.

Where may I obtain additional information and who may I contact with any questions I may have?

You may contact your local account manager or send your questions to info@tail-f.com.

What are the dates for end of maintenance and end of support of ConfD releases?

You can find the definitions of end of maintenance and end of support as well as the schedule here: https://www.tail-f.com/confd-eos-eom/.

What is the schedule for upcoming ConfD release?

You can find the ConfD release schedule here: https://www.tail-f.com/confd-release-schedule/.

Which OSes does ConfD run on?

Linux (for production and development use), Mac OS X (for development use only)

Which CPUs does ConfD run on?

• ConfD Premium: x86, PowerPC, ARM, and MIPS
• ConfD Basic: x86

Is ConfD source code available?

No

Architectural highlights?

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. While ConfD is the world’s leading implementation of NETCONF and YANG, it also provides support for RESTCONF, CLI, Web API, and SNMP.

How are data-models defined?

Data-models are defined in YANG (RFC7950) irrespective of northbound interfaces like RESTCONF, 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.
• RESTCONF: 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?

1. You model your management data and administrative actions in YANG.
2. For configuration data:
   1. 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.
3. For operational data:
   1. 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.
   2. Some operational data might be calculated periodically. Applications can store this kind of data in the CDB database.
4. For administrative actions:
   1. You register callback functions which will be invoked when the action is requested.

Why are transactions important?

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.

How does ConfD help implementing transactions?

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.

How can ConfD validate the configuration data?

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.

How do I manage standardized or predefined MIBs?

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.

Can ConfD generate MIBs from the YANG data-model?

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).

What if I want to define the YANG modules and MIB modules separately?

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.