What's the benefit of using superscopes?

Hi, first a bit of background...

We have a 192.168.2.0 / 255.255.255.0 scope which is depleted so i
intend to move to a 10.10.0.0 / 255.255.0.0 range, all the clients are
on the same physical network so we'll end up with a multinetted
environment.

I planned to achieve this by leaving the old 192.168.2.0 scope running
on "DHCP Server 1" whilst creating a 10.10.0.10 - 10.10.0.254 scope on
"DC1" and a 10.10.1.1 - 10.10.1.254 scope on "DC2".

Both DC1 and DC2 have static IPs on the 192.168.2.0 subnet and i
planned on adding nics with 10.10.0.0 address on which they could
service dhcp requests. I'd then give our internal firewalls'
192.168.2.2 NIC an additional IP of 10.10.0.1 and set up routing.

This all seemed fine until i started reading about superscopes. What
benefit would there be to creating a supercope on the existing dhcp
server that encompasses both scopes as opposed to the proposal above?
Would i still need to put one of it's nics on the 10.10.0.0 network?

Also, when the subnets are physically seperate how does the superscope
determine which IPs to assign to which subnet?

Thanks,

Tim.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> This all seemed fine until i started reading about superscopes. What
> benefit would there be to creating a supercope on the existing dhcp
> server that encompasses both scopes as opposed to the proposal above?
> Would i still need to put one of it's nics on the 10.10.0.0 network?

The simplest sulotion is to just add another subnet. Subnet should be kept
below 250-300 hosts. A 16bit segment (255.255.0.0) as you propose is way
too many hosts and those "large" segment are used under the assumption that
it would be futher split up along the way downstream.

Create a new segment, either physically or with VLANs.

You can use 192.168.3.0/24 for example.

1. Run the DHCP Server with *one* Nic and *one* IP#.
2. Create a separate Scope for each subnet in the DHCP Server.
3. Configure the LAN Router (not an Internet Sharing Device) to forward DHCP
Queries from the Client that sent it to the DHCP Server. This is one of the
normal functions of a LAN Router.
4. Add the 192.168.3.0/24 range to the Internet Sharing Device so it knows
this is a local LAN segment. Give the device a Static Route to the
192.168.3.0 segment that uses the LAN Router as the "gateway" so it knows
where the new segment actually "lives".

All done! Nice and clean and simple. No screwing around with Superscopes, no
screwing up the DCs with multple adapters, no screwing up everything else
that I just haven't thought of yet.

You can move user machines to the 2nd segment on your leasure a little at a
time so it doesn't create disruptions. The Servers will stay where they are
and the IP# won't change.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

>From cramsession.com

What is Superscope?

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:

192.168.1.0/24
192.168.2.0/24

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.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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.

It doens't make a lot of sense. I have never seen a "real" situation where
Superscopes were *truely* required because there are so may extremely easy
ways to avoid the whole thing altogether and never have to get involved with
the Superscopes in the first place.

> 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.

You have to "not care" which subnet a particular client become "part of" and
there must be a routing device to "route" between the two segments that are
on the same wire.

> 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,

I do it right here in front of me everyday. I do *not* run them all on the
same wire. I do *not* use Superscopes. I *do* use separate distinct
Scopes for each subnet.
Using VLANs is *not* running it on the same wire even thorugh it is the same
wire physically because the VLANs separate it "logically" with the Frame
Tagging. The LAN Router forwards the DHCP Queries and the router *includes*
in those forwarded packets the information that the DHCP needs to know to
grant the proper address from the proper subnet.


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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.

I don't think you fully understood what you read.

1. DHCP Server don't need mutliple Interfaces.
2. Routers forwarding the DHCP Queries give the DHCP Server the information
it needs to choose the right address from the right scope without the DHCP
Server needing an interface on each segment.
3. Running multple IP Networks on the same wire is never "forced" on anyone
if they have enough sense to spend a few dollars to do the job right in the
first place. The topology should be physcially segmented, or logically
segmented with VLANs. I am opposed to the very existence of Multi-nets and
don't think they shouldever be used,...they are just a "band-ade" for an
insufficient network design, and a poor band-ade at that. Simply segmenting
the topology via VLANs or the physical cabling eliminates the whole reason
for them to exist in the first place.

--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com