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

Allow circuit terminations on wireless interfaces using wireless links #11562

New Issue
Open
opened 2025-12-29 21:46:46 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:46:46 +01:00
Owner
Copy Link

Originally created by @kate-james on GitHub (Sep 3, 2025).

NetBox version

v4.3.2

Feature type

Change to existing functionality

Proposed functionality

Core Change: Extend the existing wireless_links model to support circuit terminations on wireless interfaces, enabling logical connectivity tracking for cellular and other wireless circuits.

Specific Implementation:

  1. Wireless Link Model Enhancement:

    • Modify the wireless_links model to accept multiple types of termination (Circuit, and Interface)
    • Add support for connecting cellular circuits to wireless interfaces (similar to how cables terminate wired circuits to physical interfaces)
    • Maintain existing wireless link functionality for point-to-point interface based wireless connections

  2. Circuit Type Model Enhancement:

    • Add a connection_type field to the CircuitType model with choices: Wired and Wireless
    • This field determines whether a circuit can terminate to physical ports (via cables) or wireless interfaces (via wireless links)
    • Default to Wired for backward compatibility

Use case

Cellular circuits need to be tracked, just as wired circuits. This includes cellular WAN backup connections, IoT device connectivity, and mobile infrastructure circuits that have service provider relationships, billing, and SLA requirements identical to wired circuits.

When using a private APN the logical topology is identical to a wired circuit and modelling capabilities should reflect this.

As discussed in issues #19687 and #20218, the recent model changes removed this capability, and has impacted myself, @ross-cello, @itskeoo, and @denjs enough to step in and raise issues for this.

Workflow Example:

  1. User creates a Circuit with where the CircuitType has connection_type=Wireless
  2. User navigates to a device with a cellular interface
  3. User can terminate the wireless circuit to the cellular interface via the wireless link mechanism
    Image

Database changes

CircuitType Model:

  • Add connection_type field with choices: Wired (default), Wireless
  • Migration to set all existing circuit types to Wired for backward compatibility

WirelessLink Model:

  • Modify termination logic to support multiple object types (Circuit and Interface)
  • Add generic foreign key relationships or extend existing termination fields to handle circuit connections
  • Maintain existing interface-to-interface wireless link functionality

Validations:

  • Add restriction to prevent Wired circuits from connecting via wireless links
  • Add restriction to prevent Wireless circuits from connecting via cables
  • Ensure circuits can use only one connection method (mutual exclusivity between cable and wireless link terminations)

External dependencies

No response

Originally created by @kate-james on GitHub (Sep 3, 2025). ### NetBox version v4.3.2 ### Feature type Change to existing functionality ### Proposed functionality **Core Change:** Extend the existing `wireless_links` model to support circuit terminations on wireless interfaces, enabling logical connectivity tracking for cellular and other wireless circuits. **Specific Implementation:** 1. **Wireless Link Model Enhancement:** - Modify the `wireless_links` model to accept multiple types of termination (Circuit, and Interface) - Add support for connecting cellular circuits to wireless interfaces (similar to how cables terminate wired circuits to physical interfaces) - Maintain existing wireless link functionality for point-to-point interface based wireless connections 2. **Circuit Type Model Enhancement:** - Add a `connection_type` field to the CircuitType model with choices: `Wired` and `Wireless` - This field determines whether a circuit can terminate to physical ports (via cables) or wireless interfaces (via wireless links) - Default to `Wired` for backward compatibility ### Use case Cellular circuits need to be tracked, just as wired circuits. This includes cellular WAN backup connections, IoT device connectivity, and mobile infrastructure circuits that have service provider relationships, billing, and SLA requirements identical to wired circuits. When using a private APN the logical topology is identical to a wired circuit and modelling capabilities should reflect this. As discussed in issues #19687 and #20218, the recent model changes removed this capability, and has impacted myself, @ross-cello, @itskeoo, and @denjs enough to step in and raise issues for this. **Workflow Example:** 1. User creates a Circuit with where the CircuitType has `connection_type=Wireless` 2. User navigates to a device with a cellular interface 3. User can terminate the wireless circuit to the cellular interface via the wireless link mechanism <img width="768" height="437" alt="Image" src="https://github.com/user-attachments/assets/3004f9b7-df8d-404d-9584-c377e8d64b35" /> ### Database changes **CircuitType Model:** - Add `connection_type` field with choices: `Wired` (default), `Wireless` - Migration to set all existing circuit types to `Wired` for backward compatibility **WirelessLink Model:** - Modify termination logic to support multiple object types (Circuit and Interface) - Add generic foreign key relationships or extend existing termination fields to handle circuit connections - Maintain existing interface-to-interface wireless link functionality **Validations:** - Add restriction to prevent `Wired` circuits from connecting via wireless links - Add restriction to prevent `Wireless` circuits from connecting via cables - Ensure circuits can use only one connection method (mutual exclusivity between cable and wireless link terminations) ### External dependencies _No response_
adam added the type: featurenetboxneeds milestonestatus: backlogcomplexity: high labels 2025-12-29 21:46:46 +01:00
adam commented 2025-12-29 21:46:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 3, 2025):

Note: This FR received 11 👍 reactions within an hour of being opened, which is indicative of artificial promotion.

@jeremystretch commented on GitHub (Sep 3, 2025): Note: This FR received 11 👍 reactions within an hour of being opened, which is indicative of artificial promotion.
adam commented 2025-12-29 21:46:47 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Sep 4, 2025):

Need to review this:

Modify the wireless_links model to accept multiple types of termination (Circuit, and Interface)

This seems at odds with the discussion thread at https://github.com/netbox-community/netbox/issues/19687. Still, putting this in the backlog for further refinement.

@bctiemann commented on GitHub (Sep 4, 2025): Need to review this: > Modify the wireless_links model to accept multiple types of termination (Circuit, and Interface) This seems at odds with the discussion thread at https://github.com/netbox-community/netbox/issues/19687. Still, putting this in the backlog for further refinement.
adam commented 2025-12-29 21:46:47 +01:00
Author
Owner
Copy Link

@kate-james commented on GitHub (Sep 4, 2025):

My reading of the initial thread was that this was the preferred implementation of Ross and what was suggested by Omripresent.
I'm happy to clarify as needed if there's any confusion.

@kate-james commented on GitHub (Sep 4, 2025): My reading of the initial thread was that this was the preferred implementation of Ross and what was suggested by Omripresent. I'm happy to clarify as needed if there's any confusion.
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 complexity: high needs milestone netbox status: backlog 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#11562
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?