I posted a mostly related thread in GD:

http://www.ar15.com/forums/t_1_5/1670055_Inside_every_little_problem_____IT_Probs_.html


Since a lot of folks ignore that madhouse, I thought I would post a query here in the more cerebral oasis of Urban Commandos.  

In particular, I would be interested in hear about in naming naming scheme for devices on your internal network.

We are thinking about going to something using CLLI codes or airport codes. Plus building, location in building, device type, and device enumerator.

Something like:

spfmo-0301-rt03  (CLLI based)
sgf-0301-rt03  (IATA based)

To me, IATA is problematic because there are too many facilities in podunk little towns without an airport.

The next question is interface naming. Interface suffixed to the device name, prefixed to the device name, or a hostname in a device name subdomain?

ge-1-1-0-spfmo-0301-rt03.foo.net
spfmo-0301-rt03-ge-1-1-0.foo.net
ge-1-1-0.spfmo-0301-rt03.foo.net

We are a pretty big corp, several hundred sites. We use an airport code system, and it works well. If there's no airport, or multiple sites in a city, we just get creative as long as its unique.

Servers are named with airport code, function, and serialized number. We are in Sarasota, FL so for instance a fileserver would be SRQFILE01 or a websense server would be SRQWEBSENSE01. I like to make sure that whatever convention is still easy enough to be descriptive without having to look up the name in another location to decode and find out what it actually does (if possible).

Network devices would be similar, but client access switches are named by the location. They would be named by site, then floor, then switch closet, then position in rack. So for instance SRQ2-4-a would be the client access switch in Sarasota on the second floor, closet 4, first switch in the rack.

We've started using airport codes but limit the total number of characters to 15 or less due to the limitations in AD.

Airport code - three characters for the team/product owner/custonmer - two characters for prod, dev, qa etc.  - 3 character for server type. ie web, app, etc.  - one character(v or p) for virtual or physical  - 3 digit number.

example

dca300prwebv001


If a product has different parts to it, then the first two characters identifies the product, the last one identifies which part it is.  So instead of web it might be SW for Solarwinds and then P for a polling server.

example
dca300prSWPv001

We do about the same thing.



Servers get Prefix with location or business unit, type, and sequence number.

ie- ARFFS02 (unit = arfcom, type = file server, second unit)



Network gear has a type, location, then locators or identifiers

ie- sw-arfst-b-r4-7-vlan125 (type - switch, location = arfcom store, locators & identifiers = room B, rack 4, 7'th something, dedicated to vlan 125)

We have a bunch of geographically diverse locations across the state with anything from 5-250 users and two main offices with 1000+.  Things used to be broke up into districts that were previously autonomous, but have now been consolidated.

2 digit district code, 3 digit city code, 3 letter department code, [2 digit OS code + 2 digit type code]  or 3 letter device type code, 3-5 letter identifier




Yeah it was designed by committee,  how could you tell?

Make sure at least one server is named WOPR.  

It's a fucking rule, man.

We have several conventions that we use for devices. I'll try to summarize.

Desktop names are <site code>-<service tag>:    i.e. NYC-F42GXR1, BMA-FX45JFP
Server names are <site code>-<role><2 digit number>:    i.e. NJE-APP01, DCO-ADC02, HCT-SQL02
Mobile devices are MOB-<type><4 digit number>:   i.e. MOB-IPH0001, MOB-BBM0002, MOB-IPD0005

Network and Storage devices get more complicated due to having multiple interfaces in multiple networks, We're trying to standardize but it's a mess.... Same with telecom and a/v equipment.

We have several domains, current and legacy, but to keep it simple, there's three DNS zones. Two are AD, the other is public. No trusts.

Intranet: companycorp.com (.com was a bad idea, but not my idea)
DMZ Private: companydmz.com (.com was also a bad idea)
Public: company.com (DNS only, no AD)

We have subzones in DNS for MGMT and NET devices so as to not clog the main zones.

Intranet Network: net.companycorp.com
Intranet OOB/mgmt: oob.companycorp.com
DMZ Private Network: net.companydmz.com
DMZ Private OOB/mgmt: oob.companydmz.com
Public Network and OOB/mgmt: (none) - I wish we put in DNS but security would not allow it. If so, I'd use company.net for public (in case .com DNS was compromised, we could still reach our devices)

I hate subzones for each location. So 1995ish. Just keep it simple and have your site codes in the hostname.

As for site codes, they're all manually generated when a new office opens.

Offices are usually <1 char city><2 char state or country>: i.e.  RIT (Rome), BMA (Boston, Mass.), DCO (Denver, Colo.), MRU (Moscow, Russia)
Datacenters are usually <2 char state><1 char facility>: i.e. NJE (NJ Equinix), GAQ (Georgia QTS), NYI (NY Internap)

There's some deviations but it works OK.

Amazon Cloud environment design was a nightmare, though. The default naming scheme is ip-<hex IP>. Constant debate over whether to use that and join the machines to the domains w/ those names, or to rename them instead. We ended up just deciding to issue site codes for the different AWS regions - AWV for Virginia, AWO for Oregon, AWI for Ireland, etc.

My recommendation is just device your own site codes and stop trying to wrap your infrastructure around CLLI or IATA. Those standards weren't intended for modern day scale that IT infrastructures require.

If I may ask, how large is your network, what types of devices do you host, and what is in scope for your naming schemes? Everything including the kitchen sink? Or just network devices.

Good luck! If you want to brainstorm more, PM me. I love these types of discussions and learning from others what works and what doesn't work in their environments.