Droms R. The DHCP handbook
Подождите немного. Документ загружается.
Configuring Multiple IP Subnets on Each Network
Segment
It is very common to use the term subnet interchangeably with the term network
segment. Both terms are defined as any set of network connections such that a
computer plugged into any one connection can send packets to a computer plugged
into any other connection, without requiring the help of a router.
In fact, subnets are an artifact of the way IP addressing works. In order for IP routing
to work, all machines on a given subnet must be on a single network segment.
However, it is not required that only one IP subnet be configured on a single
network segment.
Some sites take advantage of this as a way of allocating address space; when a
network segment is first deployed, a single IP subnet is allocated for it. When most
of the IP addresses on that network segment have been consumed, the site adminis-
trator allocates a second IP subnet to run on the same network segment.
The ISC DHCP server documentation refers to this kind of configuration as a shared
network because one network segment is shared by two IP subnets. Another common
term for this configuration is an overlay network. In the Microsoft DHCP server, a
subnet is referred to as a scope, and a network segment with more than one subnet is
referred to as a superscope.
NOTE
Except when referring specifically to Microsoft DHCP server menu options, the word scope is
never used in this book to refer to subnets because it conflicts with the usual meaning of the
word scope.
Such configurations exhibit some unexpected behaviors. For example, two comput-
ers connected to the same network segment but with IP addresses on different
subnets cannot normally send packets to one another without the help of a router.
In theory, the two machines should be able to transmit packets directly to each other
at the physical network layer, but the IP protocol does not allow it
Address Allocation on Shared Networks
Because the network administrator defines IP subnets and assigns them to network
segments, a client’s subnet cannot be determined just by its network connection.
The client is connected to a network segment on which any number of IP subnets
may be configured.
CHAPTER 15 Configuring a DHCP Server266
019 3273 CH15 10/3/02 4:59 PM Page 266
Thus, when a request arrives from a client, the DHCP server must first determine
from which network segment the message was sent. If the client is requesting an
existing address, the DHCP server can check the requested address to determine
whether it is from any of the IP subnets assigned to the client’s network segment. If
it is, and if the address is available for the client, the server can assign the client that
address.
If a client is asking for a new address on its network segment, however, and there is
more than one subnet from which to choose, nothing tells the DHCP server which
of the subnets on that shared network to use. The ISC DHCP server normally picks
the first available IP address from the list of available IP addresses for that network
segment. That list could contain addresses for any number of IP subnets. So, the
choice of the subnet within a shared network on which the client gets its IP address
is essentially arbitrary.
The arbitrary assignment of the subnet can be inconvenient. If clients on different
subnets must communicate through routers, it is good to ensure that clients that
might often communicate with one another wind up on the same subnet. For
instance, suppose that three departments—accounting, sales, and marketing—are
using one network segment. If you have allocated three IP subnets to that network
segment, you might prefer that all the clients from sales be located on the first
subnet, all the clients from marketing be on the second subnet, and all the clients
from accounting be on the third subnet. Chapter 20, “Conditional Behavior,”
discusses ways this can be done.
You can declare a shared network by enclosing a set of
subnet statements within a
shared-network statement, as shown in Example 15.15.
Example 15.15
shared-network FLOOR1 {
subnet 204.152.188.0 netmask 255.255.255.240 {
}
subnet 10.0.0.0 netmask 255.255.255.0 {
}
}
This declaration defines two IP subnets, 204.152.188.0 and 10.0.0.0, which share a
single network segment.
Option Scoping with Shared Networks
Although the process of selecting the subnet on a shared network on which a client
will be assigned an address is somewhat arbitrary, after that subnet is selected, the
client can be assigned parameters that are specific to the subnet. In many cases,
Configuring Multiple IP Subnets on Each Network Segment 267
019 3273 CH15 10/3/02 4:59 PM Page 267
this is required. For example, each subnet must have its own default route and may
have a different broadcast address. Options that are not globally defined for all
subnets but that are common to all clients on a shared network can be declared
within the
shared-network statement, before the subnet statements, as illustrated in
Example 15.16.
Example 15.16
shared-network FLOOR1 {
option domain-name-servers 204.152.188.10;
subnet 204.152.188.0 netmask 255.255.255.240 {
option routers 204.152.188.14;
}
subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.254;
}
}
Avoiding Routing on a Shared-Network Segment
When a machine on one IP subnet wants to send a packet to a machine that it has
determined is on the same subnet, it acquires the link-layer address of the second
machine and then sends the packet directly to that address. It does this by using
Address Resolution Protocol (ARP).
Suppose a machine with address 10.0.0.1 wants to communicate with a machine
with address 10.0.0.2. It broadcasts an ARP packet that asks , “Who has IP address
10.0.0.2?” The machine with that IP address replies: “I have 10.0.0.2, and my link-
layer address is 08:00:2b:4c:29:3d.” The machine at 10.0.0.1 then sends the packet
directly to the machine at 10.0.0.2.
When a machine on one IP subnet wants to send packets to a machine on a differ-
ent IP subnet, it chooses a router from its routing table. It uses ARP to get the link-
layer address of that router (routers in a computer’s routing tables must always be on
a subnet to which that computer is directly connected), and it then sends the packet
to the router. That router then sends the packet on toward its final destination. On a
shared network, this means the packet is sent on the local network segment to the
router, which then sends it back on the same network segment to the destination
machine.
Proxy ARP with Microsoft Windows
The Microsoft IP implementation has a special mode, which is not specified by the
IP protocol standard, that enables machines on one subnet on a network segment to
CHAPTER 15 Configuring a DHCP Server268
019 3273 CH15 10/3/02 4:59 PM Page 268
send packets directly to machines on a different subnet of that same segment. It
does this by sending the client’s own IP address in the
routers option. When
Windows sees that its default route points at its own IP address, it treats all IP
addresses as if they are local; it never tries to send IP packets through a router.
Example 15.17 shows how to make the ISC DHCP server send the client’s IP address
for its default route.
Example 15.17
use-lease-addr-for-default-route on;
In Example 15.17, imagine that you have a Windows computer whose IP address is
204.152.188.10 and whose default route points to its own IP address. If Windows
needs to send a packet to a computer at 10.0.0.19, it broadcasts an ARP packet
asking for the link-layer address corresponding to the IP address 10.0.0.19. Because
10.0.0.19 is on the same network segment as the Windows computer, Windows
receives a response from the computer at 10.0.0.19 and then sends its packet directly
to that computer without going through a router.
However, what if that same machine wants to send a packet to another computer at
204.152.186.112? That computer is not on the same network segment. When the
first computer sends out an ARP request asking for the link-layer address of
204.152.186.112, it receives no reply because ARP broadcasts are never routed off a
network segment.
This can be solved by using a feature of many dedicated routers called proxy ARP. If a
computer on the network to which the router is connected sends an ARP request,
asking for the link-layer address of a machine whose IP address is not on the same
network segment, the router replies with its own link-layer address. This fools the
machine that is using ARP into sending the off-network packet to the router, which
then correctly forwards it to its final destination.
PROBLEMS WITH PROXY ARP
Using proxy ARP is not a good way to do IP routing, of course. No standard exists for describ-
ing how to accomplish proxy ARP; it is just a collection of ad hoc solutions that various
vendors have provided. In a very constricted, homogeneous environment, proxy ARP might
work well, but it will fail if machines from vendors that do not support it are installed.
In particular, if the DHCP server behavior shown in Example 15.17 is enabled, clients that do
not support proxy ARP will receive an incorrect default route and therefore cannot route
packets off their local network segments.
Proxy ARP also generates extra ARP traffic. Every time a machine must communicate with a
new machine that is not on the local network segment, it must send another ARP packet.
Normally, packets sent off the network segment are forwarded to the same router, whose
link-layer address is cached, so it requires only one ARP request to get the link-layer address
for all such machines.
Configuring Multiple IP Subnets on Each Network Segment 269
019 3273 CH15 10/3/02 4:59 PM Page 269
Pitfalls of Shared-Network Configurations
DHCP administrators commonly make the mistake of omitting necessary informa-
tion when they first set up a shared-network configuration. For example, say you
have a network segment with two IP subnets and you intend to supply IP addresses
for one subnet with one DHCP server and IP addresses for the other subnet with a
second DHCP server. You might be tempted to just write a subnet declaration in each
server’s configuration file for the subnet that server is intended to serve and not
mention the other subnet. The problem with this is that DHCP servers are responsi-
ble for telling DHCP clients whether their IP address is correct for a given network.
DHCPNAK Message Wars
Imagine that a
DHCP client on the shared network described in the preceding section
broadcasts a
DHCPDISCOVER packet. Both DHCP servers may respond with a DHCPOFFER
packet, each offering an IP address on a different subnet. The client chooses one and
sends out a
DHCPREQUEST for that IP address. The DHCP server whose address was not
chosen sees that the requested address is not on the subnet that it knows is
connected to the network segment on which the
DHCPREQUEST was sent. It therefore
sends the client a
DHCPNAK message. If that DHCPNAK message arrives before the other
server’s
DHCPACK message, the client does not get its address and must start over. This
DHCPNAK war can go on indefinitely.
If both servers know about both subnets, however, neither server will send DHCPNAK
messages in response to DHCPREQUEST messages for IP addresses on the subnet being
served by the other server. Clients can, therefore, be configured successfully.
If both DHCP servers are being managed by the same administrator, it is possible to
see what is happening by examining the server logs; if one or both of the servers are
sending
DHCPNAK messages in response to client requests that are correct, their config-
urations must be fixed. If one network administrator controls one of the DHCP
servers and a second administrator controls the other, a network analyzer could be
needed to solve this problem. Chapter 24, “Debugging Problems with DHCP,”
discusses this in more detail.
Cable Modem Networks
Cable modem networks are broadcast networks, just like Ethernet networks. Most
ISPs that provide cable modem service use DHCP to perform address assignment on
their networks. Some cable modem networks have extensive filtering so that a
subscriber sees only packets meant for his or her home. However, many cable
modem networks are just big LANs, where a subscriber can see every packet sent to
anybody on his or her network segment, including DHCP packets. If you set up a
DHCP server but do not configure it carefully, it is likely that the server will see a
DHCPREQUEST message sent by a computer belonging to your neighbor down the
street, deduce that the machine is asking for an IP address on the wrong network,
CHAPTER 15 Configuring a DHCP Server270
019 3273 CH15 10/3/02 4:59 PM Page 270
and thus send it a DHCPNAK message. Your neighbor is then unable to use the
Internet.
Private DHCP Server at an Office
You might also be tempted to set up a DHCP server at your office to serve your own
set of clients on a subnet setup that just happens to run on the same network
segment as your own workstation. Say, for example, that the network drop in your
office connects to a network segment with a network number of 10.0.128.0 and a
netmask of 255.255.255.0. Now, say you decide to set up a subnet for your own use
on the same network segment with a network number you know is not in use—for
instance, 10.192.0.0 with a netmask of 255.255.255.240. You configure your DHCP
server as illustrated in Example 15.18.
Example 15.18
subnet 10.192.0.0 netmask 255.255.255.240 {
option domain-name-server 10.192.0.1;
option routers 10.192.0.1;
range 10.192.0.2 10.192.0.14;
}
The minute you turn on the network, your DHCP server starts listening for DHCP
messages. DHCP doesn’t generate much traffic on a typical network. After a DHCP
client has its initial configuration, all further exchanges with the DHCP server are
unicast, which means the DHCP server you have installed does not see requests from
clients unless they are just starting out on the network. If you set up a server in this
way, chances are that the first time it sees a DHCP request from a computer other
than your own will be the next morning, when computers that were powered down
for the night are powered on again.
CONFIGURATION HAZARDS
Recently, a new ISC DHCP server user set up an unauthorized DHCP server on the computer
at his desk at work. Then he went home. When he came back the next day, he found that
nobody could use the network, and the system administration staff could not figure out why.
The system administration staff didn’t know about the other DHCP server. When they looked
at their own server logs, they saw a perfectly normal sequence of events. As each user arrived
in the morning, he or she turned on his computer. It broadcast a DHCPREQUEST message, and
the DHCP server sent back a DHCPACK message. Unfortunately, what the system administrators
did not see in their server’s log was the DHCPNAK message coming from the unauthorized
DHCP server.
The lesson here is that when you are setting up a server such as this, the configuration in
Example 15.19 is preferable.
Configuring Multiple IP Subnets on Each Network Segment 271
019 3273 CH15 10/3/02 4:59 PM Page 271
Example 15.19
shared-network MY-OFFICE {
not authoritative;
subnet 10.192.0.0 netmask 255.255.255.240 {
option domain-name-server 10.192.0.1;
option routers 10.192.0.1;
range 10.192.0.2 10.192.0.14;
}
}
The unfortunate culprit in this story configured his DHCP server so that it believed it knew the
configuration of the network to which it was attached, when in fact it knew only about the
private subnet the user wanted to set up. Unfortunately, other DHCP clients were connected
to the same network segment and used the officially supported DHCP server to obtain their IP
addresses. Whenever these clients sent DHCPREQUEST packets, asking for IP addresses on the
official subnet, the unauthorized server decided that these DHCPREQUEST packets were invalid
and responded with DHCPNAK packets. Because the unauthorized server was faster than the
primary DHCP server for the network, clients could not get IP addresses—they were always
stopped halfway through the process.
When you add the not authoritative directive to the shared-network declaration, as
shown in Example 15.19, the DHCP server is told that the shared-network declaration is not
complete. This prevents the DHCP server from aggressively sending DHCPNAK packets when it
sees DHCPREQUEST packets for IP addresses on networks it does not know about.
In version 3.0 of the ISC DHCP server, the server assumes that it is not authoritative for any
network; it must be explicitly told to send DHCPNAK messages whenever it sees an address that
doesn’t belong. Without this behavior, DHCP clients moving from network to network cannot
detect that they have moved until their leases expire. When you are setting up an official
DHCP server that knows the layout of the network, you should always specify the authorita-
tive
directive.
One last problem exists with the configuration shown in Example 15.18. It declares a range of
addresses for dynamic allocation. Any client attached to the MY-OFFICE shared network will
be offered an address on the 10.192.0.0 subnet. The solution to this is for the owner of the
unauthorized server to explicitly specify to which clients IP addresses may be assigned.
Chapter 16 demonstrates this in more detail.
The example in the sidebar titled “Configuration Hazards” demonstrates why, if you
are not the network administrator for a given network segment, it is not a good idea
for you to set up a DHCP server for yourself on that segment. Even if you set up
your server as shown in Example 15.19, you still run the risk that the official DHCP
server will send a
NAK message to your DHCP clients when they get addresses from
your DHCP server.
CHAPTER 15 Configuring a DHCP Server272
019 3273 CH15 10/3/02 4:59 PM Page 272
Finding Unauthorized DHCP Servers
If you are the network administrator for a network segment, and users start
complaining that they are being denied access to the network, you should look out
for the situation described in the sidebar titled “Configuration Hazards.” If you look
in your server log for a particular user’s machine and you see a completely normal
start sequence, but that user’s machine isn’t getting its IP address, it might be time
to break out a network analyzer and look for unauthorized or otherwise misbehaving
DHCP servers. Chapter 24 discusses this in greater detail.
Summary
To configure a DHCP server, the network administrator must describe to the server
all the network segments for which it is to provide DHCP service. The server must
also be configured with a set of options to send to clients so that the clients can
operate on the network, and it must be provided with IP addresses on each network
segment so that it can allocate IP addresses for clients.
If the DHCP server is managing more than one network segment, the network infra-
structure must be configured to deliver requests from every network segment to the
server. You can either attach the DHCP server directly to every network segment it
supports or set up DHCP relay agents on all the network segments to which the
DHCP server isn’t directly attached.
You can configure more than one IP subnet on each network segment and you can
configure the DHCP server to provide addresses on each of those subnets as well as
to provide different parameters for different subnets. If a DHCP server is set up on a
network segment but does not have authoritative information about the network
configuration, the DHCP server must be configured not to send inappropriate
DHCPNAK messages.
The next few chapters talk about how to refine and customize this configuration to
meet site-specific needs.
Summary 273
019 3273 CH15 10/3/02 4:59 PM Page 273
019 3273 CH15 10/3/02 4:59 PM Page 274
IN THIS CHAPTER
•Identifying Clients
• Static Allocation
•Mixing Static and Dynamic
Allocation
• Automatic Allocation
• Access Control
16
Client Identification and
Fixed-Address Allocation
Chapter 15, “Configuring a DHCP Server,” describes how
to set up a simple DHCP server configuration in which all
addresses are allocated dynamically. This chapter describes
how the DHCP server associates a lease with a particular
client, and how to
• Assign a client a static IP address, either manually or
automatically
•Mix static and dynamic IP address allocation on the
same network
• Control access to the DHCP server’s resources, based
on each client’s identification
Identifying Clients
DHCP servers keep track of the association between leases
and DHCP clients using identifiers that are unique to each
client. This is true even for dynamic allocation, as
described in Chapter 14, “The ISC DHCP Server.” If you
want to control a server’s behavior with respect to particu-
lar clients, you must know how clients are identified.
A DHCP client can identify itself to a server in two ways:
• The client can use the
dhcp-client-identifier
option to send an arbitrary identification string for
itself to the server.
• If the client does not use the
dhcp-client-
identifier option, the server uses the client’s link-
layer address to identify the client. The DHCP server
gets the link-layer address from the
chaddr, htype,
and
hlen fields of the DHCP packet.
020 3273 CH16 10/3/02 4:58 PM Page 275