The Dynamic Host Configuration Protocol
is an internet standard and as such not specific to Linux or
Microsoft. If I recall correctly, a DHCP server was introduced in
Windows NT 3.5, so I must have been running the Microsoft DHCP Server
on my network for about eight of so years, until I recently replaced
it with a Linux implementation. I don't recall many problems with the
Microsoft DHCP Server during these years, so this piece of Microsoft
software appears reasonably stable. For me, the only reason to
migrate DHCP to Linux was not because of problems with the Microsoft
implementation, but because I was simply trying to get rid of all
Microsoft machines. As a consultant promoting all-Linux solutions for
corporates I must of course practise what I preach and run an
Whilst researching how to implement the
DHCP daemon on Linux, I discovered some interesting differences
between the two implementations. Those who are running a
heterogeneous environment with the Microsoft DHCP Server, may well
want to consider migrating DHCP to Linux.
Avoiding Duplicate Addresses
Before the Linux DHCP
daemon sends an address to a new client, it will ping the address to
see whether there is already something out on the network with that
address. In a properly configured and managed environment this should
never be the case, but... it happens. Just one simple ping with a one
second wait will add one second to the boot time of a new machine,
but it also avoids problems. If the daemon gets a response to the
ping, it will add the address to its 'abandoned addresses' list. It
won't use that address until it has completely run out of addresses.
When that happens the daemon will ping the abandoned addresses to see
whether they have been freed up, remove the free ones from the
abandoned list and use them for clients. The Microsoft DHCP Server
will simply issue an address that is free according to its database,
so it's very important to exclude all addresses that are configured
statically on machines, and to never randomly pick a free address to
(temporarily) configure on a machine for any sort of testing or
network troubleshooting. With the Linux DHCP daemon this is much less
of a problem.
The Microsoft DHCP Server does not
support failover. Resilience can only be achieved by splitting a
subnet in two equal parts and installing two Microsoft DHCP Servers,
each of them using one half of addresses for the subnet, or by making
heavy use of reservations and adding identical reservations to both
servers. Both methods have serious drawbacks: The first method
requires each subnet to be twice as big as really necessary, whilst
the other creates a major administrative burden.
The ISC DHCP server as used on Linux
support the draft DHCP failover protocol. As this is still a draft
protocol, there are no guarantees that the ISC implementation will
interoperate with other vendor's implemetations, but as long as you
are using two DHCP servers with the same version of the ISC daemon,
all should be well.
The failover protocol allows two DHCP
servers to share a common address pool. Each server will use roughly
one half of the address pool for new leases. The two servers will
exchange information about issued leases, so that when one server
goes down, the other will be available to renew leases that were
issued by the failed server. When the failed server comes back, it
will request updates from the failover server, and resume its
When configuring failover between two
servers, you specific one server as a primary and the other as a
secondary. However, this is primarily a way to get each peer to act
in the opposite way of the other. It is NOT a master/slave
relationship, and it doesn't matter much as to which is which, as
long as one is the primary and the other is the secondary.
Although this protocol is not
finalised, it is implemented in the ISC DHCP server, and works
between two ISC DHCP servers. With the Microsoft DHCP Server there
simply is no failover capability.
When DHCP was introduced, one of the biggest issues was that DNS maintenance became difficult.
As IP address for machines were assigned by DHCP, and could change over time, the old system of
static DNS files posed a problem. Today, we have dynamic DNS, where entries to a DNS zone file can
be added and removed on the fly.
In a Microsoft environment, each client can be (and needs to be) configured to register itself with DNS.
For this to work, DNS needs to accept registrations from any device on the network, which is a small (but real) security risk.
In a Linux environment, the DHCP server can register and de-register the clients' IP addresses in DNS. When a lease is
issued, the DHCP daemon registers the name and IP address of the client in DNS. When a lease expires, the DHCP daemon de-registers them.
Client devices do not need write access to DNS, creating a more secure environment.
Sometimes it is useful to be able to set the value of a DHCP Option for a client, based on a value that the
client sent in its request to the server. This can be achieved with Linux's DHCP through the use of expressions.
With Microsoft's DHCP Server it simply can't be done.
For example, a lot of companies generate names for their their workstations based on some arbitrary value, which must be
unique for each machine, but also needs to be consistent for each machine. Often the asset tag (which is usually found on a sticker
on the machine) is used for this. In many cases the hardware address of the network card in the machine would
provide an equally unique and consistent value. When using a Linux DHCP Server, expressions can be used to
generate a unique machine name for each client, based on the client's network card address, and have that machine
name sent to the client as one of the DHCP options. Doing so means that there no longer will be the need to configure
the machine name manually when installing machines, which removes another hurdle for unattended installations.
Do note that this does not work for Windows clients, as they ignore the machine name sent by DHCP. Windows machines
must have their machine name configured locally.
Groups and Classes of clients
The final difference between Microsoft and Linux DHCP that I will highlight here, is the ability to create
groups and classes of machines within the DHCP configuration file on Linux. Special options and parameters
can be set for different classes or groups of machines. For example, the lease time for a dial-in client can be
set much shorter than that for an office-based client, whilst the lease time for desktops can be set much longer than
that for laptops. With Microsoft's DHCP implementation this can only be achieved by using separate subnets
for the different classes of machines. With the Linux implementation many other factors can be used
to differentiate between these types of clients and select option values based on these.