mirror of
https://github.com/netbox-community/netbox.git
synced 2026-01-11 21:10:29 +01:00
Form factor for PON interfaces #2373
Closed
opened 2025-12-29 17:25:25 +01:00 by adam
·
16 comments
No Branch/Tag Specified
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
v4.5.0
v4.4.10
v4.4.9
v4.5.0-beta1
v4.4.8
v4.4.7
v4.4.6
v4.4.5
v4.4.4
v4.4.3
v4.4.2
v4.4.1
v4.4.0
v4.3.7
v4.4.0-beta1
v4.3.6
v4.3.5
v4.3.4
v4.3.3
v4.3.2
v4.3.1
v4.3.0
v4.2.9
v4.3.0-beta2
v4.2.8
v4.3.0-beta1
v4.2.7
v4.2.6
v4.2.5
v4.2.4
v4.2.3
v4.2.2
v4.2.1
v4.2.0
v4.1.11
v4.1.10
v4.1.9
v4.1.8
v4.2-beta1
v4.1.7
v4.1.6
v4.1.5
v4.1.4
v4.1.3
v4.1.2
v4.1.1
v4.1.0
v4.0.11
v4.0.10
v4.0.9
v4.1-beta1
v4.0.8
v4.0.7
v4.0.6
v4.0.5
v4.0.3
v4.0.2
v4.0.1
v4.0.0
v3.7.8
v3.7.7
v4.0-beta2
v3.7.6
v3.7.5
v4.0-beta1
v3.7.4
v3.7.3
v3.7.2
v3.7.1
v3.7.0
v3.6.9
v3.6.8
v3.6.7
v3.7-beta1
v3.6.6
v3.6.5
v3.6.4
v3.6.3
v3.6.2
v3.6.1
v3.6.0
v3.5.9
v3.6-beta2
v3.5.8
v3.6-beta1
v3.5.7
v3.5.6
v3.5.5
v3.5.4
v3.5.3
v3.5.2
v3.5.1
v3.5.0
v3.4.10
v3.4.9
v3.5-beta2
v3.4.8
v3.5-beta1
v3.4.7
v3.4.6
v3.4.5
v3.4.4
v3.4.3
v3.4.2
v3.4.1
v3.4.0
v3.3.10
v3.3.9
v3.4-beta1
v3.3.8
v3.3.7
v3.3.6
v3.3.5
v3.3.4
v3.3.3
v3.3.2
v3.3.1
v3.3.0
v3.2.9
v3.2.8
v3.3-beta2
v3.2.7
v3.3-beta1
v3.2.6
v3.2.5
v3.2.4
v3.2.3
v3.2.2
v3.2.1
v3.2.0
v3.1.11
v3.1.10
v3.2-beta2
v3.1.9
v3.2-beta1
v3.1.8
v3.1.7
v3.1.6
v3.1.5
v3.1.4
v3.1.3
v3.1.2
v3.1.1
v3.1.0
v3.0.12
v3.0.11
v3.0.10
v3.1-beta1
v3.0.9
v3.0.8
v3.0.7
v3.0.6
v3.0.5
v3.0.4
v3.0.3
v3.0.2
v3.0.1
v3.0.0
v2.11.12
v3.0-beta2
v2.11.11
v2.11.10
v3.0-beta1
v2.11.9
v2.11.8
v2.11.7
v2.11.6
v2.11.5
v2.11.4
v2.11.3
v2.11.2
v2.11.1
v2.11.0
v2.10.10
v2.10.9
v2.11-beta1
v2.10.8
v2.10.7
v2.10.6
v2.10.5
v2.10.4
v2.10.3
v2.10.2
v2.10.1
v2.10.0
v2.9.11
v2.10-beta2
v2.9.10
v2.10-beta1
v2.9.9
v2.9.8
v2.9.7
v2.9.6
v2.9.5
v2.9.4
v2.9.3
v2.9.2
v2.9.1
v2.9.0
v2.9-beta2
v2.8.9
v2.9-beta1
v2.8.8
v2.8.7
v2.8.6
v2.8.5
v2.8.4
v2.8.3
v2.8.2
v2.8.1
v2.8.0
v2.7.12
v2.7.11
v2.7.10
v2.7.9
v2.7.8
v2.7.7
v2.7.6
v2.7.5
v2.7.4
v2.7.3
v2.7.2
v2.7.1
v2.7.0
v2.6.12
v2.6.11
v2.6.10
v2.6.9
v2.7-beta1
Solcon-2020-01-06
v2.6.8
v2.6.7
v2.6.6
v2.6.5
v2.6.4
v2.6.3
v2.6.2
v2.6.1
v2.6.0
v2.5.13
v2.5.12
v2.6-beta1
v2.5.11
v2.5.10
v2.5.9
v2.5.8
v2.5.7
v2.5.6
v2.5.5
v2.5.4
v2.5.3
v2.5.2
v2.5.1
v2.5.0
v2.4.9
v2.5-beta2
v2.4.8
v2.5-beta1
v2.4.7
v2.4.6
v2.4.5
v2.4.4
v2.4.3
v2.4.2
v2.4.1
v2.4.0
v2.3.7
v2.4-beta1
v2.3.6
v2.3.5
v2.3.4
v2.3.3
v2.3.2
v2.3.1
v2.3.0
v2.2.10
v2.3-beta2
v2.2.9
v2.3-beta1
v2.2.8
v2.2.7
v2.2.6
v2.2.5
v2.2.4
v2.2.3
v2.2.2
v2.2.1
v2.2.0
v2.1.6
v2.2-beta2
v2.1.5
v2.2-beta1
v2.1.4
v2.1.3
v2.1.2
v2.1.1
v2.1.0
v2.0.10
v2.1-beta1
v2.0.9
v2.0.8
v2.0.7
v2.0.6
v2.0.5
v2.0.4
v2.0.3
v2.0.2
v2.0.1
v2.0.0
v2.0-beta3
v1.9.6
v1.9.5
v2.0-beta2
v1.9.4-r1
v1.9.3
v2.0-beta1
v1.9.2
v1.9.1
v1.9.0-r1
v1.8.4
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.7.3
v1.7.2-r1
v1.7.1
v1.7.0
v1.6.3
v1.6.2-r1
v1.6.1-r1
1.6.1
v1.6.0
v1.5.2
v1.5.1
v1.5.0
v1.4.2
v1.4.1
v1.4.0
v1.3.2
v1.3.1
v1.3.0
v1.2.2
v1.2.1
v1.2.0
v1.1.0
v1.0.7-r1
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3-r1
v1.0.3
1.0.0
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
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
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/netbox#2373
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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?
Originally created by @candlerb on GitHub (Feb 13, 2019).
Environment
Proposed Functionality
Add form factor for PON interfaces (G-PON, XG-PON).
Use Case
Modelling POP which contains Optical Line Termination (OLT) devices. These connect to frontports on ODFs and/or circuits.
Currently you are forced to use either 'Other' or to pick some other form factor which you don't use (e.g. FibreChannel).
Database Changes
None - form factors are a static list in code.
(Making form factors configurable in database was rejected in #84 / #97)
External Dependencies
None
@jeremystretch commented on GitHub (Feb 13, 2019):
Why wouldn't these be modeled as pass-through ports?
@candlerb commented on GitHub (Feb 13, 2019):
Interesting idea.
I just tried creating OLT interfaces as "frontports", but Netbox doesn't allow you to do this without a corresponding "rearport" to link it to.
I was able to create the OLT interface as a "rearport", and then run a cable from that rearport to the frontport of an ODF.
Problems with this approach are:
@jeremystretch commented on GitHub (Feb 13, 2019):
Will be fixed under #2758
Same with media convertors and active taps. "Pass-through" doesn't necessarily mean there's an uninterrupted physical path. It just means that what goes in the front port comes out the rear port (and vice versa); there is no forwarding decision being made.
@candlerb commented on GitHub (Feb 13, 2019):
That's correct for media convertors and active taps, but an OLT port doesn't have a corresponding rear port. The "rear port", if anything, is the electronics on the line card.
@candlerb commented on GitHub (Feb 13, 2019):
Maybe I should just clarify GPON topology and terminology.
An OLT (Optical Line Termination) is the exchange-side device of a GPON network. It appears to all intents and purposes like a switch.
There are usually one or more 10G ports on the service provider side, where each service is delivered as a separate tagged VLAN. The customer-facing side is a bunch of PON ports each driving a single fibre strand (transmit/receive on different wavelengths). These go via passive optical splitters, so that typically one OLT port is shared between 32 subscribers.
Each subscriber has an ONT (Optical Network Termination) with an ethernet port on it. The ethernet packets going in and out of this port end up on the 10G ports of the OLT. The ONT is responsible for filtering out traffic not destined for that particular subscriber. The OLT knows which PON port each subscriber is on, and sends the traffic out of the right port.
So an OLT is essentially a fancy switch, where each PON port connects to a 33-port hub with 32 subscribers on it.
EDIT: for my use case I'm only concerned with modelling the OLT in the POP. The incoming fibres can be circuits arriving on the rear port of an ODF, and then there's a cable from the ODF front port to the OLT port. I don't need to model the external plant (splitters and ONTs)
@ChrisWilkins82 commented on GitHub (Feb 14, 2019):
I would think that you're best option would be to model the OLT ports to the passive splitters, and then connect the ONTs/ONUs (depending on your flavor of PON) to the splitters. The OLT ports can only be physically connected to one fiber, which then gets broken out in the field.
The only change to Netbox would be to add the various flavors of PON ports as a valid 1:1 connection option, everything else you would need is already there.
@candlerb commented on GitHub (Feb 14, 2019):
Yes, suitable interface type is all I'm asking for. I have tested using Circuits for the connection from OLT (where the circuit name is the splitter ID) and this works.
@DanSheps commented on GitHub (Feb 23, 2019):
What interface types were you thinking?
@candlerb commented on GitHub (Feb 25, 2019):
These are Calix E7-20. The slot is physically SFP but you can't plug a regular SFP module into it - they only take GPON Optical Interface Modules. So I think "SFP (GPON)" under the existing variants of SFP would be the best solution here.
There are actually different types of GPON SFP which can be plugged in (e.g. "B+" and "C+") but that's an attribute of the SFP module, not the interface.
@ChrisWilkins82 commented on GitHub (Feb 25, 2019):
You've also got the IEEE PON standards, GePON (SFP) and EPON (XFP & SFP+).
Off of the top of my head you'd need GPON, BPON, GePON, & EPON, but I could
be missing some standards in there that I'm not familiar with.
On Mon, Feb 25, 2019 at 3:21 AM Brian Candler notifications@github.com
wrote:
--
Respectfully,
Chris Wilkins
@DanSheps commented on GitHub (Mar 6, 2019):
Could we get a list of commercially available PON interfaces?
@candlerb commented on GitHub (Mar 6, 2019):
On the card side, all I've come across is a PON SFP slot. On the PON side there are various standards
I would be inclined to start with:
and see if there is demand for anything else.
@ChrisWilkins82 commented on GitHub (Mar 7, 2019):
You also have IEEE's EPON, that comes in 1G & 10G flavors; 1G is only SFP,
and 10G is XFP. As can be seen by this platform:
https://www.sumitomoelectric.com/cms/wp-content/uploads/2016/01/FSU7100.pdf.
It's what I have the most experience with, and where I'm basing the 10G XFP
optics from. IEEE has moved away from a distinction between GePON and EPON,
as you can see from that PDF, they're only referencing 1G and 10G PON,
which has all been rolled into EPON.
Given that you really only have two optic formats between the ITU and IEEE
standards, it's probably easiest to just reference the optics themselves
for this.
Something like this makes sense to me:
PON - SFP
PON - XFP
On Wed, Mar 6, 2019 at 7:36 AM Brian Candler notifications@github.com
wrote:
--
Respectfully,
Chris Wilkins
@candlerb commented on GitHub (Mar 7, 2019):
I am good with that.
@sinewaveinc commented on GitHub (Jul 11, 2019):
There's also XGS-PON, which is different from XG-PON and TWDM-PON (NGPON2). If you are going to model the optics, I would hope to include the frequencies of said optics.
@jeremystretch commented on GitHub (Dec 13, 2019):
Closing this out as no one has proposed an exact list of interface types to be included. Please see
InterfaceTypeChoicesindcim/choices.pyfor reference (NetBox v2.7 and later). If you would like to propose the addition of specific types, please open a new feature request including the exact values that you are proposing.