IP Subnet Boundaries Are Still Evil

Yes, IP Subnet boundaries are in fact, still evil. This is the long (very long) overdue follow up to my previous post called IP Subnet Boundaries are Evil. Since creating that post, there has been some serious FUD so let’s set the record straight.

It’s not that IP Subnet boundaries don’t work. They absolutely do work. The problem as I described in my original post is that they don’t work like nearly everyone expects them to work. Thus, folks make assumptions based upon their experience with the word “subnet” and when those assumptions aren’t correct, they become dazed and confused (and then blame the product instead of their own misunderstanding of what should happen). If you know exactly how they work (and when boundary use depends upon subnets defined in AD as described in the first-post — hint: during discovery), then they work just fine.

The crux of the problem is that IP Subnet boundaries do not define subnets using CIDR notation like most folks are used to even though you do specify a subnet mask when creating them. They define a subnet using a subnet ID. Sometimes, these actually correspond to each other, but not always. This, of course, leads to more confusion because sometimes they appear to work and sometimes they don’t.

Subnet IDs are calculated from an IP Address and subnet mask. A client’s subnet ID, calculated from client’s own IP Address and subnet mask, is sent to an MP by the client during auto site assignment and content lookup.

[ms_panel title=”Subnet ID Examples” title_color=”#f5f5f5″ border_color=”#00274c” title_background_color=”#00274c” border_radius=”2″ class=”” id=””](IP Address) 10.5.89.7 + (Subnet Mask) 255.255.255.0 = (Subnet ID) 10.5.89.0

(IP Address) 10.5.89.7 + (Subnet Mask) 255.255.240.0 = (Subnet ID) 10.5.80.0

[/ms_panel]

This ID is then compared against all subnet ID boundaries (within the appropriate type of boundary group) for comparison.

This sounds simple enough. The problem comes in when folks create boundaries using subnet masks that don’t exist on the clients. This (hopefully obviously) leads to a different subnet ID being calculated for the boundary than they expected. It is also different than the one calculated on the client and thus the client does not fall into a defined boundary (or boundary group).

So, why do folks not put in the proper subnet mask when defining boundaries? There are few answers here (although others are possible):

• They are trying to use “supernets”.
• They honestly don’t know the subnet masks being used by the clients.
• They don’t know any better.

Let’s address each in turn.

Supernets: Given the info just provided, these won’t work. Subnet IDs simply don’t allow for supernets. You must define each and every subnet in use.

Unknown subnet masks: Many folks argue that all client subnet masks should be known or should be easily discoverable. Unfortunately, this simply is not true in the real world. In a well-designed and/or maintained networking environment, yes, this is probably true. But, in the real world folks do all sorts of crazy things or have networking teams who refuse to collaborate or share information.

Don’t know any better: There are a lot of system admins that just haven’t picked up the manual to know what a subnet ID is or even what a subnet is. While this is foundational knowledge for all IT folks, many folks simply don’t possess much of what I consider foundational and essential for success in IT.

IP Address Range boundaries address all of the above because they are simple, don’t rely on subnet masks at all (whether known or unknown), and can combine multiple contiguous subnets into a single boundary.

That leads us to information revealed last year about the performance of IP Address Range boundaries: IP Address Range boundaries take significantly more processor time to evaluate on the SQL Server side. I’ve been told upwards of 100 times more intensive, but I’m not sure if that’s accurate or not and have no way to truly verify. The performance revelation is detailed at When not to use IP Address Ranges as Boundaries in Configuration Manager. The problem with this article though is that it applies the recommendation for the worst case scenario to all ConfigMgr installations while ignoring the reasons folks chose not to use IP Subnets in the first place and the possible problems they present. The article also makes the recommendation based solely on one aspect, performance, that does not affect or impact the overwhelming and vast majority of ConfigMgr installations.

So, when is the use of IP Address boundaries truly impactful in the real world? Based on experience and evidence from others, this additional load only becomes truly problematic when a site has thousands of boundaries or the SQL Server instance hosting the ConfigMgr DB is underpowered (or both). The one time I’ve actually seen this in production, the site had over 4,000 IP Address Range boundaries configured and the SQL Server instance was on a shared-cluster (and thus over-worked). Ultimately, the problem manifests itself as content location only sporadically working or not working at all.

So, what conclusion should that lead us to? As per life in general (IMO), unless you have a good, solid technical reason to not choose the simple thing you should always choose that simple thing, which in this case is IP Address Range boundaries. The exception here (which is a good, solid technical reason) is if you actually have thousands of boundaries.  If your SQL Server is not properly sized then you have other issues to begin with that will cause you other problems and you should address that first instead of boundaries type usage.

Also, note that you should combine contiguous IP ranges into a single boundary if they are going to be added to the same boundary group. This will reduce the total number of boundaries. At the customers that I have done this at, I’ve eliminated about 30-40% of their existing boundaries.

If you still want to use IP Subnet boundaries, please do so. Just make sure that you do your homework, know all of your client subnet masks, and know what a subnet ID is.