Network Naming Conventions

Hi Folks...

With many changes going on this year in our network, I figured it's a
good time to revisit our naming conventions used in our networks.

Today, we use the following example:

Core1-rtr-to-ge1-1-1-vl20.nexicom.net

Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc
etc....

Going forward, I'd like to examine a better method to identify the
devices.... does anyone have published standards on what they use or
that of other networks and maybe even why they chose those methods? The
core of the network is fairly easy for us to look at different changes
where you have interfaces, subinterfaces, locations etc. to deal with.

But what do folks do for "aggregation devices" such as dial-up shelves,
BAS devices etc?

Finally, we have a fair amount of gear (that we own) at customer
premises that act as either a managed device or a demarcation point ....
how to you name those today?

Open ended questions obviously - looking for many ideas.

:wink:

Paul

On my last network I named all the routers after simpsons characters.

Paul,

If my memory serves me correct, Richard presented traceroute presto at
nanog47 that covered location identifiers.

HTH,

regards,
/virendra

Paul Stewart wrote:

We use ancient Greek gods.

...Types of coffee and donuts

Tim

For end-point hosts ("servers") I prefer terse topical names for
single-function machines ("Finance", "Purchasing") and some predictable
pattern that ties somehow to the organization for multipurpose machines
("Bluejay", "Parrot").

For network equipment at end points I prefer a string that starts with
the machine's function, ends it an interface identifier, with location
info in the middle. ("rtr-oma-hosp-3rd-peds", "rtr-oma-hosp-3rd-surg").

For network out in the middle I would do the same except expand the
location data a bit and change the I/F infor to a hardware descriptive.

Hey Paul,

Core1-rtr-to-ge1-1-1-vl20.nexicom.net

Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc
etc....

That's disturbingly similar to ours :slight_smile:

tflns2-ge0-1-vl1.caneris.com

TF = Toronto/Front
LNS #2 = LNS #2
ge0-1 = interface
vl1 = VLAN 1

Going forward, I'd like to examine a better method to identify the
devices.... does anyone have published standards on what they use or
that of other networks and maybe even why they chose those
methods?

One of my colleagues has written an overview and pros/cons of the most common naming conventions (purpose, geographic, purpose+geographic, and "themes") at Page not found - Neil H. Watson. He's a systems guy, so it's not written in the context of net ops, but some of the ideas are common.

But what do folks do for "aggregation devices" such as
dial-up shelves,
BAS devices etc?

See my example at the top.

Finally, we have a fair amount of gear (that we own) at customer
premises that act as either a managed device or a demarcation
point ....
how to you name those today?

Currently similarly to this:
MANAGED-DSL-1xxxx, where the 1xxxx is the account number. At the time it was decided to use this for no other reason than when a box/link goes down, it's trivial to find the customer/contacts in the OSS since the device name in the monitoring alert already has an account number embedded in it. Silly reason perhaps, but it's simple and it works.

Open ended questions obviously - looking for many ideas.

There are many ways of doing it and many factors to consider, I'll just throw some food for thought:
-Purpose / device type
-Geography
-Hierarchical naming
-Scalability of the naming system
-DNS
-Humans - who's using the names and how? Reading/writing - how/frequency? What information do you want to convey (for obvious reason, this may vary greatly depending both on the target and the device)?
-Systems - what else is using your names or may be using your names in future? OSS/provisioning/monitoring/graphs for interfaces - automated? Limitations on character set and length of name, e.g. DNS, stupid switches with absurdly short max lengths of port description fields, etc. A regexp can come in handy to define this (and perhaps your entire naming scheme) precisely. In a heterogeneous environment, you have all sorts of stuff where you may have two or more names to refer to the same thing.
-Prefixes/suffixes
-Mergers and acquisitions - what happens when you have to merge your network with someone else's? Though I can see the value of prefixing, I don't like naming conventions which prefix everything with an abbreviation of the company for two reasons:
  -Typing extra keystrokes repeatedly every day for no reason isn't fun
  -Sorting/lists don't work nicely, especially when you would otherwise use a key to go down to the first letter of a name
-Traceroutes: I recall reading the slides from a NANOG presentation (unfortunately I don't recall the author's name and don't have a link now) which discussed naming devices in a traceroute-friendly way (friendly as in meaningful to those outside the org as well); you might want to find this.
-Finally, look at how others do it - there are plenty of examples

Erik

islands
rivers/creeks
types of swords
fruit
minerals
fermented things
3char strings
punctuation marks
twins

...

--bill

i believe in keeping host names as short as possible, so to start, i
wouldn't put the location in the hostname, but putting the loc/pop code in
dns (eg: sjc1.nexicom, tor1.nexicom, iad1.nexicom, etc), same goes for rtr,
you really dont need that, imo

personally, i prefer the shortest possible name

cr - core router
csw - core switch
br/tr/pr - border/transit/peer router

and prepending the interface id
eg:
cr1.tor1.nexciom.net
ge-1-1-1.cr1.tor1.nexicom.net

of if your want to have full role name
ge-1-1-1.core1.tor1.nexicom.net
te-1-0-0.border1.tor1.nexciom.net

-ck

Heh.

Host naming discussions is like religion and politics at parties.
It only leads to someone going home crying, red wine spilled all
over their new dress, and a black eye.

Not in that order.

-r

You'll likely get lots of different answers to this, and there really isn't a right or wrong solution. It's up to you to determine what works best in your environment.

In the last two places I've worked, where I had some level of control over the naming conventions, they ended up looking something like this for network devices (not all that different from yours):

interface_name.device_name.location_id.domain

example:
te2-1.core01.pitbpa.yourisp.com

If the interface has sub-interfaces like an 802.1q trunk with separate layer 3 interfaces, you could extend the interface name to reflect that, such as using te2-1-100 for TenGig2/1.100.

Secondary networks could have something like "s02, s03, s04..." appended to the end of the interface name.

The one deviation to this example is for the primary loopback address on the box, in which case I omit the interface name, so the example above becomes core01.pitbpa.yourisp.com. SNMP traps, auth requests, syslog messages, etc, are sourced from the primary loopback.

The same format could be extended to RAS, broadband aggregators, etc pretty easily. It also has the benefit of being pretty hierarchical and consistent. This is helpful if you have network management systems or other back-office processes that need to be able to parse the name and pull out useful information. Keeping the format consistent makes the
parsing logic less of a pain to write and update.

One other thing you'll want to think about is if you want your interface names to follow $vendor's naming format rigidly, or if you want to use your own format that's relatively close. Specifically I'm thinking about the Cisco vs. Juniper way of doing things (TenGigabitEthernet2/1 vs xe-2/1). Most other vendors I've seen do something relatively Cisco-like.

For customer premise routers, what I did in the past was something like:
interface_name.customer_router_id.cust.domain

example:

fa0-0.widgets-inc-01.cust.yourisp.com

If you don't want to reveal that the router is at or for "Widgets, Inc." you could always replace that with something like a customer ID number or something else that doesn't mean anyhting to the outside world, as long as you have a way through your back-office systems/NMS to associate that name with your customer "Widgets, Inc."

That's my 2 cents.

jms

I favor using CLLI code (well fake ones)

TAMQFLTART1 is in the city of tampa (TAMQ) in FLorida at building TA, and RT1
is the first router there.

This is nice as we know the location of the router, and building it's in from
the host name. The host name is always 11 characters long, making it easy to
filter/work with in logs. Now I alias the name in DNS so we can type "telnet
tampa" and it will just be a CNAME pointing to TAMQFLTART1.keekles.org which
is the loopback address.

Interfaces are in DNS as well, and I make use of TXT records to store info on
the hosts (mostly a contact number and a url to an internal wiki.)

Below is an exerpt from a network policy I wrote about this:
All network elements shall be named following CLLI code format. In most cases
they will not be registered CLLI codes in CLONES.
The format of a CLLI code is as follows
CCCCSSTTEEE, i.e LTRKARHQR01
C � city location
S � State postal code
T � Street or differentiator
E � Equipment Identifier

In the event the equipment is being installed at a site with a registered CLLI
site code (first 8 characters) this shall be used as the prefix. If not a
company unique code will be used for the site CLLI.
The equipment shall be identified using the following codes:

RT[0-9] � router number n, with n starting at 0. If more than 10 routers at a
site, the code will change to RU[0-9], then RV[0-9], and so on.
SW[0-9] � Switch starting at 0 following the same progression as the router.
P[00-99] � Servers at a location
M[00-99] � Mux at a location
R[00-99] � Radios
TS[00-99] � terminal server (serial or other)
VP[0-9] � VPN router or security appliance
FW[0-9] � Firewall or packet filter

I also tend to add funny names as CNAMES that are not published. Got to have
some as the network designer after all :wink:

On my last network I named all the routers after simpsons characters.

scaled well?

> On my last network I named all the routers after simpsons
characters.

scaled well?

He wrote "last" instead of "current"...make your own conclusions :wink:

At various times:

trees (redwood, spruce, ash)
animals indigenous to the area (coyote, eagle, hawk, falcon)
wines (pinot, chianiti)
area keywords (shaky was a router in an earthquake prone area)
colors (red, blue, green)
places in star wars (dantooine)

I found the wines and star wars stuff too hard to remember how to spell :slight_smile:

At BU we brought down about 1/3 of the internet (no joke!) around 1985
when our very first host table entries to SRI-NIC contained single
letter hosts (like a.bu.edu) and names starting with a digit (I
remember 3b.bu.edu) which put the HOSTS table to /etc/hosts converter
into an infinite loop filling up BSD root disks which back then would
invariably hang/crash the OS (No space in /tmp No space in /tmp No
space in /tmp No space in /tmp....)

I think there's a write-up by me in an old RISKS digest from the time
and it was quite a flap on the TCP-IP list ("BU Joins The Internet!")

Completely inadvertent but it was probably as disruptive, relatively,
as the Morris worm.

Just wanted to say thanks to everyone who responded - game me more to
think about than I thought was possible :wink:

Paul

Yeah, just learning that... got a *tonne* of offline replies.

Planets won't work well, simpson characters we'll run out very
quickly.... umm.. forgot the rest. We were looking for something that
makes sense to the function of the box itself and scales up (as per some
other folks point)....

Some of the suggestions around kinda what we have today but with some
changes are what'll we'll debate internally.

Take care,

Paul

Don't forget there were 5 Snowballs...

In a message written on Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote:

Open ended questions obviously - looking for many ideas.

I think a key question to ask yourself is who needs to be able to
interpret your names?

Depending on your business, customers, engineers, etc you may have
a good reason to use obscure names, for instance not making it easy
for people to know the speed of interfaces, where your routers are
located, how many routers you have, what brand routers you use, and
so on. In other cases, you would like as much of that as possible
to be something that someone can guess.

For instance, many ISPs use city names or airport codes. This can
help your customers decide if the latency numbers are reasonable
or not. Lots of ISPs also include interface information, often so
an engineer can log in and do a "show int xyz" based on a traceroute
with no intermediate steps to look up which interface the IP is on
and such.

Lastly, "traceroute www.<foo>.com" for a pile of web sites will give
you all sorts of schemes in no time.

There is no "right answer" in the generic, but there is a right answer
for you.