Thoughts on best practice for naming router infrastructure in DNS
I've found myself with a few spare cycles and have decided to put them towards addressing a pet peeve I frequently encounter here: the complete state of chaois that is the naming in DNS for our network infrastructure. There are mismatched forward and reverse entries, no designated subdomain for WAN or LAN gear, there are records that remained after equipment was retired, etc. The single biggest area of offense is in the naming for our routing gear. I attribute this to the fact that routers commonly have a greater number of IP addresses associated with them than, say, your average edge switch. I'm still doing some digging around the 'net as well as the NANOG archives (the document from Rutger's at http://www-td.rutgers.edu/documentation/Reference/RUNet_Network_Device_N aming_Convention/ provided a great example that I'm considering following) but I thought I'd toss it out on the list for a bit of insight into what's being done today as opposed to five years ago. There seems to be two general practices that are used when naming routers in DNS. The first is to describe the location, equipment, interface and interface number on the equipment in the hostname, matching that to a designated subdomain that describes the function (WAN routing, LAN switching, etc). Something like "corp-wan1-gige0-0.wan.example.com" would be used to describe interface Gi0/0 on WAN router #1 at the corporate office and "dpg-mu1.wan.example.com" would describe the Multilink1 interface on the DuPage location's only WAN router. The upside to this methodology is that techs and users alike can see useful information when doing a traceroute, etc. The downside is that if your router has a dozen interfaces you end up with two dozen records (12 forward, 12 reverse) associated with the device that must be maintained. Additionally, the moment you upgrade an interface you have to change the two corresponding records to reflect the new IP or interface type (FastE to GigE, for example). The other style I've seen is to use one generic name, such as "corp-wan1.wan.example.com" for the first WAN router and "corp-core1.lan.example.com" for the first core router, make the FQDN resolve to a loopback or similarly unchanging IP and for every interface that carries an IP address just have the address reverse to that single generic FQDN. This is generally simpler to maintain and is given praise because it's less likely to confuse NMS applications like OpenView Network Node Manager -- on the downside you lose a lot of potentially useful information. Neither one of these seems well-equipped to deal with "virtual" interfaces such as an ethernet interface that is VRRP or HSRP'd between two routers (eg x.x.x.10 is your "virtual" IP for the subnet's gateway, router 1 has physical interface IP of x.x.x.8 and router 2 has x.x.x.9). So, what practices do you folks follow? What are the up and downsides you encounter? -JFO Jason "Feren" Olsen DeVry University
On 6/14/07, Olsen, Jason <jolsen@devry.com> wrote:
Neither one of these seems well-equipped to deal with "virtual" interfaces such as an ethernet interface that is VRRP or HSRP'd between two routers (eg x.x.x.10 is your "virtual" IP for the subnet's gateway, router 1 has physical interface IP of x.x.x.8 and router 2 has x.x.x.9).
This particular issue has been confounding to work around as well. The issue of constantly updating DNS to match the current topology is a pain, but in my opinion, very necessary. randal
On 6/14/07, randal k <nanog@data102.com> wrote:
This particular issue has been confounding to work around as well. The issue of constantly updating DNS to match the current topology is a pain, but in my opinion, very necessary.
I'm not entirely convinced DNS records for every possible interface address are needed, in part because it's so difficult to keep them updated with topology changes over time. I think the first step is to choose a standard subdomain for infrastructure, like "wan.example.net". The next step (the last step in many companies) is to populate forward and reverse DNS for the "source interface" and managed IP of each device, so you can at least resolve the IP which the router will use when sending traps, NTP, TACACS+ and other requests, and to keep the NMS sane. Kevin
On 14-Jun-2007, at 16:25, K K wrote:
On 6/14/07, randal k <nanog@data102.com> wrote:
This particular issue has been confounding to work around as well. The issue of constantly updating DNS to match the current topology is a pain, but in my opinion, very necessary.
I'm not entirely convinced DNS records for every possible interface address are needed, in part because it's so difficult to keep them updated with topology changes over time.
I once wrote a couple of scripts to parse a repository of configurations stored by rancid, and to produce zone file fragments which could be INCLUDEd into zones and published in the DNS automagically. It wasn't hard. There is some text about it in the tutorial I wrote for NANOG 26, which Stephen Stuart presented after I accidentally went to an ICANN meeting in Shanghai instead of going to Eugene: http://www.nanog.org/mtg-0210/ppt/stephen.pdf Check pages 37-41. You'll find example scripts here: ftp://ftp.isc.org/isc/toolmakers/ I can't pretend I have used it since 2002, so some hacking may be required. Also, unless you have a particular reason to generate a topology map of a network for other reasons, and unless your naming scheme is based on something that looks like an undirected graph, you may find it easier to write something a little more focussed. For example, the trivial awk script /^interface / { ifname = $2; gsub(/\//, "-", ifname); gsub(/\./, "-", ifname); } /^ ip address / { print $3, ifname ".someisp.net"; } will digest cisco-style configs like interface FastEthernet3/1/0.214 ip address 203.97.1.241 255.255.255.240 ... ! interface POS3/2 ip address 199.212.93.1 255.255.255.252 ... and excrete the following, for example: 203.97.1.241 FastEthernet3-1-0-214.someisp.net 199.212.93.1 POS3-2.someisp.net Building IN-ADDR.ARPA zones from data like that is not at all difficult. Dealing with JUNOS configs is marginally more difficult with line-based tools like awk, but still entirely possible (see those example scripts I mentioned for examples). Package up some of this stuff so it will run unattended, and run it out of cron every $interval, and suddenly reverse DNS takes no effort at all. The hard bit is back at the beginning, working out what the mapping of router configuration -> DNS name should be (i.e. what your naming scheme is). Joe
On Friday 15 June 2007 00:27, Olsen, Jason wrote:
So, what practices do you folks follow? What are the up and downsides you encounter?
At my previous employer, we came up with a formula that we were happy with. For reverse DNS, it involves: * defining the interface * defining the device function * defining the local location * defining the international location o device interface could be: fa-0-0-0 gi-1-0-0 s0-0-0 pos-1-0 tun0 this also takes subinterfaces into account; for cases where we've had to classify a switch VI the "routes" IP traffic: vlan100 o device function could be: br-gw (border router) cr-gw (core router) cr-sw (core switch) edge-gw (edge router) edge-sw (edge switch) o device local location; we normally define this using the IATA 3-letter international city/airport code: LAX (Los Angeles ABV (Abuja) DXB (Dubai) CPH (Copenhagen) MEL (Melbourne) HKG (Hong Kong) it is not uncommon to have towns or cities being abbreviated by the locals in some other way, either because they do not care for the IATA code :-), or if they do, are not included in the IATA database; in this case, you may use your imagination; for us, depending on the length of the name, we spell out the full town's name. o device international location is easily defined if your TLD is based on a country, e.g., .uk, .ae, .ke, .za, .na, e.t.c. for situations where your domain name would end in a non-region specific TLD, e.g., .com, .net, .org, e.t.c., one would prefix a state or country (in the case of a global network) to the domain name, e.g.: .uk.somelargenetwork.com .za.somelargenetwork.com things could get interesting if you setup multiple PoP's in another location that would still fall under your .com or other such TLD, but there are ways to fix that :-). So, a final example of, say, core router number 5 and edge switch number 3 located in a datacentre of a local Australian ISP in Melbourne: gi-0-0-1.cr-gw-5-mel.somenetworknetwork.com.au vlan876.edge-sw-3-mel.somenetwork.com.au Say a large network, whose home network was the US, decided to setup a single PoP in Johannesburg that included one core router and one border router, but whose domain name ended in .net, it would look something like this: pos-3-0.cr-gw-1-jnb.za.somelargenetwork.net gi-0-0-1.br-gw-1-jnb.za.somelargenetwork.net You could then use the script Joe Abley kindly posted earlier to automatically generate your entries. Of course, this was our own approach. Different folks have different strokes. Hope this helps. Cheers, Mark.
Then you get some networks who name all the routers after cheeses or characters from bill and ben the flowerpot men. -- Leigh Mark Tinka wrote:
On Friday 15 June 2007 00:27, Olsen, Jason wrote:
So, what practices do you folks follow? What are the up and downsides you encounter?
At my previous employer, we came up with a formula that we were happy with. For reverse DNS, it involves:
* defining the interface * defining the device function * defining the local location * defining the international location
o device interface could be:
fa-0-0-0 gi-1-0-0 s0-0-0 pos-1-0 tun0
this also takes subinterfaces into account; for cases where we've had to classify a switch VI the "routes" IP traffic:
vlan100
o device function could be:
br-gw (border router) cr-gw (core router) cr-sw (core switch) edge-gw (edge router) edge-sw (edge switch)
o device local location; we normally define this using the IATA 3-letter international city/airport code:
LAX (Los Angeles ABV (Abuja) DXB (Dubai) CPH (Copenhagen) MEL (Melbourne) HKG (Hong Kong)
it is not uncommon to have towns or cities being abbreviated by the locals in some other way, either because they do not care for the IATA code :-), or if they do, are not included in the IATA database; in this case, you may use your imagination; for us, depending on the length of the name, we spell out the full town's name.
o device international location is easily defined if your TLD is based on a country, e.g., .uk, .ae, .ke, .za, .na, e.t.c. for situations where your domain name would end in a non-region specific TLD, e.g., .com, .net, .org, e.t.c., one would prefix a state or country (in the case of a global network) to the domain name, e.g.:
.uk.somelargenetwork.com .za.somelargenetwork.com
things could get interesting if you setup multiple PoP's in another location that would still fall under your .com or other such TLD, but there are ways to fix that :-).
So, a final example of, say, core router number 5 and edge switch number 3 located in a datacentre of a local Australian ISP in Melbourne:
gi-0-0-1.cr-gw-5-mel.somenetworknetwork.com.au vlan876.edge-sw-3-mel.somenetwork.com.au
Say a large network, whose home network was the US, decided to setup a single PoP in Johannesburg that included one core router and one border router, but whose domain name ended in .net, it would look something like this:
pos-3-0.cr-gw-1-jnb.za.somelargenetwork.net gi-0-0-1.br-gw-1-jnb.za.somelargenetwork.net
You could then use the script Joe Abley kindly posted earlier to automatically generate your entries.
Of course, this was our own approach. Different folks have different strokes.
Hope this helps.
Cheers,
Mark.
Mythic Beasts Ltd, IIRC, names their machines after, uh, mythic beasts. Which is consistent, but not especially useful.. On 6/29/07, Leigh Porter <leigh.porter@ukbroadband.com> wrote:
Then you get some networks who name all the routers after cheeses or characters from bill and ben the flowerpot men.
-- Leigh
On Fri, 29 Jun 2007, Alexander Harrowell wrote:
Mythic Beasts Ltd, IIRC, names their machines after, uh, mythic beasts. Which is consistent, but not especially useful..
perhaps a decent other question is: Do I want to let the whole world know that router X with interfaces of type Y/Z/Q is located in 1-wilshire. I suppose on the one hand it's helpful to know that Network-A has a device with the right sorts of interfaces/capacity in a location I care about, but it's also nice to know that for other reasons :( so naming things about mythic beasts or cheese or movies is not so bad, provided your NOC/OPS folks have a key that shows: optimus-prime.my.network.net == 1-wilshire, m160, t1-customers-only.
On 6/29/07, Leigh Porter <leigh.porter@ukbroadband.com> wrote:
Then you get some networks who name all the routers after cheeses or characters from bill and ben the flowerpot men.
On Fri, 29 Jun 2007, Chris L. Morrow wrote:
perhaps a decent other question is: Do I want to let the whole world know that router X with interfaces of type Y/Z/Q is located in 1-wilshire.
I suppose on the one hand it's helpful to know that Network-A has a device with the right sorts of interfaces/capacity in a location I care about, but it's also nice to know that for other reasons :( so naming things about mythic beasts or cheese or movies is not so bad, provided your NOC/OPS folks have a key that shows: optimus-prime.my.network.net == 1-wilshire, m160, t1-customers-only.
At 3am, I'd rather have the NOC/OPS folk be able to figure things out from the name directly, than have to have access to the magic key that lets them know what the weird name translates into. Ditto if I'm nowhere near my translation key, having a life, for example. At any rate - it's possible to have informative names without going into "too much" detail - knowing where the device is, what it does (border, core, switch), and what it's connecting (customerA) is pretty darn'd useful all around, and avoids getting into the device type and interface specifics. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now."
On Fri, 29 Jun 2007, Cat Okita wrote:
On Fri, 29 Jun 2007, Chris L. Morrow wrote:
perhaps a decent other question is: Do I want to let the whole world know that router X with interfaces of type Y/Z/Q is located in 1-wilshire.
I suppose on the one hand it's helpful to know that Network-A has a device with the right sorts of interfaces/capacity in a location I care about, but it's also nice to know that for other reasons :( so naming things about mythic beasts or cheese or movies is not so bad, provided your NOC/OPS folks have a key that shows: optimus-prime.my.network.net == 1-wilshire, m160, t1-customers-only.
At 3am, I'd rather have the NOC/OPS folk be able to figure things out from the name directly, than have to have access to the magic key that lets them know what the weird name translates into.
agreed, there's a benefit, does it outweigh the 'risk'? I was only asking a question and providing 2 examples.
Ditto if I'm nowhere near my translation key, having a life, for example.
stop joking, you don't have one of those :)
At any rate - it's possible to have informative names without going into "too much" detail - knowing where the device is, what it does (border, core, switch), and what it's connecting (customerA) is pretty darn'd useful all around, and avoids getting into the device type and interface specifics.
sure thing.
participants (9)
-
Alexander Harrowell -
Cat Okita -
Chris L. Morrow -
Joe Abley -
K K -
Leigh Porter -
Mark Tinka -
Olsen, Jason -
randal k