DHCP client takes too much time to get IP address

[Simon Hobson]

>I have ISC DHCP 3.0.4-13 running on a Debian Etch box. Our LAN is made
>mainly by Windows 2k and XP boxes, which get their addresses from the
>aforementioned box.
>
>Everything was working with no problem, but after we substituted our
>switches with Netgear models (1xGSM 7248 EU at the center of the star
>and 1xGS 748 TEU and 3xGS 724 TEU at the edges, all connected by 1000-SX
>fiber link) some problems started to arise.
>
>More in detail, some clients take much more time to get their address
>from the DHCP box (some minutes), while in the past the process was very
>fast, as expected.
>In the syslog I see following messages:
>>Oct 11 06:42:08 cnsrv010 named[17966]: client 127.0.0.1#32900: updating zone 'farmol.it/IN': update unsuccessful: CNWKSXP047
>>.farmol.it: 'name not in use' prerequisite not satisfied (YXDOMAIN)
>>Oct 11 06:42:08 cnsrv010 named[17966]: client 127.0.0.1#32900: updating zone 'farmol.it/IN': deleting rrset at 'CNWKSXP047.f
>>armol.it' A
>>Oct 11 06:42:08 cnsrv010 named[17966]: client 127.0.0.1#32900: updating zone 'farmol.it/IN': adding an RR at 'CNWKSXP047.far
>>mol.it' A
>>Oct 11 06:42:08 cnsrv010 dhcpd: Added new forward map from CNWKSXP047.farmol.it to 192.168.1.67
>>Oct 11 06:42:08 cnsrv010 named[17966]: client 127.0.0.1#32900: updating zone '168.192.in-addr.arpa/IN': deleting rrset at '6
>>7.1.168.192.in-addr.arpa' PTR
>>Oct 11 06:42:08 cnsrv010 named[17966]: client 127.0.0.1#32900: updating zone '168.192.in-addr.arpa/IN': adding an RR at '67.
>>1.168.192.in-addr.arpa' PTR
>>Oct 11 06:42:08 cnsrv010 dhcpd: added reverse map from 67.1.168.192.in-addr.arpa. to CNWKSXP047.farmol.it
>>Oct 11 06:42:08 cnsrv010 dhcpd: DHCPREQUEST for 192.168.1.67 from 00:16:76:28:ec:34 via bond0
>>Oct 11 06:42:08 cnsrv010 dhcpd: DHCPACK on 192.168.1.67 to 00:16:76:28:ec:34 via bond0
>>Oct 11 06:42:09 cnsrv010 dhcpd: DHCPDISCOVER from 00:16:76:28:ec:34 via bond0
>>Oct 11 06:42:09 cnsrv010 dhcpd: DHCPOFFER on 192.168.1.67 to 00:16:76:28:ec:34 via bond0
>>Oct 11 06:42:09 cnsrv010 dhcpd: DHCPDISCOVER from 00:16:76:28:ec:34 via bond1: network 192.168.2/24: no free leases
>>Oct 11 06:42:09 cnsrv010 dhcpd: DHCPREQUEST for 192.168.1.67 (192.168.1.1) from 00:16:76:28:ec:34 via bond1: wrong network.
>>Oct 11 06:42:09 cnsrv010 dhcpd: DHCPNAK on 192.168.1.67 to 00:16:76:28:ec:34 via bond1
>
>which repeat every second for some minutes before they stop and the
>client gets its address.
>
>The only configuration step I made on new switches was disabling
>internal DHCP servers.
>
>Anybody experienced such problems? Any hint on where to put my hands?

The particularly interesting entries are these :

>DHCPOFFER on 192.168.1.67 to 00:16:76:28:ec:34 via bond0
>DHCPDISCOVER from 00:16:76:28:ec:34 via bond1: network 192.168.2/24: no free leases
>DHCPREQUEST for 192.168.1.67 (192.168.1.1) from 00:16:76:28:ec:34 via bond1: wrong network.
>DHCPNAK on 192.168.1.67 to 00:16:76:28:ec:34 via bond1

Do you have a shared network ? What IPs do you have configured on the server ? Is 192.168.1.1 one of them ?

It looks a bit the server can't make it's mind up whether it's on 192.168.1.0/24 or 192.168.2.0/24


Also, whilst I'm certain it won't be the issue here, is this a tree arrangement, or are there redundant links ? I've seen problems where spanning tree is in use due to the delay between connecting a device and it getting network service (default 15 or 20s I think) - and on the Netgear kit I've used, you can't selectively turn spanning tree/rapid spanning tree on/off by port. So if (like one customer we have) you need normal spanning tree for the network to function correctly, then no device works until it's been connected for 20s - by which time many devices have assumed that there is no DHCP server !