Change from loadbalancing to primary/secondary?

[Thomas Markwalder]

Hello Anders:

The parser was modified to support a split value of 256 in ISC DHCP 
4.3.1.  The current release is 4.4.1.  You may want to consider 
upgrading as 4.2.x is EOL and no longer supported.

Regards,

Thomas Markwalder
ISC Software Engineering

On 04/24/2018 12:00 PM, Anders Löwinger wrote:
> Hello!
>
> Running two dhcp servers (dhcp1/dhcp2) with ISC DHCP 4.2.4 under 
> ubuntu 14.04 in a load-sharing failover configuration.
>
>
> 1)
>
> Due to bug CSCut30235 in Cisco ASR9000 BNG, we want to run in a 
> primary/secondary setup, dhcp1 should normally answer all DHCP requests.
>
>
> I added split 255 to the primary configuration and restarted both 
> servers. After 12 hours there was no real difference, dhcp1 and dhcp2 
> both sent offers as before.
>
> What is the proper way to change this?
>
>
> Currently I'm running dhcp1 with parner-down (dhcp server stopped on 
> dhcp2) so I don't trigger the Cisco issue; customers get new addresses 
> from time to time.
>
>
> 2)
>
> "split 256" is not accepted by parser but 255 is. Does that not end up 
> with 1/256 of the requests will always be handled by the other server.
>
> root at dhcp1:~/dhcp# ./show_dhcp_state.sh  | grep hba
> load-balance-hba = 
> ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:7f
>
>
> I guess I can get around this by using hba command instead.
>
>
> CSCut30235:
>
> Symptom:
> Working in DHCP Proxy, it appears that when the 9K processes a 
> Discover and adds the Release it is sending the Discover almost 
> immediately(5ms to be exact) after the Release which doesn't give 
> customer's redundant DHCP servers enough time to process the actual 
> Release and make that IP "available" thus causing the DHCP server to 
> change the IP during re-assignment.
>
> Conditions:
> DHCP servers are in a cluster and use DHCP Failover so it takes a 
> little time for information to sync.
> In a normal DHCP client Release(without the 9K), there is usually at 
> least some delay before a Discover is sent which gives the DHCP 
> servers plenty of time to process but since the 9K is now adding a 
> Release every time there is a Discover and it is immediate, that 
> appears to be where the problem is.
> We tested this in house with a manually sent DHCP Release, waited 10 
> seconds and then a Discover.  The IP did not change.
>
> Workaround:
> None
>
>