starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

CWDM/DWDM and other connection hierarchies support #2970

New Issue
Closed
opened 2025-12-29 18:24:10 +01:00 by adam · 21 comments
adam commented 2025-12-29 18:24:10 +01:00
Owner
Copy Link

Originally created by @steffann on GitHub (Oct 23, 2019).

Environment

  • Python version: 3.7.3
  • NetBox version: v2.6.7-dev

Proposed Functionality

Netbox can currently not support coarse/dense wave division multiplexing (CWDM/DWDM) connections over circuits.

It starts with not being able to trace connections over circuits when there are front/rear ports involved. Multiple front ports trace through their rear port to the circuit termination, but the _connected_circuittermination field on an interface requires a one-to-one relation.

A quick fix was proposed to change the one-to-one relation to a foreign key, but that exposed multiple other issues. For example when tracing a circuit termination through a rear port. Because there is no front port known from the circuit's point of view the trace assumes front port 1 and the connected endpoint of the circuit termination appears to be whatever happens to be connected to that front port.

So this is a broader limitation than just the "DWDM through a circuit" that we started with. The proposed functionality is to work with front+rear port "layers":

Interface <-> Front port                Front port <-> Interface
                  ^                         ^
                  |                         |
                  v                         v
               Rear port <-> Circuit <-> Rear port

Traces and endpoints should stay in their layer or the underlying layers, but never go up above their starting layer. This becomes even more important when for example using the upgrade port of a mux, where the rear port of a second mux is attached to the front upgrade port of another mux:

Interface <-> Front port                                                 Front port <-> Interface
                  ^                                                          ^
                  |                                                          |
                  v                                                          v
               Rear port 1 <-> Front port                  Front port <-> Rear port 4
                                   ^                           ^
                                   |                           |
                                   v                           v
                                Rear port 2 <-> Circuit <-> Rear port 3

When looking for the connected endpoint of rear port 1 the logical endpoint is rear port 4. Tracing any further makes no sense because there are multiple endpoints beyond that rear port. The same goes for rear ports 2 and 3.

If one side of the circuit would be unconnected then the traces would all end at the circuit termination. This shows that a connected endpoint is not a one-to-one relationship. With multiplexers many endpoints can have the same connected endpoint.

And when other connections are missing the connected endpoint may well be something else than an interface or circuit termination. As an example lets say that one of the front ports isn't connected to an interface. In that case it would be useful to see the last front port where the link ends, hopefully so that someone can go and connect it :)

Use Case

These use cases are taken from #3288:

I see these possible scenario's. These are the "classical" ones without front/rear ports. Let's assume that the A side is connected to a device interface through a circuit-termination (CT). Obviously all scenario's apply with A and B sides reversed as well.

+----------+           +------+   +---------+
| Device A |--[cable]--| CT A |---| Circuit |---[?]
+----------+           +------+   +---------+
  1. B side has no circuit-termination
  2. B side has a circuit-termination but no device connected to it
  3. B side is connected to a device

In scenario 1 we only know that the device on the A side is connected to the circuit. The user interface should show which circuit the device interface is connected to. Display "via circuit in the user interface".

Scenario 2 expands on this a bit because we now know, through the circuit-termination, which site the other end of the circuit goes to. I suggest we show both the circuit and the remote site in the user interface. Display "to site via circuit".

Scenario 3 should show the user that the device interface is connected to which remote device interface, plus which circuit the connection uses. As we already know the remote device, I don't see much value in showing the remote site of the circuit-termination as well. Display "to device port via circuit".

Then on to some more complex scenarios where there are multiple circuits on the path:

+----------+           +-------+   +-----------+   +-------+
| Device A |--[cable]--| CT 1A |---| Circuit 1 |---| CT 1B |---\
+----------+           +-------+   +-----------+   +-------+    |
                                                                |
  /-------------------------[ cable ]--------------------------/
 |
 |    +-------+   +-----------+
  \---| CT 2A |---| Circuit 2 |---[?]
      +-------+   +-----------+
  1. 2B side has no circuit-termination
  2. 2B side has a circuit-termination but no device connected to it
  3. 2B side is connected to a device

I think these scenarios are similar to the first three. In the user interface I personally would like to see all the circuits to make it more intuitive, especially when looking a the impact of outages. I think it would also be useful to see the sites of CT 1B, CT 2A, etc. (removing duplicates when CT 1B and 2A are in the same site, as they will probably be in most cases). For example: "via circuit1 - ct1B/2A-site - circuit2" etc.

And then on to the scenarios that I opened this ticket about: CWDM and DWDM circuits and suchlike multiplexers:

+----------+           +---MUX1---+
| Device A |--[cable]--| Front 1  |
+----------+           |          |           +------+   +---------+
                       |     Rear |--[cable]--| CT A |---| Circuit |---[?]
+----------+           |          |           +------+   +---------+
| Device B |--[cable]--| Front 2  |
+----------+           +----------+
  1. B side has no circuit-termination
  2. B side has a circuit-termination but no device connected to it
  3. B side is connected to a rear port, but there is no corresponding front port
  4. B side is connected to a rear port, but nothing is connected to the front port
  5. B side is connected to a device interface through a rear+front port

I'm assuming that the names of the front ports will correspond to channel names or something similar. Is that a reasonable assumption?

For scenario 7 I think it would be useful to show the front port name and the circuit in the user interface. That is probably the information a user needs most. Display "via mux1-front - circuit" (e.g. "via CH32 - DarkFiber123").

Scenario 8 would benefit from showing the remote site name as well, similar to scenario 2. Display "to ctB-site via mux1-front - circuit" (e.g. "to Amsterdam via CH32 - DarkFiber123").

Scenario 9 seems to be an error, but maybe there are cases where the mux device has a separate channel for out-of-band management which doesn't have a corresponding front port. Display "to mux2 via mux1-front - circuit" (e.g. "to mux01.ams1 via CH32 - DarkFiber123").

In scenario 10 the user probably wants to know the front port that the connection ends up at. Display "to mux2 mux2-front via mux1-front - circuit" (e.g. "to mux01.ams1 CH32 via CH32 - DarkFiber123").

A possible optimization could be to display "to mux2 mux2-front via circuit" (e.g. "to mux01.ams1 CH32 via DarkFiber123") when the front names on both MUXes are the same, as will be the case when those names are CWDM/DWDM channel names.

Scenario 11 would of course show the connected device and interface together with the circuit. If we can assume that front port names are indeed channel names, then that information would be useful to show as well. Display "to remote-device remote-interface via mux1-front - circuit - mux2-front" (e.g. "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123 - CH32").

The same optimization with duplicate front port names would apply here too: "to remote-device remote-interface via mux1-front - circuit" (e.g. "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123").

For the CWDM/DWDM scenarios we might need to rethink the circuits_circuittermination.connected_endpoint_id field as a circuit-termination may be connected to a rear port, in which case there is no single interface that it's connected to.

And then there are the scenarios where there are multiple CWDM/DWDM MUXes on the path:

+----------+           +---MUX1---+
| Device A |--[cable]--| Front 1  |
+----------+           |          |           +-------+   +-----------+
                       |     Rear |--[cable]--| CT 1A |---| Circuit 1 |---\
+----------+           |          |           +-------+   +-----------+    |
| Device B |--[cable]--| Front 2  |                                        |
+----------+           +----------+                                        |
                                                                           |
  /-----------------------------------------------------------------------/
 |
 |                        +---MUX2---+           +---MUX3---+
 |                        |  Front 1 |--[cable]--| Front 1  |
 |    +-------+           |          |           |          |
  \---| CT 1B |--[cable]--| Rear     |           |     Rear |---\
      +-------+           |          |           |          |    |
                          |  Front 2 |--[cable]--| Front 2  |    |
                          +----------+           +----------+    |
                                                                 |
  /-------------------------[ cable ]---------------------------/
 |
 |    +-------+   +-----------+
  \---| CT 2A |---| Circuit 2 |---[?]
      +-------+   +-----------+

For these scenarios I would suggest prefixing the display text of the previous section with "via mux1-front - circuit - mux2-front" (or the shorter optimized version, with front port names omitted if they are the same as the previous front port name).

  1. 2B side has no circuit-termination
  2. 2B side has a circuit-termination but no device connected to it
  3. 2B side is connected to a rear port, but there is no corresponding front port
  4. 2B side is connected to a rear port, but nothing is connected to the front port
  5. 2B side is connected to a device interface through a rear+front port

Scenario 12 would display "via mux1-front - circuit1 - mux2-front - mux3-front - circuit2" (e.g. "via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456"), or optimized to "via CH32 - DarkFiber123 - DarkFiber456"

Scenario 13 would display "to ct2B-site via mux1-front - circuit1 - mux2-front - mux3-front - circuit2" (e.g. "to Amsterdam via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456"), or optimized to "to Amsterdam via CH32 - DarkFiber123 - DarkFiber456"

Scenario 14 would display "to mux4 via mux1-front - circuit1 - mux2-front - mux3-front - circuit2" (e.g. "to mux01.ams1 via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456"), or optimized to "to mux01.ams1 via CH32 - DarkFiber123 - DarkFiber456".

In scenario 15 would display "to mux4 mux4-front via mux1-front - circuit1 - mux2-front - mux3-front - circuit2" (e.g. "to mux01.ams1 CH32 via CH32 - DarkFiber123"), or optimized to "to mux01.ams1 CH32 via DarkFiber123 - DarkFiber456".

Scenario 16 would display "to remote-device remote-interface via mux1-front - circuit1 - mux2-front - mux3-front - circuit2 - mux4-front" (e.g. "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456 - CH32"), or optimized to "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123 - DarkFiber456".

And then another scenario suggested by @bsteinert:

when you connect a multiplexer to a extension port of another multiplexer (often 1300nm cwdm or 1550nm dwdm) to extend your network this could break things in documentation..

+----------+           +---MUX1---+          +---MUX2---+
| Device A |--[cable]--| Front 1  |          |          |
+----------+           |          |          |          |
                       |     Rear |--[cbl]---| Front 1  |
+----------+           |          |          |          |  +-----------+
| Device B |--[cable]--| Front 2  |          |     Rear |--| Circuit 1 |--\
+----------+           +----------+          +----------+  +-----------+   |
                                                                           |
  /-----------------------------------------------------------------------/
 |
 |            +---MUX3---+           +---MUX4---+
 |            |  Front 1 |---[cbl]---| Rear     |
 |            |          |           |          |           +-----------+
  \-----------| Rear     |           |  Front 1 |--[cable]--| Device A2 |  
              |          |           |          |           +-----------+
              |  Front 2 |           |  Front 2 |--[cable]--| Device B2 |
              +----------+           +----------+           +-----------+

--> "From Site1 to Site2 via Mux-1 1330nm - Mux-2 1300nm - DarkFiberX - Mux-3 1300nm - Mux-4 1330nm"

That get even more complicated when i add PatchPanel to NetBox...

Database Changes

To document all these use cases the _connected_interface and _connected_circuittermination fields on Interface are no longer sufficient. The same goes for the connected_endpoint fields of all other network (and console) endpoints.

As these fields are not storing authoritative data (they are basically caches to keep the user interface and API responsive) I suggest replacing them with GenericForeignKey fields with the model type restricted to CABLE_TERMINATION_TYPES. That way any combination of endpoints can be cached and shown to the user.

Because the proposed user interface above also shows the path between endpoints ("via …") the trace should be cached too. Because of the efficient cacheing that Netbox already uses I have found that storing a list of [(('app', 'model'), id), …] in a JSON field provides all the necessary information without adding too much overhead. I have tried storing actual trace details as well, but that would require rebuilding the field on every change in any of the cached information (like names of interfaces, circuits, sites, …, …). Just storing the object's id and retrieving its details at runtime proved to be much much easier to maintain, while still having a quite acceptable performance.

External Dependencies

None

Originally created by @steffann on GitHub (Oct 23, 2019). ### Environment * Python version: 3.7.3 * NetBox version: v2.6.7-dev ### Proposed Functionality Netbox can currently not support coarse/dense wave division multiplexing (CWDM/DWDM) connections over circuits. It starts with not being able to trace connections over circuits when there are front/rear ports involved. Multiple front ports trace through their rear port to the circuit termination, but the `_connected_circuittermination` field on an interface requires a one-to-one relation. A quick fix was proposed to change the one-to-one relation to a foreign key, but that exposed multiple other issues. For example when tracing a circuit termination through a rear port. Because there is no front port known from the circuit's point of view the trace assumes front port 1 and the connected endpoint of the circuit termination appears to be whatever happens to be connected to that front port. So this is a broader limitation than just the "DWDM through a circuit" that we started with. The proposed functionality is to work with front+rear port "layers": Interface <-> Front port Front port <-> Interface ^ ^ | | v v Rear port <-> Circuit <-> Rear port Traces and endpoints should stay in their layer or the underlying layers, but never go up above their starting layer. This becomes even more important when for example using the upgrade port of a mux, where the rear port of a second mux is attached to the front upgrade port of another mux: Interface <-> Front port Front port <-> Interface ^ ^ | | v v Rear port 1 <-> Front port Front port <-> Rear port 4 ^ ^ | | v v Rear port 2 <-> Circuit <-> Rear port 3 When looking for the connected endpoint of rear port 1 the logical endpoint is rear port 4. Tracing any further makes no sense because there are multiple endpoints beyond that rear port. The same goes for rear ports 2 and 3. If one side of the circuit would be unconnected then the traces would all end at the circuit termination. This shows that a connected endpoint is not a one-to-one relationship. With multiplexers many endpoints can have the same connected endpoint. And when other connections are missing the connected endpoint may well be something else than an interface or circuit termination. As an example lets say that one of the front ports isn't connected to an interface. In that case it would be useful to see the last front port where the link ends, hopefully so that someone can go and connect it :) ### Use Case These use cases are taken from #3288: I see these possible scenario's. These are the "classical" ones without front/rear ports. Let's assume that the A side is connected to a device interface through a circuit-termination (CT). Obviously all scenario's apply with A and B sides reversed as well. +----------+ +------+ +---------+ | Device A |--[cable]--| CT A |---| Circuit |---[?] +----------+ +------+ +---------+ 1) B side has no circuit-termination 2) B side has a circuit-termination but no device connected to it 3) B side is connected to a device In scenario 1 we only know that the device on the A side is connected to the circuit. The user interface should show which circuit the device interface is connected to. Display "via `circuit` in the user interface". Scenario 2 expands on this a bit because we now know, through the circuit-termination, which site the other end of the circuit goes to. I suggest we show both the circuit and the remote site in the user interface. Display "to `site` via `circuit`". Scenario 3 should show the user that the device interface is connected to which remote device interface, plus which circuit the connection uses. As we already know the remote device, I don't see much value in showing the remote site of the circuit-termination as well. Display "to `device` `port` via `circuit`". Then on to some more complex scenarios where there are multiple circuits on the path: +----------+ +-------+ +-----------+ +-------+ | Device A |--[cable]--| CT 1A |---| Circuit 1 |---| CT 1B |---\ +----------+ +-------+ +-----------+ +-------+ | | /-------------------------[ cable ]--------------------------/ | | +-------+ +-----------+ \---| CT 2A |---| Circuit 2 |---[?] +-------+ +-----------+ 4) 2B side has no circuit-termination 5) 2B side has a circuit-termination but no device connected to it 6) 2B side is connected to a device I think these scenarios are similar to the first three. In the user interface I personally would like to see all the circuits to make it more intuitive, especially when looking a the impact of outages. I think it would also be useful to see the sites of CT 1B, CT 2A, etc. (removing duplicates when CT 1B and 2A are in the same site, as they will probably be in most cases). For example: "via `circuit1` - `ct1B/2A-site` - `circuit2`" etc. And then on to the scenarios that I opened this ticket about: CWDM and DWDM circuits and suchlike multiplexers: +----------+ +---MUX1---+ | Device A |--[cable]--| Front 1 | +----------+ | | +------+ +---------+ | Rear |--[cable]--| CT A |---| Circuit |---[?] +----------+ | | +------+ +---------+ | Device B |--[cable]--| Front 2 | +----------+ +----------+ 7) B side has no circuit-termination 8) B side has a circuit-termination but no device connected to it 9) B side is connected to a rear port, but there is no corresponding front port 10) B side is connected to a rear port, but nothing is connected to the front port 11) B side is connected to a device interface through a rear+front port I'm assuming that the names of the front ports will correspond to channel names or something similar. Is that a reasonable assumption? For scenario 7 I think it would be useful to show the front port name and the circuit in the user interface. That is probably the information a user needs most. Display "via `mux1-front` - `circuit`" (e.g. "via CH32 - DarkFiber123"). Scenario 8 would benefit from showing the remote site name as well, similar to scenario 2. Display "to `ctB-site` via `mux1-front` - `circuit`" (e.g. "to Amsterdam via CH32 - DarkFiber123"). Scenario 9 seems to be an error, but maybe there are cases where the mux device has a separate channel for out-of-band management which doesn't have a corresponding front port. Display "to `mux2` via `mux1-front` - `circuit`" (e.g. "to mux01.ams1 via CH32 - DarkFiber123"). In scenario 10 the user probably wants to know the front port that the connection ends up at. Display "to `mux2` `mux2-front` via `mux1-front` - `circuit`" (e.g. "to mux01.ams1 CH32 via CH32 - DarkFiber123"). A possible optimization could be to display "to `mux2` `mux2-front` via `circuit`" (e.g. "to mux01.ams1 CH32 via DarkFiber123") when the front names on both MUXes are the same, as will be the case when those names are CWDM/DWDM channel names. Scenario 11 would of course show the connected device and interface together with the circuit. If we can assume that front port names are indeed channel names, then that information would be useful to show as well. Display "to `remote-device` `remote-interface` via `mux1-front` - `circuit` - `mux2-front`" (e.g. "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123 - CH32"). The same optimization with duplicate front port names would apply here too: "to `remote-device` `remote-interface` via `mux1-front` - `circuit`" (e.g. "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123"). For the CWDM/DWDM scenarios we might need to rethink the `circuits_circuittermination.connected_endpoint_id` field as a circuit-termination may be connected to a rear port, in which case there is no single interface that it's connected to. And then there are the scenarios where there are multiple CWDM/DWDM MUXes on the path: +----------+ +---MUX1---+ | Device A |--[cable]--| Front 1 | +----------+ | | +-------+ +-----------+ | Rear |--[cable]--| CT 1A |---| Circuit 1 |---\ +----------+ | | +-------+ +-----------+ | | Device B |--[cable]--| Front 2 | | +----------+ +----------+ | | /-----------------------------------------------------------------------/ | | +---MUX2---+ +---MUX3---+ | | Front 1 |--[cable]--| Front 1 | | +-------+ | | | | \---| CT 1B |--[cable]--| Rear | | Rear |---\ +-------+ | | | | | | Front 2 |--[cable]--| Front 2 | | +----------+ +----------+ | | /-------------------------[ cable ]---------------------------/ | | +-------+ +-----------+ \---| CT 2A |---| Circuit 2 |---[?] +-------+ +-----------+ For these scenarios I would suggest prefixing the display text of the previous section with "via `mux1-front` - `circuit` - `mux2-front`" (or the shorter optimized version, with front port names omitted if they are the same as the previous front port name). 12) 2B side has no circuit-termination 13) 2B side has a circuit-termination but no device connected to it 14) 2B side is connected to a rear port, but there is no corresponding front port 15) 2B side is connected to a rear port, but nothing is connected to the front port 16) 2B side is connected to a device interface through a rear+front port Scenario 12 would display "via `mux1-front` - `circuit1` - `mux2-front` - `mux3-front` - `circuit2`" (e.g. "via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456"), or optimized to "via CH32 - DarkFiber123 - DarkFiber456" Scenario 13 would display "to `ct2B-site` via `mux1-front` - `circuit1` - `mux2-front` - `mux3-front` - `circuit2`" (e.g. "to Amsterdam via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456"), or optimized to "to Amsterdam via CH32 - DarkFiber123 - DarkFiber456" Scenario 14 would display "to `mux4` via `mux1-front` - `circuit1` - `mux2-front` - `mux3-front` - `circuit2`" (e.g. "to mux01.ams1 via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456"), or optimized to "to mux01.ams1 via CH32 - DarkFiber123 - DarkFiber456". In scenario 15 would display "to `mux4` `mux4-front` via `mux1-front` - `circuit1` - `mux2-front` - `mux3-front` - `circuit2`" (e.g. "to mux01.ams1 CH32 via CH32 - DarkFiber123"), or optimized to "to mux01.ams1 CH32 via DarkFiber123 - DarkFiber456". Scenario 16 would display "to `remote-device` `remote-interface` via `mux1-front` - `circuit1` - `mux2-front` - `mux3-front` - `circuit2` - `mux4-front`" (e.g. "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123 - CH32 - CH32 - DarkFiber456 - CH32"), or optimized to "to router1.ams1 xe-0/0/0 via CH32 - DarkFiber123 - DarkFiber456". And then another scenario suggested by @bsteinert: when you connect a multiplexer to a extension port of another multiplexer (often 1300nm cwdm or 1550nm dwdm) to extend your network this could break things in documentation.. +----------+ +---MUX1---+ +---MUX2---+ | Device A |--[cable]--| Front 1 | | | +----------+ | | | | | Rear |--[cbl]---| Front 1 | +----------+ | | | | +-----------+ | Device B |--[cable]--| Front 2 | | Rear |--| Circuit 1 |--\ +----------+ +----------+ +----------+ +-----------+ | | /-----------------------------------------------------------------------/ | | +---MUX3---+ +---MUX4---+ | | Front 1 |---[cbl]---| Rear | | | | | | +-----------+ \-----------| Rear | | Front 1 |--[cable]--| Device A2 | | | | | +-----------+ | Front 2 | | Front 2 |--[cable]--| Device B2 | +----------+ +----------+ +-----------+ --> "From Site1 to Site2 via Mux-1 1330nm - Mux-2 1300nm - DarkFiberX - Mux-3 1300nm - Mux-4 1330nm" That get even more complicated when i add PatchPanel to NetBox... ### Database Changes To document all these use cases the `_connected_interface` and `_connected_circuittermination` fields on `Interface` are no longer sufficient. The same goes for the `connected_endpoint` fields of all other network (and console) endpoints. As these fields are not storing authoritative data (they are basically caches to keep the user interface and API responsive) I suggest replacing them with GenericForeignKey fields with the model type restricted to `CABLE_TERMINATION_TYPES`. That way any combination of endpoints can be cached and shown to the user. Because the proposed user interface above also shows the path between endpoints ("via …") the trace should be cached too. Because of the efficient cacheing that Netbox already uses I have found that storing a list of `[(('app', 'model'), id), …]` in a JSON field provides all the necessary information without adding too much overhead. I have tried storing actual trace details as well, but that would require rebuilding the field on every change in any of the cached information (like names of interfaces, circuits, sites, …, …). Just storing the object's id and retrieving its details at runtime proved to be much much easier to maintain, while still having a quite acceptable performance. ### External Dependencies None
adam closed this issue 2025-12-29 18:24:10 +01:00
adam commented 2025-12-29 18:24:11 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Oct 23, 2019):

PS: the proposed construction also allows for future support of break-out interfaces like those with MPO cables that connect to a patch panel that breaks them out into separate front ports.

But let's leave supporting physical sub-interfaces for another feature request :)

@steffann commented on GitHub (Oct 23, 2019): PS: the proposed construction also allows for future support of break-out interfaces like those with MPO cables that connect to a patch panel that breaks them out into separate front ports. But let's leave supporting physical sub-interfaces for another feature request :)
adam commented 2025-12-29 18:24:11 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Nov 1, 2019):

For those getting here from individual bug reports:

This all started with me finding a bug, trying multiple ways to solve this, concluding that the current architecture gets in the way, proposing a revised architecture, and then looking at different bugs and feature requests that could/would be solved with this new architecture. When looking from each of the individual bug's point of view such an architectural change may seem like overkill.

I understand this is a huge step, but I also think it's a step forward that will benefit future development.

@steffann commented on GitHub (Nov 1, 2019): For those getting here from individual bug reports: This all started with me finding a bug, trying multiple ways to solve this, concluding that the current architecture gets in the way, proposing a revised architecture, and then looking at different bugs and feature requests that could/would be solved with this new architecture. When looking from each of the individual bug's point of view such an architectural change may seem like overkill. I understand this is a huge step, but I also think it's a step forward that will benefit future development.
adam commented 2025-12-29 18:24:11 +01:00
Author
Owner
Copy Link

@darkdane commented on GitHub (Nov 2, 2019):

We also use DWDM and suffer from the exact same problem. I would love to see this implemented into Netbox.

@darkdane commented on GitHub (Nov 2, 2019): We also use DWDM and suffer from the exact same problem. I would love to see this implemented into Netbox.
adam commented 2025-12-29 18:24:11 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 6, 2019):

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 (Dec 6, 2019): 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 2025-12-29 18:24:12 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Dec 6, 2019):

I really think this is an important step forward, so I'd like to keep it open. I understand that releasing 2.7 comes first at this point in time.

@steffann commented on GitHub (Dec 6, 2019): I really think this is an important step forward, so I'd like to keep it open. I understand that releasing 2.7 comes first at this point in time.
adam commented 2025-12-29 18:24:12 +01:00
Author
Owner
Copy Link

@amtypaldos commented on GitHub (Dec 13, 2019):

This is something that would help us out a ton as we use DWDM and splitters in our infrastructure that we would like to track.

@amtypaldos commented on GitHub (Dec 13, 2019): This is something that would help us out a ton as we use DWDM and splitters in our infrastructure that we would like to track.
adam commented 2025-12-29 18:24:12 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 27, 2019):

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 (Dec 27, 2019): 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 2025-12-29 18:24:12 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Dec 27, 2019):

Still keeping it open until the maintainers have more time.

@steffann commented on GitHub (Dec 27, 2019): Still keeping it open until the maintainers have more time.
adam commented 2025-12-29 18:24:12 +01:00
Author
Owner
Copy Link

@doug14 commented on GitHub (Dec 30, 2019):

I have a small DWDM structure and I am about to increase this structure. This implementation would be of great importance to keep our organization here.

@doug14 commented on GitHub (Dec 30, 2019): I have a small DWDM structure and I am about to increase this structure. This implementation would be of great importance to keep our organization here.
adam commented 2025-12-29 18:24:12 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 13, 2020):

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 13, 2020): 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 2025-12-29 18:24:13 +01:00
Author
Owner
Copy Link

@doug14 commented on GitHub (Jan 13, 2020):

Still keeping it open until the maintainers have more time.

@doug14 commented on GitHub (Jan 13, 2020): Still keeping it open until the maintainers have more time.
adam commented 2025-12-29 18:24:13 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 27, 2020):

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 27, 2020): 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 2025-12-29 18:24:13 +01:00
Author
Owner
Copy Link

@darkdane commented on GitHub (Jan 27, 2020):

Please implement this, there is a urgent need for this if you use DWDM.

@darkdane commented on GitHub (Jan 27, 2020): Please implement this, there is a urgent need for this if you use DWDM.
adam commented 2025-12-29 18:24:13 +01:00
Author
Owner
Copy Link

@doug14 commented on GitHub (Jan 27, 2020):

Still keeping it open until the maintainers have more time.

@doug14 commented on GitHub (Jan 27, 2020): Still keeping it open until the maintainers have more time.
adam commented 2025-12-29 18:24:13 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Feb 10, 2020):

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 (Feb 10, 2020): 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 2025-12-29 18:24:13 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Feb 10, 2020):

keeping it open!

@steffann commented on GitHub (Feb 10, 2020): keeping it open!
adam commented 2025-12-29 18:24:14 +01:00
Author
Owner
Copy Link

@doug14 commented on GitHub (Feb 10, 2020):

Still keeping it open until the maintainers have more time.

@doug14 commented on GitHub (Feb 10, 2020): Still keeping it open until the maintainers have more time.
adam commented 2025-12-29 18:24:14 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 10, 2020):

@steffann or @doug14 Is this something you are willing to commit to working on?

@DanSheps commented on GitHub (Feb 10, 2020): @steffann or @doug14 Is this something you are willing to commit to working on?
adam commented 2025-12-29 18:24:14 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Feb 10, 2020):

@steffann or @doug14 Is this something you are willing to commit to working on?

I have volunteered to work on this many times :) I'm just waiting for a maintainer to have time to work with me to move this forward.

@steffann commented on GitHub (Feb 10, 2020): > @steffann or @doug14 Is this something you are willing to commit to working on? I have volunteered to work on this many times :) I'm just waiting for a maintainer to have time to work with me to move this forward.
adam commented 2025-12-29 18:24:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2020):

Marking this as blocked. We can take another look at it after all the current bugs relating to cabling have been resolved (#2994, #3193, #3288).

@jeremystretch commented on GitHub (Feb 21, 2020): Marking this as blocked. We can take another look at it after all the current bugs relating to cabling have been resolved (#2994, #3193, #3288).
adam commented 2025-12-29 18:24:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 24, 2020):

Paths through nested rear ports are now supported; support was added/fixed by the work done under #4388. I believe at this point all of the cited concerns have been either fixed or addressed in separate issues (e.g. #4519). If any problems remain unaccounted for, separate and concise bug reports need to be opened for each one.

@jeremystretch commented on GitHub (Apr 24, 2020): Paths through nested rear ports are now supported; support was added/fixed by the work done under #4388. I believe at this point all of the cited concerns have been either fixed or addressed in separate issues (e.g. #4519). If any problems remain unaccounted for, separate and concise bug reports need to be opened for each one.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2970
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?