DHCP Server

Note: The purpose of this page is not to tell you how to set up a DHCP server, as the details of that will have more to do with the distribution you run than can be easily explained. The point is to show you how to make an existing installation of ISC's dhcpd obtained through your distribution's package manager do what you need it to do to eliminate the problems associated with hosts occasionally moving to different IP addresses on your home network. Very little beyond that should be mentioned here in order to keep from confusing people.

Required Knowledge

DHCP stands for Dynamic Host Configuration Protocol. It is a mechanism by which hosts which do not have an IP address already explicitly assigned can simply ask the local network what IP address should be safe for them to use. This dramatically simplifies putting new equipment on your network since you'll no longer have to manually set this information on each and every host. There are some security considerations involved in this, but thankfully since DHCP's scope is limited to the local broadcast domain (i.e., your home network) they can largely be solved by the application of a suitable blunt object to the offending user or network-connected device.

Ethernet devices (like your computer's network interface card, your hubs, and your switches) talk to each other directly in a way similar to how you might understand IP addresses work. Each ethernet-connected device has a unique address called a [MAC address], which is a set of six octets (usually represented as hexadecimal and separated by a colon or dash) that uniquely identify it on the local network. The local network will generally be referred to as the [broadcast domain] which has a slightly different and significantly more specific meaning. A broadcast domain is basically all devices directly connected to each other by a hub or a switch (not a router)--this is the equipment that will be reached by ethernet broadcast-addressed packets. DHCP allows hosts to make IP address requests on the network without having an IP address of their own by use of these broadcast-addressed packets. You will need to know the MAC address of the devices you want manage individually with DHCP. If you don't know them yet don't worry--it's relatively easy to find out what they are.

When your DHCP-aware device asks the network for an IP address, if one is available, it's given a lease to use that address for a given amount of time from a pool of IP addresses that the DHCP server has been told it can manage. The DHCP server's job is to keep track of which IP addresses are currently leased and which aren't. A good DHCP server (like ISC's dhcpd) can also be given extra instructions and information about what to do with specific hosts, identified by their MAC address. Unless something different has been specifed for a given host (i.e., computer) it will be given a dynamic lease, meaning that the DHCP server just picks an IP address from the set of IP addresses it's allowed to give out and this address is not guaranteed to always remain the same, but generally won't change for reasons we won't go into right now. If you've configured the DHCP server to give some hosts static leases, the IP address the DHCP server gives those hosts will never change. For the purposes of this documentation, we're focusing on setting up static leases for your MythTV equipment while allowing everything else to simply have a more or less random address assigned to it.

Note: The DHCP server program is called 'dhcpd' and the most common DHCP client programs are called 'dhclient' or 'dhcpcd'. Killing the DHCPd server simply means that there won't be anything to respond to DHCP requests on the network until you start it again. Killing the DHCPd client on a host often turns off the ethernet interface it was managing as a side-effect which will quickly lock you out of the machine if you were doing this remotely across that interface! The extra 'c' is something people often miss, so take care that you don't get them mixed up.

Server Basics

Get and install the DHCP server package from your distribution's repository. Practically all distributions have ISC's dhcpd implementation available, and it's name is usually something unimaginative like "dhcpd-x.x.x". Once it's installed and running (this is very much distribution-specific) it will now respond to any DHCP requests it sees on the network.

If you have a home router/firewall that's already assigning leases, this documentation will not help you use it's DHCP server, and quite frankly most of them aren't going to be very useful because many don't let you set up any static leases at all. If yours does and you can find the documentation for it, stop reading this and go see if you can use it to set up static leases for some hosts--it might be easier. If it can't (like many) or you're looking to do something more advanced, keep reading.

Populating /etc/dhcpd.conf

Once you've got ISC's dhcpd installed (whether it's running or not right now doesn't matter) we'll start by telling it what IP addresses it's allowed to manage for you. This is done with a quick edit to it's configuration file, which is almost always /etc/dhcpd.conf, although sometimes it is /etc/dhcp3/dhcpd.conf. You will need root access (or sudo) to modify this file. If it doesn't exist there it may be elsewhere in /etc and typing `find /etc -name dhcpd.conf` will tell you where. For people who just wanted to set up a DHCP server for their local LAN who don't care about static IP addresses, a few global declarations are all that are needed. Since the primary goal of this documentation is to set up some static leases, we'll have a few host-specific declarations as well.

Server-specific declarations

In order to keep things as simple as possible, we're going to start with the things that affect the DHCP server itself and then work our way "outwards" to things which affect the entire network, and then more specific things that affect individual hosts. Our basic configuration will then start with these two directives which are meant to avoid a few common pitfalls associated with running a DHCP server:

ddns-update-style none;
one-lease-per-client true;

Setting ddns-update-style to none tells the DHCP server to not try updating DNS information for the hosts it manages, because that's a wholly separate problem we're not addressing and if you know what that entails you probably don't need to be reading this at all. Setting one-lease-per-client to true makes it so that if one of your hosts explicitly requests a different IP address for some reason while it already has another still-valid lease assigned to it that the DHCP server will consider the older lease abandoned and free up that IP address for something else. This is important because there are a lot of circumstances (dual-booting, dimwitted network appliances, etc.) under which a host might request an entirely new lease while an old one is still technically valid. Over time, this can cause your DHCP server to think all the IP addresses it can give out are in use and it will begin telling DHCP clients "Sorry, I've got nothing for you" when it runs out of "free" IP addresses.

Global declarations

We'll talk about the much more important global section next, and it might require a tiny bit of knowledge about binary math and bitmasks. Basically, this section tells the DHCP server which network block (or blocks if you set up more than subnet declaration) it's supposed to be a part of as well as what IP addresses in that network block it's allowed to hand out. It looks like this (and you can probably just cut and paste this as well):

subnet 192.168.1.0 netmask 255.255.255.0 {
  authoritative; 
  range 192.168.1.16 192.168.1.127;

  max-lease-time 518400;
  default-lease-time 172800;

  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.1.255;
  option routers 192.168.1.1; 

  option domain-name "home.int";
  option domain-name-servers 192.168.1.1;
}

The sample above assumes that like most people, you're using the IANA-reserved 192.168.0.0/16 [private network] block as a Class-C network block of 192.168.1.0/16, since this is the most common configuration used on home networks. There are other IANA-reserved netblocks you can use, but stick with this one unless you're familiar with them because it will reduce the number of unpleasant suprises you may encounter.

The range statement inside this subnet declaration is really important since it tells the DHCP server that those are the lowest and highest IP addresses it's allowed to hand out. In this sample, the DHCP server will be managing the addresses from 192.168.1.16 to 192.168.1.127. We're telling it to start at the fifteenth available address (.16) instead of the first to avoid any complications with misbehaving appliances (since many devices like to assume 192.168.1.1 is free) and the IP address of your gateway to the internet (which is likely to actually be 192.168.1.1). We're also telling it to leave anything higher than .127 alone simply because you probably won't need more than 111 leases in your home and there are no problems caused by this that would be solved by merely doubling that amount. You can set it higher if you like, but there's virtually no point in doing so.

The max-lease-time and default-lease-time arguments are specified in seconds (the samples are quite long enough), and they're important. If a host requests an IP address for a positively ludicrous amount of time (like four years), they'll be told they can only have that address for the maximum time you set. If a host requests an IP address and doesn't specify for how long it wants it, it'll be given the default lease time. Note that just about every well-behaved DHCP client will try to refresh their lease when that lease is half-expired in order to reduce the chance they'll wind up having to move to a new IP address while something important is going on. A well-behaved DHCP server should never have a problem renewing a lease for an IP address that a host is already leasing.

The next stanzas specify the other very important bits that you would normally have to set manually on each and every host on the network. When the DHCP server gives a host a lease, it will also pass this information along to the DHCP client to help it get everthing else set up properly. The subnet-mask option tells the host what the subnet mask for the network is. The broadcast-address tells the host what the broadcast address for the network is. The routers option tells the host where your network gateway is. This should be set to the default gateway address for your network and as such, the most common thing is going to be your router/firewall which is probably sitting at 192.168.1.1.

The last two lines tell the host what the domain name in use is, and it's reasonably okay to simply make something up there, as long as it does not match any "real" domain name in use. You can leave that option out entirely if you like. You will want to specify at least one nameserver for your hosts. If you have your own DNS server running, or your router is providing DNS service, use that address. If your ISP has given you the addresses of some nameservers to use, you may use those. Multiple IP addresses should be separated with a comma.

There are other option declarations that you might find useful, but DHCP clients and their hosts aren't always guaranteed to care about this information when they're given it. One such useful-but-often-ignored option is the ntp-servers option. If you have an NTP server available on your local network in an attempt to keep all of your clocks strictly synchronized, you can specify it this way, although Windows and OSX machines are more likely to pay attention to this setting than Linux machines are (without some hackery on the dhcp client).

With just this much in place, you may now restart (or start) the DHCP server for the changes you've made to dhcpd.conf to take effect, and the DHCP server should begin responding to requests for leases with an address between 192.168.1.16 and 192.168.1.127 without any further work on your part. However, since the whole point of this documentation is to avoid hosts being given some random IP address in that range, we're going a bit further still.

Host-specific declarations

To start assigning static leases for specific machines, we're going to have to first define a group for them to be a part of. These type of groups don't need names, and it's recommended you at least use comments to describe these groups if you create more than one. A group declaration will involve curly braces just like the subnet declaration above, and inside that group we'll create host-specific entries for each host you want to assign a static lease to. This section will look like the following:

# These machines are on static leases
group {
  # Option statements here will be sent to the entire group
  host mythbackend {
    hardware ethernet 00:23:54:1d:98:f4;
    fixed-address 192.168.1.13;
  }

  host mysqlserver {
    # Options put here will only be sent to host mysqlserver
    hardware ethernet 00:19:66:71:aa:0f;
    fixed-address 192.168.1.14;   
  } 

  host mythfrontend {
    hardware ethernet 00:1c:dd:0f:aa:9d;
    fixed-address 192.168.1.15;   
  }
}

The host declarations inside the group declaration are just as simple as they look. In the example, we wish to assign static leases for the frontend machine, the backend machine, and the mysql server. Your setup might not need this many, but again, we're trying to make everything as obvious as possible. Each host declaration involves the name of the machine (which is a name you use to identify them which has nothing to do with their DNS name), the ethernet hardware (MAC) address used by the machine, and the IP address that you are assigning exclusively to that host.

You may have noticed an apparent contradiction in the above sample. Note that while the DHCP server has been told to use the range of addresses from 192.168.1.16 to 192.168.1.127, these address are outside that range. This is fine (as long as they're within the subnet) and will avoid confusion later if you're trying to troubleshoot a problem. This will also make your network environment in general a little more easy to identify. Anything that winds up with an IP address in the pool of 192.168.1.16 to 192.168.1.127 you will be able to tell wasn't immediately recognized as anything special by the DHCP server and is on a dynamic IP assignment. If the hosts you wanted to have a static IP address wind up in that pool, then you know that either you forgot to restart the DHCP server after you modified dhcpd.conf, that you typo'd the MAC address (or that they haven't tried to get a DHCP lease since you did this), or that something else went awry (most likely another DHCP server you forgot about was running).

Note: If you are doing any BOOTP or PXE booting of machines on your network, this section would also be the appropriate place to put those entries. There is another page on this wiki that describes PXE booting for the purposes of booting diskless machines, but that's beyond the scope of this page.

Adminstrative Tricks

Option statements are optional

While there's a lot of option statements that can be passed to a DHCP client, the sad truth is that most of them beyond the option specifying nameservers and the host's domain name are generally ignored by the client machine. Here are some example options which you may wish to use, but doing so is generally wishful thinking:

• ntp-server - This option should tell the host which server on the local network is available for NTP time synchronization.

Finding out the MAC address

Now that you know what goes into your dhcpd.conf, we'll address the one missing piece of the puzzle: How to find the MAC (ethernet hardware) address of your equipment. The MAC address for a network device is kept in the hardware and will never change (unless you do something really you shouldnt' have, they must be unique on your network--do not attempt to change them for the purposes of mere vanity!). Simply type `/sbin/ifconfig` and look for the interface you want to know the MAC address for in the output. If it doesn't appear, it's probably in a "down" state. Assuming that the interface you want the address for is eth0, you can remedy this without risking anything bad happening by simply typing `/sbin/ifconfig eth0 up` and then typing `/sbin/ifconfig eth0` again. For a host currently running Windows, you can find out the MAC address with a very similar command called 'ipconfig' run from a DOS prompt--just remember to replaces the dashes Windows uses with colons when you create the host entry.

If the piece of equipment is something you can't run a prompt on (like a PS3 or XBox or if you're just feeling too lazy to bother) and it was already using DHCP to get an address, you can also just go look in the file the server uses to store information about leases it's already handed out--just don't expect a lot of it to make sense. Usually this is /var/state/dhcp/dhcpd.leases, and it's simply a plain text file. It will contain some lease declarations in a format similar to the rest of what you've seen here, listed by IP address and each section will show the hardware ethernet address for the host that IP address was assigned to. By the way, don't edit this leases file manually and definitely don't do it while the DHCP server is still running.

Tip: The first three octets of a MAC address actually have a specific meaning--the rest are essentially random to avoid two pieces of equipment ever even accidentally using the same MAC addresss. You can very often find out who made a piece of hardware you don't recognize by finding the first three pieces of the MAC address in [this list], and doing so should let you at least see which address belongs to your Xbox or PS3 should you be struck by incredible levels of laziness while trying to assign assigning static leases.