[135531] in North American Network Operators' Group
Re: Network Naming
daemon@ATHENA.MIT.EDU (Bill Blackford)
Wed Jan 26 10:34:12 2011
In-Reply-To: <4D3FA3DE.7040809@tiggee.com>
Date: Wed, 26 Jan 2011 07:33:56 -0800
From: Bill Blackford <bblackford@gmail.com>
To: David Miller <dmiller@tiggee.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
What I found when visiting this in my own organization that being an
Enterprise and "pseudo" service provider, is that naming fits into
several categories.
1. Hostnames/Prompts
2. Rack Switches in Data centers
3. Path. Meaning routed interfaces that the world sees in the form of
PTR records.
Prompts:
{Organization}-{Site}-{Dist_Frame}-{Device_Type}{Number}
MYCORP-HQ-2B-S1 (My_Corp., headquarters, 2nd Fl idfb, switch1.
Another way I've named prompts is with relative DNS suffix. This tends
to work best with routers, not so much for rack or access gear.
ex,
CAR1.INAP.STTL#
full DNS name: car1.inap.sttl.my-corp.net
Racks:
Same as above just replacing frame with rack#
Path:
{Interface_Type}{number}.{Device_Type}{number}.{Geo_Location}.{org_fqdn}
For interface type I've been sticking to the Juniper convention as I
find it more consistent than that of Ciscos.
I have a document that describes the convention of every field of
every type in order to maintain consistency.
What I struggle with is trying to find a consistent naming convention
for gear behind the firewall vs. on the outside that is publicly
visible.
-b
--
Bill Blackford
Network Engineer
Logged into reality and abusing my sudo privileges.....
