Hi Folks... 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.... Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with. But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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? Open ended questions obviously - looking for many ideas. ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On my last network I named all the routers after simpsons characters. On 3/13/10 10:47 AM, Paul Stewart wrote:
Hi Folks...
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....
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with.
But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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?
Open ended questions obviously - looking for many ideas.
;)
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
I've used a Jimmy Buffett theme in test labs before. Matt Adcock, Manager 334-481-6629 (w) / 334-312-5393 (m) / MAdcock@hisna.com 700 Hyundai Blvd. / Montgomery, AL 36105 P The average office worker uses 10,000 sheets of paper = 1.2 trees, per year By not printing this email, you’ve saved paper, ink and millions of trees From: Ravi Pina [mailto:ravi@cow.org] Sent: Sat 3/13/2010 3:33 PM To: Randy Bush Cc: nanog@nanog.org Subject: Re: Network Naming Conventions On Sun, Mar 14, 2010 at 04:58:11AM +0900, Randy Bush wrote:
On my last network I named all the routers after simpsons characters.
scaled well?
Don't forget there were 5 Snowballs... The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments
On 16/03/2010, at 2:10 AM, Adcock, Matt [HISNA] wrote:
I've used a Jimmy Buffett theme in test labs before.
Naming themes are fine in test labs, because devices have a different function/role several times per day, a name acts like an asset tag in that it sticks with it through its lifetime. Same goes for those servers that sit in our networks that I can only really think to call "bitch boxes". They do all sorts of random one-off network hackery tasks, and never get any love. They're not supposed to scale, they were only supposed to be there for one job 5 years ago and they're still there. If I've got guys out there rolling out gear according to cookie cutter designs, I don't want them coming up with names and using ex girlfriends or TV shows or whatever. They're going to run out of ideas, and I don't want to have 50 boxes called "rachel" on the network with no idea what they do. That sort of thing works fine when you're the only person putting the names in to boxes - like in a lab - but no good if you've grown much. I'm a contractor/consultant type thing, and getting my customers to use naming schemes like the rant that follows helps me understand their network if they do things without me, and helps anyone else who comes along too. So, for production network and server gear, I like domain names built with city and site codes: site.city.domain Perhaps if I had a bigger network I'd have .country.domain on the end of that instead. Hosts within each site are told to search within their site, then city, then domain. Here's how in resolv.conf: search site.city.domain, city.domain, domain This lets me refer to a host called 'access-1' as, access-1, or access-1.site, or access-1.site.city depending on where I am. That's handy and saves my lazy ass typing lots. It also means we can have standard configs for lots of things. For example, we can syslog to "syslog" and it will choose either the one in the local site if its size warrants it, or one in the city, or a network-wide one. I'm sure you can think of other ways this can be useful. It can be annoying when a box doesn't let you display a full hostname in a prompt, or fudge it and set the "hostname" to "hostname.site.city" because hostnames shouldn't have periods in them. YMMV, etc. The benefits outweigh the negatives for me I think. Things can get a bit hairy when devices identify themselves by their hostnames in some other protocols though. Ignoring that and using DNS is encouraged, etc. As for hostnames themselves, I have varying ways of doing that, but I never use a naming scheme that won't scale for.. a long time. I always use numbers, but never use leading zeros - ie. access-1, not access-001. It's not hard to sort numerically, come on now. I generally try to use something that describes the devices function. "access-[1-9][0-9]*" = access router. "core-[1-9][0-9]*" = core router. "IP" is implied unless it's something else, ie. "(eth|atm)-access-[1-9][0-9]*" are Ethernet or ATM switches. For places where I collapse functionality, ie. a small site with collapsed core and access boxes, I call them access, because they are less to move and hence need renaming when core boxes come in the future to support additional access boxes. Interface addresses in DNS include the interface name and VLAN or some other logical circuit details (PVC, etc.), as is common. Juniper boxes have re0-hostname.domain and re1-hostname.domain, and also re-hostname.domain if I've got a moving master IP address configured. That's about all I can think of to write, I hope it's useful to someone, YMMV, etc. -- Nathan Ward
So, for production network and server gear, I like domain names built with city and site codes: site.city.domain
I don't think anyone's saying you can't also do that. Using CLLI or IATA or whatever alongside router names works fine, and using CNAME's allows you to provide both a functional name and a hostname for your device. We've done this for many, many years, and it works fine. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
ours is a small network, so is ok to have fun. 8) we do use CNAMES to provide useful information(and make managers happy).. and name servers after the service the provide, eg ldap1.auth.mgt here is an example: gwhynott@ops:~$ host rma.mgt rma.mgt.oicr.on.ca is an alias for RiserRoom5a.hp8212.rack2.mgt.oicr.on.ca. RiserRoom5a.hp8212.rack2.mgt.oicr.on.ca has address 10.3.200.35 gwhynott@ops:~$ -g On Mar 15, 2010, at 10:08 AM, Nathan Ward wrote:
On 16/03/2010, at 2:10 AM, Adcock, Matt [HISNA] wrote:
I've used a Jimmy Buffett theme in test labs before.
Naming themes are fine in test labs, because devices have a different function/role several times per day, a name acts like an asset tag in that it sticks with it through its lifetime.
Same goes for those servers that sit in our networks that I can only really think to call "bitch boxes". They do all sorts of random one-off network hackery tasks, and never get any love. They're not supposed to scale, they were only supposed to be there for one job 5 years ago and they're still there.
If I've got guys out there rolling out gear according to cookie cutter designs, I don't want them coming up with names and using ex girlfriends or TV shows or whatever. They're going to run out of ideas, and I don't want to have 50 boxes called "rachel" on the network with no idea what they do. That sort of thing works fine when you're the only person putting the names in to boxes - like in a lab - but no good if you've grown much.
I'm a contractor/consultant type thing, and getting my customers to use naming schemes like the rant that follows helps me understand their network if they do things without me, and helps anyone else who comes along too.
So, for production network and server gear, I like domain names built with city and site codes: site.city.domain
Perhaps if I had a bigger network I'd have .country.domain on the end of that instead.
Hosts within each site are told to search within their site, then city, then domain. Here's how in resolv.conf: search site.city.domain, city.domain, domain
This lets me refer to a host called 'access-1' as, access-1, or access-1.site, or access-1.site.city depending on where I am. That's handy and saves my lazy ass typing lots. It also means we can have standard configs for lots of things. For example, we can syslog to "syslog" and it will choose either the one in the local site if its size warrants it, or one in the city, or a network-wide one. I'm sure you can think of other ways this can be useful.
It can be annoying when a box doesn't let you display a full hostname in a prompt, or fudge it and set the "hostname" to "hostname.site.city" because hostnames shouldn't have periods in them. YMMV, etc. The benefits outweigh the negatives for me I think. Things can get a bit hairy when devices identify themselves by their hostnames in some other protocols though. Ignoring that and using DNS is encouraged, etc.
As for hostnames themselves, I have varying ways of doing that, but I never use a naming scheme that won't scale for.. a long time. I always use numbers, but never use leading zeros - ie. access-1, not access-001. It's not hard to sort numerically, come on now. I generally try to use something that describes the devices function. "access-[1-9][0-9]*" = access router. "core-[1-9][0-9]*" = core router. "IP" is implied unless it's something else, ie. "(eth|atm)-access-[1-9][0-9]*" are Ethernet or ATM switches.
For places where I collapse functionality, ie. a small site with collapsed core and access boxes, I call them access, because they are less to move and hence need renaming when core boxes come in the future to support additional access boxes.
Interface addresses in DNS include the interface name and VLAN or some other logical circuit details (PVC, etc.), as is common.
Juniper boxes have re0-hostname.domain and re1-hostname.domain, and also re-hostname.domain if I've got a moving master IP address configured.
That's about all I can think of to write, I hope it's useful to someone, YMMV, etc.
-- Nathan Ward
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul, If my memory serves me correct, Richard presented traceroute presto at nanog47 that covered location identifiers. HTH, regards, /virendra Paul Stewart wrote:
Hi Folks...
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....
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with.
But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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?
Open ended questions obviously - looking for many ideas.
;)
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLm7t7pbZvCIJx1bcRAin3AJ4r69FiLr+qC6KpVn3pfPnuEWRQCgCeMeRU BbhE1ExSlGBTGU/rWk+3pj4= =TeNX -----END PGP SIGNATURE-----
...Types of coffee and donuts Tim -----Original Message----- From: James Bensley [mailto:jwbensley@gmail.com] Sent: Saturday, March 13, 2010 12:27 PM To: NANOG list Subject: Re: Network Naming Conventions On 13 March 2010 16:06, James Jones <james@freedomnet.co.nz> wrote:
On my last network I named all the routers after simpsons characters.
We use ancient Greek gods. -- Regards, James ;)
On 3/13/2010 10:12 AM, Tim Sanderson wrote:
...Types of coffee and donuts
Tim
-----Original Message----- From: James Bensley [mailto:jwbensley@gmail.com] Sent: Saturday, March 13, 2010 12:27 PM To: NANOG list Subject: Re: Network Naming Conventions
On 13 March 2010 16:06, James Jones<james@freedomnet.co.nz> wrote:
On my last network I named all the routers after simpsons characters.
We use ancient Greek gods.
At various times: trees (redwood, spruce, ash) animals indigenous to the area (coyote, eagle, hawk, falcon) wines (pinot, chianiti) area keywords (shaky was a router in an earthquake prone area) colors (red, blue, green) places in star wars (dantooine) I found the wines and star wars stuff too hard to remember how to spell :-)
For end-point hosts ("servers") I prefer terse topical names for single-function machines ("Finance", "Purchasing") and some predictable pattern that ties somehow to the organization for multipurpose machines ("Bluejay", "Parrot"). For network equipment at end points I prefer a string that starts with the machine's function, ends it an interface identifier, with location info in the middle. ("rtr-oma-hosp-3rd-peds", "rtr-oma-hosp-3rd-surg"). For network out in the middle I would do the same except expand the location data a bit and change the I/F infor to a hardware descriptive. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
i believe in keeping host names as short as possible, so to start, i wouldn't put the location in the hostname, but putting the loc/pop code in dns (eg: sjc1.nexicom, tor1.nexicom, iad1.nexicom, etc), same goes for rtr, you really dont need that, imo personally, i prefer the shortest possible name cr - core router csw - core switch br/tr/pr - border/transit/peer router and prepending the interface id eg: cr1.tor1.nexciom.net ge-1-1-1.cr1.tor1.nexicom.net of if your want to have full role name ge-1-1-1.core1.tor1.nexicom.net te-1-0-0.border1.tor1.nexciom.net -ck On Sat, Mar 13, 2010 at 8:21 AM, virendra rode <virendra.rode@gmail.com>wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul,
If my memory serves me correct, Richard presented traceroute presto at nanog47 that covered location identifiers.
HTH,
regards, /virendra
Paul Stewart wrote:
Hi Folks...
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....
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with.
But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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?
Open ended questions obviously - looking for many ideas.
;)
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to
which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFLm7t7pbZvCIJx1bcRAin3AJ4r69FiLr+qC6KpVn3pfPnuEWRQCgCeMeRU BbhE1ExSlGBTGU/rWk+3pj4= =TeNX -----END PGP SIGNATURE-----
On March 13, 2010 at 10:53 ck@sandcastl.es (ck) wrote:
i believe in keeping host names as short as possible, so to start, i
At BU we brought down about 1/3 of the internet (no joke!) around 1985 when our very first host table entries to SRI-NIC contained single letter hosts (like a.bu.edu) and names starting with a digit (I remember 3b.bu.edu) which put the HOSTS table to /etc/hosts converter into an infinite loop filling up BSD root disks which back then would invariably hang/crash the OS (No space in /tmp No space in /tmp No space in /tmp No space in /tmp....) I think there's a write-up by me in an old RISKS digest from the time and it was quite a flap on the TCP-IP list ("BU Joins The Internet!") Completely inadvertent but it was probably as disruptive, relatively, as the Morris worm. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Just wanted to say thanks to everyone who responded - game me more to think about than I thought was possible ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
I agree - this convention is easy to type/understand/automate. Makes it easy to AXFR and see which devices are in a pop. We throw a bit of Perl at our device configs to create RR's for each device (imagine doing it manually... blergh). KISS :) -- Tom On 14/03/2010, at 5:23 AM, ck wrote: i believe in keeping host names as short as possible, so to start, i wouldn't put the location in the hostname, but putting the loc/pop code in dns (eg: sjc1.nexicom, tor1.nexicom, iad1.nexicom, etc), same goes for rtr, you really dont need that, imo personally, i prefer the shortest possible name cr - core router csw - core switch br/tr/pr - border/transit/peer router and prepending the interface id eg: cr1.tor1.nexciom.net<http://cr1.tor1.nexciom.net> ge-1-1-1.cr1.tor1.nexicom.net of if your want to have full role name ge-1-1-1.core1.tor1.nexicom.net te-1-0-0.border1.tor1.nexciom.net -ck On Sat, Mar 13, 2010 at 8:21 AM, virendra rode <virendra.rode@gmail.com>wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul, If my memory serves me correct, Richard presented traceroute presto at nanog47 that covered location identifiers. HTH, regards, /virendra Paul Stewart wrote: Hi Folks... 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.... Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with. But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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? Open ended questions obviously - looking for many ideas. ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFLm7t7pbZvCIJx1bcRAin3AJ4r69FiLr+qC6KpVn3pfPnuEWRQCgCeMeRU BbhE1ExSlGBTGU/rWk+3pj4= =TeNX -----END PGP SIGNATURE----- -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net<http://www.internode.on.net/>
Hey Paul,
Core1-rtr-to-ge1-1-1-vl20.nexicom.net
Core box #1, rtr=router, to=location, ge1-1-1=interface, vl20=vlan etc etc....
That's disturbingly similar to ours :) tflns2-ge0-1-vl1.caneris.com TF = Toronto/Front LNS #2 = LNS #2 ge0-1 = interface vl1 = VLAN 1
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods?
One of my colleagues has written an overview and pros/cons of the most common naming conventions (purpose, geographic, purpose+geographic, and "themes") at http://www.watson-wilson.ca/blog/name-conv.html. He's a systems guy, so it's not written in the context of net ops, but some of the ideas are common.
But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices etc?
See my example at the top.
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?
Currently similarly to this: MANAGED-DSL-1xxxx, where the 1xxxx is the account number. At the time it was decided to use this for no other reason than when a box/link goes down, it's trivial to find the customer/contacts in the OSS since the device name in the monitoring alert already has an account number embedded in it. Silly reason perhaps, but it's simple and it works.
Open ended questions obviously - looking for many ideas.
There are many ways of doing it and many factors to consider, I'll just throw some food for thought: -Purpose / device type -Geography -Hierarchical naming -Scalability of the naming system -DNS -Humans - who's using the names and how? Reading/writing - how/frequency? What information do you want to convey (for obvious reason, this may vary greatly depending both on the target and the device)? -Systems - what else is using your names or may be using your names in future? OSS/provisioning/monitoring/graphs for interfaces - automated? Limitations on character set and length of name, e.g. DNS, stupid switches with absurdly short max lengths of port description fields, etc. A regexp can come in handy to define this (and perhaps your entire naming scheme) precisely. In a heterogeneous environment, you have all sorts of stuff where you may have two or more names to refer to the same thing. -Prefixes/suffixes -Mergers and acquisitions - what happens when you have to merge your network with someone else's? Though I can see the value of prefixing, I don't like naming conventions which prefix everything with an abbreviation of the company for two reasons: -Typing extra keystrokes repeatedly every day for no reason isn't fun -Sorting/lists don't work nicely, especially when you would otherwise use a key to go down to the first letter of a name -Traceroutes: I recall reading the slides from a NANOG presentation (unfortunately I don't recall the author's name and don't have a link now) which discussed naming devices in a traceroute-friendly way (friendly as in meaningful to those outside the org as well); you might want to find this. -Finally, look at how others do it - there are plenty of examples Erik ________________________________________ From: Paul Stewart [pstewart@nexicomgroup.net] Sent: Saturday, March 13, 2010 10:47 AM To: NANOG list Subject: Network Naming Conventions Hi Folks... 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.... Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with. But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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? Open ended questions obviously - looking for many ideas. ;) Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
islands rivers/creeks types of swords fruit minerals fermented things 3char strings punctuation marks twins ... --bill On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote:
Hi Folks...
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....
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with.
But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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?
Open ended questions obviously - looking for many ideas.
;)
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Heh. Host naming discussions is like religion and politics at parties. It only leads to someone going home crying, red wine spilled all over their new dress, and a black eye. Not in that order. -r On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote:
Hi Folks...
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....
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with.
But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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?
Open ended questions obviously - looking for many ideas.
;)
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Yeah, just learning that... got a *tonne* of offline replies. Planets won't work well, simpson characters we'll run out very quickly.... umm.. forgot the rest. We were looking for something that makes sense to the function of the box itself and scales up (as per some other folks point).... Some of the suggestions around kinda what we have today but with some changes are what'll we'll debate internally. Take care, Paul -----Original Message----- From: Ravi Pina [mailto:ravi@cow.org] Sent: March-13-10 2:01 PM To: Paul Stewart Cc: NANOG list Subject: Re: Network Naming Conventions Heh. Host naming discussions is like religion and politics at parties. It only leads to someone going home crying, red wine spilled all over their new dress, and a black eye. Not in that order. -r On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote:
Hi Folks...
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....
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods? The core of the network is fairly easy for us to look at different changes where you have interfaces, subinterfaces, locations etc. to deal with.
But what do folks do for "aggregation devices" such as dial-up shelves, BAS devices 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?
Open ended questions obviously - looking for many ideas.
;)
Paul
------------------------------------------------------------------------ ----
"The information transmitted is intended only for the person or entity
to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On Sat, Mar 13, 2010 at 6:01 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Yeah, just learning that... got a *tonne* of offline replies.
Planets won't work well, simpson characters we'll run out very quickly.... umm.. forgot the rest. We were looking for something that makes sense to the function of the box itself and scales up (as per some other folks point)....
With 726 episodes in 30 TV seasons and 11 feature films, it's very difficult to run out of Star Trek characters. Not main characters, though. Rubens
On Sat, Mar 13, 2010 at 6:01 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Yeah, just learning that... got a *tonne* of offline replies.
Planets won't work well, simpson characters we'll run out very quickly.... umm.. forgot the rest. We were looking for something that makes sense to the function of the box itself and scales up (as per some other folks point)....
With 726 episodes in 30 TV seasons and 11 feature films, it's very difficult to run out of Star Trek characters. Not main characters, though.
Not to mention all the books, etc. Really, it's not hard to find precompiled lists of this sort of stuff. One could start at someplace like http://starwars.wikia.com/wiki/Coruscant for Star WARS (not Trek) stuff and probably scale up to a very large size with all the names, places, planets, etc. In the old days (pre-Web), it was actually a lot harder to come up with a comprehensive naming scheme. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
I have yet to see a core router named "Luke" or "Bart"... ;) -----Original Message----- From: Joe Greco [mailto:jgreco@ns.sol.net] Sent: March-14-10 11:11 PM To: Rubens Kuhl Cc: Paul Stewart; NANOG list Subject: Re: Network Naming Conventions
On Sat, Mar 13, 2010 at 6:01 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Yeah, just learning that... got a *tonne* of offline replies.
Planets won't work well, simpson characters we'll run out very quickly.... umm.. forgot the rest. We were looking for something that makes sense to the function of the box itself and scales up (as per some other folks point)....
With 726 episodes in 30 TV seasons and 11 feature films, it's very difficult to run out of Star Trek characters. Not main characters, though.
Not to mention all the books, etc. Really, it's not hard to find precompiled lists of this sort of stuff. One could start at someplace like http://starwars.wikia.com/wiki/Coruscant for Star WARS (not Trek) stuff and probably scale up to a very large size with all the names, places, planets, etc. In the old days (pre-Web), it was actually a lot harder to come up with a comprehensive naming scheme. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
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
On 3/13/2010 10:47, Paul Stewart wrote:
Hi Folks...
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.
I favor using CLLI code (well fake ones) TAMQFLTART1 is in the city of tampa (TAMQ) in FLorida at building TA, and RT1 is the first router there. This is nice as we know the location of the router, and building it's in from the host name. The host name is always 11 characters long, making it easy to filter/work with in logs. Now I alias the name in DNS so we can type "telnet tampa" and it will just be a CNAME pointing to TAMQFLTART1.keekles.org which is the loopback address. Interfaces are in DNS as well, and I make use of TXT records to store info on the hosts (mostly a contact number and a url to an internal wiki.) Below is an exerpt from a network policy I wrote about this: All network elements shall be named following CLLI code format. In most cases they will not be registered CLLI codes in CLONES. The format of a CLLI code is as follows CCCCSSTTEEE, i.e LTRKARHQR01 C – city location S – State postal code T – Street or differentiator E – Equipment Identifier In the event the equipment is being installed at a site with a registered CLLI site code (first 8 characters) this shall be used as the prefix. If not a company unique code will be used for the site CLLI. The equipment shall be identified using the following codes: RT[0-9] – router number n, with n starting at 0. If more than 10 routers at a site, the code will change to RU[0-9], then RV[0-9], and so on. SW[0-9] – Switch starting at 0 following the same progression as the router. P[00-99] – Servers at a location M[00-99] – Mux at a location R[00-99] – Radios TS[00-99] – terminal server (serial or other) VP[0-9] – VPN router or security appliance FW[0-9] – Firewall or packet filter I also tend to add funny names as CNAMES that are not published. Got to have some as the network designer after all ;-) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net
In a message written on Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote:
Open ended questions obviously - looking for many ideas.
I think a key question to ask yourself is who needs to be able to interpret your names? Depending on your business, customers, engineers, etc you may have a good reason to use obscure names, for instance not making it easy for people to know the speed of interfaces, where your routers are located, how many routers you have, what brand routers you use, and so on. In other cases, you would like as much of that as possible to be something that someone can guess. For instance, many ISPs use city names or airport codes. This can help your customers decide if the latency numbers are reasonable or not. Lots of ISPs also include interface information, often so an engineer can log in and do a "show int xyz" based on a traceroute with no intermediate steps to look up which interface the IP is on and such. Lastly, "traceroute www.<foo>.com" for a pile of web sites will give you all sorts of schemes in no time. There is no "right answer" in the generic, but there is a right answer for you. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Sat, Mar 13, 2010 at 10:47:28AM -0500, Paul Stewart wrote:
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods?
Looked through the thread figuring someone else would have mentioned this one, but (unless I missed it), they didn't. So sorry if you've seen this already, but I think this presentation is a really good take on the subject. http://www.nanog.org/meetings/nanog31/abstracts.php?pt=NjExJm5hbm9nMzE=&nm=nanog31
Access network primarily CLLI codes of the building where the POP is located or closest serving CO, backbone three letter airport codes and in some cases CLLI codes. During the transition form JvNCNet to VERIO/NTT we had some CNAMES to the old network names where things at for example Philadelphia where named cheesesteake_something, and some other names well known to the community at that time such as tiger.jvnc.net for the dialup access server. Regards Jorge
2010/3/13 Paul Stewart <pstewart@nexicomgroup.net>
Hi Folks...
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....
Hello, On our side we're using things like : xe3-3-0-154.tcr1.th2.par.as8218.eu xe3-3-0 : interface (Juniper behaviour) 154 : vlan (if we use vlans on the interface) tcr1 = first transport core router th2 = datacenter (Telehouse 2, generally 2 to 4 letters at our appreciation) par = city (Paris, using the 3 letters IATA City code, not the Airport code such as CDG for Paris) -- Pierre-Yves Maunier
On Tue, 2010-03-16 at 14:15 +0100, Pierre-Yves Maunier wrote:
par = city (Paris, using the 3 letters IATA City code, not the Airport code such as CDG for Paris)
definitely +1 for IATA city codes. Less problems than the airport ones. ^ ^ ^------------------------------------------ ^ ISTR we've been here ^ before about 6 months ago? If so, apologies. Gord -- "is ncurses what you do if fsck fails?" - anon
For pretty much all hardware we use <city><site><devicetype><devicequalifier><devicenumber> And for routers/switches I add the interface info. e.g: Tracing route to cal1sw-01.nff.local [10.1.9.4] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms con1sw-01-v103.nff.local [10.1.3.2] 2 1 ms <1 ms <1 ms con1rt-01-fe0-0.nff.local [10.1.250.99] 3 4 ms 3 ms 3 ms tor1rt-01-fe0-0s550.nff.local [10.1.254.1] 4 48 ms 48 ms 50 ms cal1rt-01-fe0-1.nff.local [10.1.254.22] 5 56 ms 50 ms 48 ms cal1sw-01.nff.local [10.1.9.4] But this also covers a lot of other stuff. We've got a list of 20 different device types edm1ppc01 - Edmonton 1, page printer, color, unit 1 mtl2rt-02 - Montreal 2, router, unit 2 cal1lp-04 - Calgary 1, line printer 4 con1lt-12 - Concord 1, laptop #12 Everything gets asset tagged and labelled with the ID. Servers are labelled by function (monitor, sql, etc). Thanks, Erik -----Original Message----- From: Pierre-Yves Maunier [mailto:nanog@maunier.org] Sent: Tuesday, March 16, 2010 9:16 AM To: Paul Stewart Cc: NANOG list Subject: Re: Network Naming Conventions 2010/3/13 Paul Stewart <pstewart@nexicomgroup.net>
Hi Folks...
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....
Hello, On our side we're using things like : xe3-3-0-154.tcr1.th2.par.as8218.eu xe3-3-0 : interface (Juniper behaviour) 154 : vlan (if we use vlans on the interface) tcr1 = first transport core router th2 = datacenter (Telehouse 2, generally 2 to 4 letters at our appreciation) par = city (Paris, using the 3 letters IATA City code, not the Airport code such as CDG for Paris) -- Pierre-Yves Maunier
On Sat, 13 Mar 2010 10:47:28 -0500 "Paul Stewart" <pstewart@nexicomgroup.net> wrote:
Going forward, I'd like to examine a better method to identify the devices.... does anyone have published standards on what they use or that of other networks and maybe even why they chose those methods?
Bottom line is there is probably no perfect naming scheme, but some do suck more than others. This came up on another list and resulted in a long thread, where lots of people still prefer cutesy names, but I'd recommend against them. Here is point where I contributed so I don't need to repeat it here. An ISP's naming scheme may differ slightly due to the multitude of interface conventions you might want a name to associate with, but you'll get the gist of my stance. Then browse forward and backward to see what others had to say. <http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind1002&L=SECURITY&T=0&F=&S=&P=49637> John
Sorry for the delay; I've been traveling and neglecting my lists. on Sat, Mar 13, 2010 at 10:47:28AM -0500, 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.
I study PTR naming conventions as part of my Enemieslist project; it turns out that genericity in naming is highly correlated to bot spam, so some folks find my patterns useful to block and/or score inbound mail for risk of being bot-originated. As such, I've written a few rants about /poor/ naming practices that you may find useful and/or amusing, as well as a few pointing out the rare /good/ naming practices. (See below) In a nutshell, it boils down to this: - note static/dynamic hosts in the name, in the furthest-right-hand token possible (dyn.example.net, not dyn-foo-1-2-3-4.ny.ny.example.net). - cute and funny are not useful to others trying to decide whether to block services originating from a host; clarity and forethought and transparency are. - use different conventions for different services, this helps us differentiate dialup from dsl from cable and other infrastructure; don't assume everyone will do a whois lookup to find out this block is all consumer dsl and this other one is fixed business class. - be consistent, for the love of all that is good and holy. I've got over a hundred patterns for vsnl.net.in *alone*. There are a couple of IDs that discuss naming, in the anti-abuse context: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-0... http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Here's what I've had to say on the matter over the years: DHCP doesn't necessarily mean dynamic http://enemieslist.com/news/archives/2009/09/dhcp_doesnt_nec.html annoying-stupidity.volia.net http://enemieslist.com/news/archives/2009/08/annoyingstupidi.html A few thoughts on reverse DNS / PTR naming http://enemieslist.com/news/archives/2009/06/a_few_thoughts_1.html Basic principles of DNS and their discontents http://enemieslist.com/news/archives/2009/06/basic_principle.html http://enemieslist.com/news/archives/2009/06/basic_principle_1.html http://enemieslist.com/news/archives/2009/06/basic_principle_2.html Today's DNS Spotlight: Eircom http://enemieslist.com/news/archives/2009/06/todays_dns_spot.html A couple more: kudos, and mixed kudos/gripe http://enemieslist.com/news/archives/2009/06/a_couple_more_k.html Principles http://enemieslist.com/news/archives/2009/06/principles.html There's a few dozen more in the gripes archive: http://enemieslist.com/news/archives/gripes/ HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
participants (29)
-
Adcock, Matt [HISNA] -
Barry Shein -
bmanning＠vacation.karoshi.com -
Bryan Fields -
ck -
Erik L -
Erik Soosalu -
gordon b slater -
Greg Whynott -
James Bensley -
James Jones -
Joe Greco -
John Kristoff -
Jorge Amodio -
Justin M. Streiner -
Larry Sheldon -
Leo Bicknell -
Nathan Ward -
Paul Stewart -
Pierre-Yves Maunier -
Randy Bush -
Ravi Pina -
Roy -
Rubens Kuhl -
Steven Champeon -
Tim Sanderson -
Tom Wright -
virendra rode -
William Yardley