Multiple termination sides for Curcuits #6379

New Issue

adam · 2025-12-29T19:40:03+01:00

adam commented

2025-12-29 19:40:03 +01:00

Originally created by @AndMrzv on GitHub (Apr 19, 2022).

NetBox version

v3.1.10

Feature type

Data model extension

Proposed functionality

Allow Curcuits to have multiple termination sides (now they can have 0-2).

Use case

Bus network.
Using Circuits in a meaning of a communication line between multiple objects (typically few Racks, provider side). Such a line may be complex but it is in fact a single unit in every regard, making it to be this way in Netbox would provide much cleaner experience than storing it as a bunch of Circuits all connected together.

Database changes

No response

External dependencies

No response

Originally created by @AndMrzv on GitHub (Apr 19, 2022). ### NetBox version v3.1.10 ### Feature type Data model extension ### Proposed functionality Allow Curcuits to have multiple termination sides (now they can have 0-2). ### Use case Bus network. Using Circuits in a meaning of a communication line between multiple objects (typically few Racks, provider side). Such a line may be complex but it is in fact a single unit in every regard, making it to be this way in Netbox would provide much cleaner experience than storing it as a bunch of Circuits all connected together. ### Database changes _No response_ ### External dependencies _No response_

adam added the type: feature label 2025-12-29 19:40:03 +01:00

adam closed this issue

2025-12-29 19:40:03 +01:00

adam commented

2025-12-29 19:40:03 +01:00

@jeremystretch commented on GitHub (Apr 19, 2022):

Bus network.

Please provide a real-world example of your cited use case.

@jeremystretch commented on GitHub (Apr 19, 2022): > Bus network. Please provide a real-world example of your cited use case.

adam commented

2025-12-29 19:40:03 +01:00

@AndMrzv commented on GitHub (Apr 20, 2022):

Please provide a real-world example of your cited use case.

I thought in terms of BNC or CAN to support my cause but probably not many people use coaxial nowdays.
But we do have for example big comm lines that go across few of our data-centers stringing them all together. Said line or a channel (sorry, English is not my first, I hope you'll be able to understand) includes our own connections, external provider conenctions, maybe some other ifrastructural cable lines. And this is managed as a whole.

@AndMrzv commented on GitHub (Apr 20, 2022): > Please provide a real-world example of your cited use case. I thought in terms of BNC or CAN to support my cause but probably not many people use coaxial nowdays. But we do have for example big comm lines that go across few of our data-centers stringing them all together. Said line or a channel (sorry, English is not my first, I hope you'll be able to understand) includes our own connections, external provider conenctions, maybe some other ifrastructural cable lines. And this is managed as a whole.

adam commented

2025-12-29 19:40:04 +01:00

@AnythingOverIP commented on GitHub (Apr 20, 2022):

A real world example would be a point-to-multipoint circuits. We have a few circuits that are provided to us that are, at a high level, an extended private VLAN over Metro-Ethernet. I currently model the site to provider "cable", and model a circuit in Netbox for every possibility (i.e.: Site A to B, Site A to C, Site B to C) as we don't have many of those circuit type (only two 3-ends circuits). I would see why somebody would like that type of model.

Another real-world example would be a ISP-provided MPLS network which would also a point-to-multipoint circuit.

@AnythingOverIP commented on GitHub (Apr 20, 2022): A real world example would be a point-to-multipoint circuits. We have a few circuits that are provided to us that are, at a high level, an extended private VLAN over Metro-Ethernet. I currently model the site to provider "cable", and model a circuit in Netbox for every possibility (i.e.: Site A to B, Site A to C, Site B to C) as we don't have many of those circuit type (only two 3-ends circuits). I would see why somebody would like that type of model. Another real-world example would be a ISP-provided MPLS network which would also a point-to-multipoint circuit.

adam commented

2025-12-29 19:40:04 +01:00

@jeremystretch commented on GitHub (Apr 20, 2022):

I thought in terms of BNC or CAN to support my cause but probably not many people use coaxial nowdays.

If anything, these would be modeled as cables rather than circuits, but I think it's fair to say that NetBox simply doesn't support them as they're no longer in common use in modern networks.

But we do have for example big comm lines that go across few of our data-centers stringing them all together.

These would be modeled as individual circuits in NetBox.

A real world example would be a point-to-multipoint circuits

This has been brought up numerous times. The summary is that each leg of a point-to-multipoint topology is its own circuit, with its own circuit ID, and should be modeled as such. (Consider the process for ordering and installing a new spoke circuit.) Mesh and point-to-multipoint topologies would be modeled as virtual circuits on top of the physical infrastructure; something we plan to implement eventually though to date no one has proposed a specific scheme.

I'm going to close this FR as it would not make sense to allow more than two terminations per circuit, but I encourage anyone interested to come up with a proposal for modeling virtual circuits. (If you choose to take this on, please be sure to include a detailed implementation plan including database changes with your future FR.)

@jeremystretch commented on GitHub (Apr 20, 2022): > I thought in terms of BNC or CAN to support my cause but probably not many people use coaxial nowdays. If anything, these would be modeled as cables rather than circuits, but I think it's fair to say that NetBox simply doesn't support them as they're no longer in common use in modern networks. > But we do have for example big comm lines that go across few of our data-centers stringing them all together. These would be modeled as individual circuits in NetBox. > A real world example would be a point-to-multipoint circuits This has been brought up numerous times. The summary is that each leg of a point-to-multipoint topology is its own circuit, with its own circuit ID, and should be modeled as such. (Consider the process for ordering and installing a new spoke circuit.) Mesh and point-to-multipoint topologies would be modeled as virtual circuits on top of the physical infrastructure; something we plan to implement eventually though to date no one has proposed a specific scheme. I'm going to close this FR as it would not make sense to allow more than two terminations per circuit, but I encourage anyone interested to come up with a proposal for modeling virtual circuits. (If you choose to take this on, please be sure to include a detailed implementation plan including database changes with your future FR.)

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#6379