I've only administered rather small networks (<=25 nodes). Usually I put the gateway .1, dns/proxy as .10, mail at .20, printers at .30-39 and so on and so forth. I never directly use IP addresses as DNS hostnames are clearly the better way, but I like to have a clear pattern/layout/design when building a network from scratch.

My DNS mapping also has a simple naming pattern/layout as well. For example, all of my devices have two names; one formal name based on role (dc01, mail02, etc.) and an informal name. Nothing fancy, but real simple and manageable.

I'm trying to figure out a more intuitive/creative IP/Subnet/DNS scheme (if there is something better). I'm sure others have more intuitive schemes depending on the network objectives and such. My network that I'm working on is still small, but I have numerous devices to contend with.

I'm looking for a general pattern or methodology to assign IP address (ranges/classes), dns names and subnet networks that encompasses 4-5 major points:

  1. Network services (mail, file, proxy, etc.)
  2. Software development (environments - dev/staging/prod,
  3. Media (streaming, large file transfers, archiving)
  4. Virtual servers/desktops
  5. VoIP

I've never worked directly with VoIP but it's something to take into consideration for the future.

Overall I got some really good ideas from everyone. Wish I could give out more votes/accepted answers. Thanks for the responses!


Keep it simple. As simple as possible, but still allowing for security and flexibility. Design abstraction into things, which sounds like it's not simple, but in fact is the pathway to simplicity itself.

As for subnets, this is fairly common:

  • Users on one subnet
  • Guests on another
  • Servers on their own subnet
  • VOIP on its own too.

Filter traffic through each subnet as necessary. Possibly use VLANs. I hope you are intimately familiar with the CLI of your network device vendor of choice.

As for DNS, you're not going to like this but... use whatever works for you. Personally, I like to give servers a totally abstract hostname with no ties to its services. I then CNAME services to the hostname. That way migrating services don't cause DNS change headaches. Or at least, not as many. I also prefer to name virtual servers with a v prepended to the hostname.


  • New Database server is named Athena. It will be named Athena forever.
  • Athena is CNAMED for what it does: SQL08ENT-CRM, SQL08ENT-AEGIS (the security system), SQL08ENT-DOCMAN. Perhaps also CNAMED based on geography. Or perhaps the hostname will have geography in it. Athena-ATL. Athena-Sydney. Whatever works.
  • The server is on the server subnet that has a default deny policy. It has the proper traffic included to it from the proper subnets.

Keep. It. Simple. (but functional)

  • 1
    Athena is athens which is a city already ;-) – dmourati Jul 20 '11 at 3:29
  • +1: Amen on the simple + functional. I didn't think about a default deny policy on the subnet so that's something I'll have to incorporate. I'm not well versed in the CLI for the network switch (Netgear), but it's something I can figure out. Do you use both subnets AND VLANs or only one and not the other? Which should take precedence? – osij2is Jul 20 '11 at 3:31
  • If I could upvote you again I would. This is exactly why I'm asking this question here: "Design abstraction into things, which sounds like it's not simple, but in fact is the pathway to simplicity itself". That's exactly what I'm aiming for. Thankfully you're more eloquent and succinct than I am. ;) – osij2is Jul 20 '11 at 3:34
  • 1
    @osij2is I don't use much in the way of either subnets or VLANs since I'm mostly a small office contractor. I would prefer to use VLANs since that's just what I've mostly used in the past. However, I'm willing to be accused of hammer-syndrome. When all you have is dot-one-q, everything looks like a VLAN problem. Yes, one layer of abstraction is good. Always. Two layers is a rabbit hole. Three layers is a sign of LSD abuse. – Wesley Jul 20 '11 at 4:55
  • 1
    @WesleyDavid - Re: Netgear, they certainly aren't the BEST choice, but their "ProSafe" stuff can be configured to do 802.1Q (Tagged VLANs). The implementation is standards-compliant as best I can determine: It plays well with other vendors and lets you phase in replacement with Juniper or Cisco gear later as time/funding allows. The downside with Netgear stuff is it's really more geared toward Web Browser administration than CLI management, which slows a good net admin down. – voretaq7 Jul 21 '11 at 20:10

I worked at an organisation of a similar size (we had a /26), that for reasons beyond me, the powers-that-be felt that a finely grained IP allocation scheme was paramount to operational integrity. The gateway had to be .1, the printers had to be between .2 and .12, the servers between .13 and .20 and so on. We even kept documentation on individual hosts.

This is a huge pain in the ass. No matter how diligent I was I could never seem to keep any documentation current. It didn't help that we did not have any DNS services, so using this IP allocation scheme documentation was the only "naming" services we had (which in a strange way, made it seem more indispensable than it really was).

For a network of your size I would recommend a few things (most of which you have already done):

  • Simple - You're not managing hundreds of hosts. The complexity of your solution should reflect the complexity of environment. Resist the temptation to be overly clever. You will thank yourself later.

    1. Take your available IP space and give 60% to your clients via DHCP. Setup up some kind Dynamic DNS services so you never have to look at a damn IP address again. Forget about keeping track of them. Profit.

    2. Reserve the other 30% for IP addresses you manage: servers, printers, network devices, testing services. etc. USE DNS TO DOCUMENT THIS. In my opinion, there is no bigger waste of time than studiously keeping track of all these "administrator-managed" IP addresses (as opposed to DHCP managed IP addresses) by using an Excel spreadsheet (which you have to constantly refer to and maintain), when you could be putting that effort into supporting a self documenting and far more useful DNS solution.

    3. Keep the last 10% of your address at the top of your IP addressing space unused. A little reserve never hurts.

    4. Adjust the ratios as you see fit for your environment. Some environments will have more clients, some will be "server" (i.e., "administrator-managed") heavy.

  • Network services (mail, file, proxy, etc.)
  • Software development (environments - dev/staging/prod,

These both fall into the category of "administrator-managed" IP space.

  • Media (streaming, large file transfers, archiving)

In my opinion this has little to do with subnetting and everything to do with network monitoring.

  • Virtual servers/desktops

Servers are "administrator-managed", desktops (i.e. client machines) should be "DHCP-managed".

  • VoIP

A physically discrete network would be ideal... but that's unrealistic. The next best thing would be a separate VLAN and subnet. This is about the only point in small network where I'd really feel the need to segregate traffic (except for things that are publically accessible).

  • 2
    Words. Upvote. Oh wait, this isn't Reddit. Anyway, "Resist the temptation to be overly clever." Quoted for truth! – Wesley Jul 20 '11 at 4:51

For IP allocations

My advice is to place everything under the subnet, using the following structure: 10.site.division.device

  • site is a physical location or logical equivalent (e.g. NY office, NJ office, DR facility, Development environment).
  • division is a logical subdivision that makes sense to you. e.g.
    0 => Switches/Routers
    1 => Admins, 2 => Users
    3 => VOIP
    4=> Guests
  • devices are individual devices (PCs, servers, phones, switches, etc.)

The idea here is that you can easily determine what a device is and where it is by its address: is an administrator's workstation at "Site #2".

This model is derived from class-based IP assignments: the Class A (/8) is your enterprise. Each location gets a Class B (/16), and each logical division at a location gets a Class C (/24) for their devices.
It is possible (and sometimes desirable) to use something larger than a /24 for the "division" level, and you can certainly do so: Anything from a /17 to a /24 is generally fair game with this scheme.

For DNS Names

My advice is to follow a similar scheme to the IP assignment I described above:

  • Everything is rooted at mycompany.com
  • Each site (/16) has its own sitename.mycompany.com subdomain.
  • Logical divisions may have one (or more) subdomains within the site, for example:
    • voip.mycompany.com (with devices like tel0000.voip.mycompany.com, tel0001.voip.mycompany.com, etc.)
    • switches.mycompany.com
    • workstations.mycompany.com (possibly subdivided further into admin, user & guest)
  • Devices should have meaningful names. For example:
    • Name phones so that you can see the extension they ring based on the DNS name.
    • Name workstations based on their primary user.
    • Clearly identify "guest" IP addresses.
    • Name servers so that you can tell what they are / what they do.
      This can be accomplished by using "boring" names (www01, www02, db01, db02, mail, etc.) or by promulgating a naming scheme and sticking to it (for example: Mail servers are named after rocks, web servers are named after trees, database servers are named after painters).
      Boring names are easier for a new person to learn, cool naming schemes are more fun. Take your pick.

Misc Notes

Regarding virtual servers:
Consider these the same as if they were physical machines (segregate them by division/purpose rather than by the fact that they're "virtual". Have a separate division for the Hypervisor/VM Administration network.
It may seem important to you now to know if a box is virtual or physical, but when your monitoring system says "Hey, Email is down!" the question you'll be asking is "Which machines are related to email?", not "Which machines are virtual and which are physical?".
Note that you DO need a practical way of identifying whether a machine is virtual or physical in case a hypervisor host blows up, but this is a challenge for your monitoring system, not your network architecture.

Regarding VOIP:
VOIP (asterisk in particular) is a synonym for "Security Hole". Shove all your VOIP stuff off onto its own subnet, and its own VLAN, and don't let it near anything sensitive.
Every VOIP phone I've seen in the last year supports VLAN segregation (in fact they all support both voice and data VLANs, so you can still use the phone as a pass-thru for desktop ethernet connections). Take advantage of this - You will be glad you did if/when your VOIP environment gets hacked.

Regarding Planning and Documentation:
Draw your network on paper before you start assigning addresses and DNS names. In fact, draw it in pencil on a BIG sheet of paper first.
Make lots of mistakes.
Erase liberally.
Curse fluently.
Once you stop cursing and erasing for at least 10 days it's time to put the diagram into Visio/Graffle/Some other electronic format as your official network diagram. Safeguard this diagram. Maintain it in its Most Holy Correctness as you add and remove devices, grow your organization, and modify your network structure.
This network diagram will be your best friend when you have to make changes, explain the network to new admins, or troubleshoot a mysterious failure.

  • Note that I make the assumption you're going to NAT - mostly because I make the assumption you're going to want to have >1 sites and want to VPN between them. – voretaq7 Jul 21 '11 at 20:11
  • +1: I like the use of octets and the correlation to location (and/or virtualization like you mention). This could be expanded into different logical divisions but the idea makes a lot of sense. Also for the info on VoIP. – osij2is Jul 21 '11 at 20:15
  • The octet thing does break down when you have >200 or so devices - it can get limiting if you have 1000 people in an office and all of them have IP phones on their desks. Small caveat to be aware of :-) – voretaq7 Jul 21 '11 at 20:20
  • @vortaq7: I assumed that point but still good to note. Either way, using the IP as a way of logically and physically organizing things is nice. Also, good point of virtual vs. physical being practically irrelevant. It's nice to be organized but the payoff for this separation is marginal at best. – osij2is Jul 21 '11 at 20:24
  • @osij2is - Virtual vs Physical is definitely relevant, I just don't think network infrastructure is the place to record it (or if you must, do it with DNS by creating separate A or CNAME records like app01.hypervisor02.site.mycompany.com). A well-thought-out and implemented monitoring system is the second essential item (after network organization) in any environment you care about. – voretaq7 Jul 21 '11 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.