Home » Network »DHCP


DHCP stands for 'Dynamic Host Configuration Protocol'. It is used to assign IP addresses and other information to computers, thus saving the IT department from having to visit each and every computer and assign it a static address.

Setting up DHCP on a small network is relatively simple, and if you use a broadband router with wireless capability, the chances are that you're already using DHCP. All you need is:

In this example, we'll look at using Windows Server 2003 as a DHCP server. You can run a DHCP server on pretty much anything. Almost all Linux distributions will have a DHCP daemon available. Hell, you could probably even get one for the Amiga if you really wanted to.

Range of IP Addresses

First in our list of requirements was a range of IP addresses that you can hand out. Hopefully you've already got a network up and running, and you've got some idea about which addresses you use. Let's say your computers are currently using the addresses to - so you won't want to hand those addresses out just yet. Ultimately, you're wanting to make every address between .10 and .100 available for dynamic use.

Just to be sure, we're going to do a quick ping sweep of the network to find out what's already being used. If you already have a tool which does this, use that. If not, I'd suggest you go get yourself a copy of NMap, and use that.

The syntax we're going to use here is:
nmap -sP
Which will scan all the addresses between .1 and .254 and tell us what it's found.
Before long you should see something like this:

Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-01 12:46 GMT Standard Time

Host PC0049 ( appears to be up
Host PC0003 ( appears to be up
Host PC0012 ( appears to be up
Host PC0031 ( appears to be up
Host PC0044 ( appears to be up
Host PC0009 ( appears to be up
Host PC0011 ( appears to be up
Host PC0019 ( appears to be up
Host PC0022 ( appears to be up
Host PC0030 ( appears to be up
Host gw1 ( appears to be up
Nmap finished: 254 IP addresses (11 hosts up) scanned in 6.016 seconds

So now we have a clearer idea of what sort of range is currently in use. Note that the .2 address is in use. One which we weren't expecting, so we're all jolly glad we checked now, aren't we?

Scope Options

Let's create a scope on the DHCP server for the subnet.
Before we do this, we need to decide which scope options we want to configure.

Default Gateway

This is a pretty straightforward one to figure out. It needs to be the address of the router (or possibly switch) which you want to route traffic out of the local subnet. From the Nmap results above, we can see that looks suspiciously like a router. If you want to be double sure, you can check the existing configuration on the computers that are up. I tend to do this with PsExec, which you can get from Sysinternals.
Just for good measure, I'm going to scan it using nmap with the -A switch, because it's generally much quicker and less hassle than asking the network admin (don't tell him I said that).

Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-01 14:22 GMT Standard Time

Interesting ports on
Not shown: 1696 closed ports
23/tcp open telnet Cisco router
Device type: specialized¦switch¦WAP¦router
Running (JUST GUESSING) : Cisco IOS 12.x (96%), Aironet IOS 12.x (90%)
Service Info: OS: IOS; Device: router Nmap finished: 1 IP address (1 host up) scanned in 38.078 seconds

So we're happy with that address as a default gateway. You can add extra gateways if you like, and you can see which ones are being picked up automatically with the route print command.

Next up, an exclusion range. The annoying thing with exclusion ranges is that they can't overlap at all. If you're transferring one scope to two split scopes on other servers, you might want to make exclusion ranges in 5 or 10 address chunks so that you can then free up addresses as and when you exclude them from the old server.

Another important one to consider is the DNS configuration.

DNS Configuration

Ideally, you'll want to have the first DNS server as one which is as close as possible to (or at least quickest to access from) where the client PCs are. After this, you'll want a server which isn't in the same subnet/VLAN/building as the original one. The reason for this is that if, say, somebody unplugs the power from your server segment switch in one location (or it gets hit by a tornado/tsunami/50 megaton yield bomb/Mariah Carey high F note) - you have another location you can talk to for DNS queries if you need to.
RFC3258, section 2.4 is the reason we choose the server closest to var first, followed by something at a separate site. It says that having geographically separate servers helps avoid service disruption, but network topology should be your primary concern. This will also help you in selecting/placing WINS servers if you need them; perhaps for Exchange.

Being Lazy

The above sections have shown some examples of using the GUI to create scopes and configure options in Windows Server 2003. This is a slow way of doing things, provided your network configuration is reasonably simple.

A far simpler method to define multiple scopes is the net shell, or netsh.exe.

By a reasonably simple network configuration, I mean several sites which are all configured much the same way. For example - your Milton Keynes site has the address range assigned to it. All DHCP workstations can be found in, and the gateway will be Your preferred DNS server will be Your Maidenhead site has the range, all DHCP workstations are again in, and the gateway will be the .254 address. So, you can create a sort of template with netsh commands like this:

netsh dhcp server add scope 10.SNUM.5.0 SITE-Scope1
netsh dhcp server scope 10.SNUM.5.0 add iprange 10.SNUM.5.1 10.SNUM.5.127
netsh dhcp server scope 10.SNUM.5.0 add excluderange 10.SNUM.5.1 10.SNUM.5.100
netsh dhcp server scope 10.SNUM.5.0 set optionvalue 003 IPADDRESS 10.SNUM.5.254
netsh dhcp server scope 10.SNUM.5.0 set optionvalue 006 IPADDRESS 10.SNUM.2.2
netsh dhcp server scope 10.SNUM.5.0 set optionvalue 015 STRING deusexmachina.local
netsh dhcp server scope 10.SNUM.5.0 set optionvalue 044 IPADDRESS 10.SNUM.2.2
netsh dhcp server scope 10.SNUM.5.0 set optionvalue 046 BYTE 8
netsh dhcp server scope 10.SNUM.5.0 set state 0

The above will create a scope on the DHCP server at, including an excluded IP address range, DNS server, WINS server, default gateway, node type and DNS suffix. Which is nice - but you have to do something with it first. You have to do a find/replace operation. You need to find all occurences of SNUM and replace them with the number of the subnet for the /16 assigned to that site. For Maidenhead this is 62, and for Milton Keynes it is 65. You also need to change SITE to the name of the site, so the scope will be appropriately named. If you have (as I once did) over 70 sites to do this for, your best bet is to use the UNIX utility SED (stream editor) to do a mass find/replace operation. I would save something similar to the above as dhcptemplate.txt, and use the SED command to do the find/replace operations and save the file as something like MKdhcp.bat for Mitlon Keynes.

You can get sed.exe from the GNU Win32 UNIX Utils, which are mentioned here - of course, if you're using a Linux or UNIX machine, you'll already have sed out of the box.

So, by running sed -e "s/SITE/MAIDENHEAD/" -e "s/SNUM/62/" L:\path\to\dhcptemplate.txt > L:\path\to\MDdhcp.bat - You'll end up with a shiny new batch file with all the information changed for you. The final line in the script will be set state 0, which ensures that you don't end up activiting a scope before you're ready to do so. You'll probably want to perform a quick due-diligence check before setting the scope to active.

Authorisation Requested

If you are running this on a windows server (versions 2000 and later), you'll need to authorise your DHCP server first in Active Directory. Since Windows 2000, DHCP servers check the Active Directory forest once every hour to determine if they are authorised to hand out IP addresses. If they aren't, you'll see your eventlogs filling up with errors. Other DHCP servers (including Windows NT Server 3.51/4.0) don't care if they are authorised or not, and will happily hand out IP addresses. Sometimes these will be incorrect, sometimes they will conflict with existing ranges, and sometimes they may be for malicious purposes. You need to train your helpdesk staff to be on the lookout for dodgy information from an ipconfig /all command. Ideally, you will have an IDS which detects rogue DHCP daemons and will do something to alert you.

A Little Help From My Friends

DHCP is not routable. That means - it doesn't traverse gateways. In your subnet, no-one can hear you scream (except other nodes on the same subnet). So what can you do when your DHCP server is sitting on a separate subnet to your workstations? Well, you could configure a DHCP Relay, but that means having some kind of device - perhaps an old NT4 server - with an interface on each subnet. This is not practical if your subnets are miles and miles apart.

No, what you need is an IP Helper. This will be configured on the gateway itself. It will simply listen for DHCP requests, and forward them on to wherever you tell it to. Hopefully a DHCP server. If you're using Cisco network equipment, you'll probably want to look at this Cisco Documentation - Routing IP.

Essentially, if you have already configured which protocols the IP helpers are supposed to be forwarding, and you've logged in and gotten to enable mode, what you need to do is:
conf t - which will prompt you to enter your config commands, one per line
int vlan99 - which tells us which VLAN we're configuring the helper for. You might want VOIP/Workstation/ILO/Printer VLANs to talk to different servers
no ip helper - to remove a pre-existing IP helper
ip helper-address - to add the new one
show run
- just to check what we've done before we remember to save the running config, right?

IP Helpers will forward much more than just DHCP/BOOTP traffic. To configure exactly which protocols should/should not be forwarded, you need to use the ip forward-protocol command to specify which protocols/ports should be forwarded.

You might be wondering how the DHCP server knows which scope to assign an address from. Well, when a request is forwarded by an ip helper, a header called GIADDR (gateway address) is added to the request. Based on this, the DHCP server knows which subnet the request has come from, and therefore which scope is going to be valid for it. Clever stuff, eh?