DHCP failover doesn't receive DHCP requests in secondary server

[perl-list]

Its been available since the very first time I personally used failover (~2001) as this directive:

split 128;

has been in my config since that time.  Not sure why people are saying its a new option.

----- Original Message -----
> From: "Greg Sloop" <gregs at sloop.net>
> To: "Philippe Maechler" <plcmaechler at gmail.com>, "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Thursday, August 16, 2018 1:05:20 PM
> Subject: Re: DHCP failover doesn't receive DHCP requests in secondary server

> Re: DHCP failover doesn't receive DHCP requests in secondary server But I
> believe it's always [at least for a long time] been available. IIRC it wasn't
> recommended to use any split other than even, but it was possible.
> The way it seemed to me was, that there was almost no conceivable situation
> where it made sense to run it other than an even split.

> ...because the only reason I can see to have it run with more leases to one peer
> vs the other would be if one of the peers couldn't handle all the load, while
> running even. But then how in the world would one expect the machine that can't
> even handle half the load to survive when in a peer-down situation where it has
> to handle ALL the load, and likely more heavy than "normal," since all the non
> owned leases would get renewed at the MCLT time instead of the full regular
> lease time.

> So I'm probably not thinking of some corner case, but I honestly can't think of
> a case where a non-even split makes the slightest sense. Thus the option, while
> nice - doesn't seem to have any real-world practical use.

> Sorry to the OP for the digression... :)


> 	I saw it recently in the release notes.

> 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

> Source: [ https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html |
> https://www.isc.org/wp-content/uploads/2018/02/dhcp44.html ]

> On Thu, 16 Aug 2018 at 16:23, Anders Löwinger < [ mailto:anders at abundo.se |
> anders at abundo.se ] > wrote:
> On 8/15/18 6:19 PM, Philippe Maechler wrote:
> > iirc with the latest patch, only the primary server replies to clients
> > when the split value is set to 255

> When was this added?

> /Anders

> _______________________________________________
> dhcp-users mailing list
> [ mailto:dhcp-users at lists.isc.org | dhcp-users at lists.isc.org ]
> [ https://lists.isc.org/mailman/listinfo/dhcp-users |
> https://lists.isc.org/mailman/listinfo/dhcp-users ]

> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users