We don't believe in DHCP for (our) servers

August 31, 2014

I understand that in some places it's popular for servers to get their IP addresses on boot through DHCP (presumably or usually static IP addresses). I understand the appeal of this for places with large fleets of servers that are frequently being deployed or redeployed; to put it one way I imagine that it involves touching machines less. However it is not something that we believe in or do in our core network, for at least two reasons.

First and lesser, it would add an extra step when setting up a machine or doing things like changing its network configuration (for example to move it to 10G-T). Not only would you have to rack it and connect it up but you'd also have to find out and note down the Ethernet address and then enter it into the DHCP server. Perhaps someday we will all have smartphones and all servers that we buy will come with machine readable QR codes of their MACs, but today neither is at all close to being true (and never mind the MACs of ports on expansion cards).

(By the way, pretty much every vendor who prints MACs on their cases uses way too small a font size.)

Second and greater, it would add an extra dependency to the server boot process. In fact it would add several extra dependencies; we'd be dependent not just on the DHCP server being up and having good data, but also on the network path between the booting server and the DHCP server (here I'm thinking of switches, cables, and so on). The DHCP server would become a central point of near total failure, and we don't like having those unless we're forced into it.

(Sure, we could have two or more DHCP servers. But then we'd have to make very sure their data stayed synchronized and we'd be devoting two servers to something that we don't see much or any advantage from. And two servers with synchronized data doesn't protect against screwups in the data itself. The DHCP server data is a real single point of failure where a single mistake has great potential for serious damage.)

A smaller side issue is that we label our physical servers with what host they are, so assigning IPs (and thus hostnames) through DHCP creates new and exciting ways for a machine's label to not match the actual reality. We also have their power feeds labeled in the network interfaces of our smart PDUs, which would create similar possibilities for exciting mismatches.

Comments on this page:

By Ewen McNeill at 2014-09-01 05:06:48:

I tend to provision (static) IPs onto servers too (letting the config management tool do what DHCP might have done), except netbooted machines.

But it's worth remembering that DHCP's default behaviour is to do a DHCP RENEW well before the lease time is up, and to use cached values if the no DHCP server is available. Which given long lease times for servers, would paper over most of the boot-order issues.

Besides if you already rely on centralised authentication, and your DHCP servers are colocated with your authentication servers (a common design pattern), then those machines are going to want to be amongst the first booted anyway. (Give or take credential caches.)


PS: I do agree on the miniscule font problem. Fortunately as a friend points out, modern cellphone cameras make pretty good magnifying glasses.

Written on 31 August 2014.
« The downside of expanding your storage through bigger disks
An IPv6 dilemma for us: 'sandbox' machine DNS »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Aug 31 21:40:13 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.