Network device configuration management software simplifies software, increases robustness
Many engineering professionals might intuitively point to the Simple Network Management Protocol (SNMP) as a solution for performing network device configuration management. After all, isn’t configuration just an extension of managing the device? Well, not really. While SNMP can manage configuration state, it is not widely used for configuration management due to protocol shortcomings. For example, during device configuration it’s important to be able to robustly recover and/or rollback to a known good configuration if things fail in some way. This issue, among others, demands a solution tailored for network device configuration that is scalable and reliable.
In this month’s Software Corner column we’ll explore NETCONF, an Internet Engineering Task Force (IETF) standard that defines all the details regarding robust and simple network device configuration. We’ll also hear from Hakan Millroth, CEO of Tail-f Systems and a leading expert in NETCONF. I recently got the opportunity to talk with him about the history behind network configuration management, NETCONF, and the Tail-f Systems implementation of the NETCONF standard.
Network device configuration history
I asked Hakan for some history on network device configuration. Hakan said that the seeds of NETCONF were spread in 2001 when the community realized it was using SNMP for remote network management but not device configuration. Telecom equipment providers traditionally handled device configuration with scripting language to generate configuration scripts targeting the device’s Command Line Interface (CLI). Often scaling to thousands of lines of scripting commands talking to thousands of nodes within the network, this kind of configuration management implementation can make the entire software infrastructure quite fragile. If a software upgrade is done on a network device, typically the configuration scripts will also break due to CLI or parameter differences between product revisions. This makes upgrading software upgrade risky and is one of the main reasons why network operators are averse to software upgrades within their network deployments.
Hakan mentions that this has been a problem within the community for quite a long time. Many large network equipment vendors like Ericsson, Juniper, and Cisco are very motivated to standardize on a simple, low-risk configuration management methodology and have a better customer usage model. A number of large companies may have many products with a variety of configuration management scripting systems, making updates and upgrades a complex, high-risk effort. So another important goal of NETCONF is cross-platform configuration management to greatly reduce risk and complexity.
More on the NETCONF standard
The NETCONF protocol is defined in IETF Request for Comments (RFC) 4741, published in 2006. This RFC defines the base protocol that is tailored specifically for basic configuration operation of network devices.
RFC4741 states that the NETCONF protocol defines commands and processing by which a network device can be managed, configuration data retrieved, and configuration data uploaded and manipulated. The standard defines the application programming interface as well as the connectivity requirements for NETCONF.
Figure 1 shows the four NETCONF layers. In general, the protocol is specified to run over any connection-oriented transport, with the SSH protocol as a mandatory protocol and Simple Object Access Protocol (SOAP), Blocks Extensible Exchange Protocol framework (BEEP), and Transport Layer Security (TLS) defined but optional. Framing for the connection comes from the RPC layer, with the operations layer defining base operations including get-config and edit-config to manage the configuration information data. The content layer is the configuration information itself.
Network device information comes in one of two forms – configuration data and state data. Configuration data is defined as writeable data that transforms a system from its initial default state to its current state. State data is the additional data on a system that is not configuration data. This information includes things like read-only status information and collected statistics.
Hakan mentions that the industry is now in Phase Two, where details behind NETCONF are being rounded out. The NETCONF community is currently working on a data modeling language for NETCONF much like the SMI grammar used to write SNMP Management Interface Bases (MIBs). Hierarchical data models allow an entire network’s worth of devices to be configured. The devices can be modeled, common configuration information used across devices, and new configuration capabilities can be detected and initialized properly.
One of the big differences between NETCONF and SNMP is how the protocol itself works with large chunks of configuration data, whereas SNMP uses a simple “peek and poke” method to change the value of single parameters at a time. NETCONF provides primitive operations where all or a selected part of the configuration can be loaded and downloaded on a single operation on an embedded box.
One key piece to NETCONF is allowing configuration to occur in a fail-safe manner. NETCONF takes into account how the processing works if the network management system fails at the worst possible moment. Another tough situation to handle is when some number of boxes successfully loaded the configuration, but other boxes don’t load correctly. NETCONF can define properties that allow the system to rollback everything to a known-state configuration. It allows administrators to implement transactions – atomic change operations that synchronize, validate, and commit device configuration within an entire network deployment.
A NETCONF pioneer
Tail-f Systems, with roots in network management middleware and configuration management software for network and equipment vendors, has been a pioneer of NETCONF. Thanks to an ecosystem of standards-based chassis, blades, and operating systems it has become viable to make device configuration functions a commercial product.
The company’s ConfD product resides on the network element. It manages the configuration data store and implements the NETCONF standard on the network device side. Figure 2 shows an architecture diagram of the ConfD product.
Tail-f also provides an operational support systems component called ConfM that configuration management subsystem companies can plug in. The subsystem then uses NETCONF to configure the network devices. ConfM is a set of Java classes and an SDK to allow people to easily integrate NETCONF into their operational and management systems.
ConfD implements a unified management system that accepts configuration commands via a NETCONF agent, CLIs, a web interface, or an SNMP agent. ConfD manages the data store and implements the functionality needed for a management station to view capabilities, change configuration, validate that configuration, and commit the configuration. Applications then access the configuration information through the ConfD product.
Configuration information isn’t limited to isolated applications and may also extend through the high availability middleware and operating system. Therefore, ConfD needs to integrate and interoperate with these standard software components. Telecom equipment manufacturers want their COTS software stacks – hardware interface layer, high availability software, and operating system – to integrate easily. Virtualization layer software, for example, hypervisors, and sometimes protocol stacks like VoIP signaling and IP routing stacks all have a configuration element to them. What’s critical is the integration between the actual transfer of the device configuration information (using NETCONF) and the software initialization using these configuration parameters. Tail-f Systems provides the client- and server-side implementation of the NETCONF standard. It also works with partner companies to preintegrate the Tail-f Systems solution with the configuration elements of other software packages, making integration easier for the customer.
Putting it all together
Companies tend to incorporate ConfD when they start developing a new product. The key factor here is that they have the opportunity to implement the latest standard with a new standards-based product. But compatibility with previous generations of their product is also an important consideration. A typical scenario might include adding the ConfM to their management station software. At this point, the company is on its way to implementing NETCONF product-wide since the ConfM product models the configuration information for the user and implements the mechanisms for transfer and committing configuration information the way NETCONF specifies. But legacy products that get configuration information through the scripts previously discussed still need to be incorporated into this new configuration management environment. So, updating legacy products with NETCONF capability is the next challenge. Hakan said he recommends a migration strategy to standardize on NETCONF at Management Interface and using a proxy translator on the network device to translate the NETCONF commands to their proprietary configuration method through the CLI or traditional input interface. Tail-f Systems has templates for this and can participate in the migration strategy by providing engineering services if desired. Although Hakan mentions the engineering services component of its business is quite small regarding migration, many companies have found that there is less integration work to upgrade to NETCONF capability than they originally thought. By adopting a strategy like this, companies can begin to deploy new NETCONF based network products while still handling configuration for their legacy products.
The NETCONF standard eliminates significant complexity and deployment risk by providing a standards-based solution designed specifically for providing large-scale configuration management capabilities for management stations and network devices alike. If you’ve not heard about NETCONF, I urge you to read through the NETCONF RFC and contact Tail-f Systems for access to a variety of technical white papers on NETCONF and the Tail-f Systems implementation.
For more information, contact Curt by e-mail at firstname.lastname@example.org.