dhcp sizing

I've been looking for more information about sizing DHCP servers on Windows 2003. I've seen the documents on Microsoft's site that talk about using 1000 scopes as a best practic, as well as the ones that talk about increasing the pagefile. Those same documents hint at the registry, but give no solid information about how to size accordingly.

Can someone point me to documents that will help me to quantify the amount of resources needed per scope? I need to accomplish the following:

1) Need to be able to estimate how much registry space is needed per scope. How much is possible and how much each option/entry takes
2) Need to be able to know exactly what is put into the registry for each scope
3) Need to be able to estimate how much capacity is taken and how much is left for future upgrades/redesign etc

Before you tell me that network is the usual limiting factor, I have more than enough bandwidth and decent servers to work with. In fact, today I have 4 servers doing the job but I need to be able to split those up. In order to fully understand the impact, I need to understand the sizing in more detail than I can find on the net and on Microsoft's web site.

Can somebody point me in the direction of some detailed information about this? A response from somebody who has access to the source code would make this easier

Cheers,

Al

"Al Mulnick" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Before you tell me that network is the usual limiting factor

Why not? It is the right answer.

> I have more than enough bandwidth and decent servers to work with.

Doesn't really matter

> In fact, today I have 4 servers doing the job but I need to be able to
split those
> up.

What do you mean "split those up"?

Assuming all 4 of them "live" in the same subnet.....
You are overcomplicating something that is reletively simple.
1. Create only *one* scope per subnet/network (No superscopes!).
2. Configure each DHCP *identically*.
3. Use Exclusions on each DHCP Server so that each one gives out 25% of the
addresses with no overlap among the servers.
4. Configure any Routers between the subnet to forward DHCP Queries
properly.

Things would be a little different if they all "lived" in different subnets,
but I'm not going there unless that is the case.

--

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

Thanks Phillip.

What I mean is that each server is responsible for 25% of the scopes now
with one server backing the scopes of the other. Maybe I am complicating
this more than I'd like, but bear with me for a minute. Each scope that is
defined, represents a different subnet. I work at a company with > 1400
locations at the moment, each with it's own network.

As I said, bandwidth isn't the issue I'm concerned with. I'm concerned with
the server handling the scope configuration and handing out the renewals etc
as expected. From other conversations, it looks like memory mapping might
be an issue as I scale up but I'll have to test to find out.

Your steps are exactly what I'm trying to do
> 1. Create only *one* scope per subnet/network (No superscopes!).
> 2. Configure each DHCP *identically*.
> 3. Use Exclusions on each DHCP Server so that each one gives out 25% of
> the
> addresses with no overlap among the servers.
> 4. Configure any Routers between the subnet to forward DHCP Queries
> properly

The routers are only capable of three entries for bootp forwarders. That's
what's driving the whole change in the first place. If it could handle
four, it would not be an issue in the least. To simplify the service
provided, I'd like to move this down to two servers in total for the remote
networks only. All centralized networks will be on the other two servers.
The easiest way to do this is to put all scopes on all servers and flip the
routers as conditions allow. Since we've been bit in the past by the
registry limitations, I'm checking into it and I'm open to the best way to
go about this.

What makes you say no superscopes? What's your experience with them that
makes you say that?

Thanks Phillip,

Al


"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> "Al Mulnick" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> Before you tell me that network is the usual limiting factor
>
> Why not? It is the right answer.
>
>> I have more than enough bandwidth and decent servers to work with.
>
> Doesn't really matter
>
>> In fact, today I have 4 servers doing the job but I need to be able to
> split those
>> up.
>
> What do you mean "split those up"?
>
> Assuming all 4 of them "live" in the same subnet.....
> You are overcomplicating something that is reletively simple.
> 1. Create only *one* scope per subnet/network (No superscopes!).
> 2. Configure each DHCP *identically*.
> 3. Use Exclusions on each DHCP Server so that each one gives out 25% of
> the
> addresses with no overlap among the servers.
> 4. Configure any Routers between the subnet to forward DHCP Queries
> properly.
>
> Things would be a little different if they all "lived" in different
> subnets,
> but I'm not going there unless that is the case.
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>

"Al Mulnick" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...

> defined, represents a different subnet. I work at a company with > 1400
> locations at the moment, each with it's own network.
> ...........
> The routers are only capable of three entries for bootp forwarders.
That's > what's driving the whole change in the first place. If it could
handle

Those two comments spell disaster to me. I would never want to totally
centralize something like that. Do you know what mess that will create if
those 1400 locations lost contact with the Central location and cannot
receive from the DHCP?

> four, it would not be an issue in the least. To simplify the service
> provided, I'd like to move this down to two servers in total for the
remote
> networks only. All centralized networks will be on the other two servers.
> The easiest way to do this is to put all scopes on all servers and flip
the
> routers as conditions allow.

Well two servers down from four cure the router config limitation, but it
doesn't solve the disaster created by centralizing that many site's DHCP to
become dependent upon one site for their existance. You seriously need to
think about a "distributed model",...just the opposite of what you are
doing.

> What makes you say no superscopes? What's your experience with them that
> makes you say that?

I've yet to find a "real live" situation where they even need to exist in
the first place. If you do a search for material about them you will find
most of it vague and hard to follow the logic and the two things that you
will read about them if you do a search are:

1. They take multiple Scopes and make them behave as one. This is opposite
of what you want to do, and it doesn't even make sense to me,...why would
someone take different scopes and make them act as one if they weren't in
the same subnet,...and if they are in the same subnet then what's the point
of multiple scopes in the first place when you can create one scope to
handle it.

2. They are used when multiple subnet share the same physical "wire", but
*not* a VLAN situation. To me, that is just a bad topology and not a
legitament way to build a network in the first place,...but then, I don't
get to run the world.

Some of MS's Documentation lists these purposes:

1. DHCP clients are located on a single physical network segment that
includes multiple logical IP subnets.

2. Multiple DHCP servers manage separate logical subnets on the same
physical subnet.

3. The available address pool for an active scope is nearly depleted and
more computers must be added to the physical network segment.

4. Clients are migrating to a new scope.

5. You need to support DHCP clients on a network that has multiple logical
subnets in one physical subnet on the other side of a BOOTP/DHCP relay
agent.

#1, #2, and #5 are needless since you should not even design a topology that
way to begin with, and if you find yourself with one it should be
redesigned.

#3 is useful but could easily been avoided by using the full IP Range in the
scope to begin with and use Excusions to cut back the distributed addresses.
The Exculsions can later be adjusted easily to accomidate more machines.
But if you do "Supernetting" then that could be a legitament use of it.

I can somewhat see the point of #4, but it would only be a temporary thing
used as a "migration" techinque.

The link for those items is:
http://www.microsoft.com/resources/d...c_dhc_mrqk.asp
--

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


--

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

Thanks Phillip, I'll take a look.

One clarification though: I think you have the idea that I have 1400 remote
sites hanging off the same central site. That would not be true. I have
two separate sites with two DHCP servers each currently. The idea is to get
to one server in each physical to handle 1/2 remotes but having ability to
handle 100% should one server fail. If both fail, I'm well aware of the
consequences and I understand that I only have a limited time to put the
world back before it all goes terribly wrong


Thanks for the input Phillip.


"Phillip Windell" <@.> wrote in message
news:(E-Mail Removed)...
> "Al Mulnick" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>
>> defined, represents a different subnet. I work at a company with > 1400
>> locations at the moment, each with it's own network.
>> ...........
>> The routers are only capable of three entries for bootp forwarders.
> That's > what's driving the whole change in the first place. If it could
> handle
>
> Those two comments spell disaster to me. I would never want to totally
> centralize something like that. Do you know what mess that will create if
> those 1400 locations lost contact with the Central location and cannot
> receive from the DHCP?
>
>> four, it would not be an issue in the least. To simplify the service
>> provided, I'd like to move this down to two servers in total for the
> remote
>> networks only. All centralized networks will be on the other two
>> servers.
>> The easiest way to do this is to put all scopes on all servers and flip
> the
>> routers as conditions allow.
>
> Well two servers down from four cure the router config limitation, but it
> doesn't solve the disaster created by centralizing that many site's DHCP
> to
> become dependent upon one site for their existance. You seriously need to
> think about a "distributed model",...just the opposite of what you are
> doing.
>
>> What makes you say no superscopes? What's your experience with them that
>> makes you say that?
>
> I've yet to find a "real live" situation where they even need to exist in
> the first place. If you do a search for material about them you will find
> most of it vague and hard to follow the logic and the two things that you
> will read about them if you do a search are:
>
> 1. They take multiple Scopes and make them behave as one. This is opposite
> of what you want to do, and it doesn't even make sense to me,...why would
> someone take different scopes and make them act as one if they weren't in
> the same subnet,...and if they are in the same subnet then what's the
> point
> of multiple scopes in the first place when you can create one scope to
> handle it.
>
> 2. They are used when multiple subnet share the same physical "wire", but
> *not* a VLAN situation. To me, that is just a bad topology and not a
> legitament way to build a network in the first place,...but then, I don't
> get to run the world.
>
> Some of MS's Documentation lists these purposes:
>
> 1. DHCP clients are located on a single physical network segment that
> includes multiple logical IP subnets.
>
> 2. Multiple DHCP servers manage separate logical subnets on the same
> physical subnet.
>
> 3. The available address pool for an active scope is nearly depleted and
> more computers must be added to the physical network segment.
>
> 4. Clients are migrating to a new scope.
>
> 5. You need to support DHCP clients on a network that has multiple logical
> subnets in one physical subnet on the other side of a BOOTP/DHCP relay
> agent.
>
> #1, #2, and #5 are needless since you should not even design a topology
> that
> way to begin with, and if you find yourself with one it should be
> redesigned.
>
> #3 is useful but could easily been avoided by using the full IP Range in
> the
> scope to begin with and use Excusions to cut back the distributed
> addresses.
> The Exculsions can later be adjusted easily to accomidate more machines.
> But if you do "Supernetting" then that could be a legitament use of it.
>
> I can somewhat see the point of #4, but it would only be a temporary thing
> used as a "migration" techinque.
>
> The link for those items is:
> http://www.microsoft.com/resources/d...c_dhc_mrqk.asp
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
> --
>
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>

"Al Mulnick" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> One clarification though: I think you have the idea that I have 1400
remote
> sites hanging off the same central site. That would not be true.

You're right! That's what I thought! It did sound very unusual to me but I
just had to take is as I read it.

> two separate sites with two DHCP servers each currently. The idea is to
get
> to one server in each physical to handle 1/2 remotes but having ability to
> handle 100% should one server fail.

Ok. Well that is fine. The general method for redundant DHCP is that you
configure them both identically (one independent scope per subnet if
multiple subnets exist) and use the Exclusions to control which address the
machines actually give out. If one dies you just adjust the Exlusions so
the remaining can pick up the slack, when the repair is completed, return
the Exclusion to the original state.

As far as where they are located, that is up to you,..it is flexable. You
just have to ask yourself a lot of "what ifs" and not position yourself in
a bad way if a WAN link goes down.

--

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