You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Well, the most obvious reason is to always know where the linux server is on the network. Servers tend not to move much, so assigning a static IP outside of the DHCP range will help cut down on possible confusion and/or network issues down the road.

Also, how solid is the DNS <=> DHCP binding on the network? Does the DHCP server add a DNS entry for each system it assigns an address to? A few do, but most don't. If yours doesn't, then how are you going to know where the server is when the DHCP lease gets renewed?

In many situations one might wish to have a full static network. They usually tend to come up faster and always stay up on the known addresses. Some vlan's/tunnels could be broken when dhcp renews. Many sites like to have templates of systems so that they know each computer in some place is always on. They don't have to trouble shoot any dhcp issues. There is sometimes a delay or loss of data on renews.
Server rooms are not like normal users. They don't really need many of the uses for dhcp like moving around, lack of ip addresses or pushing services like pxe boot and such.

Why not have one of them be the DHCP server?! Most of the time, when you have an internal network, once an IP address is assigned to an attached connected host's MAC it's more or less permanent anyway, or you can make it so, but still within a DHCP framework. One advantage to having one of them be DHCP server is that certain services that utilize auto detection can work better in a DHCP environment, whereas in a static IP environment, they might not work at all... Things like PXE booting and network appliance detection (embedded equipment) are the type things I have in mind... If a full blown PC is the DHCP server, firewall, and router (DD-WRT, for example).

My main server is my DHCP server for my LAN, as well as router, firewall, file server, multimedia back end, and soon,... internal Asterisk server (with at least one ATA to allow the system to grab POTS [Plain Old Telephone Service] lines). It actually sits inside another LAN (an "external" LAN, if you will). And that LAN acts as a DHCP server, router and firewall in its on write.

This from a geek running WAY past foggyhood into true geezerhood:
Client machines on a network can have static or dynamic IP addresses, servers should always be static.

This is not ONLY true of network servers or major services, but also things like Jetdirect Print servers.

Even if your DHCP server updates DNS instantly (ala dnsmasq, etc) most client machines on a network will have cached the OLD data when a server card or machine negotiates a new one. I have seen this kind of thing play out since Novell was the biggest word in networking in the world and milnet was GOING to be a good idea SOMEDAY. (Way before your time, I am sure.) Networks that allowed devices to 'float' to a new name or address (yes, even before TCP/IP) will have problems under some conditions. Those conditions are not always ones that the General or CEO is going to understand or forgive.

I have to be honest I prefer your network admin way of doing things because with that you can change every network setting from a single position and a reboot. It's easier to manage.
The only problem with that is that if the DHCP server goes down then there could be issues.

I think the real question is, why WOULD you use DHCP for a server? It makes no sense, there is no advantage...only disadvantages.

How so?!?! On a typical home network, you have a DHCP server situated within a $45-$120 router, and yet you rarely hear of failures related to that... Now combine the same software, running on a more powerful machine, with greater admin access...

I don't see that as a particularly vulnerable failure point. Plus, you may have some equipment (maybe an ATA, for example) that expects to receive IP assignment via DHCP. And once again, PXE booting without DHCP is near-impossible without shoe-horning some kind of solution in...

As for letting DHCP run away with the farm, letting anyone making a DHCP request get an IP and potentially harmful access to the network,... you can limit the MAC addresses to a pool of specifically enabled ones (and yes, I know MACs are easily spoofed).

How so?!?! On a typical home network, you have a DHCP server situated within a $45-$120 router, and yet you rarely hear of failures related to that... Now combine the same software, running on a more powerful machine, with greater admin access...

I don't see that as a particularly vulnerable failure point. Plus, you may have some equipment (maybe an ATA, for example) that expects to receive IP assignment via DHCP. And once again, PXE booting without DHCP is near-impossible without shoe-horning some kind of solution in...

As for letting DHCP run away with the farm, letting anyone making a DHCP request get an IP and potentially harmful access to the network,... you can limit the MAC addresses to a pool of specifically enabled ones (and yes, I know MACs are easily spoofed).

You seem to be misunderstanding the question behind this thread. The OP was not asking about using the server AS a DHCP server, the OP was asking about running the server as a DHCP client. That's what I was responding to. Running DHCP in your network is fine. Using one of the servers as the DHCP server is fine. But operating all of your servers on the network (file servers, mail servers, web servers, ftp servers...) under DHCP, with dynamic IP assignment, is just asking for trouble.

There are ways around the issues that arise from this, but why bother? What is the benefit in using DHCP versus static for your servers?