Your site server would get taxed as well as your sql resources. Managing and maintaining it won't be an easy task either.
I would drive to use AD sites for boundaries. Cesar On Mar 4, 2015 4:08 AM, "David Jones" <[email protected]> wrote: > 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. >> ------------------------------ >> >> >> >> >> >> >> >> >> >> > >
