Re: DHCP timeout is too short for this college network
- From: José Queiroz <zekkerj gmail com>
- To: networkmanager-list gnome org
- Subject: Re: DHCP timeout is too short for this college network
- Date: Mon, 11 Jan 2010 17:02:48 -0200
2010/1/11 Sven Nielsen <post svennielsen de>:
> Ask the dhcp team on your campus why they are giving away DHCP leases
> for 3! days (286274 seconds):
>
>> >> Jan 10 21:40:12 DHCPACK of 149.106.215.247 from 149.106.192.253
>> >> Jan 10 21:40:13 bound to 149.106.215.247 -- renewal in 286274
> seconds.
>
> Maybe the DHCP server is continously short on free IP addresses because
> many addresses that are actually free, are still bound to clients that
> connected e.g. 2 days ago. (It surely gets hundreds of requests every
> day.) Might be that every time it tries to process a DHCP requests, it
> has no addresses left and then has to go through all addresses manually
> by way of pinging them to find out which ones are not in use anymore
> before it finds a free address. This might easily be one of the causes
> for the long delays.
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.
>
> Also, perhaps the DHCP configuration should be divided into two address
> pools (it it isn't already), one address pool for resident computers
> (Destkop PCs and laptops of university staff), and another pool for
> student laptops (unknown DHCP clients).
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.
Is there a better way to do that? o_O
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]