Looked through the thread figuring someone else would have mentioned
this one, but (unless I missed it), they didn't. So sorry if you've seen
this already, but I think this presentation is a really good take on the
subject.
http://www.nanog.org/meetings/nanog31/abstracts.php?pt=NjExJm5hbm9nMzE=&nm=nanog31
With 726 episodes in 30 TV seasons and 11 feature films, it's very
difficult to run out of Star Trek characters. Not main characters,
though.
Rubens
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).
KISS 
-- Tom
It was a small network.
I've used a Jimmy Buffett theme in test labs before.
Matt Adcock, Manager
334-481-6629 (w) / 334-312-5393 (m) / MAdcock@hisna.com
700 Hyundai Blvd. / Montgomery, AL 36105
P
The average office worker uses 10,000 sheets of paper = 1.2 trees, per year
By not printing this email, you’ve saved paper, ink and millions of trees
Naming themes are fine in test labs, because devices have a different function/role several times per day, a name acts like an asset tag in that it sticks with it through its lifetime.
Same goes for those servers that sit in our networks that I can only really think to call "bitch boxes". They do all sorts of random one-off network hackery tasks, and never get any love. They're not supposed to scale, they were only supposed to be there for one job 5 years ago and they're still there.
If I've got guys out there rolling out gear according to cookie cutter designs, I don't want them coming up with names and using ex girlfriends or TV shows or whatever. They're going to run out of ideas, and I don't want to have 50 boxes called "rachel" on the network with no idea what they do. That sort of thing works fine when you're the only person putting the names in to boxes - like in a lab - but no good if you've grown much.
I'm a contractor/consultant type thing, and getting my customers to use naming schemes like the rant that follows helps me understand their network if they do things without me, and helps anyone else who comes along too.
So, for production network and server gear, I like domain names built with city and site codes:
site.city.domain
Perhaps if I had a bigger network I'd have .country.domain on the end of that instead.
Hosts within each site are told to search within their site, then city, then domain. Here's how in resolv.conf:
search site.city.domain, city.domain, domain
This lets me refer to a host called 'access-1' as, access-1, or access-1.site, or access-1.site.city depending on where I am. That's handy and saves my lazy ass typing lots. It also means we can have standard configs for lots of things. For example, we can syslog to "syslog" and it will choose either the one in the local site if its size warrants it, or one in the city, or a network-wide one. I'm sure you can think of other ways this can be useful.
It can be annoying when a box doesn't let you display a full hostname in a prompt, or fudge it and set the "hostname" to "hostname.site.city" because hostnames shouldn't have periods in them. YMMV, etc. The benefits outweigh the negatives for me I think. Things can get a bit hairy when devices identify themselves by their hostnames in some other protocols though. Ignoring that and using DNS is encouraged, etc.
As for hostnames themselves, I have varying ways of doing that, but I never use a naming scheme that won't scale for.. a long time.
I always use numbers, but never use leading zeros - ie. access-1, not access-001. It's not hard to sort numerically, come on now.
I generally try to use something that describes the devices function. "access-[1-9][0-9]*" = access router. "core-[1-9][0-9]*" = core router. "IP" is implied unless it's something else, ie. "(eth|atm)-access-[1-9][0-9]*" are Ethernet or ATM switches.
For places where I collapse functionality, ie. a small site with collapsed core and access boxes, I call them access, because they are less to move and hence need renaming when core boxes come in the future to support additional access boxes.
Interface addresses in DNS include the interface name and VLAN or some other logical circuit details (PVC, etc.), as is common.
Juniper boxes have re0-hostname.domain and re1-hostname.domain, and also re-hostname.domain if I've got a moving master IP address configured.
That's about all I can think of to write, I hope it's useful to someone, YMMV, etc.
ours is a small network, so is ok to have fun. 8)
we do use CNAMES to provide useful information(and make managers happy).. and name servers after the service the provide, eg ldap1.auth.mgt
here is an example:
gwhynott@ops:~$ host rma.mgt
rma.mgt.oicr.on.ca is an alias for RiserRoom5a.hp8212.rack2.mgt.oicr.on.ca.
RiserRoom5a.hp8212.rack2.mgt.oicr.on.ca has address 10.3.200.35
gwhynott@ops:~$
-g
Access network primarily CLLI codes of the building where the POP is
located or closest serving CO,
backbone three letter airport codes and in some cases CLLI codes.
During the transition form JvNCNet to VERIO/NTT we had some CNAMES to
the old network
names where things at for example Philadelphia where named
cheesesteake_something, and
some other names well known to the community at that time such as
tiger.jvnc.net for the
dialup access server.
Regards
Jorge
Hello,
On our side we're using things like :
xe3-3-0-154.tcr1.th2.par.as8218.eu
xe3-3-0 : interface (Juniper behaviour)
154 : vlan (if we use vlans on the interface)
tcr1 = first transport core router
th2 = datacenter (Telehouse 2, generally 2 to 4 letters at our appreciation)
par = city (Paris, using the 3 letters IATA City code, not the Airport code
such as CDG for Paris)
definitely +1 for IATA city codes. Less problems than the airport ones.
^ ^
^------------------------------------------
^
ISTR we've been here ^ before about 6 months ago? If so, apologies.
Gord
For pretty much all hardware we use
<city><site><devicetype><devicequalifier><devicenumber>
And for routers/switches I add the interface info.
e.g:
Tracing route to cal1sw-01.nff.local [10.1.9.4]
over a maximum of 30 hops:
1 1 ms 1 ms 1 ms con1sw-01-v103.nff.local [10.1.3.2]
2 1 ms <1 ms <1 ms con1rt-01-fe0-0.nff.local [10.1.250.99]
3 4 ms 3 ms 3 ms tor1rt-01-fe0-0s550.nff.local
[10.1.254.1]
4 48 ms 48 ms 50 ms cal1rt-01-fe0-1.nff.local [10.1.254.22]
5 56 ms 50 ms 48 ms cal1sw-01.nff.local [10.1.9.4]
But this also covers a lot of other stuff. We've got a list of 20
different device types
edm1ppc01 - Edmonton 1, page printer, color, unit 1
mtl2rt-02 - Montreal 2, router, unit 2
cal1lp-04 - Calgary 1, line printer 4
con1lt-12 - Concord 1, laptop #12
Everything gets asset tagged and labelled with the ID.
Servers are labelled by function (monitor, sql, etc).
Thanks,
Erik
Bottom line is there is probably no perfect naming scheme, but some do
suck more than others. This came up on another list and resulted in a
long thread, where lots of people still prefer cutesy names, but I'd
recommend against them. Here is point where I contributed so I don't
need to repeat it here. An ISP's naming scheme may differ slightly
due to the multitude of interface conventions you might want a name
to associate with, but you'll get the gist of my stance. Then browse
forward and backward to see what others had to say.
<http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind1002&L=SECURITY&T=0&F=&S=&P=49637>
John
Sorry for the delay; I've been traveling and neglecting my lists.
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.
I study PTR naming conventions as part of my Enemieslist project; it
turns out that genericity in naming is highly correlated to bot spam,
so some folks find my patterns useful to block and/or score inbound
mail for risk of being bot-originated.
As such, I've written a few rants about /poor/ naming practices that
you may find useful and/or amusing, as well as a few pointing out the
rare /good/ naming practices. (See below)
In a nutshell, it boils down to this:
- note static/dynamic hosts in the name, in the furthest-right-hand
token possible (dyn.example.net, not dyn-foo-1-2-3-4.ny.ny.example.net).
- cute and funny are not useful to others trying to decide whether
to block services originating from a host; clarity and forethought
and transparency are.
- use different conventions for different services, this helps us
differentiate dialup from dsl from cable and other infrastructure;
don't assume everyone will do a whois lookup to find out this block
is all consumer dsl and this other one is fixed business class.
- be consistent, for the love of all that is good and holy. I've got
over a hundred patterns for vsnl.net.in *alone*.
There are a couple of IDs that discuss naming, in the anti-abuse context:
http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt
Here's what I've had to say on the matter over the years:
DHCP doesn't necessarily mean dynamic
http://enemieslist.com/news/archives/2009/09/dhcp_doesnt_nec.html
annoying-stupidity.volia.net
http://enemieslist.com/news/archives/2009/08/annoyingstupidi.html
A few thoughts on reverse DNS / PTR naming
http://enemieslist.com/news/archives/2009/06/a_few_thoughts_1.html
Basic principles of DNS and their discontents
http://enemieslist.com/news/archives/2009/06/basic_principle.html
http://enemieslist.com/news/archives/2009/06/basic_principle_1.html
http://enemieslist.com/news/archives/2009/06/basic_principle_2.html
Today's DNS Spotlight: Eircom
http://enemieslist.com/news/archives/2009/06/todays_dns_spot.html
A couple more: kudos, and mixed kudos/gripe
http://enemieslist.com/news/archives/2009/06/a_couple_more_k.html
Principles
http://enemieslist.com/news/archives/2009/06/principles.html
There's a few dozen more in the gripes archive:
http://enemieslist.com/news/archives/gripes/
HTH,
Steve