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.
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).
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.
| IP Address | Subnet Mask | Subnet ID |
| 10.1.0.1 | 255.255.255.0 | 10.1.0.0 |
| 10.1.1.1 | 255.255.0.0 | 10.1.0.0 |
| 10.2.0.1 | 255.255.255.0 | 10.2.0.0 |
| 10.2.0.1 | 255.0.0.0 | 10.0.0.0 |
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!
Hi JAson
Very interesting… awesome blog !!
Thnx a mil !!!!
Very very helpful !!
Thank You. Do note that I am in conversation with a product group on this one as there are potentially grave performance issues with IP Range Boundaries. A follow-up post is in order.
Jason,
do you have an updated post on this topic? I have long been a fan of ip address ranges, as I regularly run into environments where the AD site has defined the subnet as something like 10.16.0.0/12 but there are really numerous subnets defined within that address space. I’ve been in several environments where there have been issues with policy, content and site assignment, but never in an environment where SQL was weighed down by using ip address ranges instead of subnets or AD sites.
I’m anxious to hear your thoughts. Thanks!
http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx
Yes, I’ve finally created an update — sorry it took so long: http://blog.configmgrftw.com/ip-subnet-boundaries-still-evil/
Are you referring to this?
http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx
After all my research I believe:
1. Use All Class C subnets in AD Sites and Services
2. Use AD Sites for Boundaries in ConfigMgr 2012
If not, you will pay the consequences either by performance issues, automatic site assignment and/or content location issues.
I look forward to your follow up.
Jason – Do you have an update on this?. TechNet http://technet.microsoft.com/en-us/library/gg712679.aspx says to only use Boundary ranges when other boundary types cannot be used. “IP address range requires a substantially larger use of SQL Server resources than queries that assess members of other boundary types”
I’m planning a follow up blog post on this, yes.
Hm.. this is not right according to this http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx (The official blog of the Microsoft System Center Configuration Manager Product Group)
Actually, it is right. The info presented in that post simply discusses performance characteristics. It does not discuss usability. I’ve had a follow up post planned for a long time now.
Please remove this article because it is totaly wrong for SCCM 2012.
Actually, no, nothing has changed from 2007 to 2012 with regard to boundaries. The information in this article is 100% accurate (although the example is not real-world).
Hey Jason,
Appreciate the breakdown on this! I am following http://www.windows-noob.com/forums/index.php?/topic/5605-using-system-center-2012-configuration-manager-part-3-configuring-discovery-and-boundaries/ and he pointed me over here. Curious if this is still an issue with Configuration Manager 2012 R2. I tried looking for a followup post on your website, but haven’t seen anything. Do you still agree with your article or has the product team released a change to address this issue?
Thanks!
Yes, my article stands as nothing has specifically changed with 2012 although a follow-up article adding some more information is well overdue (on my part). Also, note that this isn’t really a technical issue, it’s just the result of a very old design choice.
Jason, I agree that subnets are evil. And I generally agree that ranges are far easier and more reliable to apply in CM12 and 07. Having said that, what about AD Sites? How might they compare? Assuming your AD is kept up to date, I would think ADSites would be acceptable.
But I’d like your input and analysis. If you ever get around to your follow up post. 🙂
Yeah, the follow-up post will happen sooner or later.
AD Site Boundaries can be useful and don’t suffer from any perf degradation because like IP subnets, it’s simple string compare. The problem with AD Sites though is that it won’t help you if you have workgroup systems, you’re relying on someone to actually update the subnets in AD, and most organizations need more granularity than their AD topology (in the form of sites) provides. If none of these applies to your org, then yes, AD Sites are an easy answer here. Remember that build and capture is a workgroup operation also so you will probably need at least one additional boundary *when* you do this.
Hi Jason,
Very well explained, many of SCCM Admins always just says IP Subnet may work/ may not work, not always safe to use that.
The way you have explained, it has crystal clear for anyone who needs to know the answers.
Thanks a lot, and appreciate your efforts.
Regards
Manish Bangia
Legend. Thanks for this.
You’re very welcome.
This is incorrect. You could create two overlapping boundaries using subnet ID but one of the subnets would be invalid.
10.1.0.1 255.255.255.0 10.1.0.0 is a 24 bit subnet running from 10.1.0.1 – 10.1.0.254
10.1.1.1 255.255.0.0 10.1.0.0 is a 16 bit subnet running from 10.1.0.1 – 10.1.255.254
While you can create both of these as boundaries in SCCM they would not both exist on the network.
You are correct. The example is technically not valid; however, the gist of the post is still correct for the same (and related) reasons.
@Jason – Thanks. Maybe now you can settle an argument. If computer XYZ is in boundary group A (essentially default boundary, all AD sites) which points to a DP at a remote data center and also in boundary group B (all IP ranges or subnets at the local site) which points to a DP at the local site which DP will it pull content from? I say local site DP.
That depends. If one of the DPs is in the same subnet as the client or the same AD Site, it will be prioritized over the other. If neither is in the same subnet or AD site, it will be random.