Patch Panel Spreadsheet Definition
I do a combination of a spreadsheet and a diagram. The diagram is basically a map designed to show the coding/labelling scheme of the patch panels and ports. The Spreadsheet acts as a legend for the map so that it isn't cluttered with connecting lines. A tend to go PP-A-1 or SW-A-1 with PP designating patch panel and SW designating switch, the letter shows the position on the rack in sequence and the number is port number.
You can also save Visio diagrams as JPEGs for portability just keep the original for editing purposes. Hi all; As a phone tech from last century I'd like to give my two cents worth on this. In the good old days we used to provide a double accounting approach, that is, each end point had the other end point noted.
Sticking with the whole telecoms feel a jumper between two pairs would be recorded in two places. For example at the mainframe of a building - the point where the incoming cable from the telephone exchange (Central Office for those in the US) terminates into a building I would have receorded the following: In the mainframe record book I would have the two entries as follows: Main cable Pair - Jumpered to - Riser Pair, and Riser Pair - Jumpered to - Main cable Pair. Each record would be in a different section of the record book as each vertical (whether Krone, or 101 blocks or solder tags) is considered a record space. What I would suggest to you, and I have attached an empty excel spreadsheet for you all to look over, is an excel version of this.
Further I would suggest a naming version similar to: Location1-Location2-HardwareType-Number.PortNumber such that something in building 1, floor 1, on the Coreswitch 0, port 1 would show as: bld1-fl1-csw-0.p1. What you use for your terminology is up to you, but stick with something that anyone using a little bit of common sense, a vizio diagram and your record in excel or whatever, should be able to figure this out. Ideally a master codex that provides the understanding to unlock your hardware or asset naming scheme would be ideal. And I agree with Jen and her P-Touch (or Dymo Lable Maker for that matter) approach. Label everything in your comms rooms. Take a look at the spreadsheet (it is unlocked and open for your use) that is attached and let me know if anything is unclear.
Patch Panel Spreadsheet Definition Free
Hope this helps everyone in the community. I was going to chime in here but everybody beat me to the diagram + spreadsheet approach.
I find that different types of documentation require different formatting or tools. I don't like the maintenance involved in most methods. Too much overhead.
I started decades ago with the idea that everything should be documented in some sort of overarching means and I eventually decided Visio was the answer. Over the years I swung back the other way to just using a composition book per server and then to wanting to web app everything. Most recently my thought were to using a wiki with table capability to handle everything. I still think that that coupled with scriptability and possibly some sort of basic we based diagrammer would be the ideal. That said, racktables looks pretty darn neat.
I am going to go play with that for a while and see how I feel about it. So far everybody is making due with either visio or excel or a combination of the two the only other app should then be racktables but unfortunately this lacks patch panel documentation which was my original question what I was hoping for is a working template in whatever format that gives anybody a clear view of what goes where on any patch panel, be it LAN or phone or fiber. A web service like racktable sounds great, and a motivation to finally do something with my study of asp.net;-) has anybody heard of a paying solution?
Iandrewmartin wrote: Hi all; As a phone tech from last century I'd like to give my two cents worth on this. In the good old days we used to provide a double accounting approach, that is, each end point had the other end point noted.
Sticking with the whole telecoms feel a jumper between two pairs would be recorded in two places. For example at the mainframe of a building - the point where the incoming cable from the telephone exchange (Central Office for those in the US) terminates into a building I would have receorded the following: In the mainframe record book I would have the two entries as follows: Main cable Pair - Jumpered to - Riser Pair, and Riser Pair - Jumpered to - Main cable Pair. Each record would be in a different section of the record book as each vertical (whether Krone, or 101 blocks or solder tags) is considered a record space. What I would suggest to you, and I have attached an empty excel spreadsheet for you all to look over, is an excel version of this. Further I would suggest a naming version similar to: Location1-Location2-HardwareType-Number.PortNumber such that something in building 1, floor 1, on the Coreswitch 0, port 1 would show as: bld1-fl1-csw-0.p1. What you use for your terminology is up to you, but stick with something that anyone using a little bit of common sense, a vizio diagram and your record in excel or whatever, should be able to figure this out. Ideally a master codex that provides the understanding to unlock your hardware or asset naming scheme would be ideal.
And I agree with Jen and her P-Touch (or Dymo Lable Maker for that matter) approach. Label everything in your comms rooms.
Take a look at the spreadsheet (it is unlocked and open for your use) that is attached and let me know if anything is unclear. Hope this helps everyone in the community.
Andrew Dude I know this is an old thread but thanks for the excel sheets. So much cleaner than mine. Hope you don't mind me stealing them there great!
In this post, I will be doing a brief commentary on creating and maintaining a physical port mapping spreadsheet. A port mapping spreadsheet is useful for keeping track of used/available ports on your network equipment, thoroughly documenting to which remote device each port connects, and generating configuration scripts to update port descriptions on the equipment. You can download this article’s template file using the link to the right. What to Document The first question to ask when deciding to create a port mapping is which details should you record. The answer completely depends on your specific environment and what you plan to do with the documentation. Different requirements demand different data to be collected.
I recommend you identify what you would like to do with this documentation before collecting and creating it. All that being said, the template linked to on this post contains a baseline of the most common data points which can provide a solid starting point. Type This field details the layer-1 and layer-2 media and protocols used on the wire.
Layer-1 can be things like RJ45, OM2 (SC), OS1 (LC), etc. Layer-2 can be things like Ethernet, PPP, or God forbid, Frame Relay. Source Device Hostname & Port These fields record the hostname and port information of the source device.
Whenever possible, I will use the port name as it is seen in the configuration terminal of the device.NOTE. In case you are wondering the difference between the source device and the destination device, there really is no difference other than the fact that the focus of the document is always on the source device. In other words, the complete listing of ports for a device can be found in the section of the document where it is focused on as the source. Patch Panel Fabric & Port When there is infrastructure cabling used in-between the source and destination device: it is handy to note down which patch panel and port is used for the connection. The “Fabric” column can be replaced with “Panel Name” or anything else which specifies the infrastructure cabling extension set.
Destination Hostname & Port This field defines the remote (non-focused) device and port where the connection terminates. When the port on the source device is empty and unused, these fields will be blank. Destination Device Notes These fields can be used for notations about the destination device including information about its role, purpose, and if the documented link is in an aggregated group (port-channel). Scripting Columns The scripting columns are used to generate configuration scripts using the information contained in the other columns.
The scripting columns in the template are set up to generate port descriptions for Cisco based switches and will automatically detect when the different “Notes” fields are populated. Documentation Tips Make sure to visit the homepage for this series and review the generic documentation tips listed there which apply to all network-related documents.