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 :).