ConfD
is a powerful solution for building on-device management systems for all kinds
of networking equipment. Tail-f Systems customers can choose among different
modules of ConfD depending on their requirements and use ConfD either to extend
an existing management system or to implement a new one.
Faster Development Time
Reduced Risk
Support for Key Industry Standards
Transaction Management
High Availability
Powerful Administration
Scalable Performance
Flexible and Extensible
ConfD
enables developers to build carrier-grade applications in less time and with
less risk and is the only product that renders all critical northbound
interfaces (NETCONF, CLI, SNMP and Web UI) from a single data model. Designed
with a robust infrastructure, ConfD includes transaction management, high
availability, security, and role-based access control.
·
SNMP, Cisco (IOSXR and IOS) and
Juniper-style CLI, NETCONF, and Web interfaces
·
Integrated database for configuration
and operational data
·
Fully meets carrier and enterprise
class requirements
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
Reduced Risk
·
Mature software that is proven from
development through deployment
·
Integrated database
·
TailPack libraries of source code
pre-integrating protocols, middleware, and operating systems
·
Experience support team and
professional services available to balance resources
Support for Key Industry Standards
·
Full NETCONF support (RFCs 4741,
4742, and 5277) including support for transactions, validations, confirmed
commits, rollbacks, event notifications, partial locking, and XPath filtering
·
Support for YANG data modeling
language
·
SNMP Agent support for v1, v2c, and
v3 including USM and VACM
Transaction Management
·
Two-phase commit transaction protocol
·
Session management
·
Rollback management
·
Data validation
High Availability
·
1:N data replication
·
Ability to perform in-service data
model upgrades without restarting the ConfD application
Powerful Administration
·
Auditing and event logging
·
Role-based access control
·
Authentication over RADIUS and LDAP
·
Single system view through
centralized console
Scalable Performance
·
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 binary encoded XML data structures
Flexible and Extensible
·
Management API allows development of
additional interfaces
·
The Database API provides support for
external data stores
·
CLI with rich features for extensions
and customization
·
The Database API provides support for
external data stores
·
Web UI customizable with CSS and
XHTML templates
·
ConfD implemented as a lean daemon
with few library dependencies and efficient use of RAM, and disk footprint
NETCONF Overview
NETCONF is a protocol designed to install, manipulate, and delete the configuration of network devices. NETCONF operations are realized on top of a Remote Procedure Call (RPC) layer using an XML encoding and provides a basic set of operations to edit and query configuration on a network device.
NETCONF is a protocol designed to install, manipulate, and delete the configuration of network devices. NETCONF operations are realized on top of a Remote Procedure Call (RPC) layer using an XML encoding and provides a basic set of operations to edit and query configuration on a network device.
History
The NETCONF base protocol was officially published as a RFC 4741 NETCONF Configuration Protocol in late 2006. The IETF working group producing the standard also produced supporting RFCs for various transport mappings, including:
The NETCONF base protocol was officially published as a RFC 4741 NETCONF Configuration Protocol in late 2006. The IETF working group producing the standard also produced supporting RFCs for various transport mappings, including:
·
RFC 4742 Using
the NETCONF Configuration Protocol over Secure SHell (SSH)
·
RFC 4743 Using
NETCONF over the Simple Object Access Protocol
·
RFC 5539 NETCONF
over Transport Layer Security (TLS)
The above versions was updated in 2011 to become the
following:
·
RFC 6241 obsoletes
RFC 4741 with a small set of changes including a persist-id for
confirmed commits.
·
RFC 6242 obsoletes
RFC 4742 and introduces e.g. a new framing mechanism to address some potential
security issues with the initial design
Notable additions to the family of NETCONF RFCs produced by the
working group are:
·
RFC 5277 NETCONF
Event Notifications that describes an asynchronous notification
mechanism allowing clients to subscribe to named event streams
·
RFC 6243 With-defaults
Capability for NETCONF that describes an extension to the
NETCONF protocol that allows clients to identify how defaults are
processed by the server
Why NETCONF vs. Other Approaches
CLI scripting was the primary approach to making automated configuration changes to the network prior to NETCONF. CLI scripting has several limitations including lack of transaction management, no structured error management and ever changing structure and syntax of commands that makes scripts fragile and costly to maintain. These are all side-effects of the basic fact that CLIs are designed to be used by humans and not an API for programmatic access.
CLI scripting was the primary approach to making automated configuration changes to the network prior to NETCONF. CLI scripting has several limitations including lack of transaction management, no structured error management and ever changing structure and syntax of commands that makes scripts fragile and costly to maintain. These are all side-effects of the basic fact that CLIs are designed to be used by humans and not an API for programmatic access.
SNMP is another approach that could be used to write changes,
but, in practice, is mostly used for performance and monitoring applications.
Reasons for this include the lack of a defined discovery process that makes it
hard to find the correct MIB modules, limitations inherent in the use of the
UDP protocol, and the lack of useful standard security and commit mechanisms.
Key NETCONF Capabilities
The NETCONF protocol was designed to address the shortcomings of existing practices and protocols for configuration management. The background work preceding the design phase has been documented in RFC 3535 Overview of the 2002 IAB Network Management Workshop. The design goals from that work includes:
The NETCONF protocol was designed to address the shortcomings of existing practices and protocols for configuration management. The background work preceding the design phase has been documented in RFC 3535 Overview of the 2002 IAB Network Management Workshop. The design goals from that work includes:
·
Distinction between configuration and state data
·
Multiple configuration data stores (candidate, running, startup)
·
Configuration change transactions
·
Configuration testing and validation support
·
Selective data retrieval with filtering
·
Streaming and playback of event notifications
·
Extensible procedure call mechanism
NETCONF’s Role in Tail-f System’s
Product Family
Tail-f Systems offers the broadest family of NETCONF-enabled products and tools in the industry. Developers can build new on-device management applications with ConfD including a robust implementation of NETCONF. ConfM allows EMS/NMS providers to add a NETCONF agent. NCS leverages NETCONF as a key mechanism to manage device configuration.
Tail-f Systems offers the broadest family of NETCONF-enabled products and tools in the industry. Developers can build new on-device management applications with ConfD including a robust implementation of NETCONF. ConfM allows EMS/NMS providers to add a NETCONF agent. NCS leverages NETCONF as a key mechanism to manage device configuration.
Tail-f Systems’ implementations of NETCONF are mature and
thoroughly proven in production networks. Our participation and contribution to
the development of the standard ensures our customers benefit from a fully
future-proofed solution.
YANG Overview
YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol. YANG was published as an IETF standard (RFC 6020) in September, 2010. YANG relates to the content and operations layers in NETCONF.
YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol. YANG was published as an IETF standard (RFC 6020) in September, 2010. YANG relates to the content and operations layers in NETCONF.
The authors of YANG were involved in the development of the
next generation SNMP SMI and are very experienced in the IETF network
management arena. Modern network standards groups such as the Metro Ethernet
Forum are adopting YANG as a device configuration standard.
Why YANG vs. Other Modeling Languages
The rapid industry adoption of NETCONF made it a priority to define a data modeling language to complement NETCONF. Modeling languages such as SMI (SNMP), UML, XML Schema, and others already existed. However, none of these languages were specifically targeted to the needs of configuration management. They lacked critical capabilities like being easily read and understood by human implementers, and fell short in providing mechanisms to validate models of configuration data for semantics and syntax.
The rapid industry adoption of NETCONF made it a priority to define a data modeling language to complement NETCONF. Modeling languages such as SMI (SNMP), UML, XML Schema, and others already existed. However, none of these languages were specifically targeted to the needs of configuration management. They lacked critical capabilities like being easily read and understood by human implementers, and fell short in providing mechanisms to validate models of configuration data for semantics and syntax.
Key YANG Capabilities
·
Human readable, easy to learn representation
·
Hierarchical configuration data models
·
Reusable types and groupings (structured types)
·
Extensibility through augmentation mechanisms
·
Supports the definition of operations (RPCs)
·
Formal constraints for configuration validation
·
Data modularity through modules and submodules
·
Versioning rules and development support
YANG’s Role in Tail-f System’s Product
Family
Tail-f Systems was the first company to introduce 100% YANG compliant software applications and tools. Both ConfD and NCS thoroughly leverage the power of YANG to model device and service parameters. YANG allows Tail-f Systems customers to build more robust and resilient products in less time. Moreover, developers using YANG-enabled products have the peace of mind that they are using industry standard technology with an assured growth path.
Tail-f Systems was the first company to introduce 100% YANG compliant software applications and tools. Both ConfD and NCS thoroughly leverage the power of YANG to model device and service parameters. YANG allows Tail-f Systems customers to build more robust and resilient products in less time. Moreover, developers using YANG-enabled products have the peace of mind that they are using industry standard technology with an assured growth path.
----------------------------------------------------------
Traditionally, SNMP has been the
standard for remote management and a large body of work has emerged to support it. However, there
are several problems with SNMP that make it a less suitable candidate for some management tasks.
First, SNMP operates over UDP which is an unreliable datagram protocol. Second, UDP limits
the maximum message size so large configurations cannot be sent in a single datagram. Both of
these properties combine to make UDP unsuitable for writing configurations. Third, SNMP uses a
protocol-specific security mechanism rather than a standard method (such as SSH) which increases
administrator workload and complicates the network architecture. Finally, while some
vendors provide commit/rollback-like functionality, SNMP lacks a standard commit operation for
individual devices or groups of network elements. Therefore in practice, SNMP is rarely used for writing
configurations. The new IETF protocol for device management,
NETCONF offers an alternative to the previous device-specific means of interrogating a box from a CLI with an XML-based API. NETCONF can be inexpensively provided by devices and straightforwardly used by higher-level management tools. It thus provides a suitable base protocol for management servers.
NETCONF offers a number of advantages over other approaches to network management. Since
NETCONF is based on XML and XML Schema, it easily represents complex data, which are stored in XML-databases and manipulated with tools such as XSLT, XML style sheets and others. NETCONF provides a secure answer to network management as it is based on SSH which enables simple remote management.
NETCONF is extensible, future proof, and reasonably straightforward to implement for vendors, which reduces cost, price and time-to-market. NETCONF sessions begin with a capability discovery phase in which the device (or server) exposes its capabilities to the client, and the client discards unknown capabilities. New features can be defined locally, but are defined formally, with rigorous syntax and semantics. If the client detects unknown capabilities, it will not use them. Finally, NETCONF provides protocol mechanisms for locking configurations and manipulating configurations in bulk. By locking and working on multiple devices at once, a management system built on NETCONF can implement network-wide policies as logical management operations.
NETCONF also provides a candidate commit mechanism. After a configured interval, devices automatically revert to their original configuration, unless the change has been confirmed by a second, confirming commit. Administrators can use this capability to test configurations that may potentially degrade or disable connectivity. If such an error occurs, the confirming commit does not reach the misconfigured devices. After a timeout, the network automatically reverts back to the original working configuration.
Task: Install a new network element
Task: Simultaneously configure two devices
Task: Translate a device-independent configuration to become device-specific
Task: Troubleshoot multiple devices
ConfD usecases and Alternatives.
NETCONF, offers a powerful solution to
the problem of network management, as it satisfies all of the criteria
of an ideal management system.
What is NETCONF?
NETCONF is an XML-based protocol for automated configuration
management. NETCONF was formalized as RFCs 4741 through 4744 by the IETF in December of
2006. As a building block for device management automation, it provides the mechanisms for
installing, querying, manipulating and deleting the configurations of network devices. NETCONF is a way
for equipment vendors to outsource the management interface of network elements. NETCONF is
a way for service providers to optimize the administrative workflow by moving management
intelligence out of the device under management and by enabling this consolidation of management into
higher-level applications, such as the consolidation servers discussed previously.
NETCONF exposes a standardized RPC-style API based on XML. The XML
requests and responses are sent over a persistent, secure, authenticated transport
protocol, such as SSH. See Figure 1 below for examples of NETCONF layers.
Figure .
The use of encryption means that the
requests and responses are confidential and tamper-proof. In addition to a secure communication
system, NETCONF requires devices to track client identities and enforce permissions associated with
identities. This means that devices can be managed over an untrusted wide area network, a distinct
advantage compared to other approaches. Configuration over a WAN means that network management can
be centralized through consolidation of all management to a single site, and also decentralized,
as multiple sites can share device management work.
NETCONF offers an alternative to the previous device-specific means of interrogating a box from a CLI with an XML-based API. NETCONF can be inexpensively provided by devices and straightforwardly used by higher-level management tools. It thus provides a suitable base protocol for management servers.
NETCONF offers a number of advantages over other approaches to network management. Since
NETCONF is based on XML and XML Schema, it easily represents complex data, which are stored in XML-databases and manipulated with tools such as XSLT, XML style sheets and others. NETCONF provides a secure answer to network management as it is based on SSH which enables simple remote management.
NETCONF is extensible, future proof, and reasonably straightforward to implement for vendors, which reduces cost, price and time-to-market. NETCONF sessions begin with a capability discovery phase in which the device (or server) exposes its capabilities to the client, and the client discards unknown capabilities. New features can be defined locally, but are defined formally, with rigorous syntax and semantics. If the client detects unknown capabilities, it will not use them. Finally, NETCONF provides protocol mechanisms for locking configurations and manipulating configurations in bulk. By locking and working on multiple devices at once, a management system built on NETCONF can implement network-wide policies as logical management operations.
NETCONF also provides a candidate commit mechanism. After a configured interval, devices automatically revert to their original configuration, unless the change has been confirmed by a second, confirming commit. Administrators can use this capability to test configurations that may potentially degrade or disable connectivity. If such an error occurs, the confirming commit does not reach the misconfigured devices. After a timeout, the network automatically reverts back to the original working configuration.
Examples of NETCONF at Work
A management system can use NETCONF to script, automate or
routinely carry out some management tasks. A sampling of NETCONF implementations follows, in which the
individual NETCONF steps are defined.
Task: Install a new network element
1. Query the device to determine the model and software revision.
2. Generate or select an appropriate configuration at the management
server.
3. Deposit the concrete configuration document at URL uuu.
4. Ask the device to copy the configuration from uuu.
5. Perform device-specific adjustments as directed by the
management server.
6. Make the configuration permanent at the device.
Task: Simultaneously configure two devices
1. Lock device A, then device B.
2. Modify the configuration of A to refer to B, and the
configuration of B to refer to A as appropriate.
3. Commit new configurations on A and B.
4. Release locks on both configurations.
Task: Translate a device-independent configuration to become device-specific
1. On the management server, read the device-independent
configuration document.
2. Get the device-specific parameters.
3. Select and perform an XSLT transformation to generate a new XML
configuration document at URL uuu.
4. Copy the configuration from URL uuu to the device or devices,
or perform further transformations.
Task: Troubleshoot multiple devices
1. Lock the running configurations of the devices.
2. Read the configurations to the management server.
3. Unlock the device configurations.
4. Analyze the XML documents to determine problems, verify policy
compliance, archive the
network state, or similar.
Tailf
Systems
Tail-f Systems is the leading developer of XML-based network
management software for the providers of networking equipment and software. Customers using Tail-f
Systems’ technology radically reduce their time-to-market and benefit from carrier-grade
implementations of NETCONF, Web, CLI, and SNMP interfaces. Tail-f Systems is an active participant in the
NETCONF Working Group within the IETF. Tail-f’s ConfD software (see figure 2 below) provides a
complete solution to build on-device network management systems including a NETCONF management interface
that supports all base and optional capabilities of the NETCONF standard. Tail-f’s Instant
NETCONF Manager enables southbound NETCONF interfaces to be added to EMS/NMS systems. For
more information on Tail-f Systems, go to www.tail-f.com.
Conclusion
NETCONF allows network operators to automate the configuration of
their networks in a reliable and efficient fashion. NETCONF is being adopted in the
telecommunications industry to help reduce operating costs, in data centers to help reduce network outages,
and by the military to ensure continuous service and ironclad
security.
**ConfD by Tail-f (Cisco):**
ConfD by Tail-f (now a part of Cisco) is a software solution designed for network device management. It provides a framework for building programmable network devices by enabling the use of YANG models and standard protocols like NETCONF and RESTCONF. Here are some use cases for ConfD:
1. **Network Device Configuration:**
- ConfD is used to model and configure network devices based on YANG models. It allows network operators to define, modify, and retrieve configurations using standard protocols such as NETCONF or RESTCONF.
2. **Service Orchestration:**
- ConfD facilitates service orchestration by allowing the dynamic configuration of network devices based on service requirements. This is particularly useful in cloud and virtualized environments where services need to be provisioned and modified on-the-fly.
3. **Network Automation:**
- ConfD plays a crucial role in network automation by providing a programmable interface for managing network devices. It allows for automation of repetitive tasks, reducing the likelihood of errors and speeding up network management processes.
4. **Zero-Touch Provisioning:**
- Zero-Touch Provisioning (ZTP) is simplified with ConfD. New devices can be automatically provisioned and configured based on predefined YANG models, making the onboarding process more efficient.
5. **Software Defined Networking (SDN):**
- In SDN environments, ConfD supports programmable interfaces, allowing for dynamic and automated control of network devices. It is instrumental in achieving the goals of SDN, such as centralization of control and network programmability.
6. **Multi-Vendor Network Environments:**
- ConfD is designed to work with network devices from various vendors, providing a standardized way to manage and configure heterogeneous network environments. This is essential in large networks with diverse equipment.
7. **Network Telemetry:**
- ConfD supports the collection of network telemetry data by providing interfaces for monitoring and retrieving operational data from network devices. This is valuable for network monitoring and analytics.
8. **Security Policy Implementation:**
- ConfD allows the enforcement of security policies on network devices. Access control and permissions can be managed through the use of YANG models, ensuring that only authorized changes are made to device configurations.
**Alternatives to ConfD:**
1. **NETCONF and YANG with Other Tools:**
- Instead of using ConfD, network operators can directly use NETCONF and YANG with other tools and libraries that provide similar functionality.
2. **OpenDaylight (ODL):**
- OpenDaylight is an open-source SDN controller that includes support for NETCONF and YANG. It provides a framework for building SDN solutions and managing network devices.
3. **Ansible:**
- Ansible is an automation tool that supports network automation and configuration management. It can be used for managing network devices using various protocols, including NETCONF.
4. **NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support):**
- NAPALM is a Python library that allows network engineers to interact with network devices using a unified API. It supports multiple vendors and can be used for automation and configuration tasks.
5. **Junos XML API (JET):**
- For Juniper Networks devices, the Junos XML API (JET) provides similar capabilities for configuration and management. It allows programmable access to Junos OS devices.
The choice between ConfD and alternatives depends on factors such as specific use cases, vendor preferences, and the overall network architecture. Each solution has its strengths and may be more suitable for certain scenarios.
No comments:
Post a Comment