Network Naming Conventions
Justin M. Streiner
streiner at cluebyfour.org
Sat Mar 13 19:12:13 UTC 2010
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
More information about the NANOG
mailing list