jbostoen/iTop-custom-extensions

Patch panels, cables

jbostoen opened this issue ยท 8 comments

Pro
Better documentation

Con
Currently our PC's are linked to switches already. Patch panels would simply add another CI similar to network device, and complicate things. Rather than PC (port 01) <=> network device (port 01/01), we'd have PC (port 01) <=> patch panel (A1) <=> network device (port 01/01).

It doesn't add much information (location can be defined with for example a PC , patch panel is near the network device ).

Also see https://github.com/cwgueco/itop_modules (only works on iTop 2.1.x )

Perhaps a field could be added to links between ConnectableCI and NetworkDevice.

Downside: patch panel won't show up in @Molkobain 's DataCenter View extension; but patch panels are natively not supported anyway. Adding it just as a field for reference is the easiest way.

  • Added this in jb-class-ipdevices --> lnkConnectableCIToConnectableCI

Hello Jeffrey !

I don't know if I may/can comment here, please feel free to let me know if I shouldn't.
While looking on Google for discussion on iTop, racks and patch panels; I stumbled on this thread. So I would like to have your insight on this... ๐Ÿ˜

You seemed to have an attempt to bring patch panels in iTop. Do you think about patch panels, should they be a dedicated class in iTop? I'm not familiar with these IRL, so I can't really say.

I saw as one of the downside of not doing it, that it would not be included in the "Datacenter View" extension. Well, this object could be part of it actually if it's a common thing. ๐Ÿ˜Š

As you can imagine, the idea would be to add patch panels to rack objects in order to document connections between them.

Thanks,
Guillaume

There are 2 ways to look at this: It's not an active device (compared to a switch) and is more like a cable, on the other hand it can have naming and has port numbers.

In my view and opinion, it should be a DatacenterDevice. Then it can benefit from the use of lnkConnectableCIToConnectableCI and port number in the rack and also a port number/name on the wall outlet. It can then also be specified in which rack it is mounted and can then indeed be present in the datacenter view.

I actually saw another implementation of this earlier.

Just like @Hipska mentioned: it's not an "active" device. But most things aren't, and it is a physical thing.

For regular patch cables, I'd say there's no real upside for our (small) organization. We have the actual port on a switch where the client device is connected to. And there's the patch label. It takes less time to check out one or two cables in between if an issue arises than keeping track of everything. I know patch cables often get a number, but then again they could be identified by the two ends of the connection.

I guess it could be interesting at some point if you had much more cables and kept track of replacing the actual cable (rather than document the connection).

The only kind of cable which might be more interesting to document though is an optical cable (fiber). Because then you might want to draw it on a map (geometry extension) and perhaps add documentation. For now I did that in a different software package which is dedicated to GIS data instead, but it could as well be in iTop.

As for Hipska's suggestion on using DatacenterDevice as the parent: it might be a good start. Wondering if there aren't too many fields that aren't needed, but it's probably only the power-related stuff which is the biggest cut to be made (read: make it invisible)

Hello guys,

Thanks for your replies, it gave me some insights on this. I think I'll try to add the patch panel as a new class into the datacenter view in order to document them more easily. Some organizations have many racks / PPs, so it should make sense IMHO.

Have a nice day!
Guillaume

Hello guys,

Thanks for your replies, it gave me some insights on this. I think I'll try to add the patch panel as a new class into the datacenter view in order to document them more easily. Some organizations have many racks / PPs, so it should make sense IMHO.

Have a nice day!
Guillaume

I'm curious about that one. In some way, it's very similar to an (unmanaged) switch. If there's no real point in visualizing each port individually, it looks a lot like an (unmanaged) Network Device.

What about actual cables? Include or exclude? Or document it in the link between devices like we do?

Will you make it a generic thing or will there be a sub class (or perhaps attribute) to specify the type of connections? "RJ45", "Fiber", ...?

Actually the more I think about it, the more I think that for a simple documentation iTop already has what's necessary:

  • Create a new Network Device Type called "Patch panel"
  • Add rack devices in the "Devices" tab with a "down link" connection. You can even set the port number
  • Add connections to other rack patch panels in the "Devices" tab with an "up link" connection and you are good to go.

Creating a specific class would be great to add some attributes like:

  • Number of ports
  • Numbering start location (top-left, top-right, ...)
  • Numbering direction (left-right, top-bottom, ...)
  • Consistency checks to ensure that a port is not used twice
  • And more over have a graphical view of the cable connections between all the devices

But that would be a big feature to add or a dedicate extension. Not sure that's where I want to go right now. ๐Ÿ˜…

Regarding the type of connections, maybe a new typology for this could be nice? Maybe 1 typology for the port type (RJ45, FC, ...) and 1 typology for the cable type (Cat. 5, Cat. 6, ...)

You could move some of the typology to the link between network devices too ;)