This is my long planned post on the evils of IP Subnet boundaries in ConfigMgr – this includes both 2007 and 2012 because nothing has changed between the two versions as far as boundary implementation goes.

The primary reason for the “evilness” of IP Subnet boundaries is that they do not represent or define IP Subnets at all: They actually define Subnet IDs. This is evident to anyone who has gone back into the definition of an IP Subnet Boundary after creation and noticed (wondered even) why the subnet mask is no longer there as shown below.

During Boundary Creation	After Boundary Creation

So what’s going on? When you create an IP Subnet Boundary, you enter a Network and a Subnet mask and the Subnet ID is calculated for the boundary; however, the expectation when creating an IP Subnet boundary is that you are defining a range of IP addresses exactly like in Active Directory. Notice in the following screenshots though that AD does not discard the subnet information (defined as bits instead of the traditional but equivalent subnet mask format).

During AD Subnet Creation	After AD Subnet Creation

You can actually just enter the Subnet ID when creating an IP Subnet Boundary. Either way, the point is that only the Subnet ID is significant to ConfigMgr because, as mentioned, they are actually Subnet ID boundaries.

This leads us directly to why Subnet ID (aka IP Subnet) Boundaries are evil: because Subnet IDs are subjective and no longer valid in modern networking where Variable Length Subnet Masks (VLSM) have been the norm for over a decade. Subnet IDs are only useful if you know the subnet mask. Prior to VLSMs, this was easy because all IP addressing used the standard class A, B, and C addresses with standard subnets masks of 255.0.0.0, 255.255.0.0, and 255.255.255.0 respectively. With VLSMs in the picture though, a single Subnet ID can actually define multiple different subnets or an IP address can be part of multiple subnet IDs. This ambiguity is unacceptable when defining boundaries as it can lead to overlaps (which are generally bad in ConfigMgr even in 2012 where overlaps are still unsupported for site assignment), clients not being members of the boundary that you think they should be, or clients not being in any boundary. This is illustrated in the following table.

The first two lines in the table above show the fact that IP addresses from two different (but overlapping) subnets actually have the same Subnet ID. The last two lines show the same IP address having two different Subnet IDs. In both examples, the subnet mask is important and without it, the Subnet ID is useless in defining a scope, or range of IP Addresses.

The use of subnet IDs has additional issues also. Specifically, during site assignment. There are two times that site assignment happens: discovery and client agent initiated.

During discovery, the site server discovers resources and their IP addresses; it does not and cannot discover their subnet masks. Thus, to calculate each resource’s subnet ID, which it compares across the subnet IDs in defined boundaries, the discovery process must somehow identify the subnet mask of the client. It does this in one of two ways: by using the AD subnets or by assuming A, B, C standard subnets if there is no corresponding IP Subnet in AD. Both of these are bad ways to identify the subnet mask of a client’s IP. Many use either aggregated subnets when defining subnets in AD so using them to determine a subnet mask is totally not indicative of what the actual IP Addressing scheme is. This will of course throw off the calculation of the subnet ID exactly as illustrated in the table above. Using the fallback of A, B, C classes is equally bad for the same reason. Ultimately, neither is necessarily accurate because neither way can actually identify the subnet mask and thus should not be used to calculate the Subnet ID.

During client side site assignment, the subnet mask is of course known, but because of the issues detailed in the table above, this may not meet your expectations and also may not meet the site assignment done during discovery which could cause other issues like downloading and installing the client from a site across the WAN.

What are the ramifications of the above? That depends. If your IP addressing scheme follows the A, B, C classes, then you may not actually have any issues as long as you define your boundaries with those same subnet masks/subnet IDs that follow the A, B, C class rules. and you don’t aggregate your subnets in AD. If you are doing any type of VLSM addressing or try to do any aggregation of subnets, you will run into issues in site assignment during discovery, client side site assignment, and content location.

The solution: It’s simple. Use IP Address Range boundaries and only IP Address Range boundaries. They are completely unambiguous, have none of the issues described above, work exactly as you think they should, do not rely on AD IP Subnets, can be aggregated freely, and can be very granular (down to a single IP Address if needed).

Even if you don’t understand any of the above, the simple fact that IP Address Range boundaries do *exactly* as their name implies – define a start and end IP Address and include everything in between – without any ambiguity, should be reason enough to use them instead of IP Subnet boundaries.

IP Address Ranges are even easier in ConfigMgr 2012 because the new Forest Discovery will automatically create them for you.

IP Address Range boundaries FTW!