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:
- Network services (mail, file, proxy, etc.)
- Software development (environments - dev/staging/prod,
- Media (streaming, large file transfers, archiving)
- Virtual servers/desktops
- 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:
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:
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.
These both fall into the category of "administrator-managed" IP space.
In my opinion this has little to do with subnetting and everything to do with network monitoring.
Servers are "administrator-managed", desktops (i.e. client machines) should be "DHCP-managed".
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).
For IP allocations
My advice is to place everything under the 10.0.0.0/8 subnet, using the following structure: 10.
site.division.devicesiteis a physical location or logical equivalent (e.g. NY office, NJ office, DR facility, Development environment).divisionis 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: 10.2.1.100 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:
mycompany.comsitename.mycompany.comsubdomain.voip.mycompany.com(with devices liketel0000.voip.mycompany.com,tel0001.voip.mycompany.com, etc.)switches.mycompany.comworkstations.mycompany.com(possibly subdivided further into admin, user & guest)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.