On Sat, 13 Mar 2010, Paul Stewart wrote:
With many changes going on this year in our network, I figured it's a good time to revisit our naming conventions used in our networks.
Today, we use the following example:
Core1-rtr-to-ge1-1-1-vl20.nexicom.net
Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc etc....
Finally, we have a fair amount of gear (that we own) at customer premises that act as either a managed device or a demarcation point .... how to you name those today?
You'll likely get lots of different answers to this, and there really isn't a right or wrong solution. It's up to you to determine what works best in your environment. In the last two places I've worked, where I had some level of control over the naming conventions, they ended up looking something like this for network devices (not all that different from yours): interface_name.device_name.location_id.domain example: te2-1.core01.pitbpa.yourisp.com If the interface has sub-interfaces like an 802.1q trunk with separate layer 3 interfaces, you could extend the interface name to reflect that, such as using te2-1-100 for TenGig2/1.100. Secondary networks could have something like "s02, s03, s04..." appended to the end of the interface name. The one deviation to this example is for the primary loopback address on the box, in which case I omit the interface name, so the example above becomes core01.pitbpa.yourisp.com. SNMP traps, auth requests, syslog messages, etc, are sourced from the primary loopback. The same format could be extended to RAS, broadband aggregators, etc pretty easily. It also has the benefit of being pretty hierarchical and consistent. This is helpful if you have network management systems or other back-office processes that need to be able to parse the name and pull out useful information. Keeping the format consistent makes the parsing logic less of a pain to write and update. One other thing you'll want to think about is if you want your interface names to follow $vendor's naming format rigidly, or if you want to use your own format that's relatively close. Specifically I'm thinking about the Cisco vs. Juniper way of doing things (TenGigabitEthernet2/1 vs xe-2/1). Most other vendors I've seen do something relatively Cisco-like. For customer premise routers, what I did in the past was something like: interface_name.customer_router_id.cust.domain example: fa0-0.widgets-inc-01.cust.yourisp.com If you don't want to reveal that the router is at or for "Widgets, Inc." you could always replace that with something like a customer ID number or something else that doesn't mean anyhting to the outside world, as long as you have a way through your back-office systems/NMS to associate that name with your customer "Widgets, Inc." That's my 2 cents. jms