After Kea for 1 year, reverted back to Bind (ISC)

maverickws

I am opening this topic to share my experience with the Kea DHCP.

As a novelty fan I changed the DHCP server on my pfSense to Kea right when it was released.
One of the things we immediately missed was the inability of resolving names for locally set fixed ip leases. It should work even if dynamically attributed, but the fixed leases? Pivotal.
Anyway one learns to go around it.

There haven't been any significant changes to this home network so everything went more or less smooth (ignoring the not resolving local leases and the Kea DHCP server stopping out of the blue and having to restart the firewall. Ludicrous).

Anyway, last week I made some changes. One of this changes was moving the IP PBX to a new subnet, which meant changing the provisioning files with the address for the new server and setting the tftpserver address on the DHCP options. Quite straightforward.

Under Kea DHCP you. even have a "tftp server" option or something of sorts, so all good.

But no.

My IP Phones would boot, acquire an IP display a quick error message and reboot. Indefinitely.
After reviewing all the configurations and ensuring the whole procedure was correct, I started sniffing packets.

So what does the Kea DHCP server offer as a response to a DHCP Discover message?
Option 53: DHCP Message Type (Offer)
Option 1: Subnet Mask)
Option 3: Router
Option 6: DNS
Option 12: Hostname
Option 15: Domain Name
Option 51: Lease Time
Option 54: DHCP Server Identifier
Option 255: The end.

So, where is the "tftp" option that I had filled in DHCP Server options? No where to be seen.
I then proceeded with researching about how to pass options other than the setup on the pfSense GUI.
After a thorough reading of Kea documentation, I edited the file /usr/local/etc/kea/kea-dhcp4.conf and added the following under option-def:

{
    "space": "dhcp4",
    "name": "tftp-server-address",
    "code": 150,
    "type": "ipv4-address"
}

then, proceeded to the subnet configuration, and added:

{
    "subnet": "192.168.1.0/24",
    "option-data": [
        {
            "name": "tftp-server-address",
            "data": "192.168.1.1" 
        }
    ]
}

Validated the configuration, and restarted Kea DHCP. Sniffed packets, nothing. Info on TFTP Server is simply not being sent. Also rebooted the firewall just to be sure. Nothing.

I then changed my config from Kea to ISC.
It didn't take 1 minute before the phone (that was stuck rebooting) to start loading the configuration and provisioning itself.

My question is, how can such a poor DHCP server software, lacking so many fundamental options, can be offered to its customers?
I would understand if pfSense was OPNsense or something else, but since this is developed by a company targeting B2B, can you really offer such a mediocre software with a popping ISC deprecation warning?
Should companies rely on third party equipments for completeness? (I could add an ip helper to my Cisco switch if it were in L3 mode, but is that really the way to go?)

Anyway, I did try to use Kea for as long as possible. But faced with these recent shortcomings of this software, I can't recommend it to anyone.

Patch

@maverickws Agree the labelling in pfsense for Kea was always plain wrong. The labelling was a bug which should have been corrected with the initial patch or point upgrade.

Justifying it by saying the documentation was correct elsewhere just reflects poorly on Netgate.

I assume it will be mute very soon when a feature parity version of Kea is released and the labelling from a year ago will actually almost be appropriate.

Gertjan

@maverickws said in After Kea for 1 year, reverted back to Bind (ISC):

My question is, how can such a poor DHCP server software, lacking so many fundamental options, can be offered to its customers?

KEA isn't "poor".
It needs to have a correct setup. Right now, Out of the box, it does 'DHCP' out of a pool. That's it.

KEA, right now - version 24.03, is offered as a "A DHCP alternative to ISC' to play with.
Unfortunately, it was activated by default. The pfSense user had to take some actions (clicking in the GUI) to go back to ISC. Why did Netgate activate it ? Well, IMHO, and easy to understand, to get as much feedback as possible.
As a pfSense, I would prefer, I guess, ISC, a all depend my needs.
For Netgate ... well, you get my point.

It's for sure that ISC will get phased out as soon as KEA is usable for 9x % of the pfSense users base. That's not the case right now, but this will be the case after several pfSense releases.
ISC still rocks pretty well right now.
Again, very IMHO of course.

maverickws

@Gertjan Well ... I completely understand your comments, but I'll have to disagree on the poor part and I'll explain.
About the "a DHCP alternative to ISC' to play with" fits perfectly, Should never be enabled by default (didn't know that because I changed to Kea when it was released on my home setup ... to play with".

About the "poor" ... if a DHCP server is unable to send DHCP options, is not poor?
DHCP options are cornerstone of DHCP service, you're running a business, you have IP Phones that provision over the network, and you have a piece of software that is unable to comply. In my book, this is very poor. Also, being Netgate targeted at companies, how would you evaluate a company running Kea and pushing a change in this fashion? Some won't even notice the change until they have to commit changes to the current environment. In over a year my phone never complained nor stopped connecting, because it had already been provisioned.
Imagine being an IT department, pushing these changes and all the phones unable to provision?
Also, what is the option for TFTP Server for, if you fill it and ... nothing gets over the DHCP negotiation?

johnpoz

In what version was it enabled by default? I don't recall that - there was the warning at top about isc being deprecated, which sure many users clicked on without reading the WARNINGS in the blog and release notes on what kea will not do, etc.

I think pretty much everyone agrees that the warning about isc and click here to move over to kea could of been worded a bit differently. Or maybe not even brought up as a warning in the gui until such time that it has reached feature parity with isc..

In hindsight there should of also been a warning when you did click over to kea that hey this is preview, it is missing all of these features.. Use at your own risk.

There have been plenty of posts user clicking over and wondering why X doesn't work - that never read the blog or release notes even.

maverickws

@johnpoz I don't know what version had it enabled by default, but I think 24.03 was mentioned.

The warning on ISC deprecation imposes a sense of urgency in making the change. I agree the warning should only be displayed when feature parity has been achieved.

johnpoz

@maverickws why would they make something default to switch over to that is no where close to parity, and pretty much all it does is hand out IPs from a pool..

I highly doubt it was defaulted to use on any install out of the box.. That just makes zero sense for them to clearly shoot themselves in the foot..

Maybe their tac was just sitting there idle without any tickets.. Oh hey lets make a dhcp server that is no where close to ready and we blogged and filled the release notes about it not supporting X, Y and Z etc.. But hey lets make it the default option ;) So we can get people screaming this doesn't work and open up tickets for our tac guys to have something to do ;)

I am sure they got plenty of those - after the user clicked to switch to it. Not like they didn't warn about it in the blog and in release notes.

maverickws

@johnpoz I don't know. Wasn't me that said Netgate made Kea default.

johnpoz

@maverickws maybe it was a typo

@Gertjan said this

"Unfortunately, it was activated by default. The pfSense user had to take some actions"

Maybe he meant to say

"Unfortunately, it wasn't activated by default. The pfSense user had to take some actions"

@Gertjan where did you see or hear that it was activated with no interaction from the user? Because I have not seen this with clean installs to VMs - nor does it make any sense to do something like that..

Gertjan

@johnpoz

I'm pretty sure it was activated after I installed (upgraded to) 23.09.

If it wasn't, the "issue" wouldn't exist, as it would be a simple "tried the new DHCP (KEA), and I didn't like it - and I switched back to what I had before (ISC)".

There are numerous examples where I and many other had to propose : "Problems with KEA ? Switch to ISC !".

If people were switching themselves to the new KEA, they would have know how to get back by themselves.

The bottom line is probably that the word depreciated doesn't scare me at all.

johnpoz

@Gertjan It makes zero sense for them to switch over to a package as the default when its nowhere near ready..

When 23.09 was the first release was even available in - and with all the warning about it being preview and missing a bunch of stuff. And clearly states OPT-IN..

https://docs.netgate.com/pfsense/en/latest/releases/23-09.html

https://www.netgate.com/blog/netgate-adds-kea-dhcp-to-pfsense-plus-software-version-23.09-1

"If people were switching themselves to the new KEA, they would have know how to get back by themselves."

Pretty sure your giving users way to much credit here.. Most of them after clicking the warning - couldn't of told you what they were running.. Oh something to click, must click!

Patch

@johnpoz the Netgate bug is and always was the in applications alert description of the choice between KEA and ISC. There is no place for blatantly misleading information within a professional software product.

Arguing a user should know the built in alert was an error, and researched alternative information sources is also wrong.

The in application alert is a bug. Failure to correct it reflects poorly on Netgate.

Sure community support identifies the solution but that or other documentation doesn’t change the fact pfsense software has a glaring bug

johnpoz

@Patch said in After Kea for 1 year, reverted back to Bind (ISC):

fact pfsense software has a glaring bug

What bug is that? You have validation that pfsense auto switches to the preview copy of kea on its own without any user interaction?

Where has netgate stated that kea was ready for prime time? If you go use it without reading the release notes - sorry but that is on you.. Could it have been worded better, or not done at all at this time about the warning.. I would concur - but where is the "bug"?

Patch

@johnpoz it is possible to miss lead without actually lying.

Missing leading users within professional software is a bug.

johnpoz

@Patch said in After Kea for 1 year, reverted back to Bind (ISC):

Missing leading users within professional software is a bug.

I think you need to look up the definition of a bug.. And where did they mislead anyone.. I mean the warnings are glaring that it wasn't ready for prime time..

Sorry you didn't bother to read them.. Or anyone else - but that sure is not a "bug"

binfree

@maverickws said in After Kea for 1 year, reverted back to Bind (ISC):

One of the things we immediately missed was the inability of resolving names for locally set fixed ip leases

That was the deal breaker right there. And if this most basic of basic features is missing, what else is missing? What else doesn't work?

The warning about DHCP, after first installing pfSense, appears to any typical human as a firm instruction to activate KEA. It reads as though your system is going to be unsafe running a deprecated DHCP server if you don't choose KEA - "RIGHT NOW!"

There were no warnings about KEA "not being ready for prime time." Only the opposite - that you'd better run KEA OR ELSE - because the original ISC DHCP is deprecated, outdated, and shouldn't be used. This is how anyone not involved in support (official or otherwise) with Netgate will have understood the messaging.

To make matters worse, if you don't select KEA, the warning is persistent.

The decision to include that warning was misplaced and foolish. The decision to include KEA, which at best can be considered an early beta, is itself also foolish. At most, it could have been available in Packages to install for anyone curious. But if I were leading the project, it wouldn't have even been available there.

Patch

@johnpoz said in After Kea for 1 year, reverted back to Bind (ISC):

the definition of a bug.

An error in documentation is a bug, many are recorded in redmine

@johnpoz said in After Kea for 1 year, reverted back to Bind (ISC):

I mean the warnings are glaring that it wasn't ready for prime time.

The warnings are correct in the blog site / press release.
But that is not the subject of this thread.

The bug is in the pfsense software not the press release.
A deceptive alert within professional software is a bug.

JonathanLee

KEA is the fix for the twilighted DHCP server, that DHCP software the developers no longer release updates for. pfSense/Netgate had to redesign a lot of code just to get KEA to work, again with anything new there is a timeline for software convergence that is expected. That is why it was a depreciation notice and not automatically merged to KEA. Thanks for sharing your experience with the community. Sorry you had that experience. Again with the Boot Environment features mitigation for such issues is a breeze to jump back to a known good configuration. I love Boot Environments.