Labels should only list properties of the object to which they’re affixed. This may mean some education about the hierarchy of things, but, with very few exceptions, putting a label on one object with data that belongs to another object is a recipe for problems later.
“What problems?” you ask. Well, at the least you’re increasing the amount of work you need to do when you change something. Got IP addresses on your cable labels? Add an IP to a server and you need to change the cable’s label, too, otherwise you have incomplete documentation. Same thing with DNS names, too. Or application information. Incomplete and incorrect data on labels leads to assumptions, and assumptions lead to outages, problems, and wasted time. Not to mention the hassle of redoing a bunch of duplicate documentation. Every piece of documentation you have, including labels, needs to be maintained, so don’t have any more of it than you need.
Some examples and my thoughts:
Cables with IP addresses on their labels.
Cables with DNS entries on their labels.
Cables with MAC addresses on their labels.
Cables merely conduct electricity from one point to another, layer 1 in the OSI model. Cables don’t have IP or MAC addresses, and since they don’t have IP addresses they also can’t have DNS entries. Good things to put on a cable’s label might be where the the other endpoint is, like “TO SERVER1” and “TO switchX-Y 1/0/8”.
Server hardware with IP addresses on their labels.
Server hardware with DNS entries on their labels.
I see this a lot, and it depends on what you’re putting on the label. Most server hardware has an out-of-band management interface that can have an IP address, confusing the issue. In general, though, operating systems are the parts of the stack that have IP addresses, not the server hardware itself.
Some places just put the main DNS entry and main IP address on the label, and everybody knows that additional ones are to be looked up. My opinion is that if you’re going to have a lookup process anyhow you’re duplicating effort and documentation by having anything of the sort on the hardware label.
Server hardware with the application on its label.
Server hardware with the application in its name.
If you can, try not to conflate billing or ownership with naming, because server hardware doesn’t care who owns it, and frankly who owns it might change (especially if a CxO steps in and reminds people that the equipment belongs to the company). Same is true of purpose. I’ve seen a number of cases where a particular project buys a server and they name it something very application-specific, like APPWEB1. Then, six months later, they decide to run something else there, and that something else isn’t “APP” or “WEB” related at all. So now everybody’s confused.
This is even more interesting when a particular project buys a VMware ESX host and names it “APPESX1” or “PROJECT-VM-HOST-2.” Then some political decision happens and you have another app or another project co-habitating those ESX servers. Again, everybody is confused.
My organization names server hardware with a unique name that follows that piece of hardware through its entire lifecycle, and that works well for us. We happen to pick random words, but some places do it based on location, hardware type, etc.
VMware port groups with IP ranges/subnet information in the name.
Virtual infrastructure port groups often have more to do with a VLAN than an IP subnet, as a particular IP range can exist on multiple VLANs, and multiple IP subnets can exist on a single VLAN. Knowing the difference between VLANs and IP addressing is important for communicating accurately with others, particularly networking staff.
Sure, It can be handy to put the subnet information in the name, but ultimately it duplicates documentation because the port group name is probably not the authoritative source for what subnets are available on that particular VLAN. If you can avoid it, do.
In conclusion, if IT had a motto it would be “it depends.” Certainly there are pros and cons to some of this, and sometimes you can get away with certain techniques (or lack of techniques) when everybody is on the same page. Some environments, like colocation facilities, can also choose to do things differently because of the distinction between them and the people managing the hosts. It’s generally true, though, that the larger and more complex your environment is the more you can benefit from both avoiding duplication and being extremely accurate in documentation. Always ask yourself two questions:
- Does this information exist somewhere else in a more authoritative form?
- Would this information be more informative if it was attached to something else?
There’s no better time than the present to improve the way you do things; it took years for a few of us to change how my organization does some of this, and we did it slowly, on equipment replacement cycles. Frankly, if you don’t start somewhere you’ll never start at all.
Over the years I have used most (if not all) of your above labeling methods, until I realized that it was a meta-data problem. Now I tend to label the cable with two labels. One is usually what port the cable is plugged into and the second has a barcode. The barcode allows you to tie all the relevant information (using a cmdb) to the cable. The port number label is merely a convenience and can be left off if required. A good label printer and barcode scanner is well worth the investment in my opinion.
“some places do it [assign a unique name to follow the hardware] based on location”
I may be missing something, but location seems like a particularly poor choice for an immutable name.
@Andrew — Exactly! It’s all meta-data, and you’re right, you need a good label printer and a database of some sorts, at the least. A barcode scanner can help a lot in some cases, too, especially now that vendors are shipping MAC addresses encoded like that on hardware.
@Ed — Might be, the locations I saw were sites, not racks/rows/columns sort of thing.
My company’s express policy is to use the BUILDING AND LOCATION of a server as the domain name of the server. Yup. You have to rename a machine when it is moved.