Network configuration names are not decoration. They are operational metadata. When something is broken at 2:00 a.m., the difference between ACL-EDGE-IN and access-list is not aesthetic. It is the difference between narrowing the blast radius quickly and spelunking through hundreds or thousands of lines of Cisco IOS configuration while your coffee gets cold.

The old version of this article was mostly a pet peeve about lower-case access list names. I still have that pet peeve. But the larger point is more important: if your IOS names are inconsistent, ambiguous, or clever in the wrong way, your configuration becomes harder to review, automate, audit, and troubleshoot.

That matters even more now than it did when most of us were hand-editing router configs one device at a time. Network configurations are read by humans, copied into change tickets, linted by scripts, backed up to Git, parsed by automation, and compared during incident response. Naming policy is one of the cheapest ways to make that whole workflow less fragile.

What Needs a Naming Policy

Cisco IOS lets you name more than just access lists. Depending on platform and feature set, you may be naming:

• Access control lists
• Prefix lists
• Route maps
• Class maps and policy maps
• Object groups
• Crypto maps and IPsec profiles
• NAT rules or route-map-driven NAT policies
• VLANs
• VRFs
• Tunnel interfaces
• Tracking objects
• BGP peer groups

You do not need a 40-page standards document for all of this. In fact, please do not write one unless you enjoy watching people ignore it. What you need is a small set of naming rules that make configurations predictable.

The goal is simple: when an engineer sees a name, they should have a decent idea of what the object is, where it is used, and whether it is safe to touch.

Use Names That Stand Out From IOS Syntax

My oldest rule still holds up: make locally defined names visually distinct from IOS keywords.

This is hard to scan:

ip access-list extended outside
 permit tcp any host 203.0.113.10 eq 443

interface GigabitEthernet0/0
 ip access-group outside in

The name outside is not wrong, but it is visually weak. It disappears into the rest of the configuration.

This is easier to read:

ip access-list extended ACL-WAN-IN
 permit tcp any host 203.0.113.10 eq 443

interface GigabitEthernet0/0
 ip access-group ACL-WAN-IN in

The all-caps style is not magic. Some teams prefer AclWanIn, acl_wan_in, or wan-in-acl. The important thing is consistency and contrast. Personally, I like all-caps names for IOS objects because they jump out when I am reading a raw config. IOS commands are mostly lower-case in examples and habits, so upper-case object names act like syntax highlighting in plain text.

That sounds small until you are reviewing a 5,000-line router configuration in a terminal window.

Put the Object Type in the Name

Names like OUTSIDE, CUSTOMERS, and PROD are better than nothing, but they still force the reader to chase context. Is PROD an ACL? A route map? A class map? A prefix list? A VRF?

Prefer names that include the object type:

ip access-list extended ACL-WAN-IN
ip prefix-list PL-BGP-CUSTOMERS-IN seq 10 permit 198.51.100.0/24
route-map RM-BGP-CUSTOMERS-IN permit 10
class-map match-any CM-VOICE
policy-map PM-WAN-QOS

This style is a little verbose, but it pays rent. When RM-BGP-CUSTOMERS-IN shows up under a BGP neighbor, the reader immediately knows they are looking at a route map. When PL-BGP-CUSTOMERS-IN shows up inside that route map, the relationship is obvious.

The prefix does not need to be elaborate. Common patterns are enough:

The exact abbreviations matter less than using them consistently.

Include Direction and Scope Where It Helps

Network policy usually has direction. A name should make that direction clear when direction matters.

For ACLs, prefix lists, route maps, and QoS policies, I tend to include both the scope and the direction:

ACL-WAN-IN
ACL-WAN-OUT
PL-BGP-TRANSIT-IN
PL-BGP-TRANSIT-OUT
RM-BGP-PEERING-IN
PM-BRANCH-WAN-OUT

This prevents a class of mistakes that are annoying in review and ugly in production. If a route map named RM-BGP-TRANSIT-IN is applied outbound, that looks suspicious immediately. Maybe there is a reason. More likely, somebody copied the wrong line.

Scope is equally useful. ACL-IN is not a useful name on a router with WAN, LAN, DMZ, management, and VPN interfaces. ACL-DMZ-IN is much better.

Avoid Names That Repeat IOS Commands

Please do not name an access list access-list.

Yes, IOS may let you do some deeply unhelpful things. That does not mean you should. Names that collide with command vocabulary create needless ambiguity for the next person reading the configuration.

Bad:

ip access-list extended ACCESS-LIST
route-map ROUTE-MAP permit 10
class-map CLASS-MAP

Better:

ip access-list extended ACL-DMZ-IN
route-map RM-BGP-DEFAULT-ONLY permit 10
class-map CM-REALTIME-VOICE

This is one of those engineering rules that looks pedantic until you have to debug the system under pressure. Naming things after their generic type gives you almost no information. Naming things after their purpose gives you a map.

Do Not Encode Too Much

There is a trap on the other side of sensible naming: trying to encode the entire network design into every object name.

This is too much:

ACL-RTR03-GI0-0-WAN-PROVIDER-A-IN-PROD-IPV4-EDGE-FILTER-V2

That name is precise, but it is also brittle. Interface names change. Providers change. Version suffixes rot. After two years, half the name may be false.

Use names that describe durable intent:

ACL-WAN-IN
ACL-PROVIDER-A-IN
RM-BGP-DEFAULT-ONLY
PM-WAN-QOS

If you need device, interface, ticket, owner, or exception metadata, put that in comments, source control, change records, or your automation inventory. The IOS object name should be specific enough to be useful and short enough to survive operational reality.

Make Names Friendly to Search and Automation

Modern network operations often involve config backups, text search, generated diffs, and scripts. Names should work well in those tools.

Practical rules:

• Use ASCII letters, numbers, and separators.
• Avoid spaces.
• Pick one separator style and stick with it.
• Avoid punctuation that has special meaning in shells, templates, or regular expressions.
• Keep names short enough that command output remains readable.
• Avoid names that differ only by case.

For IOS configurations, hyphenated all-caps names are easy to read and easy to search:

ACL-WAN-IN
PL-BGP-CUSTOMERS-IN
RM-BGP-CUSTOMERS-IN

If you use automation tooling that prefers underscores, use underscores. The point is not my preferred style. The point is that a human and a script should both be able to identify the object without doing archaeology.

A Small Naming Policy Template

Here is a lightweight policy I would be happy to see in a real network:

• Use upper-case names for locally defined IOS objects.
• Prefix names with the object type: ACL, PL, RM, CM, PM, OG, VRF.
• Include scope when the object is tied to a location, role, provider, or interface class.
• Include direction for directional policies: IN, OUT, IMPORT, EXPORT.
• Name objects after their durable purpose, not a temporary implementation detail.
• Avoid generic names such as ACCESS-LIST, ROUTE-MAP, TEST, and TEMP.
• Use comments or source control for ticket numbers, owner metadata, and historical explanation.

That is enough structure to keep a configuration readable without making every change feel like it needs a standards committee.

How This Helps During Troubleshooting

Naming policy is boring until something breaks. Then it becomes one of the few things that makes the configuration legible.

If you are investigating queue drops, interface errors, or policy behavior, you are already jumping between interface configuration, ACLs, route maps, and show commands. A readable naming scheme reduces the mental bookkeeping. It pairs well with operational habits like checking Cisco input and output queue drops or using quick platform-specific checks like showing power supply status in Cisco IOS.

Good names do not fix bad designs. They do make bad designs easier to find.

Conclusion

Sensible IOS naming is not about being fussy. It is about respecting the next operator, which might be you six months from now with a production incident and too many terminal windows open.

Use names that stand out from IOS syntax. Include the object type. Include scope and direction when they matter. Avoid cleverness. Keep the scheme small enough that people will actually follow it.

That is not glamorous network engineering, but it is the kind of discipline that makes networks easier to operate. For more practical technical notes, visit Slaptijack.