Naming Things Is Hard: Conventions for Subnets, VLANs, and Hostnames That Survive Employee Turnover

It is two in the morning, half the company is offline, and the monitoring system says a machine called gandalf is down. You have worked here for five months. You do not know what gandalf is, where it lives, or what depends on it, and the one person who did know carried that information to a new job last spring. Somewhere in a rack, a machine named after a wizard is holding your whole night hostage, and the name on the alert is helping nobody.

Programmers tell a joke, usually credited to the engineer Phil Karlton, that there are only two hard things in computer science: cache invalidation and naming things. Networks give the joke a cruel edge, because network names outlive their authors by years. A switch stays in service for seven to ten years and a door controller for longer, while the person who installs and names them typically moves on in three or four. Run that arithmetic and an uncomfortable conclusion falls out: most of the names on your network will spend most of their working lives being read by people who had no part in choosing them. A naming convention is a letter to those future strangers, and it is worth learning to write one they can read without you.

Every doomed naming scheme begins charmingly. The network is small, one person runs it, and that person names the machines after Norse gods, Simpsons characters, moons of Jupiter, or espresso drinks. Each machine gets a hostname, the human-readable name a computer answers to, and each hostname is a small private joke its author understands completely. For a while the scheme even works, because the mapping from loki to "the backup server in the third-floor closet" lives comfortably in one particular head. Then the head takes a job across town, and the mapping goes with it. The wiki page that once decoded the pantheon is three years stale, and the successor is left to reconstruct, machine by machine, which name belongs to which IP (Internet Protocol) address, the number that identifies each device on a network. That excavation is involved enough that we gave it its own guide, building an IP inventory from scratch. A name that requires its author in the room is a piece of trivia, and trivia is a poor foundation for an outage.

The way out rests on one observation: a device's name is the only label guaranteed to follow it everywhere. The name appears in monitoring alerts, in log files, in DNS (the Domain Name System, the internet's directory that turns names into addresses), in configuration backups, in tickets, and in hallway conversations, automatically and forever. Documentation kept anywhere else has to be maintained by hand, and it drifts the moment discipline lapses, but a fact embedded in the name rides along with every alert and every log line for free. So a good name carries the facts a stranger needs first: where the thing is, what kind of thing it is, and which one of its kind it is. Consider what different names hand to a newcomer.

The last two rows follow the pattern that has quietly won at most well-run organizations: site, then role, then a number, joined by hyphens. nyc-fw-01 is the first firewall in New York, atl-sw-03 is the third switch in Atlanta, and nobody has to remember either fact, because the parts are read straight off the name. The order of the parts is deliberate, too, because names spend their lives being sorted. Listed alphabetically, every machine groups first by site and then by role, and the raw device list arranges itself into something a person can actually scan.

An inventory that sorts itself

atl-cam-01 … atl-cam-38     every Atlanta camera, together
atl-fw-01                   the Atlanta firewall
atl-sw-01 … atl-sw-06      the Atlanta switches, in order
chi-cam-01 … chi-cam-114   every Chicago camera, together
nyc-fw-01   nyc-fw-02       both New York firewalls
nyc-sw-01 … nyc-sw-09      the New York switches, in order

A few small choices in the same spirit pay off for years. Keep names lowercase, because they get typed under pressure. Use hyphens rather than underscores, because the rules for DNS names do not allow underscores in hostnames, and the violation surfaces in the least convenient places. Pad the number to at least two digits, 01 rather than 1, so the tenth switch sorts after the ninth instead of after the first. And keep the role vocabulary tiny and written down: fw for firewall, sw for switch, srv for server, cam for camera, prn for printer. Ten abbreviations cover nearly any building, and the eleventh can be added when it earns its place.

Just as important is what stays out of the name. The temptation is to encode everything, the owner, the manufacturer, the model, the operating system, the rack it sits in, the project that paid for it. Resist all of it, because those facts change while the device stays the same, and changing a name is expensive: it ripples through DNS, firewall rules, monitoring, scripts, and other people's muscle memory. The brand changes when the unit is replaced by a cheaper rival doing the same job. The owner changes with every reorganization. The rack changes the weekend somebody tidies the server room. A name should carry only the facts that die with the device, its site, its role, its number, and everything else should live in fields you can edit without renaming anything: a one-sentence description of what the thing does, plus structured fields for owner, model, firmware version, install date, and the ticket that installed it. This is the quiet half of how IPCraft is designed, since every subnet and address record carries a description and whatever custom fields your convention calls for, but the principle holds in any tool, including a spreadsheet. The name keeps the stable facts, and the fields keep the rest.

Subnets deserve the same care, and they are easier to neglect because their formal names are numbers. A subnet is a block of neighboring IP addresses managed as one group, written in slash notation like 10.20.30.0/24, and our visual guide to subnetting explains how to read the slash. The number is the subnet's true identity, and it is honest but mute: 10.60.50.0/23 tells a newcomer nothing about cameras, trust levels, or the building it serves. So give every subnet two pieces of prose. The first is a short name that states its role, like hq-cameras or atlanta-guest-wifi. The second is a description that says what a stranger would need to hear out loud: which site it serves, what belongs in it, and anything surprising, such as "no internet access, on purpose" or "the top half of the range is reserved for testing."

VLANs teach the same lesson in different clothes. A VLAN (virtual local area network) is a feature built into ordinary business network switches that splits one physical network into several isolated ones, and our guide to VLANs and VRFs explains the machinery. Every VLAN carries a number and, in the switch's configuration, a name, and both deserve conventions. Let the same number mean the same thing at every site, so that VLAN 20 is staff wherever you go and VLAN 90 is guests wherever you go, and an engineer who transfers between offices arrives already fluent. Reserve bands of numbers by trust level, perhaps the teens and twenties for people, the fifties through eighties for devices you keep at arm's length, the nineties for guests. Name each VLAN for its function, cameras, voice, guest-wifi, and never for a person or a moment in time, because bobs-vlan will outlive Bob's employment and temp-migration is the most permanent structure in all of networking. Then let the addressing echo the numbering. The most durable trick in network design is to make the third number of each subnet match its VLAN number, so an address like 10.2.30.42 announces its own VLAN on sight, and our worked IP plan example builds an entire company's addressing on exactly that convention.

To judge any convention, existing or proposed, give it the turnover test, which has two halves. The read test asks whether a new hire, armed with nothing but a one-page document, can look at any name on the network and say what the thing is, where it is, and roughly who suffers when it breaks. The write test asks whether that same new hire can add a brand-new device and name it correctly without asking anyone. The write test is the harsher half, and it usually fails on the sequence number: if learning that the next free camera number is 115 requires interviewing a veteran, the scheme still depends on the veteran. So the convention document needs one more line, stating where numbers come from, and the only durable answer is an inventory that shows which numbers each site and role have already used, turning the question into a lookup instead of an interview.

A name also has to be the same name everywhere, because every mismatch is a small lie that someone will eventually believe. The label in your inventory, the hostname the machine reports about itself, its entry in DNS, and the sticker on the physical box should agree to the letter. DNS deserves special vigilance, since it keeps two sets of books, forward records that turn names into addresses and reverse records that turn addresses back into names, and the two drift apart quietly for years; our guide to keeping DNS and the IP inventory in sync is about exactly that reconciliation. For a quick reading on where you stand, point our free reverse DNS lookup at a few of your own addresses and see what your network currently calls itself. An answer like nyc-mail-01 is a good sign, and an answer like OLD-DO-NOT-USE-2 is a diagnosis.

None of this calls for a heroic weekend of renaming, and the heroic weekend is the wrong instinct anyway, since a mass rename breaks every script, bookmark, and firewall rule that mentions an old name, all at once. Start the convention today for new devices, so the network stops getting worse. Rename old devices opportunistically, when a machine is being rebuilt, replaced, or moved anyway, because at those moments its dependents are already being touched and tested. And when a device finally sheds its mythology, keep the old name in its record: a description that says "formerly gandalf" costs nothing and means a search for the old name still finds the machine for as long as anyone thinks to look. Within a year or two the pantheon dwindles to a few stubborn holdouts, and by then the holdouts are documented.

The same logic scales all the way down. A five-device home network feels too small for a convention, and then two years pass and the machine called newpi turns out to be the oldest of four Raspberry Pis. Every network experiences employee turnover, even a network of one: the employee who leaves is the you who set everything up, and the replacement is the you of two years from now, arriving with no notes. Our home lab addressing guide shows what a written plan looks like at apartment scale, and the naming part of it takes about ten minutes.

Back at the two-in-the-morning outage, the story ends the way undocumented outages always end, with someone tracing cables until gandalf confesses to being the file server that holds everyone's home directories. The prevention costs one page. Write down the pattern, the role abbreviations, the reserved VLAN bands, and the rule for where numbers come from, then keep every name next to its description in a system the whole team can search. Good names are boring on purpose, and boring is a gift to whoever comes next, including the future version of you who has forgotten everything. Phil Karlton was right that naming things is hard. It is also the rare hard problem in computing that mostly surrenders to a page of agreements and a little consideration for the stranger reading your alerts in the dark.