Add PON ports to interface type #6072

@DorianBourgeoisat commented on GitHub (Feb 15, 2022):

I can try to work on this if no one's opposed

@DorianBourgeoisat commented on GitHub (Feb 15, 2022): I can try to work on this if no one's opposed

adam commented

@DanSheps commented on GitHub (Feb 15, 2022):

Duplicate of #4302

@DanSheps commented on GitHub (Feb 15, 2022): Duplicate of #4302

adam commented

@DanSheps commented on GitHub (Feb 15, 2022):

Can you provide a list of actual physical interface types you wish to model?

@DanSheps commented on GitHub (Feb 15, 2022): Can you provide a list of actual physical interface types you wish to model?

adam commented

@BrunoBlanes commented on GitHub (Feb 15, 2022):

Sure, I'll compile those and add them to the original text of this issue.

@BrunoBlanes commented on GitHub (Feb 15, 2022): Sure, I'll compile those and add them to the original text of this issue.

adam commented

@DorianBourgeoisat commented on GitHub (Feb 16, 2022):

The list would resemble that :
GPON:
SFP GPON OLT (2.5G)
SFP+ XG-PON OLT (10G)
SFP+ XGS-PON OLT (10G)
SFP+ CPON OLT (10G/2.5G) *
SFP+ TWDM-PON OLT (10G)
XFP XG-PON OLT (10G)
XFP XGS-PON OLT (10G)
XFP TWDM-PON OLT (10G)

EPON:
SFP EPON OLT (1G)
SFP+ 10G-EPON OLT (10G)

I also think generic ONT PON types could be useful :
GPON ONT (2.5G)
XG-PON ONT (10G)
XGS-PON ONT (10G)
EPON ONT (1G)
10G-EPON ONT (10G)

I suggest the removal of this type because it could be modeled by 2 interfaces of the desired combo, if I understood correctly what was intended in the first issue.

@DorianBourgeoisat commented on GitHub (Feb 16, 2022): The list would resemble that : GPON: SFP GPON OLT (2.5G) SFP+ XG-PON OLT (10G) SFP+ XGS-PON OLT (10G) SFP+ CPON OLT (10G/2.5G) * SFP+ TWDM-PON OLT (10G) XFP XG-PON OLT (10G) XFP XGS-PON OLT (10G) XFP TWDM-PON OLT (10G) EPON: SFP EPON OLT (1G) SFP+ 10G-EPON OLT (10G) I also think generic ONT PON types could be useful : GPON ONT (2.5G) XG-PON ONT (10G) XGS-PON ONT (10G) EPON ONT (1G) 10G-EPON ONT (10G) * I suggest the removal of this type because it could be modeled by 2 interfaces of the desired combo, if I understood correctly what was intended in the first issue.

adam commented

2025-12-29 19:36:24 +01:00

@DorianBourgeoisat commented on GitHub (Feb 18, 2022):

I also wander how to model some "weird" PON modules, such as nokia's double GPON XFP module.

Would it be better to scind the PON technology from the module's connectivity ? And therefore be able to model the weird things manufacturers come up with ?

@DorianBourgeoisat commented on GitHub (Feb 18, 2022): I also wander how to model some "weird" PON modules, such as nokia's double GPON XFP module. Would it be better to scind the PON technology from the module's connectivity ? And therefore be able to model the weird things manufacturers come up with ?

adam commented

@DanSheps commented on GitHub (Mar 2, 2022):

@BrunoBlanes @DorianXGH So I have a question about this.

How are you expecting to connect these up? Currently, there is a 1:1 relationship between interface and fiber (1 interface can only connect to either a single interface, front port or rear port with 1 position)

@DanSheps commented on GitHub (Mar 2, 2022): @BrunoBlanes @DorianXGH So I have a question about this. How are you expecting to connect these up? Currently, there is a 1:1 relationship between interface and fiber (1 interface can only connect to either a single interface, front port or rear port with 1 position)

adam commented

2025-12-29 19:36:24 +01:00

@BrunoBlanes commented on GitHub (Mar 2, 2022):

@DanSheps I don't quite follow what you mean. GPON would be an interface type and it would have its SFP modules as inventory items.

@BrunoBlanes commented on GitHub (Mar 2, 2022): @DanSheps I don't quite follow what you mean. `GPON` would be an interface type and it would have its SFP modules as inventory items.

adam commented

2025-12-29 19:36:24 +01:00

@DanSheps commented on GitHub (Mar 2, 2022):

Yes, but supposedly you would want to connect fiber to this interface at one point. I am saying that the interface-to-port (front or rear) is a 1:1 relationship.

You can't go out and have 1 interface connect to a rear port which spiders out into multiple "front ports" for each end user. I just want to make sure you are clear on the limitation of if we did this you would either be limited to a single "strand" end-to-end. You couldn't model the splitter and CPE devices for example.

@DanSheps commented on GitHub (Mar 2, 2022): Yes, but supposedly you would want to connect fiber to this interface at one point. I am saying that the interface-to-port (front or rear) is a 1:1 relationship. You can't go out and have 1 interface connect to a rear port which spiders out into multiple "front ports" for each end user. I just want to make sure you are clear on the limitation of if we did this you would either be limited to a single "strand" end-to-end. You couldn't model the splitter and CPE devices for example.

adam commented

@BrunoBlanes commented on GitHub (Mar 2, 2022):

Oh, I'm aware of that. Our need is to document the network as long as active devices go, mainly because if we were going to map the fiber with all the splitters, we'd be mapping the entire outdoor fiber network.
We work with OLTs and they have PON ports, that's as far as I'd like to go with this for now.
But hey, that could be a future major release of Netbox, documenting passive optical networks with splitters and all, not a bad idea.

@BrunoBlanes commented on GitHub (Mar 2, 2022): Oh, I'm aware of that. Our need is to document the network as long as active devices go, mainly because if we were going to map the fiber with all the splitters, we'd be mapping the entire outdoor fiber network. We work with OLTs and they have PON ports, that's as far as I'd like to go with this for now. But hey, that could be a future major release of Netbox, documenting passive optical networks with splitters and all, not a bad idea.

adam commented

@DorianBourgeoisat commented on GitHub (Mar 2, 2022):

@BrunoBlanes Oh, I thought about modeling splitters like switches, it's not the nicest way of doing it, but doing it cleanly would require a proper decoupling of the L2 and L1 layer.
Otherwise I agree with putting the module connection with the OLT in the inventory. Still, I think having the different PON technologies would be better, to model the bandwidth capabilties.
That would make it :

GPON
XGPON
XGSPON
TWDM-PON (NG-PON2)
EPON
10G EPON

@DorianBourgeoisat commented on GitHub (Mar 2, 2022): @BrunoBlanes Oh, I thought about modeling splitters like switches, it's not the nicest way of doing it, but doing it cleanly would require a proper decoupling of the L2 and L1 layer. Otherwise I agree with putting the module connection with the OLT in the inventory. Still, I think having the different PON technologies would be better, to model the bandwidth capabilties. That would make it : - GPON - XGPON - XGSPON - TWDM-PON (NG-PON2) - EPON - 10G EPON

adam commented

@BrunoBlanes commented on GitHub (Mar 2, 2022):

I thought about modeling splitters like switches, it's not the nicest way of doing it, but doing it cleanly would require a proper decoupling of the L2 and L1 layer.

Yeah, it would be messy and might not work as intended for everyone, so I think we'd be better off not doing that. As for the PON technologies, I think that is a great list we might just need to detail it a bit more, for example GPON (2.5GE).

Also I should ask, these would be under any existing interface type category, like Ethernet (modular)? Seems like it might be better to define a new one.

@BrunoBlanes commented on GitHub (Mar 2, 2022): > I thought about modeling splitters like switches, it's not the nicest way of doing it, but doing it cleanly would require a proper decoupling of the L2 and L1 layer. Yeah, it would be messy and might not work as intended for everyone, so I think we'd be better off not doing that. As for the PON technologies, I think that is a great list we might just need to detail it a bit more, for example `GPON (2.5GE)`. Also I should ask, these would be under any existing interface type category, like `Ethernet (modular)`? Seems like it might be better to define a new one.

adam commented

@DorianBourgeoisat commented on GitHub (Mar 2, 2022):

Yeah, a new PON category seems like a good idea.
This would make the list:

GPON (2.5G/1.25G)
XGPON (10G/2.5G)
XGSPON (10G)
TWDM-PON (NG-PON2) (4x10G)
EPON (1G)
10G EPON (10G)

@DorianBourgeoisat commented on GitHub (Mar 2, 2022): Yeah, a new `PON` category seems like a good idea. This would make the list: - GPON (2.5G/1.25G) - XGPON (10G/2.5G) - XGSPON (10G) - TWDM-PON (NG-PON2) (4x10G) - EPON (1G) - 10G EPON (10G)

adam commented

@shatt79 commented on GitHub (Apr 11, 2022):

Just to throw some more complexity into this...

Several vendors are offering "combo" OLT cards that can run multiple PON technologies simultaneously out the same OLT port using multi-wavelength optics. Adtran, Calix, and DZS are all doing this.

These cards can fire both GPON and XGS-PON wavelengths onto a single distribution network (ODN) out to a common splitter. The technology that is used is entirely dependent upon the ONT installed at the customer premise. If you install a GPON ONT, it locks onto 1490/1310. If you install an XGS ONT, it locks onto 1577/1270. So, you'll have a single ODN and splitter running ONTs on different technologies. Within the software of the shelf itself, it creates 2 virtual/logical ports for each physical OLT/PON port on the card. Example: An Adtran 8 port combo OLT card consists of 8 physical ports. If you install 8 of the multi-wave optics into the card, the TA-5000 shelf creates 16 PON ports internally. 1-8 are GPON, and 9-16 are XGS-PON. The internal GPON port 1 and XGS port 9 are logically connected to the physical port 1 on the OLT card.

So, how does one model this in NetBox? You can't necessarily have a single port running two "speeds", and you can't really create a module with 16 ports, because there's no way to connect two ports to a single fiber and splitter. Maybe something clever could be done with the bridging feature?

@shatt79 commented on GitHub (Apr 11, 2022): Just to throw some more complexity into this... Several vendors are offering "combo" OLT cards that can run multiple PON technologies simultaneously out the same OLT port using multi-wavelength optics. Adtran, Calix, and DZS are all doing this. These cards can fire both GPON and XGS-PON wavelengths onto a single distribution network (ODN) out to a common splitter. The technology that is used is entirely dependent upon the ONT installed at the customer premise. If you install a GPON ONT, it locks onto 1490/1310. If you install an XGS ONT, it locks onto 1577/1270. So, you'll have a single ODN and splitter running ONTs on different technologies. Within the software of the shelf itself, it creates 2 virtual/logical ports for each physical OLT/PON port on the card. Example: An Adtran 8 port combo OLT card consists of 8 physical ports. If you install 8 of the multi-wave optics into the card, the TA-5000 shelf creates 16 PON ports internally. 1-8 are GPON, and 9-16 are XGS-PON. The internal GPON port 1 and XGS port 9 are logically connected to the physical port 1 on the OLT card. So, how does one model this in NetBox? You can't necessarily have a single port running two "speeds", and you can't really create a module with 16 ports, because there's no way to connect two ports to a single fiber and splitter. Maybe something clever could be done with the bridging feature?

adam commented

@BrunoBlanes commented on GitHub (Apr 11, 2022):

From what I understood here and by having taken a look at some of Adtran products, you are talking about a modular 10 Gigabit PON port interface which accepts both a GPON or an XGS-PON transceiver.
In that case, I think it is safe to assume that the board itself would contain 8 generic 10G PON slots where you can then plug your specific GPON (2.5G/1.25G) or XGS-PON (10G) transceivers into.

@BrunoBlanes commented on GitHub (Apr 11, 2022): From what I understood here and by having taken a look at some of Adtran products, you are talking about a modular 10 Gigabit PON port interface which accepts both a GPON `or` an XGS-PON transceiver. In that case, I think it is safe to assume that the board itself would contain 8 generic `10G PON` slots where you can then plug your specific `GPON (2.5G/1.25G)` or `XGS-PON (10G)` transceivers into.

adam commented

@DorianBourgeoisat commented on GitHub (Apr 11, 2022):

From our previous discussion, I think was discussed that only the logical PON port would be modeled as interfaces, with the underlying modules as inventory items. I don't think netbox can currently model PONs that effectively, so as long as Netbox keeps its L1/L2 representation as is, PONs, especially the ODN part, will be kind of hard to model, but perfect is the enemy of good. The proposed list aims to model the logical PONs for now, and maybe, as we are a few small ISPs wanting to use netbox to model their network, we might later want to work towards more modelling ability.

@DorianBourgeoisat commented on GitHub (Apr 11, 2022): From our previous discussion, I think was discussed that only the logical PON port would be modeled as interfaces, with the underlying modules as inventory items. I don't think netbox can currently model PONs that effectively, so as long as Netbox keeps its L1/L2 representation as is, PONs, especially the ODN part, will be kind of hard to model, but perfect is the enemy of good. The proposed list aims to model the logical PONs for now, and maybe, as we are a few small ISPs wanting to use netbox to model their network, we might later want to work towards more modelling ability.

adam commented

@shatt79 commented on GitHub (Apr 11, 2022):

Bruno... Yes and no. Adtran has an 8 port Combo OLT card.
This card can accept three different types of SFPs (and their various flavors) in each physical SFP+ slot:

GPON SFP: 1490/1310 - Allows only GPON ONTs on the ODN
XGS-PON SFP+: 1577/1270 - Allows only XGS-PON ONTs on the ODN
Combo/Multi-Wave SFP+: 1490/1310 AND 1577/1270 - Allows both GPON and XGS-PON ONTs on a single ODN/splitter at the SAME TIME.

Think about these multi-wave optics as like a DWDM optic that fan transmit and receive multiple wavelengths at the same time. In this case, its a bi-directional PON SFP that is transmitting two waves (1490 and 1577) and receiving two wavelengths (1310 and 1270). This is pretty new stuff, so I understand if most aren't familiar with it. Its much like having multiple vlans on a trunk, but this is at the layer 1 level. The SFP basically has a built-in mux/demux.

When you insert one of these "8 Port Combo OLT" cards into a TA-5Kx shelf, the shelf will internally create 16 logical ports. Ports 1-8 will attach themselves to the GPON plane, and ports 9-16 to the XGS-PON plane of the card. Logical ports 1 and 9 are bridged at layer 1 to physical port 1, regardless of what type of transceiver is installed. If you install a GPON only SFP into physical port 1, logical ports 1 and 9 will still exist, but you wont be able to provision services to logical port 9 because a layer 1 path won't actually exist for XGS on the ODN. I mean, you can provision to logical 9, but you won't be able to use an XGS ONT on that ODN. However, if you install one of the multi-wave SFPs into physical port 1, now you DO have that layer path. With this, you can install both GPON and XGS-PON ONTs on the same ODN. You'd provision the GPON ONT to logical port 1, and any XGS ONTs to logical port 9.

Make sense?

Again, this may be impossible to model in NetBox. However, this is what all of the primary PON vendors (Adtran & Calix) have moved to, so I felt it was important enough to at least mention it before a whole bunch of work goes into modeling the obsolete PON model we've been used to for 15+ years. Pretty soon, you won't be able to get "GPON only" cards. This new way gives providers the ability to easily - and inexpensively - make their networks 10G-PON ready from the start without having to use PON coexistence elements (the industry's fancy word for a PON WDM) or rework the fiber infrastructure in the headend/CO/RT. Vendors like it because they dont have to engineer or manufacture 15 different flavors of cards. Those who work for ISPs that are just now getting into PON... you should ask your vendors why they're NOT telling you about this. My assumption is that they want to get rid of all the backstock of legacy/obsolete stuff in their warehouses. The cost difference between the old and new way is only 5-10%.

Shelf

OLT Card
- Physcal PON Port 1 with multi-wave SFP ---> Splitter ---> ONT (can be GPON and XGS)
  - Logical GPON Port 1: GPON ONTs provisioned here
  - Logical XGS PORT 9: XGS ONTs provisioned here
- Physical PON Port 2 with GPON SFP ---> Splitter ---> ONT (GPON only)
  - Logical GPON Port 2: ONTs provisioned here
  - Logical XGS Port 10: Nothing provisioned here
- ...
- Physical PON Port 8 with XGS SPF ---> Splitter ---> ONT (XGS Only)
  - Logical GPON Port 8: Nothing provisioned here
  - Logical XGS Port 16: ONTs provisioned here

@shatt79 commented on GitHub (Apr 11, 2022): Bruno... Yes and no. Adtran has an 8 port Combo OLT card. This card can accept three different types of SFPs (and their various flavors) in each physical SFP+ slot: - GPON SFP: 1490/1310 - Allows only GPON ONTs on the ODN - XGS-PON SFP+: 1577/1270 - Allows only XGS-PON ONTs on the ODN - Combo/Multi-Wave SFP+: 1490/1310 AND 1577/1270 - Allows both GPON and XGS-PON ONTs on a single ODN/splitter at the SAME TIME. Think about these multi-wave optics as like a DWDM optic that fan transmit and receive multiple wavelengths at the same time. In this case, its a bi-directional PON SFP that is transmitting two waves (1490 and 1577) and receiving two wavelengths (1310 and 1270). This is pretty new stuff, so I understand if most aren't familiar with it. Its much like having multiple vlans on a trunk, but this is at the layer 1 level. The SFP basically has a built-in mux/demux. When you insert one of these "8 Port Combo OLT" cards into a TA-5Kx shelf, the shelf will internally create 16 logical ports. Ports 1-8 will attach themselves to the GPON plane, and ports 9-16 to the XGS-PON plane of the card. Logical ports 1 and 9 are bridged at layer 1 to physical port 1, regardless of what type of transceiver is installed. If you install a GPON only SFP into physical port 1, logical ports 1 and 9 will still exist, but you wont be able to provision services to logical port 9 because a layer 1 path won't actually exist for XGS on the ODN. I mean, you can provision to logical 9, but you won't be able to use an XGS ONT on that ODN. However, if you install one of the multi-wave SFPs into physical port 1, now you DO have that layer path. With this, you can install both GPON and XGS-PON ONTs on the same ODN. You'd provision the GPON ONT to logical port 1, and any XGS ONTs to logical port 9. Make sense? Again, this may be impossible to model in NetBox. However, this is what all of the primary PON vendors (Adtran & Calix) have moved to, so I felt it was important enough to at least mention it before a whole bunch of work goes into modeling the obsolete PON model we've been used to for 15+ years. Pretty soon, you won't be able to get "GPON only" cards. This new way gives providers the ability to easily - and inexpensively - make their networks 10G-PON ready from the start without having to use PON coexistence elements (the industry's fancy word for a PON WDM) or rework the fiber infrastructure in the headend/CO/RT. Vendors like it because they dont have to engineer or manufacture 15 different flavors of cards. Those who work for ISPs that are just now getting into PON... you should ask your vendors why they're NOT telling you about this. My assumption is that they want to get rid of all the backstock of legacy/obsolete stuff in their warehouses. The cost difference between the old and new way is only 5-10%. Shelf - OLT Card - Physcal PON Port 1 with multi-wave SFP ---> Splitter ---> ONT (can be GPON and XGS) - Logical GPON Port 1: GPON ONTs provisioned here - Logical XGS PORT 9: XGS ONTs provisioned here - Physical PON Port 2 with GPON SFP ---> Splitter ---> ONT (GPON only) - Logical GPON Port 2: ONTs provisioned here - Logical XGS Port 10: Nothing provisioned here - ... - Physical PON Port 8 with XGS SPF ---> Splitter ---> ONT (XGS Only) - Logical GPON Port 8: Nothing provisioned here - Logical XGS Port 16: ONTs provisioned here

adam commented

2025-12-29 19:36:27 +01:00

@DorianBourgeoisat commented on GitHub (Apr 11, 2022):

I have seen those modules before and my answer was in light of this knowledge. There are so many different physical modules with each their own interfaces that listing them all exhaustively would be really difficult, thus our proposal of having "logical" PON ports. In the case of multiwave modules, they'd be modelled by 2 "logical" PON interfaces, a GPON one and an XGSPON one.

@DorianBourgeoisat commented on GitHub (Apr 11, 2022): I have seen those modules before and my answer was in light of this knowledge. There are so many different physical modules with each their own interfaces that listing them all exhaustively would be really difficult, thus our proposal of having "logical" PON ports. In the case of multiwave modules, they'd be modelled by 2 "logical" PON interfaces, a GPON one and an XGSPON one.

adam commented

@github-actions[bot] commented on GitHub (Jun 11, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 11, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 19:36:27 +01:00

@vittore commented on GitHub (Jun 23, 2022):

We have a ZTE XGPON system in our infrastructure and would love to have this included with NetBox.
Now I'm trying to add some devices type.

How to model a single GPON port (GBIC) that can mount different types of modules?

@vittore commented on GitHub (Jun 23, 2022): We have a ZTE XGPON system in our infrastructure and would love to have this included with NetBox. Now I'm trying to add some devices type. How to model a single GPON port (GBIC) that can mount different types of modules?

adam commented

2025-12-29 19:36:27 +01:00

@jeremystretch commented on GitHub (Aug 3, 2022):

Has a consensus been reached on this proposal? Does anyone want to own its implementation?

@jeremystretch commented on GitHub (Aug 3, 2022): Has a consensus been reached on this proposal? Does anyone want to own its implementation?

adam commented

@DorianBourgeoisat commented on GitHub (Aug 4, 2022):

@jeremystretch
Most comments regarding the proposal seem to stem from the difficulty to model the weirdness that some manufacturers come up with, but as we said, it is possible to model it with out proposal, even if it is in the same way combo ports are currently modeled.
I can write a PR to implement this if needed.

@DorianBourgeoisat commented on GitHub (Aug 4, 2022): @jeremystretch Most comments regarding the proposal seem to stem from the difficulty to model the weirdness that some manufacturers come up with, but as we said, it is possible to model it with out proposal, even if it is in the same way combo ports are currently modeled. I can write a PR to implement this if needed.

adam commented

@vittore commented on GitHub (Aug 5, 2022):

I think that the main problem about GPON is (was) the splitter logic (one-to-many-cables). With version v3.3-beta1 - 2022-07-14 of netbox this problem vanish.

@vittore commented on GitHub (Aug 5, 2022): I think that the main problem about GPON is (was) the splitter logic (one-to-many-cables). With version v3.3-beta1 - 2022-07-14 of netbox this problem vanish.

adam commented

@BrunoBlanes commented on GitHub (Aug 5, 2022):

I think that the main problem about GPON is (was) the splitter logic (one-to-many-cables). With version v3.3-beta1 - 2022-07-14 of netbox this problem vanish.

I don't think that was ever a problem since this proposal is not related to mapping passive GPON equipment like splitters and such.

@BrunoBlanes commented on GitHub (Aug 5, 2022): > I think that the main problem about GPON is (was) the splitter logic (one-to-many-cables). With version v3.3-beta1 - 2022-07-14 of netbox this problem vanish. I don't think that was ever a problem since this proposal is not related to mapping passive GPON equipment like splitters and such.

adam commented