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

Custom/Additional Interfaces #3481

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

Originally created by @mddeff on GitHub (Mar 14, 2020).

Environment

  • docker-latest

Proposed Functionality

User-defined interfaces and cabling types. I know this issue has been addressed in #2865, #2882, #97, and many others I'm sure, but I wanted to throw my 2c in on this given those tickets are closed.

I know @jeremystretch has cited scope creep and performance degradation as specific reasons to not do a user-defined list of cable and interface types. At least as it relates performance, I'd be interested to see how much performance actually degrades as users start to define their own interfaces.

I'm sure many users here would be willing to accept some level of performance degradation in favor of having one solution to track their entire infrastructure. Even if you had custom interfaces disabled out of the box and a giant "Caveat Emptor" performance impact banner when they enable it. I'd happily accept that risk (or scale out my NetBox deployment appropriately).

Barring that, I'd like to have RF/Coax cabling and appropriate physical interfaces added. Happy to attempt a pull request as appropriate. I can also provide a list of cable and connector types if accepted.

Use Case

I have a need to track RF cables in my environment. 90% of my sites have primary or secondary WAN connectivity via SatCom or 4G connectivity which employ custom antennas. Many of my sites have VHF/UHF or microwave point to point IP radios which also use custom antennas. Finally, most of my sites have GPS for precise NTP and timing. Again, more RF cabling.

The litmus test in all of the tickets seems to be "is this an IP interface". In the use cases of SatCom, 4G, PtP VHF/UHF, and PtP Microwave, the RF interfaces on the Modems all have IPs assigned to them, and encapsulate and transport IP traffic in one way or another. The only difference are the layer 1 and 2 standards they abide by.

Database Changes

Supporting table for user defined cable and interface types.

External Dependencies

None that I'm aware of

Thank you all for making a fantastic open source product and continuously supporting it. Your work doesn't go unnoticed.

Originally created by @mddeff on GitHub (Mar 14, 2020). ### Environment * docker-latest ### Proposed Functionality User-defined interfaces and cabling types. I know this issue has been addressed in #2865, #2882, #97, and many others I'm sure, but I wanted to throw my 2c in on this given those tickets are closed. I know @jeremystretch has cited scope creep and performance degradation as specific reasons to not do a user-defined list of cable and interface types. At least as it relates performance, I'd be interested to see how much performance actually degrades as users start to define their own interfaces. I'm sure many users here would be willing to accept some level of performance degradation in favor of having one solution to track their entire infrastructure. Even if you had custom interfaces disabled out of the box and a giant "Caveat Emptor" performance impact banner when they enable it. I'd happily accept that risk (or scale out my NetBox deployment appropriately). Barring that, I'd like to have RF/Coax cabling and appropriate physical interfaces added. Happy to attempt a pull request as appropriate. I can also provide a list of cable and connector types if accepted. ### Use Case I have a need to track RF cables in my environment. 90% of my sites have primary or secondary WAN connectivity via SatCom or 4G connectivity which employ custom antennas. Many of my sites have VHF/UHF or microwave point to point IP radios which also use custom antennas. Finally, most of my sites have GPS for precise NTP and timing. Again, more RF cabling. The litmus test in all of the tickets seems to be "is this an IP interface". In the use cases of SatCom, 4G, PtP VHF/UHF, and PtP Microwave, the RF interfaces on the Modems all have IPs assigned to them, and encapsulate and transport IP traffic in one way or another. The only difference are the layer 1 and 2 standards they abide by. ### Database Changes Supporting table for user defined cable and interface types. ### External Dependencies None that I'm aware of Thank you all for making a fantastic open source product and continuously supporting it. Your work doesn't go unnoticed.
adam closed this issue 2025-12-29 18:29:26 +01:00
adam commented 2025-12-29 18:29:27 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Mar 14, 2020):

This issue has been closed as it does not conform to one of the provided templates as required by the contributing guide. If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).

@lampwins commented on GitHub (Mar 14, 2020): This issue has been closed as it does not conform to one of the [provided templates](https://github.com/digitalocean/netbox/issues/new/choose) as required by the [contributing guide](https://github.com/digitalocean/netbox/blob/master/CONTRIBUTING.md). If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).
adam commented 2025-12-29 18:29:27 +01:00
Author
Owner
Copy Link

@mddeff commented on GitHub (Mar 14, 2020):

Fixed formatting. Sorry, I found the formatting template after I had submitted the issue.

@mddeff commented on GitHub (Mar 14, 2020): Fixed formatting. Sorry, I found the formatting template after I had submitted the issue.
adam commented 2025-12-29 18:29:27 +01:00
Author
Owner
Copy Link

@mddeff commented on GitHub (Apr 3, 2020):

@lampwins I addressed the formatting issue, can we re-open this for discussion?

@mddeff commented on GitHub (Apr 3, 2020): @lampwins I addressed the formatting issue, can we re-open this for discussion?
adam commented 2025-12-29 18:29:27 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Apr 3, 2020):

There is already an open issue for tracking wireless links.

@lampwins commented on GitHub (Apr 3, 2020): There is already an [open issue](https://github.com/netbox-community/netbox/issues/3979) for tracking wireless links.
adam commented 2025-12-29 18:29:27 +01:00
Author
Owner
Copy Link

@mddeff commented on GitHub (Apr 9, 2020):

This issue is less about tracking the wireless link itself (which, is also important), but tracking the cabling between the antenna and the modem/transceiver.

@mddeff commented on GitHub (Apr 9, 2020): This issue is less about tracking the wireless link itself (which, is also important), but tracking the cabling between the antenna and the modem/transceiver.
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#3481
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?