Boundaries are mainly about content location/DP lookups. So sure, putting in one big range is technically valid, but that would also imply you only have one set of DPs for all of the IPs within that range; i.e., you only have one well-connected location.
Yes, IP Ranges do consume quite a bit more processing time during content lookups – this is generally only significant if you have thousands of boundaries as mentioned. With 1,200, you are probably safe but that truly depends upon the specifications and capacity of the SQL Server – only base-lining and proper perf analytics will be able to tell you the true impact (there’s no magic when it comes to per and load testing – you have to try it to know). Aggregating contiguous ip range boundaries (which is kind of like supernetting) is one great way to reduce the number of boundaries though and I have been able to achieve up to 30% (or thereabouts) reduction in boundaries for organizations when I do this; e.g., if 192.168.1.0/24 and 192.168.2.0/24 are at the same location and will use the same DP, then they can easily be represented as 192.168.1.0-192.168.2.255 in an ip range. This will take a little while to analyze and determine, but is worth the effort. It’s a simple matter to document what is so that you have a fallback also. J From: [email protected] [mailto:[email protected]] On Behalf Of David Jones Sent: Wednesday, March 4, 2015 6:07 AM To: [email protected] Subject: Re: [mssms] Old Subject: Boundary Subnets Oh well. I wonder if any one has just said to heck with it and put in the range 10.0.0.0-10.255.255.255. The worry here is that one article out there states that using ranges could eat SQL processing time and some have fixated on that. We have 35,000 windows computers only in our SCCM and 1200 boundaries. Without some sort of example to determine what kind of load we are talking about, the worry wins out. Our boundaries are 99% subnet id that theoretically range from /16 to /28 according to a spreadsheet I was shown that wasn't up to date. I want to change to ranges to know for sure that we are covering everything, but...I am just a contractor inheriting a system. Dave On Tue, Mar 3, 2015 at 5:46 PM, Jason Sandys <[email protected]<mailto:[email protected]>> wrote: You don’t. Subnet IDs are independent from the mask. That’s part of the problem here. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of David Jones Sent: Tuesday, March 3, 2015 1:09 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Old Subject: Boundary Subnets Thanks Jason. Something click with what you wrote. I inherited an SCCM system. It works great. I have only found a few anomalies. Some were in boundaries. If I want to check the boundaries against the DHCP servers for scope and subnet mask, how do find out what subnet mask was used originally to create the subnet boundary in SCCM just to confirm accuracy exists? Dave On Thu, Feb 26, 2015 at 11:39 AM, Jason Sandys <[email protected]<mailto:[email protected]>> wrote: First, to summarize the example: IP Subnet boundary: 10.1.0.0 Clients (assuming /24 subnet mask): 10.1.0.100/24<http://10.1.0.100/24>, 10.1.1.100/24<http://10.1.1.100/24>, 10.1.2.100/24<http://10.1.2.100/24>, and 10.1.3.100/24<http://10.1.3.100/24> Clients subnet IDs: 10.1.0.0, 10.1.1.0, 10.1.2.0, 10.1.3.0 Thus, only the clients in the first subnet would match boundary wise. If however you clients were all /22 for their subnet mask, this would work fine. How many folks use a /22 though. As Todd pointed out in his reply also that if your clients are truly using /22 as their subnet mask, then this is *not* a supernet. Supernets are aggregations of multiple subnets at a network level but this is not an aggregation, it’s the actual subnet. The true supernet issue also comes in during discovery because supernets are often used in AD. AD discovery has no idea what subnet mask a client uses (it can’t) so it uses subnet information in AD to determine this and thus the subnet ID. So if you’ve used a supernet in your AD sites, then AD Discovery will calculate the incorrect subnet ID for the client causing it to not be assigned to the proper site. Ultimately, it’s not that all of this doesn’t or can’t work. It’s that most folks don’t understand (or truly have the need to understand) the details of what’s going on and by simply using IP Address ranges, you don’t need to either. They are completely straight-forward and simple. The only caveat is for orgs with lots of boundaries (think thousands) then there can be perf implication. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Miller, Todd Sent: Thursday, February 26, 2015 9:00 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Old Subject: Boundary Subnets I think the only thing here is confusion over what a supernet is. Your example is correct. You have a subnet that has a mask of 255.255.252.0 and covers a range from 10.1.1.0 to 10.1.3.255 with the gateway at 10.1.1.0. That is a subnet, not a supernet. An example of a supernet might be that you have two subnets 10.1.1.0/22<http://10.1.1.0/22> and 10.1.4.0/22<http://10.1.4.0/22> and you think “why not just specify 10.1.1.0/21<http://10.1.1.0/21> in the SCCM boundary instead and cover then both?” That would be where you would run into trouble. You would need to specify both subnets 10.1.1.0/22<http://10.1.1.0/22> AND 10.1.4.0/22<http://10.1.4.0/22> and not the “supernet” of 10.1.1.0/21<http://10.1.1.0/21> Or maybe you have 256 subnets 10.1.0.0, 10.1.1.0, 10.1.2.0 …. 10.1.255.0 and you think “Hey, I’ll just specify the boundary as 10.1.0.0/16<http://10.1.0.0/16> and cover all my addresses with one line. You can’t do that. If you did this, the clients in 10.1.0.0 would work since their subnet is listed in SCCM, and the other 254 subnets would not since their subnets are not listed. You could however specify a single address RANGE of 10.1.0.0-10.1.255.255 and be done. So, it is easier to maintain a single range rather than define 256 subnets (powershell not included.) Also, when the computer tries to check its boundary, if you have 256 ranges, it needs to look through more data to figure out if it is in scope. If you had a single range defined, it would only look at one piece of data. I think these arguments are less important now with easy to create boundaries and fast AD clusters. Another reason that you might avoid subnets as boundaries is that it is not always the case that the computer’s IP address is configured correctly. Someone might misconfigure the IP information on a client and then the subnet might be computed incorrectly, although hopefully that is unlikely if you are using DHCP. The computer’s subnet is computed by the client so if the IP information is incorrect, the client might compute its subnet incorrectly. (I am about 90% confident of this answer – I am not a network engineer) From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of David Jones Sent: Thursday, February 26, 2015 7:47 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] Old Subject: Boundary Subnets I've spent the last few days reading as much as I could find on the old fun topic of boundary subnets vs. ranges. It get both arguments. Just reading them would lead one to believe that "best practice" on this topic is based on ones interpretation of the many articles. Such as, If the subnet is a /24, then entering it as a ‘subnet’ is best. If it is a supernet of some kind, then entering it as a ‘range’ seems to be better. So I did some testing and now I have a question about my findings. Test is based on this partial comment in one of the articles online... ----For instance, assume the network 10.100.240.0. If a machine with the address 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. I looked for a supernet on our network and used a /22 boundary where the DHCP gave out addresses across 4 'class C' subnets. I looked in DHCP and found a computer that was issued an address from each subnet. Then I looked each up in the SCCM console and looked at their properties. In all 4 cases the device property 'IP Subnets' showed the correct subnet entry that was created in the boundary when we used the subnet mask 255.255.252.0. Example: Create Boundary as a Subnet: 10.1.1.0, mask 255.255.252.0 results in Subnet ID=10.1.0.0 DHCP issues IP's from : 10.1.0.1 to 10.1.3.254 Find computer name for IP's: 10.1.0.100, 10.1.1.100, 10.1.2.100, and 10.1.3.100 Look up all 4 computers in SCCM and find their device property 'IP Subnets' is the same on all 4: 10.1.0.0 So... I am making the assumption that the property 'IP Subnets' in the device properties is what is used by the client to determine the boundary and is compared to the boundary Subnet ID. Am I a correct or not? If that is correct than I don't see where putting in a boundary as a supernet is a problem as the partial comment I used above would indicate. Dave ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________
