A subnet by any other name...

There has been a lot of discussion recently around boundaries in Configuration Manager...do you use ranges or subnets? All ranges or all subnets?  What about AD sites?  The ConfigMgr product team as put out blog on this here: https://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx. Rod Trent has raised a few questions and highlighted community feedback over on myITForum: https://myitforum.com/myitforumwp/2013/03/02/official-microsoft-blog-on-ip-address-ranges-as-configmgr-boundaries-met-with-instant-rebuttal/.

Now - I'm not going to step foot into either camp (or even acknowledge any camps).  Rather...I want to discuss how subnets and ranges are used internally by ConfigMgr.

Subnets

Subnets in a ConfigMgr are a client-side (or more accurately a network host) view of networking.  We'll comeback to that in a second; however, that is one of the major reasons supernets don't exist in ConfigMgr (let alone being supported).  Supernets are a network construct for a way of grouping like subnets to make their management and routing more simple. A supernet is like saying all of Japan is supernet A, composed of Tokyo office subnets 1, 2 & 3.  We might want to serve that location through a single ConfigMgr server or site. 

That said, let's go back to client-side.  A client only knows about its IP address and subnet mask.  It doesn't know anything else.  It uses that to determine if an IP address is local or remote (something that needs to be routed by a gateway/router). It is the ConfigMgr client on that network host (Windows device) that determines its IP subnet by applying its subnet mask against its IP address. 

Now - you might think that's simple and too basic; but it is the ConfigMgr client that drives this entire subnet process. It's a client sends content location request, along with SUP and MP list within 2012. When a client does a location request to the MP for content (e.g. packages) it does so by supplying its subnet to the MP.  You can see this by turning on trace logging and looking at Location Services log files or the MP log files (if you have a few clients) - or even firing up NetMon and doing a network trace.  The MP passes the subnet by calling a SQL query with that information to determine if the content/site system is available on that subnet or a remote one (Jason discusses this more in his blog, https://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx).  This is a fairly straight forward comparison of the supplied subnet against a list of subnets.  Obviously...as you get more and more subnets this gets more computationally expensive - but it still string lookup against a list of strings, not the end of the world in SQL complexity.

IP Ranges

IP ranges are conceptually simple.  They aren't even really supernets, there just a range of addresses.  The determination of if a client falls into a range, unlike a subnet, is done by the ConfigMgr server infrastructure.  Specifically it is done by SQL Server.  Again, in the location request you'll see an IP address sent up by the client.  The MP passes that to the SQL Server, and the SQL Server does the determination of where that IP address falls into. Again, Jason discusses this further and discusses why this is a more complex operation than a simple lookup of a subnet we talked about above.  Since the individual query is expensive, adding lots of them burns up more SQL Server resources. 

Real world

Some customers I have worked with have subdivided a subnet into two different IP ranges to support different sites serving different departments or client types.  For example, PCs can only talk to Global End User team's server (not my North America team's server) or Retail Banking cannot talk to Treasury servers (if they contained the same packages).  That's an example of something bad, and something I'd strongly advise my customers against when working with them. Valid ways of using might include (I say might include because the below is not exhaustive):

• You might use IP Ranges when you have been provided with supernets by your networking team (in my Tokyo example, I might group those three subnets into a single IP Range).
• You might use them when your AD sites have been consolidated heavily and DC have been consolidated.  This helps you maintain granularity needed for ConfigMgr.
• You might use them you have a tremendous amount of subnets in your environment (you network team is using subnet masks like 255.255.255.128 or .192 to create very small ranges)
• You might also need them when dealing with the VPN client scenario (naturally :-)

The key is - don't just start throwing IP Ranges just because they work.  Have a think about it.  Know the trade-off when using something more complex internally within the product and costs you more database perf resources but easier to administer.  It's a trade off...

You could probably create millions of IP Ranges, if you get your boss to sign off on 512GB of RAM for SQL Server and a SSD SAN...kidding... ;)

Happy ConfigMgr'ing - Saud

P.S. If your going to MMS - catch my session on reporting in ConfigMgr 2012 SP1 here: https://www.2013mms.com/topic/details/UD-B338

Comments

• Anonymous
  January 01, 2003
  Hi Nagendra, I'm impressed you can get approval for that. :)  Most of my customers struggle with that sort of capital expenditure in this climate. Trust me - we have customers looking at over a million IP host devices across their network.  When I say IP host devices I mean PCs, tablets, mobiles, VoIP phones and printers. When you say real numbers what do you mean?  We have depth scalability testing but in this case the permutation of possible configurations outside of a single configuration like IP ranges make giving a fixed value difficult.  Coming up with a X number of IP Ranges is the maximum possible is very tricky...because what if collection eval is two times more frequent than default or some other similar configuration adds to the load of SQL Server. Regards, Saud

• Anonymous
  April 03, 2013
  The comment has been removed