When your DHCP system isn’t configured correctly, or you have reachability problems, or a server has failed, it is an urgent problem. It is critical to find out and restore service quickly before other network services, that rely on DHCP, start failing. Stork can enable you to monitor a multi-server DHCP system quickly, making changes in status obvious and easy to spot.
Stork provides a web-based graphical interface for monitoring, troubleshooting, and maintaining the configuration of, Kea DHCP servers. Stork provides a single point for administrative control for your Kea servers, including integration with LDAP for administrator authentication and authorization. The graphical interface makes it possible for network administrators to easily make configuration updates to the DHCP service without having to struggle with unfamiliar CLI.
Key Features
- Monitor CPU and OS data, including speed, memory, memory utilization, operating system and software versions
- Monitor DHCP pool utilization, including shared network utilization
- See which Kea servers are in a High Availability relationship and monitor their failover status
- Manage DHCP Host reservations via GUI (requires the commercially-licensed Host Commands hook)
- Manage subnets and pools via GUI (requires the commercially-licensed Kea Subnet Management hook)
- Spot changes in DHCP traffic activity in customizable Grafana charts
Open Source Linux Application
Stork is open source, shared under MPL2.0 licensing. Stork is developed in the open on ISC’s GitLab; we welcome you to open issues and submit patches there. Stork runs on most Linux and Unix platforms, as well as MacOS. If you don’t want to build from our source distribution, we also provide a repository of pre-built packages for most popular operating systems, for both Kea and Stork.
Components of the Stork solution
Stork is comprised of two primary components: the Stork server (stork-server) and the Stork agent (stork-agent). Stork interacts with the Kea servers via the agents, installed on each Kea server. One Stork server is deployed in a network, providing an integrated, centralized front end for these services. The Stork server requires a PostgreSQL database, ideally installed on the same machine. The Stork server communicates with the agents via GRPC channels secured with TLS encryption. The Kea servers may also be using back end databases: Stork communicates with the Kea daemons and the daemons will manage any communications with their dependant databases.
Stork can integrate with Prometheus and Grafana for warehousing and visualizing DHCP usage data. This is extremely useful for viewing trends over time, and for filtering and analyzing large amounts of traffic data.
Stork and Kea
Stork leverages several of the optional Kea hook libraries. We strongly recommend Stork users install at least the lease_cmds and stat_cmds on Kea servers they want to manage with Stork. Kea may optionally be deployed with a database backend for host reservations, and if it is, Stork will manage the host reservations in the database. Most Kea users deploy the optional high availability hook - if your Kea servers are configured to work as HA pair then Stork will use this library to display the HA status.
Stork requires the subnet_cmds hook installed on the Kea servers in order to modify subnets and pools: it also enhances the metrics passed to Prometheus by including subnet labels. Without this hook, Prometheus identifies subnets by subnet IDs. The subnet_cmds hook is commercially licensed.
Stork does not require nor integrate with the optional Kea configuration backend at this time.
On-line DEMO
