ConfD radically reduces the time and resources needed to develop network management applications, helping developers meet critical market deadlines.
Traditional agents are protocol centric and are limited in ability to extend to new features. In ConfD, key management interfaces are automatically rendered from a single data model. Since all management interfaces share one set of common instrumentation functions engineers can avoid the tedious recoding efforts required by legacy stovepipe architectures.
In the Stove Pipe approach, management interfaces connect directly to the Managed Objects (MOs).
The Tail-f approach separates the management interfaces to the back-end system.
ConfD overview (22:50 minutes):
Faster Development Time
- Auto-render management interfaces from single data model
- All management interfaces share one set of common instrumentation functions avoiding maintenance overhead associated with stovepipe architectures
- Extensive schema validation
- Modular architecture with well-defined APIs between all components
- Mature software that is proven from development through deployment
- Integrated database
- TailPack libraries of source code pre-integrating protocols, middleware, and operating systems
- Experienced support team and professional services available to balance resources
- Fully compliant to support network-wide service and application programmability
- Industry-leading implementation of NETCONF protocol and YANG modeling language
Complete On-Device Management Solution
- SNMP, Cisco (IOS-XR and IOS) and Juniper-style CLI, NETCONF, REST and Web interfaces
- Integrated database for configuration and operational data
- Fully meets carrier and enterprise class requirements
Support for Key Industry Standards
- Full NETCONF support (RFC 6241) including support for transactions, validations, confirmed commits, rollbacks, event notifications, partial locking, and XPath filtering
- Support for YANG data modeling language (RFC 6020)
- SNMP Agent support for v1, v2c, and v3 including USM and VACM
- Two-phase commit transaction protocol
- Session management
- Rollback management
- Data validation
- 1:N data replication of configuration and operational data
- Ability to perform in-service data model upgrades without restarting the ConfD application
- Detailed auditing and event logging
- Role-based access control
- Authentication with external sources (e.g. RADIUS, LDAP) through PAM
- Support for symmetric multicore processing enabling ConfD to distribute processing loads over multiple cores to maximize performance
- Configuration database optimized to allow very efficient operations on tree structured data
Flexible and Extensible
- Management Agent API allows development of additional interfaces
- The Database API provides support for external data stores
- Web UI application environment using modern libraries and tools
- ConfD implemented as a lean daemon with few library dependencies and efficient use of RAM, and disk footprint
ConfD Kick Start Guide
This 35+ page guide provides a practical understanding of the ConfD on-device management framework, ConfD’s architectural principles and how it fits in with the surrounding world.
Simplifying the Management of Virtualized Network Elements in Telecom
Tail-f provides an abstraction layer between operations support systems (OSSs) and ISV software-based network elements running on Intel Xeon processors.
ConfD Product Overview
Description of ConfD’s key components and their benefits.
Tail-f ConfD, Metaswitch N-BASE and MetaCLI Integration Tailpack Datasheet
Tail-f ConfD in combination with Metaswitch N-BASE drastically reduces the time and resources needed to develop management interfaces on top of L2/L3 Protocol Stacks.
Automating Network and Service Conﬁguration Using NETCONF and YANG
A presentation on NETCONF and YANG for Service Automation presented at LISA Usenix 2011.
ConfD Core Engine
The ConfD Core Engine is a shared backplane that connects configuration and operational data on the device to all management interfaces through a transaction-oriented API.
A fully featured CLI is automatically rendered from the data model used to describe configuration data.
ConfD NETCONF implements the NETCONF RFC 6241 and supporting specifications.
ConfD Web UI
The ConfD Web UI enables very rapid development of modern, dynamic, and graphical network management applications using state of the art tools.
ConfD SNMP Agent is a fully featured SNMP agent providing a northbound SNMP v1, v2, and v3 interface.
ConfD Quagga Demo – Part 1
ConfD Quagga Demo – Part 2
ConfD Quagga Demo – Part 3
- 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 my system to ConfD?
- How do I manage standardized or predefined MIBs?
- Can ConfD generate MIBs from the YANG data-model?
- What if I want to define the YANG modules and MIB modules separately?
Unix/Linux flavors: FreeBSD, Linux, Mac OS X, NetBSD, QNX, Solaris.
- Disc: Runtime environment <10 MB, development environment add 40 MB documentation
- Memory: Varies depending on operating system, CPU and how many ConfD components are used. Typically about 10MB RAM plus the size of the data in the in-memory database. The database might consume a few MB RAM for a configuration of a few thousand settings, but may range into the gigabytes for really large configurations.
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 APIs and UIs. As a developer, you add functionality to ConfD by writing data-models. The models are loaded into ConfD and the database schema and northbound APIs/UIs 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, e.g., in a chassis environment. 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 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, for example, CLI specific knowledge into the data-model 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:
- CLIs: Juniper-style, Cisco IOS-style, Cisco XR-style
- 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.
- SNMP: SNMPv1, SNMPv2c, SNMPv3
- REST: XML and JSON encoding
- 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.
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.
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.