For IP allocations
My advice is to place everything under the 10.0.0.0/8 subnet, using the following structure: 10.
site is a physical location or logical equivalent (e.g. NY office, NJ office, DR facility, Development
division is a logical subdivision that makes sense to you. e.g.
0 => Switches/Routers
1 => Admins, 2 => Users
3 => VOIP
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:
- Everything is rooted at
- Each site (/16) has its own
- Logical divisions may have one (or more) subdomains within the site, for example:
voip.mycompany.com (with devices like
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 (
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.
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.
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.
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.