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

add length to circuits for documentation and cable trace #4739

New Issue
Closed
opened 2025-12-29 19:20:01 +01:00 by adam · 5 comments
adam commented 2025-12-29 19:20:01 +01:00
Owner
Copy Link

Originally created by @julianze on GitHub (Apr 8, 2021).

NetBox version

v2.10.8

Feature type

Data model extension

Proposed functionality

documentation
add attribute "length" with "unit" to the circuit model, so we can put there the length of the circuit.

path traces
Path traces are now working in 2.11-beta1 over circuits (#6071, thanks a lot!!) it would be great if we can calculate the circuit length on top of the rest path.
The path logic has to be extended to add the circuit length (if available) to the complete length of the path.
The path view should show the circuit length (example see below) and the complete length should include the circuit length

Use case

circuits are used in different ways:

  • unknown internet line (with new provider network)
  • dsl line (length of the last mile is interesting)
  • connections between sites
    • unknown connection, like active mpls connection over provider backbone
    • passive fiber/copper connectoin, like dark fiber

When tracing paths over circuits only the linked cables are part of the calculation.
But these end-to-end path (interface to interface) is quite longer, because of the physical length of the circuit.

We use circuits to connect many sites in our backbone network (datacenters and network nodes) together.
Most of them are passive fiber connections with cwdm/dwdms on both sites. Some paths (interface to interface) are tracing over 2-3 circuits.
With the total length of this path (cables + circuit) we can determine the required optics (10km, 20km, 40km, 80km) and otdr measurements can be compared to identify wrong cablings.

Database changes

new field "length" and "unit" in the circuit model as it exists for cables. Not as a required field, because not all use cases will have a known length of the circuit.

External dependencies

No response

Originally created by @julianze on GitHub (Apr 8, 2021). ### NetBox version v2.10.8 ### Feature type Data model extension ### Proposed functionality **documentation** add attribute "length" with "unit" to the circuit model, so we can put there the length of the circuit. **path traces** Path traces are now working in 2.11-beta1 over circuits (#6071, thanks a lot!!) it would be great if we can calculate the circuit length on top of the rest path. The path logic has to be extended to add the circuit length (if available) to the complete length of the path. The path view should show the circuit length (example see below) and the complete length should include the circuit length ### Use case circuits are used in different ways: * unknown internet line (with new provider network) * dsl line (length of the last mile is interesting) * connections between sites * unknown connection, like active mpls connection over provider backbone * passive fiber/copper connectoin, like dark fiber When tracing paths over circuits only the linked cables are part of the calculation. But these end-to-end path (interface to interface) is quite longer, because of the physical length of the circuit. We use circuits to connect many sites in our backbone network (datacenters and network nodes) together. Most of them are passive fiber connections with cwdm/dwdms on both sites. Some paths (interface to interface) are tracing over 2-3 circuits. With the total length of this path (cables + circuit) we can determine the required optics (10km, 20km, 40km, 80km) and otdr measurements can be compared to identify wrong cablings. ### Database changes new field "length" and "unit" in the circuit model as it exists for cables. Not as a required field, because not all use cases will have a known length of the circuit. ### External dependencies _No response_
adam added the type: featurepending closure labels 2025-12-29 19:20:01 +01:00
adam closed this issue 2025-12-29 19:20:01 +01:00
adam commented 2025-12-29 19:20:02 +01:00
Author
Owner
Copy Link

@julianze commented on GitHub (Apr 8, 2021):

This seems to bei related to #5806 .

I agree that long cables aren't the right abstraction layer to connect sites.

With #6071 and this feature request we can solve #5806.
Adding the new length field with a bigger integer and we can represent circuits longer than 33.000 Meters, which ist quite real. The existing cable model has not to be changed.

@proudbro can then use circuits (correct way) instead of cables without loosing the cable trace function at all and the total physical length of the path.

@julianze commented on GitHub (Apr 8, 2021): This seems to bei related to #5806 . I agree that long cables aren't the right abstraction layer to connect sites. With #6071 and this feature request we can solve #5806. Adding the new length field with a bigger integer and we can represent circuits longer than 33.000 Meters, which ist quite real. The existing cable model has not to be changed. @proudbro can then use circuits (correct way) instead of cables without loosing the cable trace function at all and the total physical length of the path.
adam commented 2025-12-29 19:20:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 14, 2021):

I don't think it makes sense to support a length attribute for circuits. Circuits are meant to be abstract to the point where their actual length is irrelevant. You're also unlikely to sum, for instance, the length of a 20Km circuit and the two 10m cables attached at either end.

I admit there's some gray area around e.g. long-haul dark fiber as discussed in #5806, but I'd be more inclined to support extensions to the cabling model to better support this use case rather than extend the circuit model to mimic cables.

@jeremystretch commented on GitHub (Apr 14, 2021): I don't think it makes sense to support a length attribute for circuits. Circuits are meant to be abstract to the point where their actual length is irrelevant. You're also unlikely to sum, for instance, the length of a 20Km circuit and the two 10m cables attached at either end. I admit there's some gray area around e.g. long-haul dark fiber as discussed in #5806, but I'd be more inclined to support extensions to the cabling model to better support this use case rather than extend the circuit model to mimic cables.
adam commented 2025-12-29 19:20:02 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 14, 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 (Jun 14, 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 2025-12-29 19:20:02 +01:00
Author
Owner
Copy Link

@julianze commented on GitHub (Jul 13, 2021):

Are there any thoughts about my post in #5806 to implement both scenarios (#5806 + #6122)?
https://github.com/netbox-community/netbox/issues/5806#issuecomment-826362019

I have thought about it again.
Maybe there could be another solution with coupling/linking a circuit with an cable?
There could be a checkbox (threat ad cable) which will create a cable when creating the circuits. Could be a little hickup to bind those two models together, but er haven't to add circuits to the cable tracing model. The length with long units ist now available in #5806.
In the cable tracing we have to show only a hint/link to the circuit, which ist linked to the cable.

Again, i would bei ready for a volunteer :)

@julianze commented on GitHub (Jul 13, 2021): Are there any thoughts about my post in #5806 to implement both scenarios (#5806 + #6122)? https://github.com/netbox-community/netbox/issues/5806#issuecomment-826362019 I have thought about it again. Maybe there could be another solution with coupling/linking a circuit with an cable? There could be a checkbox (threat ad cable) which will create a cable when creating the circuits. Could be a little hickup to bind those two models together, but er haven't to add circuits to the cable tracing model. The length with long units ist now available in #5806. In the cable tracing we have to show only a hint/link to the circuit, which ist linked to the cable. Again, i would bei ready for a volunteer :)
adam commented 2025-12-29 19:20:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 30, 2021):

With the implementation of #5806 in the upcoming v3.0 release, the use case has been addressed: If you need to track the physical distance of long-haul connections, use a cable. Otherwise, use a circuit.

@jeremystretch commented on GitHub (Jul 30, 2021): With the implementation of #5806 in the upcoming v3.0 release, the use case has been addressed: If you need to track the physical distance of long-haul connections, use a cable. Otherwise, use a circuit.
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 pending closure 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#4739
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?