CCIE Pursuit Blog

January 23, 2008

Network Device Naming Conventions

Filed under: Cisco,Personal,Work — cciepursuit @ 8:09 pm
Tags: , ,

I stumbed across this posting by Michael Morris concerning naming conventions:

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.

—Read The Rest Here—

My previous job was supporting an international WAN with over 3000 routers.  Not only did we have a ton of routers, but nearly 30 separate business divisions –  each of which had their own naming convention.  To add even more fun, most of the router “hostnames” were not the same as their FQDN names.  We kept a database with circuit IDs mapped to router names.  Of course, there were many deleted circuits and typos in the database.  This always made it fun when a vendor called to report a circuit down and we could not find out which device it terminated on.  Not to mention all of the tiny sites that we supported that shared a city name with a more famous, larger city.  A router named “miami” goes down and you start looking at Florida…wrong!  It’s in Miami, Oklahoma.  We had three Pittsburgh sites – none of which were in Pennsylvania.  And (as Michael Morris mentioned) there were a bunch of places (including our corporate headquarters) that were referred to by any number of local cities.  This lead to a lot of lost “support cycles” just trying to narrow down what device was being affected. 

My current job supports a uniform naming convention and it is an absolute joy to work with.  There are still the occasional anomalies, but it’s infinitely better than the mess I came from.  Our naming convention is similar to the one mention in Michael Morris’ post.  We have unique five-character real estate codes.  Prepended to that is a code for the device type.  At the end is the floor and IDF that the device is located in.  Very little time is lost trying to determine where a device is located.

I’m sure that there are a number of readers who do/did server support and have MUCH worse naming stories.  🙂

Advertisements

2 Comments »

  1. We’re moving to a similar naming convention with our devices at work. The only issue I am having is matching real estate ID’s to site addresses. I guess that all comes in time, and it makes sense for larger country wide/global networks.

    I’m still used to dealing with city/state wide networks and being able to use abbreviated addresses with IDF, device, and device number for naming.

    If you don’t mind me asking, how do you guys manage circuit information in your current job?

    Comment by jonathan kintner — January 23, 2008 @ 9:03 pm | Reply

  2. @Jonathan,

    We just recently created a database mapping our circuits to the routers that they terminate on. We got our vendors to send a list of our circuits and the address that they terminate. We then related those to our site codes. We also keep circuit IDs on our network maps as well as in a description under the interface(s) on the router. Those two methods are not dynamic, so you can run into issues when the map and/or the device’s interface description have not been updated. Our NOC is authorized to page out the site engineer when there is bad data in the network maps and that engineer is expected to do the NOC’s job (open a ticket with the vendor, communicate status updates, etc.) anytime of day as well as on holidays and weekends. This has drastically reduced the amount of missing/wrong circuit IDs in our documentation. 🙂

    Comment by cciepursuit — January 24, 2008 @ 8:42 am | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: