[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Network Naming
- Subject: Network Naming
- From: bblackford at gmail.com (Bill Blackford)
- Date: Wed, 26 Jan 2011 07:33:56 -0800
- In-reply-to: <[email protected]>
- References: <7aeb7ba0$10caab2c$7a5700bb$@com> <[email protected]> <CF4687332659244DA0C2D1F53AFF9F83614953@sb-server-sbs.SharedComUK.local> <[email protected]>
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.....