This post is probably first of TEC 2009 follow-up series, at least partially as I thought about covering it just before going to TEC. However Brian Desmond has touched this topic during his session so it is good reason to follow-up on it.
This will be about usage of catch-all subnets in AD topology design. What catch-all subnet means?? Let start from definition.
What’s this about …
When client computer is trying to locate domain controller it is performing location process during which it will try to discover its site based on network subnet information which will be send to DC (Jorge has put nice description of DC location this process in three parts – I, II, III). If client will determine its site it will try then to locate DC in this site using DNS queries. Site location process fro Active Directory perspective is based on site and subnets defined in AD. If client network subnet matches subnet object defined in AD client is assigned to site to which this subnet was assigned at directory level.
But there might be situation in which client is not able to determine it’s site because subnet object corresponding to client’s network subnet was not defined in Active Directory. In such situation client will pick one of available DCs (I will cover what “available” means in this context later) it can reach and will use it for its operation. Problem is that this might be far from most optimal DC for this client to use – for example it might be DC in one of far and poor connected branch site.
So what if we will create on subnet object (or few of them) which will span across multiple sites and will cover all of our subnets used in network. If these super subnets objects will be connected to some site our client will always be able to determine its site and at the end determine corresponding DCs. In worst case client will use not optimal DC but one in a site for which catch all subnet was configured. Done. Some explanation on this topic can be found in article in TechNET Magazine.
So what’s the catch …
Looks promising, but – can we do this in other way? Yes we can and I wrote about it earlier in my post How to cover un-covered – the case of missing subnet. In short words we can use DNS registration to control which site will be chosen by client in case it will not be able to determine exact site it belongs to. This can be achieved through proper registration of site and domain specific domain SRV records. If client will not be able to locate its own site it will pick one of DCs which registered domain specific records.
And that’s it … is it better approach than catch-all subnet? Is this better approach than catch-all subnet?? Probably it is just a personal preference but I like to use DNS records over such subnets. It is more elegant solution for me and I think that it is easier to manage and troubleshoot in case of some problems. The choice is Yours …
When catch-all subnet can benefit …
However I can see scenarios in which catch-all subnet can have some benefit. Let’s take a look at topology which is not exactly hub-n-spoke but is something which sometimes is called snow flake. In such topology we have central site (hub) and two or more tires of satellite sites.
If we would want to gather traffic from all clients from 3’rd tier at the 2’nd tier level and even if they can’t find their site not re-direct them to one of DCs in a hub we can’t do this with DNS records. In such case we can use catch-all subnet for each region \ sub configured at 2’nd tier sites level to control behavior of clients and keep all clients attached to correct site at 2’nd tier of our topology as on this picture.
Of course DNS records registration should also be correctly planned and configured for such design.
And that’s basically it – this just came out on Brian’s session on TEC and maybe it would not catch my ear\eye if I would not read this article on TechNET just before TEC.
So what do you think about using catch-all subnets? Are You using them? Any other ideas or comments? Comments are open … so is contact form :).
I've been using them ever since Windows 2000 when I ran into this issue with "unplanned" subnets popping up with clients in them. Despite our best efforts, no one consulted us when a new campus was coming up, so we found it best to cover all of the Class A, B and C ranges we knew were in use and tie them back to our four main regional datacenters. Defining a more specific range always took precedence and we had a lot less "slow logon" reports from the "shadow sites."
Well … in case you have multiple reginal data centers it makes more sense … this is case similar to what I've described as "snow flake"
This is a great post. I wish I had seen something like this many years ago! As with Brad's comment, we were also repeatedly left out on new subnets getting added where Windows systems were placed. On the plus side, I simply had to check the DC event log to find event ID 5778 or 5807 to find missing subnets and add them to AD Sites and Services. Very handy. Except we had (at the time) over 50 domain controllers. Obviously, there could be a delay in getting new subnets set up so clients could be getting connected to a DC in a different part of the world. We always tried to add a more general, all-ecompassing subnet for each site so that we didn't have a bunch of discrete subnets to manage, but the networking team would frequently add a completely new subnet not inclusive in the already existing generalized subnet. A couple of years ago, I chose to use a tiered approach like what you term the "snowflake" topology to use "catch-all" subnet entries. I set our main colo (HQ) to use the most generic (largest) subnets, then the 5 main datacenters outside of HQ to use the largest subnets that would be used in those areas, and then the office sites to use the more specific subnets. This has resolved the issues of clients getting connected to DC's that are too far away. To me, it is a huge downside to no longer receive the events that show missing subnets. I wish that there was a good way to get the best of both, because now we have many new subnets that I am unaware of and that are not in AD Sites and Services, so many more clients are getting routed to the datacenters rather than the DC that is closer to their site. — Rob —