Network Naming Conventions
TWright at internode.com.au
Sun Mar 14 18:47:46 CDT 2010
I agree - this convention is easy to type/understand/automate.
Makes it easy to AXFR and see which devices are in a pop.
We throw a bit of Perl at our device configs to create RR's for
each device (imagine doing it manually... blergh).
On 14/03/2010, at 5:23 AM, ck wrote:
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
of if your want to have full role name
On Sat, Mar 13, 2010 at 8:21 AM, virendra rode <virendra.rode at gmail.com>wrote:
-----BEGIN PGP SIGNED MESSAGE-----
If my memory serves me correct, Richard presented traceroute presto at
nanog47 that covered location identifiers.
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:
Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan 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.
"The information transmitted is intended only for the person or entity to
which it is addressed and contains confidential and/or privileged material.
If you received this in error, please contact the sender immediately and
then destroy this transmission, including all attachments, without copying,
distributing or disclosing same. Thank you."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Internode Network Operations
P: +61 8 8228 2999
More information about the NANOG