Multiple routers in a single AD domain network

Nerm

Member
Reaction score
20
Location
Madison, IN
I have a client that has a fairly large network (over 250 workstations). What they want to do is separate 3 labs that each have over 30 workstations but still be in the same domain/forest. I know it is possible to add a router to each lab and have them access back through that router to the main network and domain controller, file server, etc. The problem is I can't seem to get it to work.

I setup a spare router in one of the labs to test with and it worked in every way (got on internet, etc) except it wouldn't see or access the domain controller. Anyone have any suggestions of things to check so I can figure out why this isn't working?

Primary Network:
Main Router: 192.168.1.1
Domain Controller: 192.168.1.2
DHCP range: 192.168.1.35 - 192.168.1.249
Subnet: 255.255.255.0

Test Lab Network:
Router: 192.168.1.251 (WAN)
Router: 192.168.2.1 (LAN)
DHCP range: 192.168.2.100 - 192.168.2.199
Subnet: 255.255.255.0
 
Last edited:
Can you ping the DC from a Test Lab Network client?

Are you running a DHCP relay agent or a local DHCP server on the Test Lab Network as the router may not be passing through DHCP broadcasts? You can tell on the client as it'll have a 169 address.

Name resolution working OK, can you resolve the FQDN of the DC from a Test Lab Network client?
 
The router in the test lab is handling DHCP for that room and that works fine.

I cannot ping the DC nor does name resolution work from test lab client machines.

I know it has got to be something not correctly configured in the test lab router but I cannot figure out what.
 
The quick answer is to get a managed switch so that you can set up VLANs.
With the scope/scale of your project a managed swithch will also give you the ability to setup access control from VLAN to VLAN with in the network.

You are dealing with different subnets for the different areas. Is DHCP disabled in all but the main router?

Good luck
:)
 
No the plan is to have the router in each lab handle DHCP for that lab. The whole purpose is to free up more IP addresses on the network. There current DHCP scope has only 8 available address remaining and they are wanting to add another 25 computers.

EDIT: After a second attempt at the test setup I can get the lab PC's to ping the dc but still cannot join and browse the domain.
 
No the plan is to have the router in each lab handle DHCP for that lab. The whole purpose is to free up more IP addresses on the network. There current DHCP scope has only 8 available address remaining and they are wanting to add another 25 computers.

You could change to a Class A IP range.

How Domain Controllers Are Located in Windows

EDIT: After a second attempt at the test setup I can get the lab PC's to ping the dc but still cannot join and browse the domain.

Maybe you need to open LDAP port?
 
Last edited:
I really do think it is a DNS issue since I can ping the IP of the DC. The test lab router is pointing to the DC for DNS as it also does the DNS for the network which should take care of any name resolution issues but I still cannot join the domain.
 
I just get a generic "domain not found" error. I don't remember the error code now but when I looked it up it referred to improperly configured DNS forward lookup zone but I don't see how that can be the case when the other 200+ workstations can connect just fine on the main network.
 
I don't see how that can be the case when the other 200+ workstations can connect just fine on the main network.

According to your first post, the existing machines are on a 192.168.1 network, your test lab machines are on a 192.168.2 network.

Has a zone for the test lab network been setup on the DNS server? My guess is the existing forward zone is setup for a 192.168.1 network.
 
I just tried replicating this in my workshop, without any real problems.

I used a Linksys RVS4000 as my 'lab' router, and connected to my SBS2003 server using my laptop quite easily.

I set the router to be in 'router' mode not 'gateway' - so NAT is disabled. I disabled any firewall settings I could, allowed incoming on the 'WAN' interface.

The Linksys is serving DHCP to the 'lab', and setting the DNS to the IP of my SBS Server. I had to put a temporary static route on the SBS Server to show it how to get back to the 'lab' network - this should really be done on the main gateway on the DC's network, or use a routing protocol like RIP (be careful with RIP).

I can logon, see my network drives, browse the Active Directory, print to printers on the server, connect to Exchange.

I might test router as a DHCP relay too. - Oh and VLANs are definitely a better solution than using routers, but the switches can be expensive.
 
DNS resolution is the biggest configuration issue I run into with Windows domains. The ip of your domain controller is the only DNS server that should be specified on the workstations.

Having a DNS zone for 192.168.2.0 is recommended but the workstations will connect without it. The server just won't be able to keep track of the DNS names for that zone.

Working yet?

Eric
 
Having a DNS zone for 192.168.2.0 is recommended but the workstations will connect without it. The server just won't be able to keep track of the DNS names for that zone.

In an AD environment running Microsoft DNS with Microsoft clients, can you explain this? :confused:
 
In an AD environment running Microsoft DNS with Microsoft clients, can you explain this? :confused:

Not sure what you would like me to explain.

In an AD domain, when a computer that is part of the domain logs in, it's IP address is registered in DNS. As all the computers in the network are using the server as their primary DNS server, they should all be able to do name resolution to each other.

All the DNS records can be contained in the forward DNS zone, even those that are in a different IP subnet.

However, the server can also update the reverse DNS zone, which can resolve IP's to names, a function completely opposite from the forward zone, which resolves names to IP's. The catch is that the reverse DNS zone is NOT created by default! You have to go into the DNS management console and create a reverse DNS zone for each Class C subnet that you are using.

So, workstations can login to the server even though the reverse DNS zone does not exist.

Eric
 
Thanks for the help guys. I have been busy and haven't had time to try the latest suggestions yet. I am pretty sure the issue is the scope not being set for the lab subnet, but will let you know when I try it.

Also I am trying this with a very cheap $50 Linksys router. Any chance the router just isn't sophisticated enough to work in this situation.
 
The catch is that the reverse DNS zone is NOT created by default! You have to go into the DNS management console and create a reverse DNS zone for each Class C subnet that you are using.

So, workstations can login to the server even though the reverse DNS zone does not exist.

Eric

Ah ha, I missunderstood your original statement but now get what you are saying. :)

So as nerm has mentioned, it's more than likely there is no DHCP scope setup for the 192.168.2 network.
 
In the configutration for the lab router, set the dns server to point to the AD server. This is very likely the problem. If you do this, the router will give the Lab PCs the AD server address is the DNS server. The problem is no doubt a DNS issue.
 
Back
Top