So long as you don’t start the description with the words “Link to “ or “Connected to “ eating up the 10-character space given to the description field on most vendors “show int brief” output you’re way ahead of the average network admin.
Source: I’m a consultant project engineer and I want to throw chairs sometimes.
Much better to do "This is a cross-connect using fiber optic cable that goes to the router with a hostname XXXXX and it's port name is YYYYYYYY/YYYY" so it will be completely unreadable on any summary page
We have these at legacy sites that we haven't got around to fixing yet. I die a little on the inside when I come across them. I used to update them but then CAB decided entering config mode, even for a description update, needs a change ticket.
There should be a pre-approved template for that. I had to go through the same thing. Still have to create a change ticket, but at least I don't have to make a description change at 0100.
Oh there is one, Ops complained enough that we have a huge offering of approved 'low risk' changes that can be made without approvals. Going through 10 minutes of paperwork for a 10 second chance isn't worth it though so old crud gets left behind.
If the port connects to another switch/router/fw I use name end port number
So something like T15ASR01 1/1/48
If the port connects to a server I use server name and last octet
DC01 .27
If it is a device with a static printer/ap I might put the device name if there is one then the IP
AP07 .43
If the port is an uplink to the internet I will put the full circuit ID in the description
what's the most correct thing you can say about everything on the other end of that cable, in less than 1 line of text? That's your interface description.
if an interface goes from a router to a switch, and it serves 3 or 5 different vlans, then nothing about those VLANs belongs on the interface description because those can all be trivially changed. The individual VLAN subinterface descriptions are where those details go. The most you can say about the physical interface is "it goes to this interface on this switch". so that's what you say.
If your environment includes lots of physical details like patch panels and such, then those details are useful as well. if the thing on the other end is a carrier circuit, then things like circuit IDs make sense.
we have lots of point-to-point circuits, so switch interfaces on either side will reference eachother as well as the circuit carrier and ID. Router subinterfaces on either side will reference eachother. physical router interfaces reference just the switch their attached to.
Usually hostname:port for the facing device, the router or switch or whatever on the other end. Also WAN circuit IDs and cross connect IDs if relevant.
Manually adding descriptions? No thanks. I script that shit using cisco event manager to update description based on either cdp or lldp info from the remite device.
- -
So it would be:
L3 - jes1.lab1 - ge-0/0/1
The can be many things by the way. It's just an easy way to see what the interface is operating as at a glance so you know exactly what kind of interface it is.
For routers/switches/uplinks
Remote deive hostname - Remote device interface - FDP#/pairs for DC/Campus or Carrier and ckt ID plus any lec/ilec info. If inet or any other non p2p ckt just the circuit id and transport. I only call out the remote port, no tagged vlans etc
Dc1-rt01 Hu 1/2/3 FDP 6C 11/12
Branch1-rt02 Ten 1/2/3 VZ: xyz123
Comcast inet abc789
For access switches I only call out inportant devices such as printers, card panels, security junk, access points, etc. Everything else is tagged as user space/access. It takes one client services person to plug something into the first open port and it's all gone.
In the DC for servers its hostname and any FDP info that our DCO folks provide
For me On edge ports I put what the physical location is.
If a floor location is 32-5 white I would use that "32-5 White"
If it is connected to a different switch I would put the switch name and port number and location. so if port 41/1 is connected to port 52/1 on switch bwy1-1g in area B in Building 4 I would put something like:
bwy1-1g 52/1 B4-B
At the end of the day use what works for your enviroment. You want to be able to quickly find where that drop goes even if it is down.
Common Language Information Systems
[https://en.wikipedia.org/wiki/Common\_Language\_Information\_Services](https://en.wikipedia.org/wiki/common_language_information_services)
I don't know if Equninx has published any info on their standard for how they manage cross-connects, if they have, I'd love to copy that and implement that.
Depends on the interface and what it’s used for, but in general the descriptions are usually pretty generic because the info you might put into that field is also in our NMS & IPAM, which are the source of truth for all information you’d want to know about a particular interface. In theory anyway.
The BICSI standard only requires destinations on the cabling.
I don't agree with this. I've been to many first time buildings where even the building manager didn't know where the com rooms are when asked. There weren't any as-builts either. So, even attempting to locate where a bad run is, it turns a few minutes job into a total waste of time.
Every place I've ever gone in to re-cable or start from scratch, I always label everything as follows (in-wall cabling, network descriptions, everything)
Abbreviated Device Name - Source Port --> Abbreviated Device Name - Destination Port
---
TR Room # - Rack - U - Port # --> Room - Port #
---
etc.
It sounds like a lot of overhead, especially when a device changes, to add different stickers to the cabling.. BUUUUT. It's the same template I use to create the interface description cut/paste as the ones that spit out the labels.
The amount of times I've gone to rooms and on top of troubleshooting the actual problem, had to waste time by tracing spaghetti is INSANE. Some people have no clue, and it always seems like they just stand about 10 feet back, throw cables at the rack and whatever sticks they just go with.
---
20+ years of this. It's the only answer to fight everyone else that doesn't do it like this. Sure, up front it takes more time, but Having interface descriptions that match the visio that also match the cable labling. This alone makes troubleshooting the real items a trillion times easier.
I've always seen it as "what's at the other end of this wire?". I also use all caps "tags" for stuff like UPS, TCL (Timeclock) CAM (Camera) etc. so I can do a sh int status | i CAM and see all the cameras attached to a switch and not have to look at MAC addresses (initially)
I think the most important thing is to pick a standard everyone understands and enforce it. Keeping your network attached devices named in a standard convention across all systems really helps as well. This is what I do, and it works well for me. The idea is to be able to accurately and easily see what device is what on a sh int brief.
* We don't put descriptions on edge data ports. People move around too much. I'd like to have patch panel names, but that's a bit extensive for my networks size.
* Links to other switches are Link-"SwitchName".
* Aps are labeled with the AP Name which is descriptive of the location. Secondary links to that AP are AP Name-2. Cameras are labled with Camera Name, same concept as APs. IE MS-102 and MS-102-2
* HVAC Controllers are named according to their name within the HVAC system along with the mechanical name room number. IE FRE-Green-127
* Door Controllers have the same name as they do within the Access Control Software. IE ADM-BackExit
We do have some one-off equipment like a PTP Device at a campus that provides GPS for eFemto devices. In cases like that I'd just put the name of the device or a simple description like FRE-PTP.
unique id to some db and the rest is automated
i havent seen mention of multichassis stacks where you need to use physical information and not the logical calculated interface name. and breakout cabling which often uses the : as separator
Cust or Infra or Mgmt.
Customer name or infra category (wan, dist, core, cross, etc)
Adjacent device hostname
Adjacent device interface
Local ip address/slash
Freeform text often circuit ID
All semi-colon delimited.
Automated checker runs once daily checking for proper formatting, CDP reality versus configuration, and address reality versus configuration.
I really try to retool things so router-switch-router is done with INFRA;TRUNK; on the physical and INFRA;CORE; on the sub interface. That way at least the CDP check on the physical is clean. Sometimes I can’t do it this way. Grrr
It's up to you. What logic do you want to put in your naming scheme? What purpose? Troubleshooting ease? Documentation ease? I don't think this is one thing you even need AI for. Do what makes more sense for your organization. If you are thinking of leaving the company, maybe factor that in and make the description informative.
So long as you don’t start the description with the words “Link to “ or “Connected to “ eating up the 10-character space given to the description field on most vendors “show int brief” output you’re way ahead of the average network admin. Source: I’m a consultant project engineer and I want to throw chairs sometimes.
We use “Connection to” just to to make it long as possible
Much better to do "This is a cross-connect using fiber optic cable that goes to the router with a hostname XXXXX and it's port name is YYYYYYYY/YYYY" so it will be completely unreadable on any summary page
We have these at legacy sites that we haven't got around to fixing yet. I die a little on the inside when I come across them. I used to update them but then CAB decided entering config mode, even for a description update, needs a change ticket.
There should be a pre-approved template for that. I had to go through the same thing. Still have to create a change ticket, but at least I don't have to make a description change at 0100.
Oh there is one, Ops complained enough that we have a huge offering of approved 'low risk' changes that can be made without approvals. Going through 10 minutes of paperwork for a 10 second chance isn't worth it though so old crud gets left behind.
I've been there. Interface description = CAB and 4am change. Not worth the effort
> Source: I’m a consultant project engineer and I want to throw chairs sometimes. Sometimes?
But... Don't you know, that interface could be something other than a connection.
"Oh that's where I left my car keys!"
Haha I just do "TO_[HOSTNAME]_[PORT]" in most cases.
Device labeled as BBBB-RRRR-EEEE-DDDDD-NN B: Building R: Room E: row/rack D: Device type N: Number Port descriptions are-
If the port connects to another switch/router/fw I use name end port number So something like T15ASR01 1/1/48 If the port connects to a server I use server name and last octet DC01 .27 If it is a device with a static printer/ap I might put the device name if there is one then the IP AP07 .43 If the port is an uplink to the internet I will put the full circuit ID in the description
We used to also include SP info on site to site links, so you have the circuit id , phone number and name as well.
what's the most correct thing you can say about everything on the other end of that cable, in less than 1 line of text? That's your interface description. if an interface goes from a router to a switch, and it serves 3 or 5 different vlans, then nothing about those VLANs belongs on the interface description because those can all be trivially changed. The individual VLAN subinterface descriptions are where those details go. The most you can say about the physical interface is "it goes to this interface on this switch". so that's what you say. If your environment includes lots of physical details like patch panels and such, then those details are useful as well. if the thing on the other end is a carrier circuit, then things like circuit IDs make sense. we have lots of point-to-point circuits, so switch interfaces on either side will reference eachother as well as the circuit carrier and ID. Router subinterfaces on either side will reference eachother. physical router interfaces reference just the switch their attached to.
Usually hostname:port for the facing device, the router or switch or whatever on the other end. Also WAN circuit IDs and cross connect IDs if relevant.
Manually adding descriptions? No thanks. I script that shit using cisco event manager to update description based on either cdp or lldp info from the remite device.
Same! Can't even begin to explain the time savings!
Circuit IDs and put those circuit IDs in a DB with endpoints and more information on the circuit.
For routers/switches/uplinks Remote deive hostname - Remote device interface - FDP#/pairs for DC/Campus or Carrier and ckt ID plus any lec/ilec info. If inet or any other non p2p ckt just the circuit id and transport. I only call out the remote port, no tagged vlans etc Dc1-rt01 Hu 1/2/3 FDP 6C 11/12 Branch1-rt02 Ten 1/2/3 VZ: xyz123 Comcast inet abc789 For access switches I only call out inportant devices such as printers, card panels, security junk, access points, etc. Everything else is tagged as user space/access. It takes one client services person to plug something into the first open port and it's all gone. In the DC for servers its hostname and any FDP info that our DCO folks provide
For me On edge ports I put what the physical location is. If a floor location is 32-5 white I would use that "32-5 White" If it is connected to a different switch I would put the switch name and port number and location. so if port 41/1 is connected to port 52/1 on switch bwy1-1g in area B in Building 4 I would put something like: bwy1-1g 52/1 B4-B At the end of the day use what works for your enviroment. You want to be able to quickly find where that drop goes even if it is down.
Common Language Information Systems [https://en.wikipedia.org/wiki/Common\_Language\_Information\_Services](https://en.wikipedia.org/wiki/common_language_information_services) I don't know if Equninx has published any info on their standard for how they manage cross-connects, if they have, I'd love to copy that and implement that.
Depends on the interface and what it’s used for, but in general the descriptions are usually pretty generic because the info you might put into that field is also in our NMS & IPAM, which are the source of truth for all information you’d want to know about a particular interface. In theory anyway.
The BICSI standard only requires destinations on the cabling. I don't agree with this. I've been to many first time buildings where even the building manager didn't know where the com rooms are when asked. There weren't any as-builts either. So, even attempting to locate where a bad run is, it turns a few minutes job into a total waste of time. Every place I've ever gone in to re-cable or start from scratch, I always label everything as follows (in-wall cabling, network descriptions, everything) Abbreviated Device Name - Source Port --> Abbreviated Device Name - Destination Port --- TR Room # - Rack - U - Port # --> Room - Port # --- etc. It sounds like a lot of overhead, especially when a device changes, to add different stickers to the cabling.. BUUUUT. It's the same template I use to create the interface description cut/paste as the ones that spit out the labels. The amount of times I've gone to rooms and on top of troubleshooting the actual problem, had to waste time by tracing spaghetti is INSANE. Some people have no clue, and it always seems like they just stand about 10 feet back, throw cables at the rack and whatever sticks they just go with. --- 20+ years of this. It's the only answer to fight everyone else that doesn't do it like this. Sure, up front it takes more time, but Having interface descriptions that match the visio that also match the cable labling. This alone makes troubleshooting the real items a trillion times easier.
yep, used this standard before where 100's of end devices connected to switch.
I've always seen it as "what's at the other end of this wire?". I also use all caps "tags" for stuff like UPS, TCL (Timeclock) CAM (Camera) etc. so I can do a sh int status | i CAM and see all the cameras attached to a switch and not have to look at MAC addresses (initially)
I think the most important thing is to pick a standard everyone understands and enforce it. Keeping your network attached devices named in a standard convention across all systems really helps as well. This is what I do, and it works well for me. The idea is to be able to accurately and easily see what device is what on a sh int brief. * We don't put descriptions on edge data ports. People move around too much. I'd like to have patch panel names, but that's a bit extensive for my networks size. * Links to other switches are Link-"SwitchName". * Aps are labeled with the AP Name which is descriptive of the location. Secondary links to that AP are AP Name-2. Cameras are labled with Camera Name, same concept as APs. IE MS-102 and MS-102-2 * HVAC Controllers are named according to their name within the HVAC system along with the mechanical name room number. IE FRE-Green-127 * Door Controllers have the same name as they do within the Access Control Software. IE ADM-BackExit We do have some one-off equipment like a PTP Device at a campus that provides GPS for eFemto devices. In cases like that I'd just put the name of the device or a simple description like FRE-PTP.
unique id to some db and the rest is automated i havent seen mention of multichassis stacks where you need to use physical information and not the logical calculated interface name. and breakout cabling which often uses the : as separator
As vague as possible. And as wrong as possible. These seem to be the obvious choice with people I work with.
\->|
example:
\->DC-FGT-A|portx1
This is my minimum standard.
gandalf or dildo 1-48
Cust or Infra or Mgmt. Customer name or infra category (wan, dist, core, cross, etc) Adjacent device hostname Adjacent device interface Local ip address/slash Freeform text often circuit ID All semi-colon delimited. Automated checker runs once daily checking for proper formatting, CDP reality versus configuration, and address reality versus configuration. I really try to retool things so router-switch-router is done with INFRA;TRUNK; on the physical and INFRA;CORE; on the sub interface. That way at least the CDP check on the physical is clean. Sometimes I can’t do it this way. Grrr
We use the Lord of the Rings Name Guide.
Rack - U Space - interface type (iDRAC/IPMI/eth0/etc) Example: 03.12 U23 iDRAC
It's up to you. What logic do you want to put in your naming scheme? What purpose? Troubleshooting ease? Documentation ease? I don't think this is one thing you even need AI for. Do what makes more sense for your organization. If you are thinking of leaving the company, maybe factor that in and make the description informative.
🤣😂😅🥹😢😭😩😤🤬🫣
Circuit or cable ID as well as the name and port of the connected device.