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.
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.
Revisiting the comments, here are some thoughts:
1. The concept of a supernet is a server-side construct that abstracts remote subnets to simplify routing. For local subnet interfaces and clients, they local subnet is always used. Since all of the location and assignment logic is evaluated on the client, the client would never be able to accurately handle a boundary that referenced a supernet.
2. I see a lot of confusion on this thread with regards to ConfigMgr "interpretation" or "assumption" of a subnet. In actual implementation, there is no assumption going on. All of these evaluations are direct string comparisons that occur from data provided by the client. The client sends a list of its subnet ID, IP address and AD site and these are evaluated for appropriate location and assignment requests in SQL via a straight string comparison - except for IP range boundary types.
3. This is where things become expensive. As string comparisons, the SQL evaluation is a simple does "x" equal "y" for AD sites and for IP subnets. For the IP range boundary, the SQL query is a calculation of the potential range of values and a comparison of whether the subnet falls within the range, which is far more expensive.
4. In general, the goal should be efficiency of boundary usage. Regardless of boundary types, using 10,000 boundaries for 40,000 clients well lead to SQL contention when clients make location/assignment request. If you do need to use more than 100 clients per boundary, you should use less SQL intensive boundary types for your strategy.
@RobS - everything I know about IP supernetting I learned in my NT 4.0 MCSE :)
@DonP - the term "supernetting in use" needs to be decomposed a bit. Every network has supernetting of some type. The real question is where is the supernetting in use. If you are using supernets in AD, you can encounter issues when "mixing" boundary types between AD Sites and IP Subnets. In general, even if your environment is using Supernets, as long as you reference the actual local subnet in your boundaries, you will be fine.
@John Marcum - the subnet mask is important as a means to calculate the subnet boundary (going back to the MCSE reference, this is the "IP anding" exercise we all know and love). Once the value has been calculated it really is not necessary.
@Ralph Kyttle - I've spoken with the author of that section of the book and clarified how the process works. There are no "assumptions" involved. We use a Windows API and ask for the subnet values entered into the AD site.
@Mark Phillips - you are correct that the mask is not really important. We only use the mask to help a user derive the appropriate subnet. That way they can input any IP address in the range, add the mask and we will derive the Subnet ID for the user.
This was discussed in greater detail at MMS 2013. You can see more information at this session channel9.msdn.com/.../UD-B403 starting at the 14:12 mark.
I guess you misinterpret whats written in the book and blog by Jason.
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.
Below is 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.
Thanks Jason for nice Post.
Yvette, you contradict M$ guidlines for ConfiMan 2012. Take your post down. It only adds to the confusion on the topic.