Allocate IP /Subnet Address based on OU

[Steve Ireland]

Is there a way to assign a group of machines a range
of IP addresses (from a pool) based on their
containing OU in Active Directory?

I have about 300 PCs on a LAN and would like to
introduce a new IP subnet and allow machines in
certain rooms access to services in non-windows
environments based on their grouped IP addresses.

 

[Andrew Mitchell]

Is there a way to assign a group of machines a range
of IP addresses (from a pool) based on their
containing OU in Active Directory?

I have about 300 PCs on a LAN and would like to
introduce a new IP subnet and allow machines in
certain rooms access to services in non-windows
environments based on their grouped IP addresses.

AFAIK the only way you could do this would be to have the rooms cabled to
particular ports on a layer 3 switch (which is basically a switch with
routing capabilities).
You then configure VLANs on the switch (tagged to paricular ports on the
switch) and create multiple scopes on your DHCP server. The DHCP server will
then assign the client an address from the scope associated with a particular
VLAN.

 

[Steve Ireland]

Fair enough. Thank you.

Incidentally, would it be correct to say that the DHCP server would be
unable to see the VLAN configuration of the Router (unless I joined
different network cards on the DHCP server to ports included in each VLAN)?

Could I somehow use RRAS to configure the DHCP server as a router and
thereby somehow assign IPs based on some Active Directory value?

 

[Andrew Mitchell]

Fair enough. Thank you.

Incidentally, would it be correct to say that the DHCP server would be
unable to see the VLAN configuration of the Router (unless I joined
different network cards on the DHCP server to ports included in each VLAN)?

Not quite. Although the documentation that comes with Windows 2000/2003 DHCP
states that you need a separate NIC for each subnet, this is not strictly the
case. You only need a single NIC on the DHCP server and set the switch to
point to the DHCP server as a DHCP helper.
As an example:
You configure the switch so that ports 1-4 are on a 172.16.4.0/24 network and
ports 5-8 are on a 172.16.8.0/24 network and have these scopes also defined
on your DHCP server. A client plugged into port 1 on the switch sends a DHCP
request as a broadcast. The switch detects this packet and sends a packet to
the DHCP server, also including information about which subnet the request
came from (172.16.4.0/24). The DHCP server assigns an address from the pool
defined in the 172.16.4.0 scope and returns it to the switch which then
relays it to the client.
Make sure that you don't use different scopes within a superscope as this doe
not appear to work (at least it didn't with my HP switches)

Could I somehow use RRAS to configure the DHCP server as a router and
thereby somehow assign IPs based on some Active Directory value?

Not that I am aware of. Network subnets are usually based on the physical
layout of the network, where AD is purely a logical structure and not tied to
network hardware in any way.

 

[Steve Ireland]

Very good of you, thanks.

Odd that Superscope doesn't work with your switch.
I thought the whole point of the superscope was to prevent possible
crossover conflicts. Don't I kind of 'have to' use a superscope? If not, and
I can just go ahead and use separate scopes, then I'm happy.

I guess the VLANs on different subnets make your network perform as if it is
routed so it effectively becomes two or more physical networks.

Maybe additional 'virtual' IPs configured on the NIC (in advanced TCP
properties) would help. Maybe the Superscope server needs to think it's on
the same subnet as the addresses it's allocating or something.

Overall, though it's a shame that I can't spearate the classrooms without
using a managed switch. It would have been nice to easily separate the
environments based on IP address.

 

[Andrew Mitchell]

Very good of you, thanks.

Odd that Superscope doesn't work with your switch.

Yeah, I'm not sure why but didn't bother to look into it too much. Just got
it going with individual scopes.

I thought the whole point of the superscope was to prevent possible
crossover conflicts.

The main advantage I see with superscopes is that you can configure
'global' settings (DNS and WINS server etc.) at the superscope level and
not have to define them individually for each scope. In my situation it
didn't matter as all machines are using the same DNS and WINS servers so I
just set them at the server level and didn't have to set them for each
scope anyway.

Don't I kind of 'have to' use a superscope?

Not unless you have different DNS and WINS servers for different groups of
subnets.

If not,
and I can just go ahead and use separate scopes, then I'm happy.

That would work fine.

I guess the VLANs on different subnets make your network perform as if
it is routed so it effectively becomes two or more physical networks.

It is routed. The layer 3 switch performs the routing, and all broadcast
traffic is kept within its own subnet. That was the main reason I did it.
We have an NEC PABX (but no VoIP) and traffic analysis indicated that about
60% of our traffic was multicast traffic coming from this monster. We have
a lage number of (limited bandwidth) radio links that were being saturated
by this traffic. Put the PABX on its own subnet and instead of the activity
LEDs on the switch being nearly constantly on, we now get a nice flicker
with loads of inactivity in between.

Maybe additional 'virtual' IPs configured on the NIC (in advanced TCP
properties) would help. Maybe the Superscope server needs to think it's
on the same subnet as the addresses it's allocating or something.

Overall, though it's a shame that I can't spearate the classrooms
without using a managed switch. It would have been nice to easily
separate the environments based on IP address.

Layer 3 switches are fairly cheap now. I'm using all HP Procurves but you
can pick up a 48 port Extreme Summit 200 (which I've got for a hot spare)
for about US$2500. It might well be worth the investment. I know it was for
me.