I'm often surprised by the different ways people and organizations will name their network devices. I've seen really bad, decent, and come up with my own that, of course, I think are the best. Plus, the affection people have for their naming conventions equals the affection people have for their icons.
When I first started in networking in the Army the routers were inside mobile telecommunication shelters; for example, a Mobile Subscriber Equipment Forced Entry Switch (FES). The routers went wherever the FES went, so naming was easy. It was the FES name with a "-RTR1": FES57-RTR1. This scaled fine because Army networks had small administrative domains with maybe 30 telecommunication shelters for each unit. Each unit was a separate organization in a different BGP AS (sort of like a bunch of small ISPs).
When I started working on global enterprise networks it got much more interesting. Now you had thousands of routers at hundreds of sites in different rooms and closets/IDFs in all parts of the world. Now naming conventions became very important. A very large bank network I worked on was terrible: 5,000 routers with a cryptic naming convention that was (1) hard to understand and (2) not well followed. Adding to the problem was the city name of the router was often not an actual city. It was a name the bank liked to refer to the site as. Good luck trying to remember all those names. The rest of the name had some good points, but also several bad ones. It was not something I enjoyed.
The government network I worked on was minimalist. It was [city]-r1. For example, BUF-R1. Really boring and really useless. Some small company networks like to be cute and name devices after beer brands or rock bands or cartoon characters. That starts to fail quickly when the small company gets just a tad larger.
A few other networks I worked on introduced me to some good naming conventions. That led to a device naming standard that I recommended for a new customer and that was actually used. It's long, but very useful:
These are the codes that make up the naming convention: [customer name - 1 character] - [region - 1 character - N = "North America", E = "EMEA", A= "ASPAC", etc.] [state or country - 2 characters] [city - 3 characters] [site number - 2 characters (in case there is more than one site in the same city)] - [device function - 2 characters - WR = "WAN Router", "CR" = "Core Router", "WA" = WAP, AS = "Access Switch", IR = Internet Router, etc.] [device number - 2 characters] - [criticality - 1 character - H = "High", M = "Medium", L = "Low"] - [device model - 7206, 3845, 2821, etc]
So, taking all this in....if you were running GE's network with a site in Buffalo, NY with a 7206 as a critical WAN router the device name would be "G-NNYBUF01-WR01-H-7206". Or for Cisco's network with a 3845 in Tokyo serving as a low priority voice gateway: "C-AJPTYO01-VG01-L-3845". Country and city codes come from the UN Code for Trade and Transport Locations.
Another nice addition, if appropriate, is an extended suffix to identify the exact device location with the following format:
B# = Building F# = Floor C# = Closet (if appropriate) R# = Rack
So, if the aforementioned Cisco router in Tokyo was located in Building 1, Floor 10, Rack C, the name would be extended to: "C-AJPTYO01-VG01-L-3845-B1F10RC". The names can get long but the extended suffix is crucial for helping remote technicians locate specific devices. Extended suffixes are also very useful in data centers.
Above all, the naming convention should ease and automate functions for the network operations team. They should be able to read a device name and understand where the device is, what the device does, how critical it is, and what type of device it is. This can cut 10-15 minutes off their initial triage and speed outage resolutions. It also makes scripting and reporting easier.
Now get out there and rename those "BUF-R1" devices.
Michael Morris is a communications engineering manager at a $3-billion high-tech company. His background is in enterprise WANs working with telcos and developing large-scale routing designs. He has worked on networks at government and corporate organizations, including networks at two Fortune 10 companies. In his current role, he leads a team of 10 engineers responsible for large-scale IT networking projects and architectural standards for data networks, storage area networks, IP telephony, contact centers, and security. Michael is CCIE #11733 and recently became one of the first three Cisco Certified Design Experts (CCDE) ever (#20080002). He has 11 years experience in networking and communications, including four years as a paratrooper in the U.S. Army. He has a bachelor's degree in MIS from the University at Buffalo and is working on his MBA from NC State University. In 2008, he was awarded the Network Professional Association (NPA) Professional Excellence and Innovation Award for his work on network architecture, templates and enterprise MPLS design.
Michael Morris's From the Field blog is also featured on the Cisco Learning Network. See it there, along with the blogs of other Cisco Experts.