Re: Network Naming Conventions

["Justin M. Streiner" <streiner () cluebyfour org>]

On Sat, 13 Mar 2010, Paul Stewart wrote:

> 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....
>
> 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?

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