| Subject: | Failover load balancing delay looks for secs > configured value... |
... while the non-failover load balancing delay looks for secs >= the
configured value.
This may be a bug, may have been intentional, may be too late to change,
or any combination of the three.
As it is right now, if someone needed to disable the failover load
balance delay completely they have no way to do so.
On Wed Mar 18 13:11:46 2015, bconry wrote:
> On Wed Mar 18 07:11:37 2015, robert.willmann@commerzbank.com wrote:
> > Do
> > I understand it correctly that when " load balance max seconds" is
> > set to zero (default), then it that case the problem wouldn't
> > occour and both dhcp-servers would answer?
>
> Hi Robert,
>
> From looking at the code and consulting with our primary DHCP engineer,
> a value of '0' for 'load balance max seconds' does *not* disable this
> behavior.
>
> This is because the code looks for the value in the 'secs' field to be
> greater than the configured value. So for a configured value of '0'
> both peers will answer any time the 'secs' field is non-zero, but only
> the peer responsible for the client MAC will respond when the 'secs'
> field is exactly zero.
>
> Thanks,
> Brian
On Wed Mar 18 15:15:07 2015, bconry wrote:
> On Wed Mar 18 14:02:44 2015, robert.willmann@commerzbank.com wrote:
> > If so, then how do I get them to answer both even if the secs-field is
> > zero?
> >
> > Mit freundlichen Grüßen
> > Robert Willmann
>
> As the code currently stands, you can't.
>
> This has been evaluated as possibly being a bug, e.g. using '>' instead
> of '>=' in the test.
>
> I've reviewed the draft failover specification and it refers to RFC 3074
> for the load balancing logic. That RFC says:
>
> "
> If the parameter is configured, the server that is not supposed to
> serve a specific request (based on the HBA and the STID hash), is
> allowed to respond, after S seconds have elapsed since the client
> first attempted to get service. A server MAY use the secs field in
> the BOOTP header for determining the time since the client has been
> trying to get service, or it MAY track repeated requests some other
> way.
> "
>
> Further, looking at how we handle load balancing outside of failover,
> which is also based on RFC 3074, we are using '>=' for the comparison
> there.
>
> So I would say that there's a very strong case for this behavior being
> a bug, and thus something that we will address in our next set of
> releases.
>
> Assuming I haven't overlooked something. :)
>
>
> Now, with regard to considering using an actual working '0' for this
> value (if you could), understand that means that both DHCP servers will
> respond to every request they see, every time. Aside from increasing
> network traffic this has some other implications that are more subtle.
>
> First, it seems that currently you're relying on the client experience
> to validate that you have your relays configured properly. If you
> continue with this as your only validation method then you won't notice
> an issue until the one server handling the load is down (whether planned
> or unplanned) and no clients get addresses.
>
> Second, when a DHCP server makes an OFFER to a client, unless that
> client already has an active lease one must be allocated to that client
> temporarily. This allocation is for a duration that does not exceed
> the MCLT (and is often less, depending on the failover configuration),
> and so isnot communicated to the failover peer. With the load
> balancing delay the normal case is that the lease association then gets
> confirmed, committed, and then communicated. Without a load balancing
> delay both peers will allocate a lease for the client. If the network
> segment is busy and near capacity this could cause 'soft' outages where
> each peer has leases tied up temporarily but appear free to the partner.
>
> Third, this decreases the effective number of clients that your DHCP
> server pair can handle. Even though the lease associations are
> temporary, they still need to be committed to the leases file before
> they are sent to the client. In a properly configured network this
> doubles the work done for a DISCOVER, albeit split over both peers.
> Since the client can only accept one of the OFFERs, half of this work
> will always be wasted. The magnitude of the impact of this will depend
> on how long clients typically stay around on the network. In an
> environment with mostly long-term clients it would be minimal, while in
> an environment with mostly transient clients it could be significant.
>
> You probably ought to work on that first potential problem anyway, even
> if you choose to retain a failover load balancing delay.
>
> Thanks,
> Brian