DHCP server problems with static IP clients

While there are some server functions that must have locally defined IPs, I'm a huge fan of using DHCP for server addresses.

First, as others have noted, you can (and should) use DHCP to serve up static addresses. Assuming Linux, you want this in your dhcpd.conf:

host server {
        option host-name "server.example.com";
        hardware ethernet  xx:xx:xx:xx:xx:xx;
        fixed-address server.example.com;
}

And in your DNS zone file, assign an IP to server.example.com.

Pros:

• The DNS zone file is now the 'one source of truth' for all IP assignments. Makes it easy to look for errors (duplicate IPs, typos), and ensures that everyone can find the server's IP address without error
• Changes to network infrastructure can be propagated easily. Rolling out a backup DNS server? Just add it to the DHCP config file, and all systems will pick it up as they renew their leases.
• Changes to the machine's IP and the machine's DNS entry can't, by definition, get out of sync. Moving a machine to a new subnet? Change the IP in exactly one place, and you're all set.

Cons:

• You've added a significant point of failure. Mitigate that with backup DHCP server. Long lease times can also help.
• Spanning tree learning mode blocks DHCP requests, which can significantly lengthen machine boot times, and even cause DHCP timeouts. Use portfast to turn off spanning tree on select ports. Good idea for workstation, too, by the way.

My understanding of DHCP is, a client broadcasts a DHCP Discovery request on the network, and any device on the network can respond.

A client can make an unicast DHCP request too, the renewal request is made in unicast, so the client requests directly the DHCP Server. What if the DHCP changed his original IP address ? The renewal will fail and the next request will be made in broadcast. Which is not a behavior that will optimize your network traffic.

Microsoft:

Renewing a Lease The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known as T1, has passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP server that originally granted its lease. If the server is available, and the lease is still available, the server responds with a unicast DHCPAck message and the lease is renewed.

Source

ISC:

Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:0c:29:ac:18:75
Sending on   LPF/eth0/00:0c:29:ac:18:75
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 << First request
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.0.0.253
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 133 seconds.



DHCPREQUEST on eth0 to 10.0.0.253 port 67 << Renewal
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 119 seconds.
DHCPREQUEST on eth0 to 10.0.0.253 port 67
DHCPACK from 10.0.0.253
bound to 10.0.0.6 -- renewal in 118 seconds.

Once the lease has been granted, however, future DHCP DHCPREQUEST/RENEWAL messages are unicast directly to the DHCP Server

Source