Creative IP/subnet/dns schemes
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.
Examples:
- 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)
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.
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.
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.
Keep the last 10% of your address at the top of your IP addressing space unused. A little reserve never hurts.
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).