Dear group,
it seems to be next to impossible to change the subnet mask of an
already existing DHCP scope (references: [1], [2], [3], [4])
on a Microsoft Windows Server platform.
This holds true for any version of Windows Server Software I can
think of (yes, it does not work in NT 3.5, 3.51, 4.0, Windows 2000
and not even in Windows Server 2003). At least not the GUI way.
Maybe some weird Registry settings might enable the change, but
guess what - I also tried this and it won't work.
Since I have good reasons why it should be possible, I am really
wondering, why Microsoft has implemented it this way. I will explain
my reasons a little later on.
Now, if I understand RFC2132 [5] correctly - and I have little doubt
that I do - the subnet mask is nothing more but DHCP option number 1
([5], 3.3) and should not be treated in any particularly special way.
So, I see no reason for inhibiting a change of just a simple network
parameter. Of course, such a change has influences, some of which
may well affect an entire local network.
But if an administrator does know the impact of his changing such a
value, there is little to no sense in preventing him from doing so.
The logic in DHCP Administrator seems to base on the assumption that
no two scopes shall ever overlap in a way that they would build a
combined network.
For example, if you had two logical networks on your physical network
(often dubbed "multi-netting"), say 192.168.1.0/24 and 192.168.2.0/24
and would like to lease IP addresses through DHCP, you have two options
in Microsoft's DHCP: Either use Supernetting or use Superscoping. [6]
While both options have their advantages, they also do have some form
of limitation. If you implement this the Supernetting way, you have
the correct subnet mask (255.255.254.0), but you only have one scope
and cannot handle the two seperate logical networks in different ways.
If you implement this in Superscope manner, you don't lose the big
advantage of having two distinct networks to handle individually,
but you have to stay with the original subnet mask of 255.255.255.0
for both networks.
While the latter may not seem a problem, it actually is, in terms of
network performance and scalability. This is because the two networks
don't see each other as "associated", which in fact they really are.
This means that sending packets from either network to the other does
result in unnecessary routing involvement, because the hosts on each
network don't see the other network as belonging to the same Network
ID, which ultimately triggers the IP-Stack to route the packet to
the default router, when it actually could do without it.
So, now consider not having two, but thirty-two full-fledged Class C
networks instead. Would you use the Supernetting method for DHCP in
this very case? I won't. Not just because you have way too little
flexibility within the parameters for each network, but because of
the fact of having several hundred hosts altogether in a single DHCP
scope. I sure won't like this.
This is just a nightmare to administer, especially if your whole IP
address assignment is based on reservations.
"Why not go with the Superscope option then?" you might ask. Well,
in fact I just went this way. No, I _had_ to go it, because there
is simply no other way (besides from using another operating system
for the duty of assigning IP addresses; thus losing the options for
dynamic DNS, for example).
"OK, so what is the problem here" you say?
The routing is. Since every host gets its IP address together with
a much-too-narrow Class C network mask (255.255.255.0 that is),
much of the traffic in the local network is unnecessarily routed
through the default gateway. Which in our case is another Windows
server machine configured for routing, but being defaulted to not
route. These machines also use DHCP and have to go through their
default router, because they also get the small 255.255.255.0 net
mask. So they reach our main router, which in case turns out to
be a heavily used Windows 2003 Server. This server is configured
statically of course and has the correct network mask, but as you
can see, there's two routing instances involved. Two too much.
"Why the heck are you using such a weird configuration?"
Ah, good question.
I work for an education company. We have twenty or so classrooms
equipped with networked hosts, mostly windows machines. We have
trainer PCs in the classrooms and at the desk. I wanted every
single classroom to form a distinct network. The trainer PCs at
their desk are a separate network. The infrastructure (servers,
printers, wireless access points, etc.) are on their own net.
Logically. For good reasons.
What I did not want was to provide a physically distinct network
for every logical one. I don't have the budget to spend several
thousand Euros for Routers to connect the networks. Instead, every-
thing is switched together. Basically, the idea was that every
connected host can communicate freely with any other host on that
physical network.
So far so good, but we also needed internet access. A key goal was
to give every trainer the ability to enable or disable access of
each individual classroom to the internet at his own will at any
given time, while not interrupting the network connectivity to all
the internal resources, such as servers and printers. Not for his
own PC and sure not for the client PCs.
We implemented this using Windows 2000 Servers with two net cards
and configured routing between them, while a small Visual Basic
program did the job of enabling and disabling access by starting
and stopping the RemoteAccess-Service. Since all client PCs get
their IP configuration by DHCP and group policies prevent the users
from changing this configuration, we are perfectly sure that no one
can access the internet if the trainer doesn't allow it.
Another option would have been to implement VLANs, but our switching
equipment is just not capable of doing this. You remember the budget
constraints, do you?
So, while all internal traffic should be handled by the client itself,
not needing any router for packet delivery, internet access should be
controlled by the trainer at his PC in the classroom.
Unfortunately, you know that this scenario does not work with the
given parameters, because the client PCs don't see the whole large
physical network, but only their limited logical one. Too bad.
Now, there is a workaround for this situation, which is rather nasty.
There's another method of making the client see the big physical net
apart from changing the subnet mask (which is, as we know, not possible
using Microsoft's DHCP implementation): Use static routes.
And this is how it is currently implemented. I wrote a small VBScript
that runs at machine startup using a group policy that basically sets
a route to the bigger physical LAN using its own interface IP address
to communicate instead of the default gateway. Yes, it's a permanent
static route and there should be no need to apply it every time at
startup, but occasionally the clients "forget" their permanent routes
or are re-installed and lose the route this way.
Ah, I feel relieved now. I have been writing this article for more than
an hour now. It turns out to be a rant, though. This was not intended.
Really not. But this behaviour makes debugging a lot more complicated.
It is simply unnecessary. And a major performance bummer.
Please share your thoughts. Maybe Microsoft gets my point.
Maybe I have overseen some restriction that _should_ inhibit
subnet mask changing. Maybe there is another way I did not see.
However, in other operating systems this is just another parameter.
[1] http://groups.google.com/groups?as_umsgid=6uraql$qjc$(E-Mail Removed)
[2]
http://groups.google.com/groups?as_umsgid=93dtql$sjs$(E-Mail Removed) u.au
[3]
http://groups.google.com/groups?as_u...ngxa10.phx.gbl
[4]
http://groups.google.com/groups?as_umsgid=uFGGzbSQ$(E-Mail Removed) soft.com
[5]
http://www.faqs.org/rfcs/rfc2132.html
[6]
http://support.microsoft.com/?kbid=186341
Regards,
Franz Starhan
--
Franz -STAR- Starhan, Ing. MCSA MCSE * "A STAR in global communication!"
**
http://www.starhan.org/me.shtml ** mailto:franz+(E-Mail Removed) **
Similar Threads
Linear Mode
