[123753] in North American Network Operators' Group
Re: Network Naming Conventions
daemon@ATHENA.MIT.EDU (Nathan Ward)
Mon Mar 15 10:08:59 2010
From: Nathan Ward <nanog@daork.net>
In-Reply-To: <EEA8BBE1EFCAB74DB40C6A18550733ADF34421@HKEMAIL.hke.local>
Date: Tue, 16 Mar 2010 03:08:19 +1300
To: nanOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 16/03/2010, at 2:10 AM, Adcock, Matt [HISNA] wrote:
> I've used a Jimmy Buffett theme in test labs before.
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]*" =3D access router. "core-[1-9][0-9]*" =3D 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.
--
Nathan Ward
