uid lease is duplicate / multiple DHCPOFFER [solution]
Carlos Vicente
cvicente at network-services.uoregon.edu
Tue Jul 20 20:05:52 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Wim,
I seem to be experiencing the same issue in my tests with 4.1.1-P1.
Did you happen to submit a bug report with ISC?
cv
Wim Vandersmissen wrote:
> Hi,
>
> I found a solution for the problem, apparently "Most versions of Microsoft Windows improperly encode the secs field on the wire as little-endian." (http://wiki.wireshark.org/DHCP#head-838a814984848532459be023c4d9da55a411dff9)
>
> This means that the check in load_balance_mine (in server/failover.c) isn't working correctly for such hosts.
>
> I made the following small patch, if it sees a value above 255 it probably means we're dealing with little-endian, so we can use the secs value of the raw packet.
>
> --Wim
>
>
> diff -urp dhcp-4.1.1/server/failover.c dhcp-4.1.1-endianfix/server/failover.c
> --- dhcp-4.1.1/server/failover.c 2009-07-23 21:02:10.000000000 +0200
> +++ dhcp-4.1.1-endianfix/server/failover.c 2010-04-30 14:38:59.000000000 +0200
> @@ -5751,9 +5751,18 @@ int load_balance_mine (struct packet *pa
> struct data_string ds;
> unsigned char hbaix;
> int hm;
> + short int ec; // endian check
>
> - if (state -> load_balance_max_secs < ntohs (packet -> raw -> secs)) {
> - return 1;
> + ec = ntohs (packet -> raw -> secs);
> + if (ec > 255) {
> + // little endian encoding (ms client probably)
> + if (state -> load_balance_max_secs < packet -> raw -> secs) {
> + return 1;
> + }
> + } else {
> + if (state -> load_balance_max_secs < ec) {
> + return 1;
> + }
> }
>
>
>
>> -----Original Message-----
>> From: Wim Vandersmissen [mailto:wim.vandersmissen at icts.kuleuven.be]
>> Sent: donderdag 29 april 2010 15:23
>> To: dhcp-users at lists.isc.org
>> Subject: uid lease is duplicate / multiple DHCPOFFER
>>
>> Hi,
>>
>> We recently migrated our old dhcp environment to a 4.1.1 failover one.
>> After the migration we got users complaining that they got new ip
>> addresses and
>> the logs are showing "uid lease x.x.x.x for client aa:bb:cc:dd:ee:ff is
>> duplicate on x.x.x.x/y" on those users.
>>
>> Sometimes the dhcpservers know that they should load balance to the
>> peer and
>> only send one DHCPOFFER and sometimes they respond with two DHCPOFFERS
>> containing two different IP addresses.
>>
>> I used wireshark to debug the DHCPDISCOVER
>> - the client 'secs' field (0) or sometimes (3) or (5) is below our
>> 'load-balance-max-secs' (6)
>> - the clients 'client address field' is also 0.0.0.0
>>
>> Some more information about the failover:
>> - we're using 'split 128' for the load-balancing
>> - we're not using any reservations.
>> - we're using 'one-lease-per-client'
>> - both partners are in normal state (00:00:00:02)
>> - MCLT = 1800
>> - for this example the max-lease-time = 900
>>
>> In the example below you can see that at 09h35 it works correctly, load
>> balanced
>> to peer.. but at 21h40 both servers responds with different DHCPOFFERS
>> and
>> different ip's which cause the duplicate message and a possible
>> different ip for
>> the client (in this case it takes the same, but in other cases it takes
>> the other
>> one)
>>
>> We're seeing this behaviour on around 10% of our users (unique mac
>> addresses).
>>
>> cat /var/log/all|grep "Apr 29"|grep DHCPDISCOVER|awk '{print
>> $8}'|sort|uniq|wc
>> 10912 10912 196416
>> cat /var/log/all|grep "Apr 29"|grep duplicate|awk '{print
>> $11}'|sort|uniq|wc
>> 1160 1160 20880
>>
>> Disabling the secondary dhcp server solves the duplicate messages and
>> obviously
>> also the two different DHCPOFFERS but also removes the failover, so
>> it's not
>> really an option.
>>
>> Any clues/ideas what I can do/check next ?
>>
>> Thanks,
>>
>> Wim
>>
>>
>> -----------------------
>> 09:35:44 dhcp1-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
>> 10.0.14.254: load balance to peer dhcp-failover
>> 09:35:44 dhcp2-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
>> 10.0.14.254
>> 09:35:45 dhcp2-l dhcpd: DHCPOFFER on 10.0.14.164 to 00:00:00:aa:bb:cc
>> (Jarri) via 10.0.14.254
>> 09:35:45 dhcp1-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
>> 00:00:00:aa:bb:cc via 10.0.14.254: lease owned by peer
>> 09:35:45 dhcp2-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
>> 00:00:00:aa:bb:cc (Jarri) via 10.0.14.254
>> 09:35:45 dhcp2-l dhcpd: DHCPACK on 10.0.14.164 to 00:00:00:aa:bb:cc
>> (Jarri) via 10.0.14.254
>> 09:36:25 dhcp2-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc) via
>> eth1
>> 09:36:25 dhcp1-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc) via
>> eth1
>>
>> ---
>> 21:40:06 dhcp1-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
>> 10.0.14.254
>> 21:40:06 dhcp2-l dhcpd: DHCPDISCOVER from 00:00:00:aa:bb:cc via
>> 10.0.14.254
>> 21:40:07 dhcp2-l dhcpd: DHCPOFFER on 10.0.14.164 to 00:00:00:aa:bb:cc
>> (Jarri) via 10.0.14.254
>> 21:40:07 dhcp1-l dhcpd: DHCPOFFER on 10.0.14.179 to 00:00:00:aa:bb:cc
>> (Jarri) via 10.0.14.254
>> 21:40:07 dhcp1-l dhcpd: uid lease 10.0.14.179 for client
>> 00:00:00:aa:bb:cc is duplicate on 10.0.14.0/24
>> 21:40:07 dhcp1-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
>> 00:00:00:aa:bb:cc via 10.0.14.254: lease owned by peer
>> 21:40:07 dhcp2-l dhcpd: DHCPREQUEST for 10.0.14.164 (134.58.127.6) from
>> 00:00:00:aa:bb:cc (Jarri) via 10.0.14.254
>> 21:40:07 dhcp2-l dhcpd: DHCPACK on 10.0.14.164 to 00:00:00:aa:bb:cc
>> (Jarri) via 10.0.14.254
>> 21:40:12 dhcp1-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc) via
>> eth1
>> 21:40:12 dhcp2-l dhcpd: DHCPACK to 10.0.14.164 (00:00:00:aa:bb:cc
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFMRgGgDADXcoYj2ZwRAug+AJ4mpKvtYQ1ZSqlYFSL+bgb6LpQTVwCfdRsE
BdZGKe+tcctJ6uOt6up9yJE=
=blto
-----END PGP SIGNATURE-----
More information about the dhcp-users
mailing list