Change from loadbalancing to primary/secondary?

Anders Löwinger anders at
Tue Apr 24 16:00:12 UTC 2018


Running two dhcp servers (dhcp1/dhcp2) with ISC DHCP 4.2.4 under ubuntu 14.04 in a load-sharing failover configuration.


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.


"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# ./  | 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.


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.

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.


Anders Löwinger, Abundo AB, 072-206 0322 (international +46 72 206 0322)

More information about the dhcp-users mailing list