Re: DHCP timeout is too short for this college network

Am Montag, den 11.01.2010, 17:02 -0200 schrieb José Queiroz:

> I understand that, if the address pool is exausted, the DHCP server
> should respond immediatelly with a DHCPNACK, and not start a ping
> sweep to find free addresses.
from dhcpd.conf (

"... If no addresses are found that can be assigned to the client, no
response is sent to the client."

DHCPNACK only happens when there is an active deny condition for the
specific client to use a specific IP.
I was wrong about the ping though. I thought the server would do this
periodically in "crowded" situations. However, it is only true for
abandoned ip addresses:

"The  DHCP  server  checks IP addresses to see if they are in use before
allocating them to clients. It does this by sending an ICMP Echo request
message to the IP address being allocated. ..." (read on to get the
detailled process.)

There surely is some issue with the DHCP server. Badly configured
network, too much load on the DHCP server computer through other
processes and daemons, badly configured failover DHCP servers etc. etc.
could be dozen causes. I know, it is extremly tricky to resolve network
problems once you have them ;)

But, reducing the lease time might as well help, at least admins might
give it a try for a few days. Although, exhausted address pool should
have showed up in the logs which the admins most probably checked

> The only way I can think of to implement this division without
> separating "known" and "unknown" clients in independent broadcast
> domains (by means of physical separated switches, or even VLANs), is
> pre-registering the known clients in dhcp configuration.

I'm afraid, yes. VLANs however, are one option which should really be
considered, especially for security reasons. Chances are there already
is a VLAN infrastructure or even multiple physically separate networks,
because having critical research and accounting PCs on the same net with
freely accessible lan ports or wlan access points is not a very wise
thing to do, obviously.

Well, back to your questions. Surely it is now bug in nm. However it
still is frustrating to have all Windows and Macs connect when linux
won't. That should not happen. Even when it is the other ends fault. So,
I hope the response mailed earlier by John Mahoney was of some help ;)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]