DanSheps
commented
3 years ago 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.
jeremystretch
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