> 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: gary.ste...@sharedband.com >> >> We have a new support system - http://support.sharedband.com >> >> >> -----Original Message----- >> From: Cutler James R [mailto:james.cut...@consultant.com] >> 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 >> james.cut...@consultant.com >> >> >> >> >> >> > > James R. Cutler james.cut...@consultant.com