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

Support for Cross-Connects without circuits #2912

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

Originally created by @ryanmerolle on GitHub (Sep 26, 2019).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.6.5

Proposed Functionality

Currently, only circuit termination allows you to enter/track a cross-connect. The reality is that not all cross-connects are assigned a circuit id when the physical and logical termination of a service is just between cages/tenants in a co-location datacenter.

My thought is to tweak the circuit termination model to allow for cross-connects by adding a drop down to the cable options from just ["Interface", "Front Port", "Rear Port", "Circuit Termination"], to also include "Cross-Connect". Cross-Connect would present the circuit-terminations module without requiring a provider and circuit to be entered.

Use Case

This proposal, would allow teams to track cross-connects to meet-me rooms and carriers with circuit IDs as well as cross-connects within the same site or campus in the same inventory.

Database Changes

Set the table circuits_circuittermination to allow for null circuit_ids

External Dependencies

Originally created by @ryanmerolle on GitHub (Sep 26, 2019). ### Environment * Python version: 3.6.8 * NetBox version: 2.6.5 ### Proposed Functionality Currently, only circuit termination allows you to enter/track a cross-connect. The reality is that not all cross-connects are assigned a circuit id when the physical and logical termination of a service is just between cages/tenants in a co-location datacenter. My thought is to tweak the circuit termination model to allow for cross-connects by adding a drop down to the cable options from just ["Interface", "Front Port", "Rear Port", "Circuit Termination"], to also include "Cross-Connect". Cross-Connect would present the circuit-terminations module without requiring a provider and circuit to be entered. ### Use Case This proposal, would allow teams to track cross-connects to meet-me rooms and carriers with circuit IDs as well as cross-connects within the same site or campus in the same inventory. ### Database Changes Set the table circuits_circuittermination to allow for null circuit_ids ### External Dependencies
adam closed this issue 2025-12-29 18:23:21 +01:00
adam commented 2025-12-29 18:23:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 26, 2019):

The xconnect_id field on the CircuitTermination model predates any physical cable modeling in NetBox and really only provides a place to reference physical infrastructure outside your own organization's scope. For instance, you might have an Internet transit circuit delivered from a provider to your cage via a DC-provided cross-connect. You can associate this information with the circuit for easy reference.

If you need to model cross-connects in NetBox, you can easily represent them using either cables or circuits as appropriate. Often, a data center cross-connect is literally just a cable connecting two patch panel ports. For more complex scenarios, or cases where it's important to track the cross-connect provider, the circuit model should work.

At any rate, we spent several months hashing out the cabling model prior to the v2.5 release, and it's pretty much frozen for the near future as development efforts are focused elsewhere.

@jeremystretch commented on GitHub (Sep 26, 2019): The `xconnect_id` field on the CircuitTermination model predates any physical cable modeling in NetBox and really only provides a place to reference physical infrastructure outside your own organization's scope. For instance, you might have an Internet transit circuit delivered from a provider to your cage via a DC-provided cross-connect. You can associate this information with the circuit for easy reference. If you need to model cross-connects in NetBox, you can easily represent them using either cables or circuits as appropriate. Often, a data center cross-connect is literally just a cable connecting two patch panel ports. For more complex scenarios, or cases where it's important to track the cross-connect provider, the circuit model should work. At any rate, we spent several months hashing out the cabling model prior to the v2.5 release, and it's pretty much frozen for the near future as development efforts are focused elsewhere.
adam commented 2025-12-29 18:23:21 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Sep 27, 2019):

@jeremystretch as always I appreciate the time and thought in responding. It all makes perfect sense. I will document possible approaches here if anyone stumbles on this.

For the case I am talking about I think for anyone wanting to be consistent with the current cable model, you have two options:

  • Create patch panel devices with interface descriptions representing the crossconnect_id (also terminating circuits on the patch panel also)
  • Create providers for any third party peers and circuits for each crossconnect over a data center cross connect, then you would consistently have a crossconnect_id and WAN termination point for all these connections I think I prefer this way
@ryanmerolle commented on GitHub (Sep 27, 2019): @jeremystretch as always I appreciate the time and thought in responding. It all makes perfect sense. I will document possible approaches here if anyone stumbles on this. For the case I am talking about I think for anyone wanting to be consistent with the current cable model, you have two options: * Create patch panel devices with interface descriptions representing the crossconnect_id (also terminating circuits on the patch panel also) * Create providers for any third party peers and circuits for each crossconnect over a data center cross connect, then you would consistently have a crossconnect_id and WAN termination point for all these connections __I think I prefer this way__
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#2912
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?