It is often surprising to me how what may seem like innocuous decisions on how to configure settings in Configuration Manager can lead to very different performance results. A case that has come up recently is the difference between using IP subnet based boundaries and IP address range based boundaries. While many users assume that the two boundary types are two varieties of the same thing, they were designed for very different applications and that difference can have a profound impact on the overall performance of your site.
The IP address range boundary type was designed to remedy a simple problem. When VPN clients interacted with older versions of Systems Management Server, the precursor of Configuration Manager, the VPN clients did not present a subnet that could be rendered via either Active Directory site or IP subnet boundaries. To remedy this situation, the concept of an IP address range boundary was created specifically to handle VPN clients. The design intent, however, was to continue to use Active Directory site or IP subnet boundaries for non-VPN clients. If you prospect through the Internet, you can find the original guidance on the use of ranged boundaries in the Systems Management Server 2003 documentation. In fact, in the original implementation, ranged boundaries could not be used for site assignment – only for distribution point and management point location requests.
Over time, customers have adopted ranged boundaries for uses other than VPN clients. This was not the intent, but should be fine for a small scale implementation of Configuration Manager. However, in recent years, blogs and other commenters have appeared recommending the replacement of all boundary types with ranged boundaries. While it is true that ranged boundaries represent a more granular approach to defining sets of clients, they are often not necessary and in all cases ranged boundaries have a larger performance impact on your site server than the use of other boundary types.
As an example, I have heard customers indicate that the lack of persistence of the subnet mask makes them nervous about using IP subnet boundaries. This is often fed by the misperception that the subnet mask is required along with the network ID to identify the subnet a client belongs to. It is true that the subnet mask is essential when configuring a subnet on routers or other networking devices. It is also important to have the subnet mask to calculate the network ID from an IP address. However, once the subnet ID is derived using the subnet mask, it is no longer required by Configuration Manager. The subnet ID is an intrinsic attribute of the system in the Configuration Manager database. This is an important consideration for performance.
When Configuration Manager runs a database query to determine if a client exists within a boundary, the type of query required to match the client depends on the boundary type in use. The different boundary types require different queries. In the case of an Active Directory site boundary or an IP subnet boundary, the query attempts to match the exact value of the subnet or the site against a specific attribute of the system. This is a relatively inexpensive SQL query. On the other hand, when the boundary is an IP address range with a range of values, the query requires a complex join against a temporary table composed of all values above the minimum and below the maximum. This last query (for ranged boundaries) is an extremely expensive SQL statement that must be checked for each ranged boundary in the database. Thus, with more ranged boundaries and larger ranges for those boundaries, the query places more pressure on SQL Server. In addition, in System Center 2012 Configuration Manager SP1, we added new functionality that assesses all clients on a regular basis to determine if any client assignments have changed based on new boundaries. This means that boundaries are assessed regularly. The more IP address range boundaries that are used, the more additional pressure is put on the SQL instance.
The IP address range boundary fills a gap in the client assignment story for Configuration Manager. For clients on edge networks that lack either an Active Directory site or a subnet, ranged boundaries are an excellent way to extend management capabilities. However, it is important to remember that ranged boundaries are designed for a specific purpose and should only be used in scenarios that cannot be addressed through Active Directory site or IP subnet boundaries. When designing your boundary strategy, we recommend boundaries that are based on Active Directory sites. Where those are not possible, use IP subnet boundaries. If neither of these options are available, then leverage IP range boundaries.
This posting is provided "AS IS" with no warranties and confers no rights.
Your statement, while true that "once the subnet ID is derived using the subnet mask, it is no longer required by Configuration Manager" is exactly why people don't trust using it. For instance, assume the network 10.100.240.0. If a machine with the adddress 10.100.241.15 attempts to connect, is it in the boundary? Did SCCM interpret that as a class C network or as 10.100.240.0/20? Knowing that and controlling that is important to people that know what they are doing.
Seems the people in the Active Directory team seem to understand subnetting and supernetting a little better than those SCCM guys. Maybe they should take a Network Essentials class from the NT 4.0 MCSE's.
"However, in recent years, blogs and other commenters have appeared recommending the replacement of all boundary types with ranged boundaries. While it is true that ranged boundaries represent a more granular approach to defining sets of clients, they are often not necessary "
Would it be considered "necessary" to use ranged boundaries in the scenario where supernetting is in use?
Or where an internal network is employing Class A private IP (based on 10.0.0.0 and subnetted along the lines of CIDR RFC4632) ?
Any gotcha's in there at all ?
Sorry Jason but I have to disagree with your conceptions of the importance of the proper subnet mask being assigned to the client. Also the terminology in the MS docs, specifically the usage of the word "super nets" has added to the confusion around IP subnet boundaries. That support statement needs clarification.
Excellent Stuff. There were a lot cases the month pertaining the same issue.
Great post!! However, you have now turned the post-modern world on its head!!
Can you publish the tested / supported IP addresses range and AD site and services limit?
I was wondering how to compare these two:
A. relatively inexpensive SQL query
B. an extremely expensive SQL statement
And in a real world how much pressure does it put on the SQL server?
Would you please comment on the following excerpt from the System Center 2012 Configuration Manager Unleashed book? (www.amazon.com/.../ref=sr_1_1)
"AD site and IP subnet boundaries suffer from the same major shortcoming: They do not work correctly with the Classless Inter-Domain Routing (CIDR) method commonly used in networking today. CIDR uses variable length subnet masks (VLSM) to provide more flexible addressing than the older class A, B, and C IP subnets. Both AD site and IP subnet boundaries assume the use of a specific subnet mask based on the legacy “class” assignment of the specified subnet. Here is an example of the problems you can run into using these types of boundaries.
An AD site used as a boundary contains the IP subnet of 192.168.14.0– 192.168.15.255 or 192.168.14/ 23. ConfigMgr calculates the subnet ID as 192.168.14.0. If you now have a client with an IP address of 192.168.15.27 with a subnet mask of 255.255.255.0, or 192.168.15.27/ 24, the calculated subnet ID is 192.168.15.0. Although the client’s IP address is clearly within the range specified in AD, the subnet ID comparison does not match and the client is not assigned during discovery.
In addition, clients unable to retrieve site information from your AD, such as workgroup clients or clients in domains that do not have a trust relationship with your site server’s domain, cannot use AD sites as boundaries. For these reasons, IP ranges or IPv6 prefixes are usually the best choice for defining boundaries."
FYI: Lots of rebuttal to this...
And, the thread is still ongoing on the SCCM email discussion list if you want to join in: myitforum.com/.../email-lists
Might want to revise this post due to some customer community comments and continuing threads: myitforum.com/.../official-microsoft-blog-on-ip-address-ranges-as-configmgr-boundaries-met-with-instant-rebuttal
Any ideas why the Active Directory Forest Discovery has a tick box option "Automatically create IP address range boundaries for IP subnets when they are discovered".
It seems like this will be doing exactly the opposite of what you recommend.
Do you have any comments or response to the questions everyone has asked on this topic?
----For instance, assume the network 10.100.240.0. If a machine with the adddress 10.100.241.15 attempts to connect, is it in the boundary? ---
The answer is YES provided the subnet mask of the computer is 255.255.254.0
If the mask is 255.255.255.0, the client will have the subnet calculated as 10.200.241.0.
Subnets in a ConfigMgr are a client-side view of networking. When the client looks for content-location or MP location, it has two information with it. The IP and the subnet. IP is straightforward. Subnet is calculated by IP and Subnet mask. You can see the calculated subnet in SCCM client peoperties in Control Panel. If that subnet is defined in the boundary, you are done. If not, is the IP defined in a bondary range? if yes, OK
Else, there is a problem. It's as simple as that. No need to worry about Classes, Supernet, CIDR etc.
Clearly it is disappointing Jason has not responded, but it also seems that maybe not everyone is understanding what he is saying. If I understand him correctly, it is that when we program a subnet into SCCM for a boundary, we are specifying a specific attribute that is just a number with dots in it. The product team has told me this as well. SCCM is not using that attribute to calculate subnets like we do and like we think of them. Because that would mean creating the type of high cost query that range boundaries create. So if you double click on any of your clients, you'll see subnet as an attribute. Now either that entry matches an entry in your boundaries or it doesn't, that's all. The confusing part for me is, if that is the case, then why ask for the MASK? A MASK simply serves to provide a range for the subnet, in the context of the way we think of subnets. And the bigger problem for me is the enterprise I manage has thousands of subnets when thought of in that single attribute sense, and which, as I described, I cannot summarize.