DHCP on a Multi-Segment Network
by Dru Lavigne05/15/2003
So far in this series about DHCP I have demonstrated how to configure DHCP clients and a DHCP server for a single segment network. In today's article I'd like to finish the series by explaining how to use DHCP in a multi-segment network.
While I happen to be concentrating on the ISC software on a FreeBSD system, DHCP is a standard protocol: regardless of your particular mix of operating systems and the software you use to provide DHCP, the logic behind configuring DHCP remains the same.
What needs to be considered when using DHCP in a network that contains more than one segment? I'll discuss the following:
- the addressing and subnetting scheme
- dealing with broadcasts over multiple segments
- configuring any intervening firewalls or router access lists
IP Addressing
Before you can successfully configure a network for DHCP, you need to know the physical and logical layout of the network. If you are fortunate, this information has already been recorded, is kept up-to-date, and you can actually find the necessary documentation. If so, immediately track down the responsible administrator and buy her or him lunch.
If you're not so fortunate, grab a pen and notepad and start walking through the network. Make note of every hub or switch and how many devices are plugged into each. Work your way toward the server closet and record the number of routers or LAN router interfaces. Find the locations of any DNS servers, WINS servers, and any other servers that may require static addresses. When you're finished, sketch out your results.
Next, determine which IP addressing scheme, if any, is currently in use on the network and add it to your sketch. If you are responsible for creating the addressing scheme, you will most likely be using one of the private range addresses:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
Here is an example of a small office with four network segments:
network ID: 192.168.10.0
subnet mask: 255.255.255.224
front office: available addresses:
subnet ID 192.168.10.32 192.168.10.33 - 61
broadcast ID 192.168.10.63
default gateway 192.168.10.62
6 workstations
server closet: available addresses:
subnet ID 192.168.10.64 192.168.10.68 - 93
broadcast ID 192.168.10.95
default gateway 192.168.10.94
DNS server 192.168.10.65
WINS server 192.168.10.66
file server 192.168.10.67
lab1: available addresses:
subnet ID 192.168.10.96 192.168.10.98 - 125
broadcast ID 192.168.10.127
default gateway 192.168.10.126
WINS server 192.168.10.97
25 workstations
lab2: available addresses:
subnet ID 192.168.10.128 192.168.10.129 - 157
broadcast ID 192.168.10.159
default gateway 192.168.10.158
15 workstationsIt's important to record the subnet ID and broadcast ID of each network segment, as those two addresses are unavailable for use as host IDs. Each segment will have a unique default gateway address which must be a valid host ID for that segment. If you're rusty on subnet masking or don't understand the subnet IDs and broadcast IDs in the above chart, you may find the following URLs helpful:
- http://www.3com.com/other/pdfs/infra/corpinfo/en_US/501302.pdf
- http://www.cisco.com/warp/public/701/3.html
Now let's see how the sketch of a network translates into a DHCP server configuration file. Remember that you will need a subnet declaration for each network segment. For the example above, I would need four subnet declarations or something like this:
$ more /usr/local/etc/dhcpd.conf
#global options
option domain-name "smallcompany.com";
option domain-name-servers 192.168.10.65;
option netbios-name-servers 192.168.10.66, 192.168.10.97;
option netbios-node-type 2;
default-lease-time 86400;
max-lease-time 86400;
authoritative;
ddns-update-style none;
#front office
subnet 192.168.10.32 netmask 255.255.255.224 {
range 192.168.10.33 192.168.10.61;
option routers 192.168.10.62;
}
#server closet
subnet 192.168.10.64 netmask 255.255.255.224 {
range 192.168.10.68 192.168.10.93;
option routers 192.168.10.94;
}
#lab1
subnet 192.168.10.96 netmask 255.255.255.224 {
range 192.168.10.98 192.168.10.125;
option routers 192.168.10.126;
}
#lab2
subnet 192.168.10.128 netmask 255.255.255.224 {
range 192.168.10.129 192.168.10.157;
option routers 192.168.10.158;
}See how straightforward the subnet declarations are once you know
the layout of your network? You may have noticed that I've included
two additional options in the global options section. The option
netbios-name-servers refers to WINS, so it includes the IP
addresses of the two WINS servers. It is followed by the option
netbios-node-type which I have set to 2. There are four
possible node types:
| Value | Type | Description |
|---|---|---|
| 1 | b-node | uses broadcasts instead of a WINS server |
| 2 | p-node | only uses a WINS server |
| 4 | m-node | tries a broadcast first, then a WINS server |
| 8 | h-node | tries a WINS server first, then a broadcast |
The node type tells a computer running a Microsoft OS how to deal with NetBIOS name resolution. This type of name resolution is required whenever a computer needs to access a resource on a Microsoft network. In networking land, broadcasts are considered to be a bad thing and are discouraged when there are alternative ways to get the job done. The alternative in a Microsoft network is to use a WINS server. Microsoft has more information about node types and netbios name resolution.
The two WINS server options don't have to be global options. For
example, if only lab1 contains Microsoft operating
systems, I could remove those two options from the global section and
instead insert them into lab1's subnet declaration:
#lab1
subnet 192.168.10.96 netmask 255.255.255.224 {
range 192.168.10.98 192.168.10.125;
option routers 192.168.10.126;
option netbios-name-servers 192.168.10.66, 192.168.10.97;
option netbios-node-type 2;
}Pages: 1, 2 |
