> I recommend documenting your naming standard and getting buy in across your
> organization before you put it into place.
This is a necessary condition for successful deployment, but not part of the
schema.
On Jan 25, 2011, at 11:32 PM, David Miller wrote:
> On 1/25/2011 8:15 PM, Gary Steers wrote:
>> James makes a good point...
>>
>>> Pick a scheme which:
>>> 1. Uses simple memorable names.
>>> 2. Makes business sense to you.
>>> 3. You know how to manage (database, publication, updates, etc.
>>> If I had to weight these criteria, I would weight 3 most heavily.
>>
>> The other key thing to bear in mind is consistency and scalability... (i.e.
>> design a scope that can grow with your network and needs
>>
>> {interface/server}.{router/vmhost}.{city}.{country}.example.net
>>
>> The other thing that doesn't really have any defined list is {city}, Some
>> people prefer 2 letter, some 3 letter, some people use airport codes etc..
>>
>
> The naming schemes that I have developed that needed to be upgraded in the
> past have almost always bumped up against scale, so build in much larger
> scale than you ever think that you will need from the beginning. You have X
> devices now in Y locations, but your naming scheme should scale to X^Z
> devices in Y^Z locations.
>
> I agree that for network gear, this is is a good place to start (slightly
> simplified here from above):
>
> {interface}.{host}.{location}.example.net
>
>
> - Location
> I personally prefer UN LOCODEs for country / city. The UN already went to
> the trouble of giving a unique code to every country/city. Why do I use
> them? LON makes perfect sense as London, England... until you have devices
> in London, KY and London, OH (the LOCODES for these Londons are GB LON, US
> LDN, US LOZ). In my opinion, airport codes (while certainly unique) work
> well in some locales and not so well in others (so, I don't use them, YMMV).
>
> - Host
> I prefer, like many do, an acronym denoting the primary function of the
> device. ES (edge switch), AR (access router), CR (core router), etc...
> whatever your internal terminology is. If you will *ever* have more than 10
> of a device anywhere, then I would recommend that you number out of double
> digits (more than 100, then out of triple digits...). That way in a sorted
> list AR03 will be right between AR02 and AR04, where you expect it to be,
> instead of between AR29 and AR30. Standardizing on number length also limits
> ambiguity in pressure situations and/or over noisy or less reliable
> communication channels.
>
> - Interface
> Port names vary on gear from different vendors. {interface type} -
> {selector}* ... where selector repeats ordered from highest to lowest level
> of granularity (e.g. rack/slot/module/port) is what I use. You should use
> whatever makes sense to you. Are interface speeds or vlans important to your
> infrastructure? If so, then include them where appropriate. Unless you have
> exactly the same gear everywhere, you are going to have to be flexible here.
>
> I recommend documenting your naming standard and getting buy in across your
> organization before you put it into place. By giving names to these
> devices/interfaces at all, you are exposing information to the world. What
> makes perfect sense to engineering and support may give security, management,
> and/or marketing heart palpitations.
>
> Just my $0.02 (probably overvalued).
>
>> Hope that helps!
>>
>> G
>>
>> ---
>> Gary Steers
>> Sharedband NOC/3rd Line Support
>> Sharedband
>> UK: +44 (0)1473 287207
>> US: +1 206 420 0240
>> E: [email protected]
>>
>> We have a new support system - http://support.sharedband.com
>>
>>
>> -----Original Message-----
>> From: Cutler James R [mailto:[email protected]]
>> Sent: 25 January 2011 22:41
>> To: nanog group
>> Subject: Re: Network Naming
>>
>> On Jan 25, 2011, at 3:50 PM, Nick Olsen wrote:
>>
>>> Whats the rule of thumb for naming gear these days
>>> (routers,switches...etc). Or is there one?
>> Pick a scheme which:
>> 1. Uses simple memorable names.
>> 2. Makes business sense to you.
>> 3. You know how to manage (database, publication, updates, etc.
>>
>> If I had to weight these criteria, I would weight 3 most heavily.
>>
>>
>> James R. Cutler
>> [email protected]
>>
>>
>>
>>
>>
>>
>
>
James R. Cutler
[email protected]
