You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't know if there's been a specific proposal for this before, although I saw mention of a desire to model passive networks.
I have a simple idea. Bear in mind that Netbox currently has two sorts of N-to-1 connections:
N front ports connect to 1 rear port. In this case this is a multiplexed connection, i.e. the rear port carries a multiway cable, and it can break out back to N front ports in another device.
N power outlets connect to 1 power port. In this case it's non-multiplexed: all the outlets share the same power port (inlet).
My idea was: if you had a boolean flag on the rearport which said "shared" or "non-multiplexed", so that for cable tracing purposes it works like the power port case, this may be all that's required. A PON splitter would then be a device with one rearport (marked "shared") and say 16 front ports.
You might still need to keep the concept of rearport "positions", to satisfy uniqueness constraints on the connection between frontport and rearport, but those positions would all be treated as position 1.
I think this would allow you to trace an ONT to an OLT (primary use case). If you trace from an OLT it might only pick one ONT, but that's probably acceptable. (Aside: I need to check what happens when you cable trace through a power port towards outlets)
This does leave the question of what happens for interface "connected endpoints". From the ONT side it's simple: the "connection" is the OLT PON port. But from the OLT side, there could be multiple "connections".
It's possible this is already implemented. From my cursory look at 3.3-beta2 I see "PathEndpoint" now has connected_endpoints() which returns a list, rather than connected_endpoint(). I suspect that's because of the new multi-object cable terminations, and I don't know how it would interact with my proposal.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I don't know if there's been a specific proposal for this before, although I saw mention of a desire to model passive networks.
I have a simple idea. Bear in mind that Netbox currently has two sorts of N-to-1 connections:
My idea was: if you had a boolean flag on the rearport which said "shared" or "non-multiplexed", so that for cable tracing purposes it works like the power port case, this may be all that's required. A PON splitter would then be a device with one rearport (marked "shared") and say 16 front ports.
You might still need to keep the concept of rearport "positions", to satisfy uniqueness constraints on the connection between frontport and rearport, but those positions would all be treated as position 1.
I think this would allow you to trace an ONT to an OLT (primary use case). If you trace from an OLT it might only pick one ONT, but that's probably acceptable. (Aside: I need to check what happens when you cable trace through a power port towards outlets)
This does leave the question of what happens for interface "connected endpoints". From the ONT side it's simple: the "connection" is the OLT PON port. But from the OLT side, there could be multiple "connections".
It's possible this is already implemented. From my cursory look at 3.3-beta2 I see "PathEndpoint" now has
connected_endpoints()
which returns a list, rather thanconnected_endpoint()
. I suspect that's because of the new multi-object cable terminations, and I don't know how it would interact with my proposal.Beta Was this translation helpful? Give feedback.
All reactions