It can also be slightly different for routers, switches, and servers? Addressing network interface naming first (a bit off-topic, but similar issue)...
Thinking mostly about network interfaces and nothing else, we ended up moving to a documentation scheme that roughly is: A) Primarily based on vlans. B) For routers, we include the physical port, could be like vlan1234-ge0/0-router.pop.city.county.state.country C) For switches (including layer-3 switches), we skip the physical port, so are more like vlan1234-switch.pop.city.county.state.country. D) For hosts (typically windows or UNIX-like hosts) we do it similar to routers. In the cases where there is no vlan, which is fairly rare nowadays, we either use 'native vlan1' - like vlan0001-ge0/0.router.city.county.state.country or just 'ge0/0'. For situations where we have say HSRP/VRRP/CARP running, generally there are two physical routers - like router01 and router02. For that, what figured was simplest was to do like: phys host A: vlan1234-router01.pop.city.county.state.country phys host B: vlan1234-router02.pop.city.county.state.country HSRP: vlan1234-router.pop.city.county.state.country The differentiation on the above, by the 'router01' and 'router02' we can see that IP is tied to that physical host, while the more generic 'router' means that it is the virtual HSRP/VRRP/CARP interface. In regards to names for devices/hosts themselves - which the original question was about... Yes - I am in 100% agreement that the idea of naming equipment after say cartoon characters from the Simpsons does not scale well. That works to a certain point, but does not scale well once you have more than a few dozen hosts. Many years ago, we actually named hosts out of the D&D Dieties & Demigods book. We choose a particular mythos for the type of host - cthulu for windows, greek for freebsd, etc - but again, although that helped classify the type of operating system - it still did not do well about the functionality/purpose of the machine, which is often important when you need to diagnose a problem or respond to that pager notice 'host XYZ down'. What we have done is sort of picked hostnames based on the functional purpose of the host, and then having a digit suffix to represent when there are multiple hosts doing the same thing. smtp001, smtp002, etc. From there, depending on where the host is physically located - we suffix on the appropriate pop.city.county.state.country as the domain name the host lives in. So, if for instance, you have 'smtp001' that lives in Chicago, but is virtualized, and for whatever reason, you slide it (or it fails over automatically to be running at, and you leave living) - say Atlanta, the hostname itself never needs to change but after the move, you may update the DNS zone that it lives in. Accordingly, for this to work well - host names must be unique across everything. For hosts that run multiple services, typically they are already virtualized already (each service on its own host), or in cases where they are not, having a more generic name for the host like 'netinfra' for say a network infrastructure machine that is running things like DNS, NTP and other stuff - all off a single or multiple IPs on the same host works, and allows that key ability of knowing what that host is responsible for and such in a general kind of way. There is another final, and perhaps more important issue - security. In reality, by making hostnames, IP addresses, and other stuff follow some kind of uniform standard and also publishing that information in DNS, you naturally leak out information about your network architecture, and also in some ways the purpose of the machine. I realize that this can be mitigated in a lot of ways, but currently we do not - mostly because we simply do not have the staff time to have yet 'one more' tool to take care of, update, and everything else. In all honesty, I considered a couple times before sending this e-mail even because of those kinds of issues, but since most of it we publish into DNS anyway, it is silly to think by not sending an e-mail about it, I am protecting anything. It is another one of those trade offs between time/effort, security, and availability. In this case, by 'availability' I mean the ability to quickly know for example - the physical location of where a tra! ceroute stopped when diagnosing a problem. - Mike On Sep 28, 2011, at 4:45 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Ray Van Dolson" <[email protected]> > >> Apologies if this is a bit off topic for this list. I'm looking for >> thoughts on device naming schemes -- experiences both good and bad. >> >> The "cute" names only scale to a certain point, and when you have a >> detached NOC it can be pretty helpful to have some information on >> device location, function, etc built into the hostname. > > Alas, that's true. :-) > >> (Notably absent is rack # which I've seen in other examples). > > The real question is: how many things do you bake into the machine name > *knowing that it might move, and thus, change*? How many things will > depend on that name? > > If your management software is the only thing that cares about the name, > bake as many layers into it as you like. > >> Would love to see some examples of schemes that have worked well and >> metadata you've found worth or not worth attempting to capture in a >> device name. > > Well, I can recommend the RFC, but it's not really on point. :-) > >> PS: Is there an active equivalent of NANOG or this list for >> server/sysadmin related discussion? > > I should think it's on-topic here; it's not like we're burning up the > bitstreams or anything... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > [email protected] > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 > _______________________________________________ > dc-ops mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/dc-ops _______________________________________________ dc-ops mailing list [email protected] https://puck.nether.net/mailman/listinfo/dc-ops
