Connecting Clients to Remote DHCP Servers
Through
the use of network broadcasts, DHCP allows client computers to locate
DHCP servers on the local subnet and to obtain an IP address from that
local server. However, routers by default prevent broadcasts from
crossing into other subnets. Consequently, without some other added
functionality, every physical subnet would need to contain a DHCP server
for clients to receive DHCP service.
This added
functionality can be provided in the form of RFC 1542-compliant routers,
which can be configured not to block DHCP broadcasts, or DHCP relay
agents, which can be configured to intercept broadcasted DHCP messages
and transport them across the network to the IP address of a DHCP
server.
Before passing a DHCP
message on to a DHCP server, both RFC 1542-compliant routers and DHCP
relay agents write their own address inside a certain field (named
Giaddr) within that message. This address recorded within the DHCP
message informs the DHCP server of the subnet ID of the originating
subnet of the DHCP request and, consequently, of the proper scope from
which to issue addresses to that subnet.
Using Superscopes
A superscope is an administrative grouping of scopes that is used to support multinets,
or multiple logical subnets on a single network segment. Multinetting
commonly occurs when the number of hosts on a physical segment grows
beyond the capacity of the original address space. By creating a
logically distinct second scope (such as 207.46.150.0) to add to an
original scope (such as 207.46.9.0), and then grouping these two scopes
into a single superscope, you can double your physical segment’s
capacity for addresses. (In multinet scenarios, routing is also required
to connect the logical subnets.) In this way, the DHCP server can
provide clients on a single physical network with leases from more than
one scope.
Note
Superscopes
contain only a list of member scopes or child scopes that can be
activated together; they are not used to configure other details about
scope use. |
To create a superscope,
you must create a scope first. After you have created a scope, you can
create a superscope by right-clicking the DHCP server icon in the DHCP
console tree and then selecting New Superscope. This procedure launches
the New Superscope Wizard. In the wizard, select the scope or scopes
that you would like to add as members. You can also add new scopes to
the superscope later.
To create a superscope, complete the following steps:
1. | Open the DHCP console.
|
2. | In the console tree, select the applicable DHCP server.
|
3. | From the Action menu, select New Superscope.
This menu command appears only if at least one scope that is not
currently part of a superscope has been created at the server.
|
4. | Follow the instructions in the New Superscope Wizard.
|
Superscope Configurations for Multinets
The next section shows how a
simple DHCP network consisting originally of one physical network
segment and one DHCP server can be extended by means of superscopes to
support multinet configurations.
Superscope Supporting Local Multinets
Figure 2 illustrates multinetting on a single physical network (Subnet A) with a single DHCP server.
To support this
scenario, you can configure a superscope that includes as members the
original scope (Scope 1) and the additional scopes for the logical
multinets you need to support (Scopes 2 and 3).
Note
When you are supporting two logical subnets on one physical segment, use a router to connect traffic from one subnet to another. |
Superscope Supporting Remote Multinets
Figure 3
illustrates a configuration used to support multinets on a physical
network (Subnet B) that is separated from the DHCP server. In this
scenario, a superscope defined on the DHCP server joins the two
multinets on a remote segment beyond the router. Because DHCP traffic is
normally restricted to the local subnet, a DHCP relay agent is used to
support clients on the remote segment.
Superscopes Supporting Two Local DHCP Servers
Without superscopes, two DHCP server computers issuing leases on a single segment would create address conflicts. Figure 4 illustrates such a scenario.
In
this configuration, DHCP Server A manages a different scope of
addresses from that of DHCP Server B, and neither has any information
about addresses managed by the other. A problem arises when a client
that has previously registered with Server A, for example, releases its
name during a proper shutdown and later reconnects to the network.
When the client (Client
A) reboots, it tries to renew its address lease. However, if Server B
responds to Client A’s request before Server A does, Server B rejects
the foreign address renewal request with a negative acknowledgment
(NACK). As a result of this process, Client A’s address resets, and
Client A is forced to seek a new IP address. In the process of obtaining
a new address lease, Client A might be offered an address that places
it on an incorrect logical subnet.
Figure 5
shows how, using superscopes on both DHCP servers, you can avoid these
problems and manage two scopes predictably and effectively. In this
configuration, both servers are still located on the same physical
subnet. A superscope included on both Server A and Server B includes as
members both scopes defined on the physical subnet. To prevent the
servers from issuing leases in each other’s scopes, each server excludes
the full scope range belonging to the other server.
In this example,
Server B is configured to exclude the scope managed by Server A, and
vice versa. This configuration prevents the servers from sending
negative acknowledgments to DHCP clients attempting to renew IP
addresses from the excluded logical range of addresses. Because each
server is informed of the scope managed by the other server, each server
simply ignores requests from clients originating from the other
server’s scope.
