jeremystretch
commented
5 years ago 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.
ryanmerolle
Environment
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