LINKS

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:

A range of IP addresses you can hand out

Knowledge of which other IP settings you want to configure

A DHCP server

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 192.168.7.10 to 192.168.7.50 - 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 192.168.7.1-254
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:

Host PC0049 (192.168.7.2) appears to be up
Host PC0003 (192.168.7.12) appears to be up
Host PC0012 (192.168.7.13) appears to be up
Host PC0031 (192.168.7.14) appears to be up
Host PC0044 (192.168.7.15) appears to be up
Host PC0009 (192.168.7.16) appears to be up
Host PC0011 (192.168.7.17) appears to be up
Host PC0019 (192.168.7.18) appears to be up
Host PC0022 (192.168.7.19) appears to be up
Host PC0030 (192.168.7.22) appears to be up
Host gw1 (192.168.7.254) 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 192.168.7.0/24 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 192.168.7.254 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).

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.

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 10.65.0.0/16 assigned to it. All DHCP workstations can be found in 10.65.5.0/24, and the gateway will be 10.65.5.254. Your preferred DNS server will be 10.65.2.2. Your Maidenhead site has the range 10.62.0.0/16, all DHCP workstations are again in 10.62.5.0/24, and the gateway will be the .254 address. So, you can create a sort of template with netsh commands like this:

The above will create a scope on the DHCP server at 10.221.1.147, 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 lineint vlan99 - which tells us which VLAN we're configuring the helper for. You might want VOIP/Workstation/ILO/Printer VLANs to talk to different serversno ip helper 10.10.199.4 - to remove a pre-existing IP helperip helper-address 10.10.221.50 - to add the new oneendshow 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?