A superscope is a collection of individual scopes that can be
managed as a single administrative unit. That's what the book
says, so it must make sense, right? Well if that doesn't make
much sense to you, join the club. Let's see if we can shed some
light on what superscopes are and what they can be used for.
A superscope is actually a collection of individual scopes. When
you group different scopes together into a single superscope, you
can do the following:
Place DHCP clients from multiple network IDs on the same
physical segment
Allow remote DCHP clients from multiple network IDs to
obtain an address from a DHCP Server
Place multiple DHCP Servers on the same physical segment,
with each DCHP Server being responsible for a different
scope.
The superscope will allow the DHCP Server to answer requests from
DHCP clients from different network IDs. Now, you might ask,
can't you just create multiple scopes on a DHCP Server and then
everything will be cool? Let's see what happens.
Multiple Scopes on a Single DHCP Server
Imagine that you have configured a DHCP Server with two scopes
serving the entire address range for the following network IDs:
The DHCP Server has a single network interface, and its IP
address is 192.168.1.5. You want the DHCP Server to answer
requests from clients on its locally attached network
192.168.1.0/24, and from the remote network, 192.168.2.0/24. The
remote DHCPRequest messages are forwarded through BOOTP Relay.
What will happen when a request from a client on the
192.168.2.0/24 makes a request to this DHCP Server?
The request is forwarded through the BOOTP Relay to the DHCP
Server. The DHCP Server checks the giaddr field in the
DHCPRequest or Discover message to see what network ID the
request is coming from. The DHCP Server compares this information
with the network ID assigned to its local interface. If the
network ID in the request and the network ID of the DHCP Server's
interface is the same, the DHCP Server will check to see if it
has a scope that can service the request. If it does have a
scope, it continues the DHCP negotiation.
However, if the request from a network ID that is different from
that of the DHCP Server, the DHCP Server will see if it has a
superscope that includes an address pool that can service that
network ID. If it does not have such a superscope, then it will
send a NACK packet, and the DHCP client must start all over
again.
How about adding multiple IP addresses to the DHCP Server's
Interface? In this way, the DHCP Server would be able to compare
the source network ID with the addresses on its interface, and
see that the source was on the name network ID as the DHCP
Server. Now it wouldn't need to look for a superscope.
This will not work! It will not work because when you bind
multiple IP address to a single adapter on the DHCP Server, the
DHCP Server service will only use the primary IP address to make
its assessments. It will not use any of the secondary IP
addresses bound to the adapter.
A solution to this problem could be to include a second NIC on
the DHCP Server and assign it a primary address on the
192.168.2.0/24 network ID. However, using a superscope is a lot
easier and a lot cheaper than adding new hardware.
What About Multinets?
A multinet is a single physical network segment that supports
multiple network IDs. A Windows 2000 DHCP Server can be used to
support multinet configurations. When would you want to configure
a multinet? Perhaps when you've used up all the IP addresses in
the scope that you've already configured on the physical segment,
and you want to add more hosts to that segment. In this case, a
multinet is your solution.
A multinet presents the same problems, and the same solutions as
our example above. You can either add multiple network interface
cards to the DHCP Server or assign an IP address on each card
dedicated to the required network IDs, or you can create a
superscope.
Multiple DHCP Servers on a Single Physical Segment
Perhaps you considered the possibility of placing multiple DHCP
Servers on the same physical segment to solve the problem of
issuing IP address for multiple network IDs. Let's take a look at
what might happen here.
We have two DHCP Servers, DHCP-1 and DHCP-2. The DHCP Servers
contain scopes that include all addresses for the following
network IDs:
DHCP-1 192.168.1.0/24
DCHP-2 192.168.2.0/24
Now imagine that a DHCP client with IP address 192.168.1.10 needs
to renew its IP address. When the client sends out its
DHCPRequest message to renew its address, that request is
broadcast to the entire segment. Therefore, either DHCP Server
can receive the message. If DHCP-2 receives the message, it will
check the network ID on the request and compare that with the
network ID on its local interface and find that the source
network ID is different from its own network ID. Since these are
different, DHCP-2 will look for a member scope in a superscope
that can service this request. Since there is no superscope to
service the request, DCHP-2 will send a NACK to the client.
After receiving the NACK, the DHCP client then has to begin the
discovery process from the beginning and send out a DHCPDiscovery
packet. Let's say that DHCP-2 is the first to respond to the
DHCPDiscover packet, and assigns the clients the IP address of
192.168.2.15. Hey look at that! The client is now a located on a
different network ID. And what's really rich is that the whole
thing could start all over again, and the DHCP client could end
up on network ID 192.168.1.0/24 again.
The Solution
The solution is to configure superscopes on both DHCP Servers,
and then exclude all the addresses on one of the scopes. For
example:
DHCP-1
Superscope
192.168.1.1-192.168.1.254
192.168.2.1-192.168.2.254
Exclude:
192.168.2.1-192.168.2.254
DHCP-2
Superscope
192.168.1.1-192.168.1.254
192.168.2.1-192.168.2.254
Exclude:
192.168.1.1-192.168.1.254
With this configuration, what happens to the DHCP client that
tries to renew its IP address, 192.168.1.10?
If DHCP-2 receives the DHCPRequest message, rather than sending a
NACK, it will just ignore the message, because it does have a
scope for the client's network ID, but just doesn't have any
addresses available because they've all been excluded. The client
will try again, and perhaps again, and sooner or later will
contact DHCP-1 and renew its IP address. The key here is that
when you configure the scope for network ID 192.168.1.0/24 and
then exclude all the addresses in the scope and make it part of
the superscope, DHCP-2 will ignore requests from clients from
that network ID.
Conclusion
If you didn't know about the utility of superscopes, you do now.
You now know that putting multiple scopes on a single DHCP Server
and letting 'er rip won't do the job, and so you have to consider
the network IDs of the clients that need to access the DHCP
Server, and the IP addresses and network interfaces on the DHCP
Server.
Superscopes allow you to not add extra network interfaces to your
DHCP and still be able to service DHCP clients from multiple
network IDs. They also allow you to place multiple DHCP Servers
on a single physical segment and prevent clients from obtaining
IP addresses on a different network ID as well as reducing the
number of NACKS send by the DHCP Server. This will help reduce
the number of NACK entries in your Event Log as well.
2 comments:
Thanks a lot. I was totally confused by MS articles. The key point is "the
DHCP Server service will only use the primary IP address to make
its assessments. It will not use any of the secondary IP
addresses bound to the adapter."
Keep writing.
Pgt
Thanks for this explanation! This helped me understand much better than some other sites and text, including, as mentioned by Pgt, MS articles. Clear and plainly worded while being very informative!
Post a Comment