pfSense

Jim Pingle wrote:

The current behavior is correct and as intended, and as suggested in the ISC docs. The two will work in a coordinated fashion and exchange lease information so both know about all hosts. There is no bug here, but adding that option as a feature may be considered in the future if someone decides to submit a patch to enable the behavior.

Which ISC docs suggest it? The default failover example(https://kb.isc.org/docs/aa-00502) uses `split 128`. But there is no suggestion saying it should be used. It is just an example of failover with load-balancing. When master/backup CARP setup is made with pfsense, the expected behavior is that backup does not run services. So I expected value to be 256 by default.

`dhcpd.conf` man page (https://www.freebsd.org/cgi/man.cgi?query=dhcpd.conf) clearly mentions "Note that a value of 0 makes the secondary responsible for all clients and a value of 256 makes the primary responsible for all clients."

Anyway, you guys can decide what to do I guess. This is a minor issue never the less....

https://kb.isc.org/docs/isc-dhcp-41-manual-pages-dhcpdconf

The split statement

split bits;

The split statement specifies the split between the primary and secondary for the purposes of load balancing. Whenever a client makes a DHCP request, the DHCP server runs a hash on the client identification, resulting in value from 0 to 255. This is used as an index into a 256 bit field. If the bit at that index is set, the primary is responsible. If the bit at that index is not set, the secondary is responsible. The split value determines how many of the leading bits are set to one. So, in practice, higher split values will cause the primary to serve more clients than the secondary. Lower split values, the converse. Legal values are between 0 and 256 inclusive, of which the most reasonable is 128. Note that a value of 0 makes the secondary responsible for all clients and a value of 256 makes the primary responsible for all clients.

(emphasis mine)

The current behavior is well documented and widely understood.

If someone wants to submit a PR to add an option (which defaults to the current behavior), it could be considered, but it's not something we'd spend time developing.