Outdated network naming conventions can stall automation. Learn how to simplify names, centralize data, and automate naming updates using modern tools.

. . . . .

Recently, a customer asked for recommendations to accelerate their transition to an automated infrastructure environment. While they had strong buy-in for automation at all levels, some legacy processes were creating unexpected bottlenecks.

One significant issue we identified was their complex naming and IP addressing conventions. Their infrastructure naming practices were actually causing delays and preventing them from fully benefiting from their automation platform.

How Traditional Network Naming Conventions Evolved

Naming conventions have long been a core part of infrastructure management. I’ve often seen teams build elaborate names and descriptions to pack multiple data points into a single string. A typical network device name might include seven elements, like this:

[AIRPORT_CODE][LOCATION_ID]-[POD]-[RACK]-[PLATFORM]-[ROLE]-[NUMBER]

This results in device names like:

cdg1-p2-aa55-eos-spine1 (Paris CDG Airport, Site 1, Pod 2, Rack aa55, Arista EOS platform, Spine role, ID 1)

iad2-p7-fe10-jos-leaf3 (IAD Airport, Site 2, Pod 7, Rack fe10, Juniper OS platform, Leaf role, ID 3)

Similar naming conventions are also used for other attributes like interface descriptions, to capture the interface’s role, peer name, circuit type, ID, and more.

We’re so used to naming infrastructure components using this sort of dense naming logic for networks that we often overlook its long-term limitations. Understanding what these names are meant to do is the key to finding a better approach.

Originally, the primary users of these naming conventions were humans: operators who needed to understand what they were looking at.

As infrastructure grew more complex, the need to capture more information grew too. But there was nowhere to store it—except maybe in a spreadsheet. So names and descriptions became the workaround for storing information. And with character limits in play, the conventions became increasingly dense.

Eventually, tools started to rely on these names and descriptions too, pulling out information using Regex simply because there wasn’t a better source.

Why Legacy Naming Conventions Break Modern Automation

Stuffing data into name strings, however, limits how much you can store and usually restricts you to static data to avoid constant renaming. For example, you won’t find the administrative state of a device (like active or maintenance) included in the name, because it changes over time. That would break tools that depend on a stable identifier.

Data accuracy is another challenge. It’s less of a problem for names, but interface descriptions change more frequently and are harder to maintain.

Trust in data is very fragile. Once people spot even a small inaccuracy, they lose confidence and find other ways to get the information they need.

From a tooling perspective, combined text strings are fragile, hard to analyze, and tricky to work with in code. They add friction to every process instead of removing it. They also undermine the effectiveness of an automated naming schema designed to support scalable operations.

A Modern Approach to Network Naming Conventions

In a modern environment, a data management platform (also known as a Source of Truth) like Infrahub is the right place to store all infrastructure-related information—names, locations, roles, statuses, and more—in a structured format.

Centralizing this data creates several advantages:

• There’s no limit to how much information you can store or the level of detail you can include.
• You can update the data as often as needed. Infrahub is well-suited for storing dynamic attributes like administrative status, for example.
• Data becomes connected rather than duplicated, which greatly reduces the effort needed to keep information up to date. As an example, a device can reference a location object instead of including the location name in its own record.

A structured infrastructure data system ensures consistency across devices, tools, and teams. When infrastructure data is well-organized, operations teams can use it to build tools that speed up root cause analysis and reduce mean time to repair (MTTR).

Once data is easy to access, the use cases multiply—from a simple Python script that displays interface info to Slack chatbot that provides a form to execute the ops team’s most common tasks.

To go a step further, classifying all your infrastructure components with the three golden attributes— Role, Type, and Status—creates a solid foundation for modern automation.

What to Do With Your Current Naming Convention

Naming conventions still help human operators, so they shouldn’t disappear entirely. It’s easier to understand cdg1-spine than dev-340d-41be-a39d.

For most teams, the real challenge is that legacy systems still depend on legacy naming conventions. Many of those tools don’t have APIs or sync mechanisms to stay updated with a Source of Truth.

Automate Your Network Naming Conventions With Computed Attributes

If you can’t eliminate complex naming schemes, the next best option is to automate them.

That means generating names and descriptions through automation and ensuring they’re always current across the infrastructure.

Infrahub supports Computed Attributes to help you codify your naming convention and keep everything up to date automatically. Computed Attributes can be defined in Jinja2 or Python.

Infrahub automatically detects which data points Computed Attributes rely on and recalculates the value when any datapoint changes. Computed Attributes are fully integrated with the rest of the Infrahub platform and work seamlessly with the automation pipeline.

Using Infrahub, you can even use different naming conventions for different audiences—such as computed_name_for_IT and computed_name_for_finance without any extra effort from the ops team.

Summary

Based on my experience, here’s how to create a more automation-friendly infrastructure environment:

• Simplify naming conventions to prioritize human readability over data storage.
• Store component details in a structured Source of Truth instead of embedding them in names.
• Use automation tools and device identifiers managed by your Source of Truth to keep infrastructure data consistent.
• Challenge and update legacy processes that don’t support modern automation.

Implement systems that automatically generate and update descriptions based on your Source of Truth.

The goal isn’t to eliminate network naming conventions entirely, but to use them more effectively while relying on modern tools to manage infrastructure data.

I’ve seen organizations that make these changes cut unnecessary complexity, reduce manual work, and accelerate their automation initiatives.