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

Unification of interfaces with front and rear ports #5523

New Issue
Closed
opened 2025-12-29 19:28:58 +01:00 by adam · 2 comments
adam commented 2025-12-29 19:28:58 +01:00
Owner
Copy Link

Originally created by @sleepinggenius2 on GitHub (Oct 15, 2021).

NetBox version

v3.0.7

Feature type

Change to existing functionality

Proposed functionality

This feature request would have a dependency on the implementation of #6346 and #7552.

The proposal would be be to eliminate the existing front and rear port models and replace them with interfaces and cross-connects. Multi-position rear ports could be implemented with breakout sub-interfaces. The one-to-one bridge connections or cross-connects would link the front and rear interfaces together, just like is done with front and rear ports today. Adding the ability to specify cross-connects as part of a device template would allow for consistency between the old and new implementations.

Use case

There are a number of scenarios when interfaces have connectors that are currently only available through front and rear ports. Two examples I have seen frequently are F connectors on DOCSIS devices, like cable modems and CMTSes, and fixed fiber connectors on active optical equipment, especially for ROADM and PON.

In order to represent a bridged cable modem in the current platform, the only options I've figured out are to create a rear F Connector port with a front 8P8C port to be able to trace trough the device or an Other type interface to represent the HFC side and a regular copper FE or GE port to represent the LAN side. The second option is the only way that I've found to associate MAC and IP addresses to the interfaces. For an eMTA, the phone ports can be represented as 6P4C or 6P2C front ports in the first option, with relatively meaningless rear positions, but would also need to have an Other type in the second option. The workarounds for a cable modem are annoying, but trying to represent a CMTS in the current platform has been a real nightmare.

On an optical service card on a ROADM node, there's often a fixed fiber connector (usually LC) for the DWDM trunk and a pluggable for the client interface. Again, the trunk interface would need to be represented as an Other type in the current platform in order to document the correct optic type for the client interface. You often see this kind of fixed connector on a PON ONT as well.

Collapsing three models down into one should help from a user experience standpoint, by not having to remember whether it was a front port, rear port, or interface that you need to connect a cable to. I make this mistake all the time, especially when having to have front/rear ports for combiner/splitter or mux/demux, because the use of front and rear ports don't always relate to their actual positions on the device. There often has to be a balance between documentation for the engineering team and potential confusion for the field technicians. Combined with #7553, this could also finally allow us to be able to properly represent WDM networks, which would be amazing.

Database changes

This shouldn't require any new fields, but might allow for eliminating some existing models.

External dependencies

None

Originally created by @sleepinggenius2 on GitHub (Oct 15, 2021). ### NetBox version v3.0.7 ### Feature type Change to existing functionality ### Proposed functionality This feature request would have a dependency on the implementation of #6346 and #7552. The proposal would be be to eliminate the existing front and rear port models and replace them with interfaces and cross-connects. Multi-position rear ports could be implemented with breakout sub-interfaces. The one-to-one bridge connections or cross-connects would link the front and rear interfaces together, just like is done with front and rear ports today. Adding the ability to specify cross-connects as part of a device template would allow for consistency between the old and new implementations. ### Use case There are a number of scenarios when interfaces have connectors that are currently only available through front and rear ports. Two examples I have seen frequently are F connectors on DOCSIS devices, like cable modems and CMTSes, and fixed fiber connectors on active optical equipment, especially for ROADM and PON. In order to represent a bridged cable modem in the current platform, the only options I've figured out are to create a rear F Connector port with a front 8P8C port to be able to trace trough the device or an *Other* type interface to represent the HFC side and a regular copper FE or GE port to represent the LAN side. The second option is the only way that I've found to associate MAC and IP addresses to the interfaces. For an eMTA, the phone ports can be represented as 6P4C or 6P2C front ports in the first option, with relatively meaningless rear positions, but would also need to have an *Other* type in the second option. The workarounds for a cable modem are annoying, but trying to represent a CMTS in the current platform has been a real nightmare. On an optical service card on a ROADM node, there's often a fixed fiber connector (usually LC) for the DWDM trunk and a pluggable for the client interface. Again, the trunk interface would need to be represented as an *Other* type in the current platform in order to document the correct optic type for the client interface. You often see this kind of fixed connector on a PON ONT as well. Collapsing three models down into one should help from a user experience standpoint, by not having to remember whether it was a front port, rear port, or interface that you need to connect a cable to. I make this mistake all the time, especially when having to have front/rear ports for combiner/splitter or mux/demux, because the use of front and rear ports don't always relate to their actual positions on the device. There often has to be a balance between documentation for the engineering team and potential confusion for the field technicians. Combined with #7553, this could also finally allow us to be able to properly represent WDM networks, which would be amazing. ### Database changes This shouldn't require any new fields, but might allow for eliminating some existing models. ### External dependencies None
adam added the type: feature label 2025-12-29 19:28:58 +01:00
adam closed this issue 2025-12-29 19:28:58 +01:00
adam commented 2025-12-29 19:28:59 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 19, 2021):

I want to add some comments here as I fear you may be mis-using NetBox

In order to represent a bridged cable modem in the current platform, the only options I've figured out are to create a rear F Connector port with a front 8P8C port to be able to trace trough the device or an Other type interface to represent the HFC side and a regular copper FE or GE port to represent the LAN side. The second option is the only way that I've found to associate MAC and IP addresses to the interfaces. For an eMTA, the phone ports can be represented as 6P4C or 6P2C front ports in the first option, with relatively meaningless rear positions, but would also need to have an Other type in the second option. The workarounds for a cable modem are annoying, but trying to represent a CMTS in the current platform has been a real nightmare.

A Bridged cable modem is still going to be a L2 device, it isn't a L1 device, which is what the cable trace traces through. You should be "hard stopping" at the cable modem on a trace and then picking up a new trace after.

On an optical service card on a ROADM node, there's often a fixed fiber connector (usually LC) for the DWDM trunk and a pluggable for the client interface. Again, the trunk interface would need to be represented as an Other type in the current platform in order to document the correct optic type for the client interface. You often see this kind of fixed connector on a PON ONT as well.

Are the ROADM node ports configurable for items such as MAC address, IP, etc (beyond reconfiguring the "light path", sorry, not 100% familiar with SP equipment)? If so, then perhaps there is merit to your request for this instance.

General rule of thumb: If the "traffic" going through a "interface" is L1, then it is a passthru port (front or rear). If it is L2 traffic, that is a interface and the trace will stop at that interface

Collapsing three models down into one should help from a user experience standpoint, by not having to remember whether it was a front port, rear port, or interface that you need to connect a cable to.

Unfortunately we most likely will not be collapsing the models as there are technical issues with doing so (How do you determine where to stop a trace? for example). The cable trace/path model is relatively fixed at this time and will likely not change significantly.

@DanSheps commented on GitHub (Oct 19, 2021): I want to add some comments here as I fear you may be mis-using NetBox > In order to represent a bridged cable modem in the current platform, the only options I've figured out are to create a rear F Connector port with a front 8P8C port to be able to trace trough the device or an Other type interface to represent the HFC side and a regular copper FE or GE port to represent the LAN side. The second option is the only way that I've found to associate MAC and IP addresses to the interfaces. For an eMTA, the phone ports can be represented as 6P4C or 6P2C front ports in the first option, with relatively meaningless rear positions, but would also need to have an Other type in the second option. The workarounds for a cable modem are annoying, but trying to represent a CMTS in the current platform has been a real nightmare. A Bridged cable modem is still going to be a L2 device, it isn't a L1 device, which is what the cable trace traces through. You should be "hard stopping" at the cable modem on a trace and then picking up a new trace after. > On an optical service card on a ROADM node, there's often a fixed fiber connector (usually LC) for the DWDM trunk and a pluggable for the client interface. Again, the trunk interface would need to be represented as an Other type in the current platform in order to document the correct optic type for the client interface. You often see this kind of fixed connector on a PON ONT as well. Are the ROADM node ports configurable for items such as MAC address, IP, etc (beyond reconfiguring the "light path", sorry, not 100% familiar with SP equipment)? If so, then perhaps there is merit to your request for this instance. General rule of thumb: If the "traffic" going through a "interface" is L1, then it is a passthru port (front or rear). If it is L2 traffic, that is a interface and the trace will stop at that interface > Collapsing three models down into one should help from a user experience standpoint, by not having to remember whether it was a front port, rear port, or interface that you need to connect a cable to. Unfortunately we most likely will not be collapsing the models as there are technical issues with doing so (How do you determine where to stop a trace? for example). The cable trace/path model is relatively fixed at this time and will likely not change significantly.
adam commented 2025-12-29 19:28:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 11, 2021):

The proposal would be be to eliminate the existing front and rear port models and replace them with interfaces and cross-connects.

I'm just going to be honest here: This is a non-starter for me. We're not going to upend such a huge chunk of the data model for pretty much any reason as it would be enormously taxing and disruptive. It's just not something we're going to consider giving everything else biding for precious development time. Maybe it's something to consider in the distant future, but it's not worth considering any further at this point I'm afraid.

As @DanSheps points out, there may be better ways to model what you're trying to accomplish. Also of relevance is the new bridging functionality being introduced in v3.1 (#6346). I strongly recommend trying that out.

@jeremystretch commented on GitHub (Nov 11, 2021): > The proposal would be be to eliminate the existing front and rear port models and replace them with interfaces and cross-connects. I'm just going to be honest here: This is a non-starter for me. We're not going to upend such a huge chunk of the data model for pretty much any reason as it would be enormously taxing and disruptive. It's just not something we're going to consider giving everything else biding for precious development time. Maybe it's something to consider in the distant future, but it's not worth considering any further at this point I'm afraid. As @DanSheps points out, there may be better ways to model what you're trying to accomplish. Also of relevance is the new bridging functionality being introduced in v3.1 (#6346). I strongly recommend trying that out.
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 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#5523
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?