DHCP client takes too much time to get IP address

[Alessandro FAGLIA]

-------- Original Message  --------
Subject: Re: DHCP client takes too much time to get IP address
From: Simon Hobson <dhcp1 at thehobsons.co.uk>
To: dhcp-users at isc.org
Date: Wed Nov 14 2007 13:11:58 GMT+0100 (ora solare Europa occidentale)

[...]

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

The DHCP server acts also as firewall (Shorewall) with 5 NICs.
eth0 is connected to the ISP router and has a public IP
eth1 and eth2 are enslaved as bond0, and serves network 192.160.1.0/24
eth3 and eth4 are enslaved as bond1, and serves network 192.160.2.0/24

bond0 is bind to 192.168.1.1/24
bond1 is bind to 192.168.2.1/24

Unfortunately, I inherited a weird network layout where devices belongs 
to two networks that share the same medium. This medium is made by one 
switch (the center of the star) and four smaller ones connected by means 
of optical links.

bond0 and bond1 are connected to the same first switch (I know this 
sounds weird, but this is a issue I cannt fix in short time).

This is an excerpt of my dhcpd.conf.
In my mind, known hosts are assigned to subnet 1 or 2 depending on their 
MAC addr. Guests with known MAC addr are put into range 
192.168.1.180-192.168.1.19 while those with unknown MAC are put into 
192.168.1.170-192.168.1.179 (for which the firewall close all doors).

subnet 192.168.1.0 netmask 255.255.255.0 {
   option routers 192.168.1.1;
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.1.255;
   option domain-name-servers 192.168.1.1;

   # guests with unknown MAC addr
   pool {
     range 192.168.1.170 192.168.1.179;
     allow unknown clients;
   }

   # guests with known MAC addr
   pool {
     range 192.168.1.180 192.168.1.199;
   }
}

group {
   default-lease-time 43200;
   max-lease-time 86400;
   option netbios-name-servers 192.168.1.1;
   use-host-decl-names on;

   host <...> {
     hardware ethernet <...>;
     fixed-address 192.168.1.20;
   }
[...]
}

# Guests with known MAC addr
group {
   default-lease-time 43200;
   max-lease-time 86400;
   use-host-decl-names on;

   host <...> {
     hardware ethernet <..>;
     fixed-address 192.168.1.180;
   }
[...]
}

group {
   default-lease-time 43200;
   max-lease-time 86400;
   option netbios-name-servers 192.168.2.1;
   use-host-decl-names on;

   host <...> {
     hardware ethernet <...>;
     fixed-address 192.168.2.50;
   }
}

include "/etc/dhcp-dns.key";

update-static-leases on;

zone farmol.it. {
         primary 127.0.0.1;
         key DHCP_UPDATER;
}

zone 168.192.in-addr.arpa. {
         primary 127.0.0.1;
         key DHCP_UPDATER;
}

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

Probably the explanation I made should have cleared your mind...

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

I don't think I have redundant links, the netwotk topology is a star so 
a point can be reached only by one path. There are no loops.


Thanks for your suggestions.
--Alessandro