Change from loadbalancing to primary/secondary?

[Anders Löwinger]

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@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


--
MVH
Anders Löwinger, Abundo AB, 072-206 0322 (international [phone])

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[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@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
>
>

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Anders Löwinger]

Den 2018-04-24 kl. 19:10, skrev Thomas Markwalder:
> 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.

Thanks.

Any input on how to get from loadbalancing->primary/secondary?

--
MVH
Anders Löwinger, Abundo AB, 072-206 0322 (international [phone])

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users