Patch Cable and Port Asset Management
Completed
My request is relatively simple in concept. I'm not too sure how difficult it would be to implement, although it appears that some of the basic structures are in place with the coming Asset and Inventory Management addition. What I would like to see is the ability to inventory and manage both patch cabling and patch ports found in wiring closets. To clarify, in this scenario a patch cable is typically an ethernet cable and the patch panel is a RJ-45 port that feeds to something like a network drop in someone's office. In moderate to larger environments, best practices suggest to label these cables, as when you begin to work in installations with densities in the 100+ cables, it becomes quite difficult to trace a cable between your switch and the patch panel port it is attached to. Many use some form of printed label attached to either side of the ethernet cable to track the switch port <-> ethernet cable <-> patch port relationship. I personally haven't found a good application to assist in tracking this info, short of manually placing it into a spreadsheet or wiki somewhere.
To me, this looks like a natural extension for D42, where you could add a patch cable and patch panel item type, along with a way to express their relationship to the switch ports that are already tracked in D42. Further, and this is stretching a bit, by extending the QR code generation functionality that D42 is soon to have to print labels for these cables, you could perhaps utilize some form of mobile application to assist in managing this inventory remotely. This would be quite awesome if implemented, and would provide functionality to the D42 product that I do not see anywhere else.
What do you think?
-
Josh,
Patch panel management is a great point and is on our long term road-map. And you are right regarding the basic structure being in place with addition of non-IP based assets in the upcoming asset and inventory management module.
QR codes for this is also a really cool idea and would save lot of time working with cables if implemented correctly.
This is still down the road feature and might take a while before we get there, but one thing that would be up for discussion and user input, would be the flow of port to end point connectivity and ideas around the best possible representation.
I will start. Few possible scenarios that come to mind immediately:
Switch Port -> Patch Panel -> Additonal Patch Panels, if any -> Desk Location -> Device(PC)
Switch Port -> Patch Panel -> Additonal Patch Panels, if any -> Patch Panel -> Device(Server)
Switch Port -> Device
Then, there is cable color management as some companies use it religiously for different data types.(e.g. iLOM vs. network vs. KVM)
Other point would be cable types: cat5e, cat6 etc. and possibly tracking fiber cables as well.
Thank you for bringing this up.
Regards,
Raj.0 -
Hi Raj, that feature would definitely serve us as well :)
0 -
Agreed. This feature although I'm sure it will be difficult to implement, it will help a lot. I suggested something similar last year so hopefully we will see it soon.
Additional to what you are requesting, I was also asking for a way to document the fiber patches in my Fiber enclosures and also patch panels.
Raj, keep us posted on when you plan on looking into this. I'm currently doing this with a Spreadsheet (which I hate) and I do use color coded cables. My flow goes something like this:
Switch Port (or end device) -> Patch Panel/Drop ID -> Patch Panel/Drop ID (If any additional ones) -> Switch Port (or end device)
So for example:
switch1 gi1/24 -> 1.WC1 PP-A/A24 -> server 1 eth0
0 -
Hi,
Thanks for the thoughts and based on interest we are bumping this up on our priority list. I would post back once some dates around this become available.
Regards,
Raj.
0 -
Our first attempt at patch cable management is available in v4.0.0 Beta as discussed in the patch management blog post: http://blog.device42.com/2012/12/patch-cable-management-with-v4-0-0-beta/
Please comment and/or send us a note(support@device42.com) if you would like to participate in the beta.
Regards,
Raj Jalan.
0 -
Hi Raj,
The patch panel feature is a great start but as it stands is a LOT of work for a datacenter of any size. I've got some suggestions for improvements. Sorry if this is overlapping any other posts or roadmap announcements you've already made.
- Model ports/interfaces and switch templates at the hardware level. We have lots of identical servers and switches so it makes more sense to me to specify their ports there rather than on an individual device level. Same goes for the "is it a switch" flag
- Consolidate the "Patch panel ports" and "Device direct connection" sections on the device to just "Patching". In this section have an optional interface field with a drop down of the interfaces specified at the hardware level for that device (including the switch ports from the template if it's a switch)
- Continue to allow arbitrary patching from a device just based on a label rather than a pre-defined interface
- Introduce a patching import for importing a spreadsheet of patching definitions between devices, switches and patch panels. E.g. Device 1 name, Device 1 interface, Device 2 name, Device 2 Interface, Type (optional), Colour (optional)
- Extend the patch panel layout view to include patching to switches - perhaps with a filter on the right so you can look at one or the other. Allow click-through to another rack view if a patch goes directly between racks (yes we know we shouldn't but I've yet to see a DC where there aren't a few!)
- Introduce a graphical patching tool based on the rack layout diagram - once you've got your devices configured into racks you could add patching with a few clicks, kind of mimicking what you are physically doing in the rack:
- pick a patch type from your pre-defined list (e.g. Cat6 STP)
- pick a colour
- click on a device/patch-panel/switch, get a pop-up of its ports, click a port
- click another device/switch/patch-panel, get a pop-up of its ports and click one to make the patch
Hugh
0 -
Hugh,
Most of these are good points and we will look into these further.
#1 and #4 can be achieved using the API calls. Not sure if you have seen the API import helper, but with this python script, you can import almost any data via CSV files in device42. Here is the github page for the repo: https://github.com/device42/API_Helpers
Main reason #1 is not associated with hardware model but with device is that, device can be discovered from multitude of tools and hardware models can be changed. And we don't want to trigger any port creations based on that. So it is easier to assign templates to a device. And once you define the template, you can quickly apply to multiple devices with this API call: http://docs.device42.com/apis/switchswitch-ports-addition-using-switch-templates-api/
For point #4, you can start by configuring back connections in bulk from Tools > Templates > Panel Back Connectivity. Once that is configured, you can use the API call to add device/switch port to the patch panel ports. Again, this would be easier with creating a CSV file and importing it via the script mentioned above. It is on our list to improve the call to accept switch and switch port name in addition to switch port id.
Let me know if that makes sense.
Thanks,
Raj.
0 -
Hi Raj,
Thanks for the feedback. That goes part way to helping but still leaves D42 unsuitable for modelling patching for us. I hadn't looked at the API before and can see how it can be used - but scripting API calls to get around shortcomings in the GUI isn't a road I'd want to go down as the staff who need to maintain our inventory aren't developers. So here's where we get to:
- I can add the panel back-connectivity OK. An import would be handy but it didn't take too long to add them in manually.
- I can use switch port templates to add ports to switches OK
- How about adding a column to the device import so you can specify a switch template if the switch flag is set?
- As far as I can see the only way I can model interfaces on a device is by adding MAC addresses. I have no need to model actual MAC addresses (and it would take a fair amount of work) so I would be adding MAC addresses set to 00:00:00:00:00:00 just so that I can add an interface name and model its patching. This may not be too bad for direct switch port connections but it doesn't help if that patching is physically hooked up via patch panels.
- I think it would be better to separate out MAC addresses which are a layer 2 concept from interfaces/ports/patching at layer 1. A device's MAC addresses could then link to it's NIC ports and the NIC ports link via patching to switch ports and there would be no direct link between a device's MAC address and a switch port.
- How about you have NIC port templates that can be assigned to non-network-switch devices in a similar vein to switch port templates?
- I guess it boils down to this - until there's a way to bulk-add physical patching from a device to a switch port or patch panel port via a GUI-based import, I don't think we'll be able to use D42 for modelling patching - which is a real pity given how close it is.
Hugh
0 -
Hugh,
Absolutey agree about a simple import vs. using APIs. That is why in v5.2.0 we will have an API excel import section, where you will be able to import an excel sheet for any API call right in d42 GUI. We will provide samples/examples for each API call.
This will make it simple to do back-connectivity, switch templates and patch panel port level connectivity(in bulk) via excel imports.
For MAC addresses, it is not a requirement.
You can connect a device to a patch panel and use object labels to identify the port name(MAC address doesn't have to be entered). And then other side of the patch panel connection can be connected to a switch port.
If the device is connected to a switch without a patch panel, you can use switchport direct device connectivity to reflect that.I will update this topic once v5.2.0 is released.
Thanks,
Raj.0 -
Starting with v5.2.0, we have added a generic API excel import option. With this you can import any data using the GUI, that can be imported via the APIs.
You can create excel sheets with patch panel connectivity and simply import these now. We have added a complete example in the docs on how to do this. Please follow this doc and comment here if any questions:
Creating patch panels from scratch in device42
Regards,
Raj.
0
Please sign in to leave a comment.
Comments
10 comments