In our article "12 Characteristics of a Well-Maintained LAN", we have several items listed. Each item is important, but I'd like to focus on a couple of these items in more detail:
You may ask, "Why these two in particular?". Well, in my position as a pre-sales engineer, I encounter problems and issues related to these two fairly frequently.
As a IT professional I've battled these issues from several angles. Both being a slave to a network that evolved organically and to a network planned in way too much detail. Neither approach is ideal but both have merit -- like project management, it can either be part of the solution or part of the problem. I'd like to describe the problems and a solution.
The DNS (Domain Name Service) Lookup tool will help you debug DNS related issues like global propagation, domain authority, MX records, security and performance.
Simply enter a target domain or hostname and click the "Lookup" button.
After a few seconds you will already see the results. Use the upper menu bar to navigate to the individual modules. You can find more tools in our free Paessler Monitoring Toolbox.
In the extreme cases, I have seen anything from random naming to deliberate obfuscation of duties of servers. Some more security conscientious argue, "If a name implies something about its duties, it is easier to compromise". That is true, a server named "xxx-Mail-001" would imply an SMTP/IMAP/POPx/etc server, but a port-scan would reveal the same information about what services it performs, regardless of the name. In addition, the size of the networks and the number of devices to be tested for vulnerabilities dictate that it can't be done effectively by humans.
There are instances where policies preclude the use of descriptive names for devices. These are usually government, law enforcement, or military/intelligence environments. The benefit of using more descriptive names, to the people dealing with the plethora of servers in this sprawling virtual world, far outweighs the potential security risk.
A naming convention can go from the simple: SSSFFFF-NNN
SSS = Site Code
FFFF = Function {DBMS|LDAP|AD|...}
NNN = sequence
To the more complex: OOOSSSotFFF-NNN, where
OOO = Organization
o = OS {W[indows]|L[inux]|S[olaris]...}
t = Device Type {W[ebserver]|N[as]|...}
And so on.
The conventions do not have to be as structured as these, but the names should imply something... A friend manages hardware at a university in Texas. They use themes for the machine names and each lab has its own theme: Hats (Fedora, Bowler, Caps, Stetson), Cities (Names of cities and towns, where servers have names of major cities), etc.
What is important is that it helps the people managing the devices to remember the names and functions of the different devices.
Just like with the naming schemes, using IP sub-netting schemes will make life easier on many levels.... It is surprising how many networks just evolved without planning. As mentioned in the "No Quick Fixes" section of the "12 Characteristics" article mentioned above, put a little thought into it before "fixing" the network. In my past experience, these fixes tend to grow out of proportion. When one network runs out of available IP's, it gets expanded. In the end you may be left with a 10.0.0.0/255.255.0.0, a half class A! Not a good situation. A little upfront planning in the form of general guidelines would have done wonders.
There are some general network use cases or patterns:
Within all of these use cases, your IP allocation should follow a pattern.
For a mixed use network, something like:
Depending on the size of the subnet and the requirements, you may shift the allocations around, but proportions of the allocations should be about right.
In a Transit, VPN or Wireless LAN something like:
Once the network grows a bit, it is usually beneficial to segment clients from servers/services. This protects the infrastructure from the clients and makes it easier to control access.
Since client LANs usually have many physically attached devices, they usually look like the mixed use without the server segments.
Server farms may be physical, virtual, or hybrid. What is more important is how you segment them. If it is a hybrid, split the IP allocations. It is recommended to segment the traffic: one for physical and one for virtual machines.
This way you can quickly ID where the traffic is going.
Management networks are typically used by sites that have larger environments. It makes it easier to control access to the management interfaces for the various hardware. Also, the management network may be isolated from all the other traffic on the network, which makes it possible to monitor and manage even when the rest of the network may be unavailable...
As you may know, Paessler is a Network Monitoring Company, we make PRTG. Why is this important to us?
Well, as strange as it may seem, it is ... NOT for us and NOT for our product.... We can monitor pretty much anything with an IP address.
But, it is important for our customers. A well-designed network will be easier for our customers to manage and grow into. Also, when they start to monitor it, they will be able to make discovery and identification of the devices around the network much easier.
If the administrator knows that the things they want to monitor are always within the first 20 IP's on each subnet, it will make it easier to create patterns for discovery. This would also make it easier to create discovery processes to find devices that don't belong and then to alert the admin to that fact. So, in order to allow the admins to perform their duties better, the introduction of a little order may go a long way....
Which is what my wife has been saying about my office for years... I guess she's right... But do NOT tell her I said that!