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
Dan Lockwood(dlockwood@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? TIADan 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.
sig=$header
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:
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:
Hrm, a useful nanog discussion, will wonders never cease...
Lets start by examining some examples from exiting "important networks":
0.so-5-1-0.TL2.DCA6.ALTER.NET
pos1-0-622M.cr1.SFO1.gblx.net
p16-7-0-0.r02.stngva01.us.bb.verio.net
sl-bb22-rly-3-0.sprintlink.net
ge5-1.mpr1.iad5.us.mfnx.net
bbr01-p4-0.nycm01.exodus.net
ges1-ge-1-1.Restonrst.cw.net
so-2-0-0.mp2.Denver1.Level3.net
gbr3-p40.sl9mo.ip.att.net
Obviously you don't NEED to state much at all, but you probably want
to come up with a naming scheme which is logical and understandable to
both your engineers and the rest of the internet.
The general components of a naming scheme are the geographic location,
the facility information, the device information, the port information,
any subint info, and optionally a speed (if you like to brag). Let's look
at each one individually.
Location -- Most networks use either airport codes, clli codes, or some
nonstandard written-out description, each with their own advantages and
disadvantages. If you are looking to describe "metro areas" moreso than
specific cities, they may be for you. On the other hand, if you expect to
have a wide variety of areas, clli code may be more appropriate. One of
the problems with airport codes comes in defining exact boundries on
overlap, for example IAD/DCA/BWI, SFO/PAO/SJC, LGA/JFK/EWR, etc. Another
problem comes when the codes aren't obvious to the average person (for
example, "what the heck is IAD? ORD? LGA?"). Clli codes are a little more
difficult to search, but sometimes a little bit easier to figure out.
Made up codes (for example CHI for Chicago, WDC for Washington DC) or
written out names tend to be the most confusing.
Facility information -- Most people tend to stick a number on their
location code and use it to name a facility, for example IAD1, stngva01,
etc.
Device information -- Here is where things get a little trickier. The
general idea is to come up with a descriptor for the "role" of the
device, and attach a number. The fun part comes when you start trying to
think up role names which are short and simple, but which people can
"get" without needing some inside info or a cheat sheet. There are a
number of ways you can go here, personally I'm kindof partial to GX's CR
(core routers) BR (border) HR (hosting) AR (access, for cust
circuits), etc. Some of the more complex ones are impossible to guess
unless you know the meaning behind them.
Port information -- There are a couple ways you can go here too,
depending on the devices you're using. Juniper's naming scheme for
interfaces solves the problem for you, with Cisco you have to get a
little more creative (p or pos? gi or ge? fa or fe?), and Foundry is even
worse (everything is called Ethernet). Usually you want to just replace
/'s with -'s. And if you have any sub-ints, you should throw them in too.
Speed -- This can sometimes be useful, sometimes bragging, or sometimes
just funny when someone gets the math wrong. If you want to tack on a
-oc48 or -2488M it won't hurt anything, but please don't do something
stupid like sprint's 405xT1 to mean OC12.
Put it all together in a way that suits you and your specific needs, and
you've got a naming scheme. Personally I prefer using the hierarchy
inherient in DNS to come up with something simple like:
0.ge-0-1-0.core1.iad1.yourcompany.net
or
pos4-0.cr1.asbnva01.us.yourcompany.net
But if you're going to be one of the "one big word" or "lots of dashes"
people, I (unfortunately) can't stop you. Some very good examples of a
logical layout you could model from are UU/GX, and Verio. My award for
most annoying layout goes to CW.