Regarding the SQL cost, this is the one topic that would be useful to have more information. That IP address ranges are 1000x more costly, or 10000x more costly really does not mean much to me. What does that really mean?
There are many ways to solve performance issues within SQL; properly created indexes, storing indexes on separate data files, properly tuned queries, re-organizing indexes/statistics, etc. Stored procedures that get pegged in memory for faster execution times. Could it be that the fundamentals of how the actual subnet ID is calculated may work for 100, or 1000 subnets. However, that may not scale to 10,000 subnets. That’s where Maik is probably correct., maybe the algorithm needs to be revisited. Seems to raise more questions than answers. From: [email protected] [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Friday, May 24, 2013 8:28 AM To: [email protected] Subject: RE: [mssms] Wait, whut? Only use IP ranges in certain cases as boundaries? Jason, Steve (Rachui) and I discussed this at MMS (before the showed started) – all three of us also discussed this in our sessions (Steve had one exclusively on boundaries). Basically, it comes down to this: If you know exactly what a subnet ID is, you know how to properly configure boundaries using them, and your AD sites don’t use any aggregation, then subnet IDs are best performance wise and should be used if you have a lot of subnets or experience performance issues (I was told by one of the devs that it’s 1,000 times more costly against SQL to process a subnet range!) The reality is that most do not know how to do this, don’t have subnets set up without aggregation in AD (if they have them set up at all), or simply don’t have that many subnets where this will ever affect them. There are lots of caveats and ways to optimize boundaries also and some other background info that isn’t really worth going into. Basically, my recommendation still stands unless you start experiencing performance issues during client content lookup on the SQL server (or expect to because you have thousands of boundaries). J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Friday, May 24, 2013 9:07 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Wait, whut? Only use IP ranges in certain cases as boundaries? Very well written Maik! lol From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Koster, Maik Sent: Friday, May 24, 2013 6:07 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Wait, whut? Only use IP ranges in certain cases as boundaries? That’s still complete lack of understanding on how VLSM works and how it’s being used. Without a subnet mask, the so called subnetID is always guessing, as depending on the subnetmask, you have the same SubnetID for different sized address ranges. And that the algorithm to identify a client within an IP range is performance intensive, is a lame excuse and problem of the algorithm itself. If they prefer creating a temporary table of all possible IP addresses in that range just to be able to do a string comparison instead of converting the IP of the client and the start and end of the range into a long value so they can easily identify if it’s within that range, it’s rather wrong choice of algorithm. If you have to mow the lawn and in your imagination always think about doing this for a size of a square foot area, you might pick a scissor. But then saying that using the scissor on 20 hectare is resource-intensive and people should rather place concrete on it, instead of providing a proper lawn-mower, doesn’t really sound like they understood the problem itself. Maik From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Trond Karstensen Sent: Freitag, 24. Mai 2013 13:16 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Wait, whut? Only use IP ranges in certain cases as boundaries? Jason Adams has published some feedback to all the comments: http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx?PageIndex=2#comments J Sandys and J Marcum care to comment ? ☺ Trond From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: 5. mars 2013 05:32 To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [mssms] Wait, whut? Only use IP ranges in certain cases as boundaries? Note that I’ve begun a dialog with Jason on this one (the PM that wrote the blog post) and gotten a lot of feedback from peers and members of the community so I’m sure an updated blog post will be forthcoming with the end goal to help everyone implement ConfigMgr “better”. J From: [email protected]<mailto:[email protected]> Sent: March 4, 2013 3:40 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] Wait, whut? Only use IP ranges in certain cases as boundaries? +1 for Jason! Never heard you disagree with the Borg leaders before On Sat, Mar 2, 2013 at 1:49 PM, Jason Sandys <[email protected]<mailto:[email protected]>> wrote: > I think everyone knows my opinion on this one. > > The author does make one valid point, IP Address Range boundaries are more > intensive to process and thus have a performance impact. That's his only > valid point though. He even implies that AD uses subnet IDs which is > completely false. > > He starts out by supporting his argument based on SMS2003 behavior as if > that makes it valid; i.e., we didn't have it there before so it's wrong > now. Terrible logic. Just because it wasn't there before, doesn't mean that > IP Subnet [ID] boundaries are correct. > > "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 statement is "laughable" (sorry, no offense, don't know how else to > put it though) as it shows a complete lack of understanding of IP > addressing. It all comes down to the fact that in a Variable Length Subnet > Mask (VLSM) world -- which we've been in for almost 15 years btw -- a > Subnet ID does *not* uniquely identify a subnet. > > The correct solution is to implement a new boundary type that is truly > based on IP Subnets (like AD does) and not IP Subnet IDs. > > I'm going to pass my feedback on directly also and will see what happens. > > J > > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto: > [email protected]<mailto:[email protected]>] On > Behalf Of Marcum, John > Sent: Saturday, March 2, 2013 10:15 AM > To: <[email protected]<mailto:[email protected]>> > Subject: Re: [mssms] Wait, whut? Only use IP ranges in certain cases as > boundaries? > > I could not disagree with that blog more. > > 1. It is microsoft's own terminology that created the initial confusion > around the importance of the subnet mask. That statement has never been > clarified to my satisfaction > > 2. The paragraph about subnet masks makes me think this person works in a > eutopian environment. In the real world the mask doesn't always match the > subnet ID. I'm not saying that's good practice but that's the way it is. > > > > Typos courtesy of Apple. Sent from my iOS device. > > On Mar 2, 2013, at 9:56 AM, "Lindenfeld, Ivan" <[email protected] <mailto:[email protected]%0b>> <mailto:[email protected]>> wrote: > > Official Microsoft blog: > > > http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-a ddress-ranges-as-boundaries-in-configuration-manager.aspx > > This goes against the prevailing wisdom of this list, including my own. > > Ivan Lindenfeld > > > ________________________________ > > Confidentiality Notice: This e-mail is from a law firm and may be > protected by the attorney-client or work product privileges. If you have > received this message in error, please notify the sender by replying to > this e-mail and then delete it from your computer. > > ________________________________ > > Confidentiality Notice: This e-mail is from a law firm and may be > protected by the attorney-client or work product privileges. If you have > received this message in error, please notify the sender by replying to > this e-mail and then delete it from your computer. > > > > > > > > > > > > - C.htm ----------------------------------------- This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information of Cameron and its Operating Divisions. Any unauthorized use or disclosure is prohibited. If you are not the intended recipient, please contact the sender by reply email and delete and destroy all copies of the original message inclusive of any attachments. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
