Whats the rule of thumb for naming gear these days
(routers,switches...etc). Or is there one?
looks like level3 does something like
interface.routertype.location.level3.net
Nick Olsen
Network Operations
(855) FLSPEED x106
I usually name them after ex-girlfriends
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
james.cutler@consultant.com
Nick,
I do not believe there is a written standard for naming gear ( or at least I have never seen one) Most naming scheme's are usually something arbitrary
RAS gave a pretty good tutorial on traceroutes once, specifically he covered the topic of interpreting DNS in a traceroute.
I know we are not talking about traceroutes or DNS here but hopefully this can give you a little insight into naming your equipment.
http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf
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..
Hope that helps!
G
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).
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.
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