Tim: >> But are you talking about configuring a DHCP client or server? Timothy Murphy: > Sorry, I mis-read the query. > I was thinking of a DHCP server The same basic answer still stands: A DHCP server, by default, doles out dynamic IPs. In other words, until an administrator customises the configuration, it doesn't absolutely associate a particular IP with a particular device. Leases are doled out from a pool of available addresses, and while there are un-used ones spare, it'll dole out these new un-used ones to new devices, re-issuing the same IPs to previous devices, if possible. There's a time period involved, so that a leased IP is kept in reserve for that device for a while, then it's no-longer reserved, and may be doled out to anything that asks for an IP. There's no standard period, that's up to whoever configured the package, and administrators can customise the lease time periods to suit themselves. Once the spare addresses run out, the DHCP server will start re-using IPs where the leases have expired, and that aren't currently in use (only a stupidly configured server will try to rip an IP off a currently active device and try to give it to someone else, but then some networks are run by idiots). A server could re-use expired-lease addresses before the spare un-used IPs have run out, but I haven't seen mine do that. It always worked through the pool of previously un-used IPs before re-using an older one. That way, even when the lease has expired, a machine is still likely to get the same IP as it had last time. My ISP doesn't work that way, if I disconnect for long enough (about over half a minute), I usually get a new random address. Which is handy if there was some sort of networking problem, I'm likely to bypass it on my next connection attempt. In general, dynamic IPs are doled out sequentially, rather than purely randomly. Some servers may dole them out from highest available IP number down to lowest, others may go the other way. But there's a convention amongst administrators to set static IPs from lowest upwards, and dynamic IPs from highest downwards, that some DHCP programmers seem to go along with. Static address assignment, where the same device always gets the same address, depends on the administrator configuring the DHCP server to work that way. It's usually done by associating a devices MAC with a particular IP, but there are other ways of doing it. DHCP clients, probably by default, may ask the server to give them the same IP as they had last time, but the server doesn't have to comply with client requests. Likewise, it should be possible for a client to be manually configured to ask for a specific address, but it's still okay for the server to ignore that and tell the client what it's going to use. On my LAN, I have a mix of static and dynamic addresses doled out by the DHCP server, and those addresses are put into the local DNS server (static ones put into the DNS server by me, dynamic ones managed by the DHCP server updating the DNS server). Certain machines which are always here get preset addresses, for the sake of my convenience, more than anything else. Any servers would get preset addresses, for the sake of less networking headaches, as wandering server addresses can upset everything else trying to access them, and make configuring their firewalls a lot more annoying. Clients, generally, don't do machine to machine networking, so changing their IP addresses rarely causes a problem. Only the DHCP server and the router have manual network configuration set on themselves with fixed addresses, such machines should never change addresses, and should be able to run stand-alone without having to be configured externally. Centrally managing all the machine addresses on the DHCP server, whether that be the hands-off dynamic addressing of new computers, or preset addressing of regular computers, means that I never have have mess with hand configuring the network settings of any computer that I plug into the LAN, at all. I don't have to learn six different ways of configuring a client, because they have different OSs, or because of all the changes that different versions of each OS has inflicted upon us. I don't need to get admin passwords to computers to get them on the net. I don't have to set their IPs, netmasks, DNS servers, mess with host files, etc. I just plug them in and they work. For what it's worth, I find it far better to centrally manage any network greater than about three machines. Above that, it becomes a right pain having to hand configure each machine, and deal with any changes that happen to your network. While you might think that you're not going to change IPs, it happens as soon as you have to replace something like a modem/router, or networked printer, that insists that it has to be 192.168.1.something rather than 192.168.0.something that your network was currently configured to use, because the damn fool device designers don't know enough about networking. Probably everything you needed to know, and more, about DHCP... NB: "By default" may refer to what the software does by default, as programmed by the author, and will do whenever there's no configuration file. Or, refer to what the installation of that software does on your computer, as configured by who put the package together, dependent on their prepared configuration files, and may be quite different from the program's defaults. Hence, why one has to be careful at presuming what the defaults may actually be, when reading the man files. When in doubt, do tests, or configure the software exactly how you want it. -- [tim@localhost ~]$ uname -rsvp Linux 3.8.12-100.fc17.x86_64 #1 SMP Wed May 8 15:36:14 UTC 2013 x86_64 All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org