Stork 2.0: Open Source DHCP Management Tool
ISC launched the Stork management application almost exactly five years ago, in November 2019, as an experimental tool.
Read post
Challenge: How to provision more devices, faster, without increasing errors?
Speed, Agility, Accuracy
Network administrators are under pressure to streamline provisioning of new devices so they can scale up, deploy new services, or otherwise make the network serve changing business needs faster than ever. The key to achieving this new speed and flexibility is centralized configuration control.
In Kea 1.5 (Download, Release notes) we have enabled a standardized provisioning interface (NETCONF), using a configuration database implemented with the Sysrepo configuration datastore. This is new provisioning model is particularly useful when coordination of changes to multiple network elements is required.
The Sysrepo engine is an open source (Apache license) datastore that uses YANG datamodels. Kea 1.5 implements ISC YANG models for DHCPv4 and DHCPv6 and integrates with the Sysrepo engine, which provides a northbound interface to a NETCONF configuration control system.
NETCONF and YANG
NETCONF and YANG model support is available for network equipment from popular vendors including Juniper, Huawei and Cisco. When implementing centralized configuration for your Kea DHCP servers, it makes sense to combine that with centralized configuration for the other network elements associated with IP addressing, such as routers, switches, bridges and relays.
YANG, kind of like a next-generation SNMP MIB, is a structured data model that mirrors the configuration data structure in the network equipment. (YANG is defined in RFC 6020.) A YANG model for a device can be combined with policy information to enable a provisioning system to specify device configuration changes to add or modify a service. YANG modeling has the potential to facilitate vendor-agnostic provisioning to the extent that multiple vendors can support standardized YANG models. A YANG model can import standard modules (such as for an IPv4 interface). Kea 1.5 implements customized data models for DHCPv4 and DHCPv6 servers which do incorporate some standard modules. The DHCPv6 model is adapted from the draft standard IETF DHCPv6 model. The IETF is not currently pursuing standardization of a DHCPv4 YANG model.
The NETCONF protocol is defined in RFC6241. NETCONF provides robust support for change control with support for transactions, multiple datastores, configuration change validation, checkpointing, commit, rollback and other features. The combination of NETCONF controls and YANG modeling permits frequent coordinated network reconfiguration, such as may be needed for SDN architectures.
Using Sysrepo with Kea
Kea’s integration with Sysrepo provides a new set of tools for configuration management. Used for Kea alone, the Sysrepo system allows you to use templates to provision new Kea servers quickly and to manage those configurations centrally. The additional benefits of YANG models comes from a shared, open source configuration datastore, allowing you to coordinate IP network configuration changes across different devices and device types.
Kea can retrieve its initial configuration from the Sysrepo store during startup. Subsequently, Kea will monitor Sysrepo for changes and apply those changes, updating its internal configuration on the fly. Loading the initial configuration from Sysrepo is essential to get the benefit of the change control capabilities of NETCONF.
The Kea DHCPv4 and DHCPv6 YANG models allow the Kea administrator to configure subnets, shared networks, and pools, as well as options associated with these, using a NETCONF client application. When a change is proposed (staged), it is sanity checked at several levels: Sysrepo does an initial validation against the YANG model, and then Kea performs a second validation, to ensure the change is “legal” and consistent with the rest of the current configuration. The user then can “commit” the change, or fix any errors found in the staged change and resubmit it.
Questions and Answers
Q. Where can I find the Kea YANG models?
A. The models are in our Gitlab source repository at: https://gitlab.isc.org/isc-projects/kea/-/tree/master/src/share/yang/modules, or in your source code distribution in a similar place.
Q. Where can I find a NETCONF client application?
A. Sysrepo is integrated with an open source NETCONF client/server project, NETOPEER. This provides both the client and server implementations of NETCONF. There are various other NETCONF client applications, including proprietary ones from different network equipment vendors.
Q. How does this new Sysrepo/NETCONF feature compare to the existing REST api for Kea configuration?
A. Kea has a number of hooks libraries that expose RESTFUL interfaces for atomically updating various elements of the Kea DHCPv4 and DHCPv6 server configuration (host reservations, subnets, leases, client classification). These libraries allow individual changes, such as, inserting a new host reservation, or modifying a single subnet, directly into the running Kea configuration. These hook modules do not interact with the Sysrepo configuration backend.
Q. Do I need the related Kea hooks for manipulating subnets in order to use the Kea Sysrepo configuration method?
A. No, you do not need any premium hook modules to use the Sysrepo configuration method. Currently, when the configuration changes in the Sysrepo configuration backend, Kea updates the (entire) new configuration. At some point, we may integrate the hook modules with the Sysrepo configuration backend, and enable atomic updates to the Kea configuration. If you plan to use the Sysrepo/NETCONF provisioning mechanism, it is recommended you do all your Kea configuration via that method.
Q. Can I manage leases or host reservations in the Kea database backend via the Sysrepo configuration interface?
A. No. Sysrepo can provide read-only access to the server state, including statistics, leases and host reservations, but this has not been implemented in Kea 1.5.
Q. It appears that Kea implements some standard YANG models, as well as the ISC-specific DHCPv4 and DHCPv6 server models. Is this correct?
A. Not exactly. There is a single YANG model for a Kea DHCPv4 daemon and another for a Kea DHCPv6 server. These ISC-specific YANG models do import standard modules for some simpler elements of the configuration, like interfaces.
Q. Does the Sysrepo server need to be co-located with the Kea server?
A. Yes. Both the Sysrepo configuration store and the NETOPEER2 server need to be on the same machine as the Kea server.
Q. Can you completely configure Kea via Sysrepo now?
A. You can complete configure the Kea DHCPv4 and DHCPv6 servers. We do not yet have Sysrepo configuration store support for the Kea DDNS server (aka the D2 server). We have implemented translators from the YANG models in Sysrepo to the native Kea JSON.
Q. What is the interface between Kea and Sysrepo?
A. The Sysrepo-Kea interface uses the Sysrepo C++ library (which itself is using the libyang API / library).
Q. Didn’t the Internet try to standardize configuration parameters once, with SNMP? It was a failure then. Why now?
A. It is true, it is hard to describe the internals of complex software developed independently by different organizations in a standard way. However, there is significant momentum behind YANG models today. The trend towards software defined networks, combined with the expectation that applications can be spun up and provisioned very quickly have increased the requirement for centralized configuration.
