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]> 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]] *On Behalf Of *David Jones > *Sent:* Tuesday, March 3, 2015 1:09 PM > *To:* [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]> wrote: > > First, to summarize the example: > > > > IP Subnet boundary: 10.1.0.0 > > Clients (assuming /24 subnet mask): 10.1.0.100/24, 10.1.1.100/24, > 10.1.2.100/24, and 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]] *On Behalf Of *Miller, Todd > *Sent:* Thursday, February 26, 2015 9:00 AM > *To:* [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 > and 10.1.4.0/22 and you think “why not just specify 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 AND > 10.1.4.0/22 and not the “supernet” of 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 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] <[email protected]>] *On > Behalf Of *David Jones > *Sent:* Thursday, February 26, 2015 7:47 AM > *To:* [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. > ------------------------------ > > > > > > > > > >
