another way is to use subdomains to separate device, geographic area, and primary function so that a core router in Washington DC might look like this:

core-1.wdc.infrastructure.net

this would be a subdomain as well as it would interfaces under it as well and possibly sub-interfaces. if you're thinking that this could make the FQDM be quite long...you're right...but one advantage is to be able to do a "dig axfr" on the sub to see all of the devices in a specific location such as "dig wdc.infrastructure.net axfr" would return all of the devices in that geographic location. Then you could dig on a specific device (as a subdomain) to see all of the interfaces configured on that device. This can lead to lots of admin overhead but some good scripts to automate it...it works. of course this is just my opinion.

steve

jnull wrote:

Dan Lockwood(dlocdlockwood@shastalink.k12.ca.us)@2002.08.21 12:16:20 +0000:

Does anyone have a resource that has recommendations about how to name
interfaces in a DNS name space?  Is there a standard that is used?  TIA
 
Dan Lockwood


I'm certain there are some good resources available, but f
m my experience, the most important thing is to work your convention to integrate with you exising or proposed management systems. If your managment system only works from a set domain (i.e. xyz.abc.net--abc being your company and xyz being a subsection) then that label xyz should only have dashes and not periods, otherwise they become a domain themselves.

So, it may depend on the size of your network:
primary device: r1.company.net
interface name: pos1-2-r1.company.net
----or		pos1-2.r1.company.net 
----or if you're there is need
primary device: r1.area-or-function.company.net
...ect...
There may be some customization involved with using domain subsets, but using <insert lang> scripts you can parse at either "-" or "." do retrieve information. So, unless size demains creating subsections I would keep the whole name in the top label by using dashes.
<
br>
sig=$header