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

Tracing cables which fork into multiple paths #2163

New Issue
Closed
opened 2025-12-29 17:22:50 +01:00 by adam · 14 comments
adam commented 2025-12-29 17:22:50 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Nov 30, 2018).

Environment

  • Python version: 3.5.2
  • NetBox version: 2.5-beta2

Proposed Functionality

The cable tracing function is linear. It's also quite smart, in that if you traverse an N:1 front-port to rear-port, and then go via rear-port to front-port on another device, it comes out again at the right offset.

However it won't trace multiple paths from single rear to multiple front ports, which may be necessary if no front-to-rear traversal has already taken place.

Use Case

Here is an example: it's when you want to convert a duplex LC connector into two separate simplex LSH fibre paths, because your fibre patching infrastructure is simplex.

You can model it like this, albeit somewhat painfully:

  • Device type "adapter" has rear port "LC" and two front ports "LSH1" and "LSH2" (linked to LC:1 and LC:2 respectively)
  • Device type "patch panel" has front ports of type LSH, linked either 1:1 or N:1 to rear port (e.g. MPO)
  • Device type "switch" has one or more SFP interfaces

Wire it up like this:

                  LSH1  F1                        F1  LSH1
    SFP  LC       ,------- O                    O -------.       LC  SFP
sw1 ------- adapt1          panel1 O----O panel2          adapt2 ------- sw2
                  `------- O      MPO  MPO      O -------'
                  LSH2  F2                        F2  LSH2

This works, but when you trace from sw1's SFP port, it only shows one of the fibre paths being traversed (the first one).

A full trace would have graphviz-like output, and could show a path splitting into multiple subpaths and then joining back together again.

A similar use case could be made for tracing from a QSFP+ port to four SFP+ ports on a break-out cable. (The fact that a QSFP+ port may itself appear as four logical "interfaces" in a device, despite being one physical port, complicates modelling further)

Database Changes

None. The code which traverses connections would change.

External Dependencies

graphviz or similar library. There is some existing graphviz usage in Netbox which shells out to the command-line dot utility. However it would probably be better to use viz.js (graphviz compiled into Javascript)

Alternative options

The use case given is a frig, because the "adapter" device does not really exist.

It would be better to model a cable with more than two connectors: an LC connector at one end, and two LSH connectors at the other end. That's what you'd have in the real world.

But (a) this is substantial database change; I expect it would require "cable types" and allowing connections with multiple endpoints; and (b) the tracing functionality described here would still be required.

Originally created by @candlerb on GitHub (Nov 30, 2018). ### Environment * Python version: 3.5.2 * NetBox version: 2.5-beta2 ### Proposed Functionality The cable tracing function is linear. It's also quite smart, in that if you traverse an N:1 front-port to rear-port, and then go via rear-port to front-port on another device, it comes out again at the right offset. However it won't trace multiple paths from single rear to multiple front ports, which may be necessary if no front-to-rear traversal has already taken place. ### Use Case Here is [an example](https://groups.google.com/forum/#!topic/netbox-discuss/EeTV-754FWY): it's when you want to convert a duplex LC connector into two separate simplex LSH fibre paths, because your fibre patching infrastructure is simplex. You can model it like this, albeit somewhat painfully: * Device type "adapter" has rear port "LC" and two front ports "LSH1" and "LSH2" (linked to LC:1 and LC:2 respectively) * Device type "patch panel" has front ports of type LSH, linked either 1:1 or N:1 to rear port (e.g. MPO) * Device type "switch" has one or more SFP interfaces Wire it up like this: ``` LSH1 F1 F1 LSH1 SFP LC ,------- O O -------. LC SFP sw1 ------- adapt1 panel1 O----O panel2 adapt2 ------- sw2 `------- O MPO MPO O -------' LSH2 F2 F2 LSH2 ``` This works, but when you trace from sw1's SFP port, it only shows one of the fibre paths being traversed (the first one). A full trace would have graphviz-like output, and could show a path splitting into multiple subpaths and then joining back together again. A similar use case could be made for tracing from a QSFP+ port to four SFP+ ports on a break-out cable. (The fact that a QSFP+ port may itself appear as four logical "interfaces" in a device, despite being one physical port, complicates modelling further) ### Database Changes None. The code which traverses connections would change. ### External Dependencies graphviz or similar library. There is some existing graphviz usage in Netbox which shells out to the command-line dot utility. However it would probably be better to use [viz.js](http://viz-js.com/) (graphviz compiled into Javascript) ### Alternative options The use case given is a frig, because the "adapter" device does not really exist. It would be better to model a cable with more than two connectors: an LC connector at one end, and two LSH connectors at the other end. That's what you'd have in the real world. But (a) this is substantial database change; I expect it would require "cable types" and allowing connections with multiple endpoints; and (b) the tracing functionality described here would still be required.
adam added the type: featurestatus: under review labels 2025-12-29 17:22:50 +01:00
adam closed this issue 2025-12-29 17:22:50 +01:00
adam commented 2025-12-29 17:22:51 +01:00
Author
Owner
Copy Link

@brianatlarge commented on GitHub (Dec 10, 2018):

I think this is the same issue I was running into. Say I have a fiber patch panel with 12 LC connectors on the front and a 24 bundled fiber patched into the back.

Since the current design only allows multiple front connectors to be mapped to single rear connectors via the position option, the only way to map each strand of the fiber bundle is to reverse the functions of the front and rear panels.

So for example, I’d have to create 12 rear ports with position of 2, but in the real world this would be the front of the panel. Then I’d have 24 front ports mapped to the 12 rear ports. This will allow me to map each of the 24 fiber strands.

This isn’t a solution I’d want to roll out in a production environment, so I’m interested in seeing how this problem will be addressed in the future.

@brianatlarge commented on GitHub (Dec 10, 2018): I think this is the same issue I was running into. Say I have a fiber patch panel with 12 LC connectors on the front and a 24 bundled fiber patched into the back. Since the current design only allows multiple front connectors to be mapped to single rear connectors via the position option, the only way to map each strand of the fiber bundle is to reverse the functions of the front and rear panels. So for example, I’d have to create 12 rear ports with position of 2, but in the real world this would be the front of the panel. Then I’d have 24 front ports mapped to the 12 rear ports. This will allow me to map each of the 24 fiber strands. This isn’t a solution I’d want to roll out in a production environment, so I’m interested in seeing how this problem will be addressed in the future.
adam commented 2025-12-29 17:22:51 +01:00
Author
Owner
Copy Link

@dnyt84 commented on GitHub (Dec 13, 2018):

Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example)
but then we also have BIDI SFP's that only use 1 Cable ... :/

@dnyt84 commented on GitHub (Dec 13, 2018): Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example) but then we also have BIDI SFP's that only use 1 Cable ... :/
adam commented 2025-12-29 17:22:52 +01:00
Author
Owner
Copy Link

@brianatlarge commented on GitHub (Dec 13, 2018):

Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example)
but then we also have BIDI SFP's that only use 1 Cable ... :/

patch

I use duplex LC connections from my switches to the patch panel. Between each patch panel, there is usually a bundle of 24 fiber strands patched in. I'd like to be able to track the complete path from each switch.

So for example, the connection from the switch to the front patch panel would be tracked by a single duplex cable. Each cable from the rear of one patch panel to the rear of the other would be tracked by two cables. Then from the front of the other patch panel to the other switch would be tracked by a single duplex cable.

@brianatlarge commented on GitHub (Dec 13, 2018): > Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example) > but then we also have BIDI SFP's that only use 1 Cable ... :/ ![patch](https://user-images.githubusercontent.com/31288431/49963450-03885680-fee6-11e8-89ee-f35b3af42193.PNG) I use duplex LC connections from my switches to the patch panel. Between each patch panel, there is usually a bundle of 24 fiber strands patched in. I'd like to be able to track the complete path from each switch. So for example, the connection from the switch to the front patch panel would be tracked by a single duplex cable. Each cable from the rear of one patch panel to the rear of the other would be tracked by two cables. Then from the front of the other patch panel to the other switch would be tracked by a single duplex cable.
adam commented 2025-12-29 17:22:52 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Dec 14, 2018):

Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example)

The problem is that the cable connects to the end device, and this has an interface. An interface can have a type (like SFP or SFP+) but accepts only one connection / cable.

Since Netbox doesn't model SFPs, one end of the fibre "cable" plugs directly into the "SFP" port.

You are saying that you want to model the duplex cable as two separate fibre cables, which is reasonable, but the SFP port only accepts one cable. Hence right now, a "duplex fibre cable" is the only realistic option.

I suppose Netbox could be changed so that an SFP interface has two legs, but that wouldn't be right all the time (e.g. when using a copper SFP or a bidi SFP).

ATM, the only way I can see to model the SFP would be as a "device" in its own right, with one rear port and two front ports, much as the "adapt" interfaces I showed earlier were.

@candlerb commented on GitHub (Dec 14, 2018): > Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example) The problem is that the cable connects to the end device, and this has an *interface*. An interface can have a type (like SFP or SFP+) but accepts only one connection / cable. Since Netbox doesn't model SFPs, one end of the fibre "cable" plugs directly into the "SFP" port. You are saying that you want to model the duplex cable as two separate fibre cables, which is reasonable, but the SFP port only accepts one cable. Hence right now, a "duplex fibre cable" is the only realistic option. I suppose Netbox could be changed so that an SFP interface has two legs, but that wouldn't be right all the time (e.g. when using a copper SFP or a bidi SFP). ATM, the only way I can see to model the SFP would be as a "device" in its own right, with one rear port and two front ports, much as the "adapt" interfaces I showed earlier were.
adam commented 2025-12-29 17:22:52 +01:00
Author
Owner
Copy Link

@ljb2of3 commented on GitHub (Dec 14, 2018):

Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example)
but then we also have BIDI SFP's that only use 1 Cable ... :/

My campus is complicated, but I assume many others are too. All our switches use Duplex LC SFPs, but we do have a handful of BiDi SFPs, and will be adding more due to fiber constraints. Modeling individual fibers seems important.

The complication comes when the connectors change. Duplex LC SFPs have to be plugged into a pair of single ST or SC connectors on the patch panels in many buildings. To make it more complicated those pairs of ST or SC connectors on one patch panel terminate as a duplex LC connector on the remote patch panel, so connectors and paring of the fibers change often. To make things more fun there's at least one patch panel where the installer messed it up, so a duplex LC pair on one end terminates in two completely different LC pairs on the other side, so LC port 1 on the A side is on terminated on one fiber in LC port 1 and one fiber of LC port 13.

However, for the bulk of our fiber connections, we treat the duplex LC connections as a single unit, and they're labeled as such. In keeping with Netbox's "80% solution" design goal, treating duplex connections as a single unit will work for me. In patch panels with simplex ST or SC connectors, I'm just going to label them in pairs with the same label as the duplex LC from the remote end. In the case of using two BiDi connections over one LC duplex, I plan to just create a dummy set of front and rear ports for that specific use case labeled <front_port.b> and <rear_port.b> and then patch the second connection across that.

Of course, if an easy solution to tracking individual strands is added to Netbox, I'll happily use that. Mapping out all our fiber is one of my spring projects, so the release of 2.5 came at a perfect time.

@ljb2of3 commented on GitHub (Dec 14, 2018): > Not sure what SFP's you are using but majority of my SFP's are Duplex. So when running into a Fiber Patch Panel that has 6 x LC Connectors my Duplex Cable from my SFP should use 2 Ports (Port 1 and 2 for example) > but then we also have BIDI SFP's that only use 1 Cable ... :/ My campus is complicated, but I assume many others are too. All our switches use Duplex LC SFPs, but we do have a handful of BiDi SFPs, and will be adding more due to fiber constraints. Modeling individual fibers seems important. The complication comes when the connectors change. Duplex LC SFPs have to be plugged into a pair of single ST or SC connectors on the patch panels in many buildings. To make it more complicated those pairs of ST or SC connectors on one patch panel terminate as a duplex LC connector on the remote patch panel, so connectors and paring of the fibers change often. To make things more fun there's at least one patch panel where the installer messed it up, so a duplex LC pair on one end terminates in two completely different LC pairs on the other side, so LC port 1 on the A side is on terminated on one fiber in LC port 1 and one fiber of LC port 13. However, for the bulk of our fiber connections, we treat the duplex LC connections as a single unit, and they're labeled as such. In keeping with Netbox's "80% solution" design goal, treating duplex connections as a single unit will work for me. In patch panels with simplex ST or SC connectors, I'm just going to label them in pairs with the same label as the duplex LC from the remote end. In the case of using two BiDi connections over one LC duplex, I plan to just create a dummy set of front and rear ports for that specific use case labeled <front_port.b> and <rear_port.b> and then patch the second connection across that. Of course, if an easy solution to tracking individual strands is added to Netbox, I'll happily use that. Mapping out all our fiber is one of my spring projects, so the release of 2.5 came at a perfect time.
adam commented 2025-12-29 17:22:52 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (Jan 27, 2019):

At our company we use only St ports per lwl patch panel (24 or 48). As normally you would use one sfp from switch and then use the cable with two st ports to the panel. As this would be easy if you could map them direct to the patch panel port but as the st ports is a single Fibre Strand you could connect them as it would be possible (Strand A (red) to p1 and Strand B (black) to p2 or p3 because maybe p2 is broken).

It would be great if the usable interfaces (only sfp and sfp+) would be allowed to map two cables on interface-side.

As this is a normal situation there should be some generic solution in netbox.

@tb-killa commented on GitHub (Jan 27, 2019): At our company we use only St ports per lwl patch panel (24 or 48). As normally you would use one sfp from switch and then use the cable with two st ports to the panel. As this would be easy if you could map them direct to the patch panel port but as the st ports is a single Fibre Strand you could connect them as it would be possible (Strand A (red) to p1 and Strand B (black) to p2 or p3 because maybe p2 is broken). It would be great if the usable interfaces (only sfp and sfp+) would be allowed to map two cables on interface-side. As this is a normal situation there should be some generic solution in netbox.
adam commented 2025-12-29 17:22:52 +01:00
Author
Owner
Copy Link

@ragzilla commented on GitHub (Feb 7, 2019):

Running into @tb-killa's issue myself, except with LC panels, modeling Rear/Front Port per fiber to allow for single fiber routes. Ideally for us there needs to be some way to have a single Cable object connect to an Interface on the A side, and 2 separate Front or Rear ports (maybe identified as Tx/Rx) on the B side.

@ragzilla commented on GitHub (Feb 7, 2019): Running into @tb-killa's issue myself, except with LC panels, modeling Rear/Front Port per fiber to allow for single fiber routes. Ideally for us there needs to be some way to have a single Cable object connect to an Interface on the A side, and 2 separate Front or Rear ports (maybe identified as Tx/Rx) on the B side.
adam commented 2025-12-29 17:22:52 +01:00
Author
Owner
Copy Link

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

I see that there starts a great discussion on:
https://groups.google.com/forum/?nomobile=true#!topic/netbox-discuss/eOdaKIhJbnw
Lets move our ideas to this discussions.

@tb-killa commented on GitHub (Feb 7, 2019): I see that there starts a great discussion on: https://groups.google.com/forum/?nomobile=true#!topic/netbox-discuss/eOdaKIhJbnw Lets move our ideas to this discussions.
adam commented 2025-12-29 17:22:55 +01:00
Author
Owner
Copy Link

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

Yes, I am also having to run into this issue as well :( Still trying to decide how to precede.

@jameswhite4684 commented on GitHub (Mar 20, 2019): Yes, I am also having to run into this issue as well :( Still trying to decide how to precede.
adam commented 2025-12-29 17:22:55 +01:00
Author
Owner
Copy Link

@Pelt10 commented on GitHub (Apr 24, 2019):

Any news about this issue ?

@Pelt10 commented on GitHub (Apr 24, 2019): Any news about this issue ?
adam commented 2025-12-29 17:22:55 +01:00
Author
Owner
Copy Link

@GaetanF commented on GitHub (Sep 3, 2019):

Hello,

Do you some news about this issue ?

A latest commit a32d185 won't permit anymore to connect a cable between two devices that don't have the same number of positions.

Example: CWDM Mutiplexer connected to a DWDM Mutiplexer or a duplex fiber on patch panel side are connected to two different devices on the other side of the fiber using simplex mode.

A recent issue #3467 based on the same topic have been closed without solution.

Thanks

@GaetanF commented on GitHub (Sep 3, 2019): Hello, Do you some news about this issue ? A latest commit [a32d185](https://github.com/netbox-community/netbox/commit/a32d185ff0308cfdbf1244e962128f8fd8dd015e) won't permit anymore to connect a cable between two devices that don't have the same number of positions. Example: CWDM Mutiplexer connected to a DWDM Mutiplexer or a duplex fiber on patch panel side are connected to two different devices on the other side of the fiber using simplex mode. A recent issue #3467 based on the same topic have been closed without solution. Thanks
adam commented 2025-12-29 17:22:55 +01:00
Author
Owner
Copy Link

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

The issues mentioned here are basically resolved as a side effect of PR #3585. It has been closed however because more discussion is needed on the architecture. The use cases described in #3633 would cover the issues in this report as well.

@steffann commented on GitHub (Oct 29, 2019): The issues mentioned here are basically resolved as a side effect of PR #3585. It has been closed however because more discussion is needed on the architecture. The use cases described in #3633 would cover the issues in this report as well.
adam commented 2025-12-29 17:22:55 +01:00
Author
Owner
Copy Link

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

@steffann Can you take another look at this given the recent work on cabling? It might not be needed anymore.

@jeremystretch commented on GitHub (Jul 24, 2020): @steffann Can you take another look at this given the recent work on cabling? It might not be needed anymore.
adam commented 2025-12-29 17:22:55 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Jul 24, 2020):

@jeremystretch has fixed the original issue in 29707cd496

As far as I can see the other issues mentioned here have also been fixed in the mean time. If there is still something wrong please open a separate issue.

@steffann commented on GitHub (Jul 24, 2020): @jeremystretch has fixed the original issue in https://github.com/netbox-community/netbox/commit/29707cd4968004eb45238c2bba11f11a3680c815 As far as I can see the other issues mentioned here have also been fixed in the mean time. If there is still something wrong please open a separate issue.
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 status: under review type: feature
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#2163
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?