Bulk connect front/rear ports #2348

@jeremystretch commented on GitHub (Feb 13, 2019):

This needs much more detail to be actionable. What is the workflow being proposed? What new views and forms would be introduced?

@jeremystretch commented on GitHub (Feb 13, 2019): This needs much more detail to be actionable. What is the workflow being proposed? What new views and forms would be introduced?

adam commented

@tb-killa commented on GitHub (Feb 14, 2019):

For the sake of simplicity,
in the bulk-mode there should be an option to 1:1 connect all ports of a patch panel to another.
You Start on your Selected Patchpanel and could select on "edit" in the new view your counterpart.
After selecting and proceeding both a connected 1:1.

Maybe some Sort of Extension of "Closes #2854: Enable bulk editing of pass-through ports" ?

Hint: The counterpart should only be selectable if there isn´t a connection available on this device.

@tb-killa commented on GitHub (Feb 14, 2019): For the sake of simplicity, in the bulk-mode there should be an option to 1:1 connect all ports of a patch panel to another. You Start on your Selected Patchpanel and could select on "edit" in the new view your counterpart. After selecting and proceeding both a connected 1:1. Maybe some Sort of Extension of "Closes #2854: Enable bulk editing of pass-through ports" ? Hint: The counterpart should only be selectable if there isn´t a connection available on this device.

adam commented

@candlerb commented on GitHub (Feb 14, 2019):

I support this idea, but add it's not always 1:1, e.g. you may be crossing over pairs.

Simple idea: under "Cable" have a "Bulk add" page.

Device A: ... (select)
Port type A: Rearport (dropdown)
Port range A: PO[1-12]
Device B: ... (select)
Port type B: Rearport (dropdown)
Port range B: PO[2,1,4,3,6,5,8,7,10,9,12,11]
Cable type, length, colour etc (as normal)

You could also do it from the device page: with multiple interfaces to be selected, click a "Bulk connect..." button and it can go to the same page, but pre-populate the device A, port type A and range A - the latter as a simple list e.g. [PO1,PO2,PO3,...]

@candlerb commented on GitHub (Feb 14, 2019): I support this idea, but add it's not always 1:1, e.g. you may be crossing over pairs. Simple idea: under "Cable" have a "Bulk add" page. * Device A: ... (select) * Port type A: Rearport (dropdown) * Port range A: `PO[1-12]` * Device B: ... (select) * Port type B: Rearport (dropdown) * Port range B: `PO[2,1,4,3,6,5,8,7,10,9,12,11]` * Cable type, length, colour etc (as normal) You could also do it from the device page: with multiple interfaces to be selected, click a "Bulk connect..." button and it can go to the same page, but pre-populate the device A, port type A and range A - the latter as a simple list e.g. `[PO1,PO2,PO3,...]`

adam commented

@tb-killa commented on GitHub (Feb 14, 2019):

Yes this is a great solution.
Let's use some regex to build the connections.

I use the term of 1:1 because it's easier to implement.
I think it would be also okay if you get automatic build 1:1 connections and modify them later by hand themselve.

@tb-killa commented on GitHub (Feb 14, 2019): Yes this is a great solution. Let's use some regex to build the connections. I use the term of 1:1 because it's easier to implement. I think it would be also okay if you get automatic build 1:1 connections and modify them later by hand themselve.

adam commented

@candlerb commented on GitHub (Feb 14, 2019):

Interesting, regex matching against the actual interface names on a device is possible.

But I think it would be simpler and less confusing to use the interface name generation patterns that already exist, e.g. when bulking adding interfaces.

In the case of 1:1 it would be the same but simpler than the example I gave.

Port range A: PO[1-12]
Port range B: PO[1-12]

Modifying connections is harder than you think, because there's not a way to swap connections; indeed there's not even a way to change one endpoint of a cable at the moment.

You would have to delete two connections and create two new connections, which is worse than not having bulk upload in the first place.

@candlerb commented on GitHub (Feb 14, 2019): Interesting, regex matching against the *actual* interface names on a device is possible. But I think it would be simpler and less confusing to use the interface name generation patterns that already exist, e.g. when bulking adding interfaces. In the case of 1:1 it would be the same but simpler than the example I gave. * Port range A: `PO[1-12]` * Port range B: `PO[1-12]` Modifying connections is harder than you think, because there's not a way to swap connections; indeed there's not even a way to change one endpoint of a cable at the moment. You would have to delete two connections and create two new connections, which is worse than not having bulk upload in the first place.

adam commented

@tb-killa commented on GitHub (Feb 14, 2019):

Yes your right, I test them...
I agree with to use the interface name generation patterns that already exist.

@tb-killa commented on GitHub (Feb 14, 2019): Yes your right, I test them... I agree with to use the interface name generation patterns that already exist.

adam commented

@deku-m commented on GitHub (Feb 20, 2019):

Sorry for late reaction. Think the above comments already give a good view/idea.
My view was almost the same but didnt included the multiple connections / cross connections from front port to rear. We don`t use that for patchpanels. As they mainly are 1on1 connection.

The most common way in my view for patchpanels to implement this is to link the front / rear panel to the same port numbers. 1/1, 2/2, 3/3. So selecting front ports and match / connect them with the rear.
If you think about it. If you create a front panel also the same rear panel is created with same numbering as front so you can also create it on the back-end then so that they are linked. Then you don`t have to bulk edit the front to rear connections in my opinion.

@deku-m commented on GitHub (Feb 20, 2019): Sorry for late reaction. Think the above comments already give a good view/idea. My view was almost the same but didnt included the multiple connections / cross connections from front port to rear. We don`t use that for patchpanels. As they mainly are 1on1 connection. The most common way in my view for patchpanels to implement this is to link the front / rear panel to the same port numbers. 1/1, 2/2, 3/3. So selecting front ports and match / connect them with the rear. If you think about it. If you create a front panel also the same rear panel is created with same numbering as front so you can also create it on the back-end then so that they are linked. Then you don`t have to bulk edit the front to rear connections in my opinion.

adam commented

@candlerb commented on GitHub (Mar 6, 2019):

If you correctly model the Front to Rear port connections in the Device Type object, then you should get them created automatically whenever you create a Device instance of that type.

Furthermore, it's already possible to create the Front to Rear connections in bulk in the Device Type.

Add Rear Ports, give a range (e.g. R[1-24])
Add Front Ports, give a similar range (e.g. F[1-24]). At the bottom you'll see a list of rear ports, "R1:1" to "R24:1". Select them all (click on first, shift-click on last)

You'll find you have 24 front ports, all linked 1:1 to the 24 rear ports.

Where I would find the real value in bulk-add would be in connecting between two different devices, in particular:

Range of rear ports on device A to range of rear ports on device B
Range of front ports on device A to range of front ports on device B
Range of interfaces on device A to range of front ports on device B

And as described before, I'd like to be able to do this with crossovers rather than just 1:1.

@candlerb commented on GitHub (Mar 6, 2019): If you correctly model the Front to Rear port connections in the Device Type object, then you should get them created automatically whenever you create a Device instance of that type. Furthermore, it's already possible to create the Front to Rear connections in bulk in the Device Type. * Add Rear Ports, give a range (e.g. `R[1-24]`) * Add Front Ports, give a similar range (e.g. `F[1-24]`). At the bottom you'll see a list of rear ports, "R1:1" to "R24:1". Select them all (click on first, shift-click on last) You'll find you have 24 front ports, all linked 1:1 to the 24 rear ports. Where I would find the real value in bulk-add would be in connecting between two *different* devices, in particular: * Range of rear ports on device A to range of rear ports on device B * Range of front ports on device A to range of front ports on device B * Range of interfaces on device A to range of front ports on device B And as described before, I'd like to be able to do this with crossovers rather than just 1:1.

adam commented

@deku-m commented on GitHub (Mar 13, 2019):

@candlerb
It is correct that they are linked in the device type but they arent connected for cabling.
Yes on front ports i see that its a 1on1 relation. But as soon as you check it in the rack its not connected. So its not a fully path with connected device to patchpanel front to back to another device.

@deku-m commented on GitHub (Mar 13, 2019): @candlerb It is correct that they are linked in the device type but they arent connected for cabling. Yes on front ports i see that its a 1on1 relation. But as soon as you check it in the rack its not connected. So its not a fully path with connected device to patchpanel front to back to another device.

adam commented

@candlerb commented on GitHub (Mar 13, 2019):

Sorry, I think I am not understanding something.

You can create a cable between device X to the front port on device Y, and you can create a cable between the rear port on device Y to device Z.

The internal connection from the front port on Y to the rear port of device Y is part of the device itself. Whenever you add a front port to a device, you must associate it with a rear port, and that represents the internal connection.

In the original post you said:

As we created front and rear ports on a patch panel So these ports could match each other to fast connect front to rear in a patch panel.

But it is impossible to create a front port without connecting it to a rear port. Netbox won't let you create an isolated front port.

It could also be great if its possible to bulk connect them to different panel

So that's a separate issue: if I understand, you want to connect rear ports 1-24 on panel X to rear ports 1-24 on panel Y, without creating 24 separate cables.

That's a reasonable request. There are some proposals above for this. The same could also apply to interface-to-interface or interface-to-front port connections. Those are all "cables". But it doesn't apply to front-to-rear port connections within the same device; those are not cables.

@candlerb commented on GitHub (Mar 13, 2019): Sorry, I think I am not understanding something. You can create a cable between device X to the front port on device Y, and you can create a cable between the rear port on device Y to device Z. The internal connection from the front port on Y to the rear port of device Y is part of the device itself. Whenever you add a front port to a device, you *must* associate it with a rear port, and that represents the internal connection. In the original post you said: > As we created front and rear ports on a patch panel So these ports could match each other to fast connect front to rear in a patch panel. But it is impossible to create a front port without connecting it to a rear port. Netbox won't let you create an isolated front port. > It could also be great if its possible to bulk connect them to different panel So that's a separate issue: if I understand, you want to connect rear ports 1-24 on panel X to rear ports 1-24 on panel Y, without creating 24 separate cables. That's a reasonable request. There are some proposals above for this. The same could also apply to interface-to-interface or interface-to-front port connections. Those are all "cables". But it doesn't apply to front-to-rear port connections within the same device; those are *not* cables.

adam commented

@golec83 commented on GitHub (Mar 20, 2019):

Hi,
I would like to add my request to bulk join rear ports between different patch panels. Thanks!

@golec83 commented on GitHub (Mar 20, 2019): Hi, I would like to add my request to bulk join rear ports between different patch panels. Thanks!

adam commented

@rogeriosims commented on GitHub (Apr 16, 2019):

Sorry, I'm new here and in github.

How is the development of this function?

Connect bulk ports between different devices.

Thanks!

@rogeriosims commented on GitHub (Apr 16, 2019): Sorry, I'm new here and in github. How is the development of this function? Connect bulk ports between different devices. Thanks!

adam commented

@tiffanykaczmarek commented on GitHub (May 14, 2019):

Hey there!
I have encountered the same issue, that's why I decided to develop a tool to bulk connect rear ports between different devices on my own. If you'd like, you can take a look at my project and maybe it can help a few of you out there, until netbox implements the feature.
With best regards, Tiffany Kaczmarek

@tiffanykaczmarek commented on GitHub (May 14, 2019): Hey there! I have encountered the same issue, that's why I decided to develop a tool to bulk connect rear ports between different devices on my own. If you'd like, you can take a look at my project and maybe it can help a few of you out there, until netbox implements the feature. With best regards, Tiffany Kaczmarek

adam commented

@lmgonzalezl commented on GitHub (Nov 12, 2019):

Proposed workflow
Visually I see it as follows:

I would keep the current format to select the rear ports but with the option to select both side a and side b and add a pop-up window that allows you to choose cable type, length, color, etc ... this would add it in a table.

Select rear ports on both sides

Pop-up window

Table

What happens if some of the rear ports are already connected, or one panel has more than the other?

As validation is done this will not be a problem because connected ports already are disabled from the selection.

@lmgonzalezl commented on GitHub (Nov 12, 2019): **Proposed workflow** Visually I see it as follows: I would keep the current format to select the rear ports but with the option to select both side a and side b and add a pop-up window that allows you to choose cable type, length, color, etc ... this would add it in a table. **Select rear ports on both sides** ![imagen](https://user-images.githubusercontent.com/51785108/68421585-d3514280-019e-11ea-824c-47ea701f448e.png) **Pop-up window** ![imagen](https://user-images.githubusercontent.com/51785108/68421750-1f9c8280-019f-11ea-8ff1-298042404940.png) **Table** ![imagen](https://user-images.githubusercontent.com/51785108/68421769-2aefae00-019f-11ea-860a-3cf2761143d4.png) **What happens if some of the rear ports are already connected, or one panel has more than the other?** As validation is done this will not be a problem because connected ports already are disabled from the selection.

adam commented

@m384wwn commented on GitHub (Jun 27, 2020):

Mapping the front to back or back to front descriptions would be a huge timesaver. Along with he bulk edit select feature mentioned here https://github.com/netbox-community/netbox/issues/2854#issuecomment-461317108

@m384wwn commented on GitHub (Jun 27, 2020): Mapping the front to back or back to front descriptions would be a huge timesaver. Along with he bulk edit select feature mentioned here https://github.com/netbox-community/netbox/issues/2854#issuecomment-461317108

adam commented

@stale[bot] commented on GitHub (Jan 1, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Jan 1, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@JonathonReinhart commented on GitHub (Jan 3, 2021):

I think the lack of this functionality still represents a large hurdle in modeling large-ish cable plants, often found in an enterprise. Thus, I'd hate to see it closed and lost in the ether. I would be interested in taking a look at implementing this, but I'm not sure yet when I will have the time.

@JonathonReinhart commented on GitHub (Jan 3, 2021): I think the lack of this functionality still represents a large hurdle in modeling large-ish cable plants, often found in an enterprise. Thus, I'd hate to see it closed and lost in the ether. I would be interested in taking a look at implementing this, but I'm not sure yet when I will have the time.

adam commented

@tvberlin commented on GitHub (Jan 4, 2021):

+1, would appreciate if this can be considered for implementation.

@tvberlin commented on GitHub (Jan 4, 2021): +1, would appreciate if this can be considered for implementation.

adam commented

@jeremystretch commented on GitHub (Jan 4, 2021):

@JonathonReinhart @tvberlin are either of you willing to commit to implementing the feature? If not, the "pending closure" label will be re-applied and the issue will likely be closed automatically.

@jeremystretch commented on GitHub (Jan 4, 2021): @JonathonReinhart @tvberlin are either of you willing to commit to implementing the feature? If not, the "pending closure" label will be re-applied and the issue will likely be closed automatically.

adam commented

@nikor30 commented on GitHub (Jan 19, 2021):

Hi, so having tow patchpannels directly one to one connected is not an genral netbox feature which should be considered ?

I just aggree with them so having an new site build up in netbox with several patch pannels is hughe effort to (consider without scipting apai etc.) in the gui to click on every port.

So considereing tow pannels to be 1 to 1 linked to each other should be in the standart of netbox.

Regards Niko

@nikor30 commented on GitHub (Jan 19, 2021): Hi, so having tow patchpannels directly one to one connected is not an genral netbox feature which should be considered ? I just aggree with them so having an new site build up in netbox with several patch pannels is hughe effort to (consider without scipting apai etc.) in the gui to click on every port. So considereing tow pannels to be 1 to 1 linked to each other should be in the standart of netbox. Regards Niko

adam commented

@jeremystretch commented on GitHub (Jan 19, 2021):

Of course it should be considered, and it is. That's what we're discussing in this issue. However, it doesn't seem like anyone is interested in committing to the work.

@jeremystretch commented on GitHub (Jan 19, 2021): Of course it should be considered, and it is. That's what we're discussing in this issue. However, it doesn't seem like anyone is interested in committing to the work.

adam commented

@nikor30 commented on GitHub (Jan 20, 2021):

Understand , so I can do testing if feature is working and sugest also into the design of how it should work and look like.
I am not a programmer so thats my limited contribution I can give here for this topic.

Is it possible to put this topic up to be more visible so we can find one who has programming skills to contribute and work n this feature ?

Regards Niko

@nikor30 commented on GitHub (Jan 20, 2021): Understand , so I can do testing if feature is working and sugest also into the design of how it should work and look like. I am not a programmer so thats my limited contribution I can give here for this topic. Is it possible to put this topic up to be more visible so we can find one who has programming skills to contribute and work n this feature ? Regards Niko

adam commented

@FloMeyer commented on GitHub (Feb 15, 2021):

Hi,

yeah i think 1:1 Mapping between Rear-Ports of two devices would be great.
I think the view could be build like this:

If i got some time i'll have a look into the code if I can make this possible. But I don't know if that's beyond my capabilities...

@FloMeyer commented on GitHub (Feb 15, 2021): Hi, yeah i think 1:1 Mapping between Rear-Ports of two devices would be great. I think the view could be build like this: ![image](https://user-images.githubusercontent.com/2670188/107990364-9fd1aa80-6fd4-11eb-9bf0-d304ef108142.png) If i got some time i'll have a look into the code if I can make this possible. But I don't know if that's beyond my capabilities...

adam commented

@github-actions[bot] commented on GitHub (Apr 15, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 15, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@github-actions[bot] commented on GitHub (May 4, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (May 4, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

adam commented

@jaltgen commented on GitHub (May 10, 2021):

It's a shame this got auto-closed. When planning new facilities with lots of structured cabling via patchpanels, this functionality is crucial. Netbox is amazing, the documentation and install was so easy and its so very useable, just, for physical installations, the current manual patching between rear-ports is just to cumbersome if I was to model, say, a 128x128 patch bay.

Any way to reopen this?

@jaltgen commented on GitHub (May 10, 2021): It's a shame this got auto-closed. When planning new facilities with lots of structured cabling via patchpanels, this functionality is crucial. Netbox is amazing, the documentation and install was so easy and its so very useable, just, for physical installations, the current manual patching between rear-ports is just to cumbersome if I was to model, say, a 128x128 patch bay. Any way to reopen this?

adam commented

@jeremystretch commented on GitHub (May 10, 2021):

This issue was closed because no one wanted to volunteer to do the work. As the discussion period has ended, we won't be re-opening this in the near future, however you're welcome to take a shot at building a plugin that performs this function. Maybe once a working proof-of-concept has been produced we can revisit the proposal to add it to NetBox core.

@jeremystretch commented on GitHub (May 10, 2021): This issue was closed because no one wanted to volunteer to do the work. As the discussion period has ended, we won't be re-opening this in the near future, however you're welcome to take a shot at building a plugin that performs this function. Maybe once a working proof-of-concept has been produced we can revisit the proposal to add it to NetBox core.

adam commented