Log InAs part of our contributions to the FreeRADIUS community, Network RADIUS took on the task of overhauling its DHCP support. The result is the same highly flexible and configurable DHCP server, but now easier to configure and outperforms both ISC and Kea DHCP in most common scenarios. And it’s available now, in FreeRADIUS 3.0.22
Support for DHCP has been part of FreeRADIUS since 2008. Until recently however, that support wasn’t as high performance as it could be. It also did not implement enough of the DHCP standards for the needs of some organizations.
As the team which leads maintenance and development of FreeRADIUS, we recognized that its underlying architecture meant it could potentially outperform other popular DHCP servers with some targeted refinements. For instance, we expected that FreeRADIUS’ mature multi-threaded capabilities could be leveraged to handle high load scenarios better than either ISC DHCP, which is single threaded, or Kea, which has a relatively limited multi-threaded model.
After running a battery of tests against ISC DHCP and Kea, we identified issues with FreeRADIUS that needed to be addressed in order to improve compliance as well as performance.
In this post, we’ll provide a high-level overview of the changes we made and why, as well as the final performance results.
Evaluating against industry standards: ISC DHCP and Kea
ISC DHCP is the original DHCP server and is considered by many to be the reference implementation of DHCP. It is also the DHCP engine behind many commercial offerings. The original server had a number of limitations, such as being single-threaded, and not supporting databases either for lease management or configuration. The ISC consortium has therefore developed Kea as a “next generation” replacement, which addresses these limitations to some extent.
Major performance improvements with DHCP-specific database schema
Our initial tests of FreeRADIUS found that performance became unpredictable when it was under high load.
After investigation, we found that a significant contributing factor was the design of the database schema. This result was not surprising, as the schema was optimized for RADIUS instead of for DHCP. We achieved our first major performance improvements by creating a separate database schema that is specifically designed for the latter. As of FreeRADIUS 3.0.22, we now ship separate schemas which are specific to RADIUS and DHCP.
Further optimization with database specific query strategies
We tested FreeRADIUS with a variety of backend databases and found that each had different performance characteristics when responding to queries. For example, our analysis showed that MySQL performed best using stored procedures, while PostgreSQL was fastest with a discrete query implementation.
In order to realize the best possible performance gains, we developed optimized configurations for the most common databases used in DHCP deployments. This key optimisation work has been replicated across a number of different database back ends, namely, PostgreSQL, MySQL, SQLite, Oracle and MS SQL Server.
The graphs were produced via tests run on “laptop” grade hardware, with FreeRADIUS and the SQL databases all running on the same system. We expect that “server” grade hardware would be higher performance.
These improvements resulted in a dramatic improvement in performance, making our DHCP implementation much faster than either ISC DHCP or Kea.
The above graph shows that in many cases, FreeRADIUS can outperform Kea. This improvement is especially interesting, as FreeRADIUS does two database writes for each lease assignment, while Kea only does one. The only odd thing we still have to track down is the “spiky” nature of the PostgreSQL graphs. We suspect that this is due to the MVCC implementation of Postgres. Where MySQL updates rows in place, PostgreSQL copies rows, and then periodically cleans up old “garbage” rows. We will be revisiting this issue in a later article.
After these refinements, we were able to demonstrate in our tests that FreeRADIUS DHCP is limited by the performance of the backend database, not by FreeRADIUS itself. At this stage, we were able to turn our attention to other aspects of the DHCP server.
While performance is obviously one of the most critical considerations for network administrators, it is not the only consideration. Other factors are less obvious, but can significantly impact the workload and complexity for administrators.
Designed with the network admin in mind
When designing the architecture of FreeRADIUS, we wanted to prioritize the experience of the administrator who needs to weigh multiple tradeoffs in a complex network environment. To that end, we adhered to some key principles which drove our design decisions.
1. Adapt to the existing network configuration, not the other way around
Large, complex networks often have a diverse combination of network-management components that have been specifically chosen for the unique needs of that organization. For example, device registration and provisioning systems. Our philosophy is that a DHCP server should not artificially constrain what those components are or how they should work. We believe that the network administrator has made site-local choices for a reason.
FreeRADIUS is designed to be highly modular, which makes it trivial to “mix and match” different systems. For example, leases could be taken from SQL, and options from LDAP. Or, options could be assigned from both PostgreSQL and MySQL, depending on factors such as the network from which the request originates, or the type of device. This flexibility allows the server to support almost any work-flow, without requiring a migration away from existing datastores. It also allows for fine grained control of policies, which is impossible with Kea.
2. Don’t force administrators to develop unnecessary data workflow
In many environments, device provisioning depends on existing databases and schemas. If the DHCP server is not customizable, then the local systems have to be adapted to work with it, instead of the other way around. Not only is this more effort, but it also becomes another potential source of errors, and makes the system more brittle to change.
With FreeRADIUS DHCP, queries are simply text which is stored in configuration files, and are not hard-coded into the source code. This choice means that unlike ISC DHCP and Kea, FreeRADIUS has the flexibility to work with pretty much any schema which can define device option data or be used to maintain a pool of leases.
3. Empower real-time monitoring
Good network administrators are proactive about detecting potential issues before they become actual service-affecting problems. This means that they want to monitor the DHCP server for certain conditions, for example, if they are approaching their IP address pool capacity. They also want to easily get data about usage trends over time, so that they can accurately plan and project their provisioning needs.
With FreeRADIUS DHCP, all the leases are pre-inserted into the database. For the administrator, this means a simple SQL query can give them a real-time and a historic view of the status of leases and the address pool. Creating alerts for specific conditions also becomes a trivial exercise.
In contrast, Kea stores only active addresses in the database with its pool definitions (start and end IP addresses) configured elsewhere. When a lease expires, it is eventually removed from the database. This process makes it very difficult or even impossible to know how many leases are free, by just looking at the database. Management software instead has to be aligned with the pool definitions maintained within configuration files, via some “out of band” method. Such a limited use of the database makes it more difficult to use KEA in a production environment.
DHCP capabilities are available now
At Network RADIUS, we know FreeRADIUS inside out, and network access is all we do. We like to think that we understand other network administrators pretty well too. With FreeRADIUS 3.0.22 (available now), we are excited to provide a DHCP server that:
- Outperforms ISC DHCP and Kea
- Has the flexibility to adapt to your network rather than the other way around
- Implements query strategies that are optimized for the most common databases
- Simplifies data workflow
- Empowers real time monitoring
Need some additional help?
Network RADIUS provides expertise to build bespoke deployments of FreeRADIUS in complex networks. We developed these enhanced DHCP capabilities in FreeRADIUS 3.0.22 and are the world-wide experts in FreeRADIUS. Contact us today if you need help getting the most out of FreeRADIUS DHCP.
Read more:
