Managing an Active Directory Environment With Thousands of Subnets

Solution 1:

You don't need to create a new subnet for every single Layer 3 subnet that the network people create. Instead, create subnets corresponding to the IP address allocations for the entire site.

Here's a quick example.

Say you have two sites. Let's call them "New York" and "Mountain View". New York's entire IP allocation is 10.187.128.0/22. Mountain View has 10.187.132.0/22, but it also has some old cruft hanging around in 10.244.0.0/16.

The network guys will divide all those addresses into tiny subnets of as small as /29, there will be thousands of them, but they're all contained within those supernet blocks.

Within AD, though, the New York site only needs the one subnet defined, and the Mountain View site only needs the two subnets defined. They cover all the possible IP addresses within their respective blocks.

Solution 2:

Assuming that you actually "need" these subnets and can't do as @MichaleHampton suggests in his excellent answer...

If you don't like idea of hiring 50 AD admins, you hit your network administrators with the nearest hard, blunt object until they stop making such fundamentally awful design decisions.

Really, I can think of no earthly justification for thousands of ["real"] subnets^{*See "footnote"}, beyond the curiosity of seeing how big a mess you can make of something in a lab or test environment, and anyone who even does approach that number of ["real"] subnets is a massive multi-national corporation with a market cap larger than most country's GDPs, or is a large national/trans-national ISP/hosted-service-provider. And in both cases, they literally do have dozens of people on staff to keep it somewhat sorted.

There's just no way you're going to be able to get a handle on this otherwise. Either hire dozens of people to sort it out, or change the network design to... suck less... and be even remotely manageable by less than a platoon of sysadmins.

Honestly, don't even try. It's got "fail" and "burnout" and "awful idea" written all over it. Trying is like rearranging the deck chairs on the Titanic after it hit the iceberg. Any improvements you are able to achieve are soon to be overshadowed and undone by sinking down through several thousand feet of icy water, so your time is probably better spent reclining on the deck chairs, grabbing some liquor and a smoke, and enjoying those last moments before you're swallowed up by certain death. (And I can't tell if I'm being metaphorical there or not, FWIW, I know 3 guys in IT who've have heart attacks before 35 from this kind of insanity.)

And, of course, if you can't change minds of your superiors or network team, well, you can't marry a corporation in any country I'm aware of, so your best option might be to leave. No job is worth having a heart attack in your early 30's over.

^*Footnote:

By "real" subnets, I mean to say subnets that are actually used as such. I've been in hosted service environments with thousands of customers, where each customer gets a simple, flat subnet that's not actually managed or changed by the hosted service provider, but it definitely does not sound like that's your use-case. If it is, let me know and I can adjust my answer, because that's fairly easily handled with an *AMP database (or *AMP-like product).

Solution 3:

"Learn to script" is a good answer. Presumably, someone is doing these things with a plan, that is created in advance? Work from their plan to create/modify/etc these sites and subnets in AD at the same time.

Some further thoughts - if this is "ever-evolving", does that include user desktops in these subnets? If it doesn't, then you don't even really need to do this. If it does, is someone already handling the constant changing of IP addresses, DHCP scopes, etc? Perhaps you could delegate to them.

Another thought - if these subnets are not always across WAN links, (ie subnets that could be supernetted together are well-connected with high-speed LAN connections), then just make the sites and subnets match the supernets and don't worry about these things at the subnet level. (edit - this is the same thing Michael Hampton is saying in his answer and link.)

Solution 4:

In addition to the answer Michael Hampton provided, I'd like to add the following:

There are scenarios where you need to think about how you want authentication and resource access to work when you're configuring ADS&S and then you need to configure ADS&S accordingly. As an example, let's say that I have three geographically dispersed locations as such:

Main Office: Cleveland - 192.168.1.0/24 - High speed Ethernet connection to the satellite office and has two DC's. Low speed WAN connection to DR site.

DR Site: Akron - 192.168.2.0/24 - low speed WAN connections to main office and satellite office and has two DC's. AD Replication is restricted to off hours.

Satellite Office: Canton - 192.168.3.0/24 - High speed Ethernet connection to the main office - Has no DC's. Low speed WAN connection to DR site.

Now if I create a site for each location that has DC's and associate only those subnets with those sites, then by default the clients in the satellite office will attempt to establish affinity for and authenticate to the DC's in the DR site and access resources that utilize ADS&S information (like DFS) by virtue of the fact that the DR site is the closest AD site to those clients (from a layer 3 perspective), which is not what I want because of the low speed WAN connection and the fact that AD replication only occurs after hours and AD is likely to be inconsistent between the Main office and the DR site (except for those changes that trigger urgent replication).

So what I would do is to create and associate the 192.168.3.0/24 subnet with the Main office site. That allows the clients in the Satellite office to establish affinity for and authenticate to the DC's and access resources in the Main office site via the high speed Ethernet connection, which is what I want.