Logical mapping between interfaces

[jahknem]

When modeling a GPON network, I had difficulties as additionally to the physical connection I have to model the Generic Encapsulation Protocol. This maps an ONT device to a logical port on a specific PON interface. I'd like to model this in Netbox.

To fix this I'd like to be able to create a logical mapping between interfaces which are directly connected via a direct or an indirect connection. Essentially this means that a physical interface which is connected to multiple different physical interfaces may have multiple child interfaces. These child interfaces can be selected from the remote physical interface as logically mapped interfaces.

Take as an example Device "Root", which has an interface connected to the Rear Port of a 1:5 splitter. The Front Ports are connected to 5 Devices "Leaves [1-5]". The interface of "Root" will now have 5 virtual child interfaces, each designated to the connected interface of one of the "Leave" devices. The mapping of these virtual child interfaces to the "Leave" interfaces should be independent from the physical front port of the splitter.

This is different from the existing L2VPNs as these are not dependant on a physical connection. It is different from the existing Front-Rear Port mapping as it is not dependant on the position an interface is attached to. It would be similar to #11158 , but without the maintenance burden of keeping all relevant interface types up to date.

Currently I don't see a way around either creating a plugin or creating a pull request for this functionality, as it cannot be created using only custom object fields and validation logic.
I'd really like to gather further thoughts on this, anyone?

[candlerb]

You can create the OLT sub-interfaces already: just create new interfaces called say "Root.0", "Root.1" etc and set the Parent attribute to "Root".

To associate the traffic paths with specific ONTs, the nearest feature is VLANs. But it would be fiddly to have to create a separate VLAN for every ONT, and I don't think the work is justified. I think it would be better to have a naming convention which makes the association clear: e.g. "Root.0" connects to ONT with ONU-ID 0 on that port. The ONT can have the ONU-ID as a custom field, or part of its name with a suitable naming convention [^1]

One thing that probably won't work properly today is modelling a splitter the way you've suggested. 5 front ports linked to 1 rear port means that the rear port is a 5-position port (i.e. it carries 5 fibres). Netbox won't prevent you from connecting that to an OLT interface, but when you trace outbound from the OLT, it will only follow the first virtual 'strand'; the connected peer will be only the first ONT. If you trace inbound from the other ONTs, I'm not sure if you'll hit the OLT interface at all.

The alternative would be to model the splitter more like a switch (with interfaces: 5 downstream, 1 upstream), although that has its obvious problems too (these are not really active interfaces). Then you would have to trace separately from ONT to splitter downstream port, and from splitter upstream port to OLT.

---

[^1] If I understand correctly, we're talking about GEM framing, G.948.3. The ONT on a given port is identified by the ONU-ID, which is an 8-bit number between 0 and 253.

[candlerb]

Another issue which might cause you pain is if you have combo GPON/XGS-PON OLTs. There will be two internal, independent PON interfaces; but these are combined onto a single physical port, with a single fibre strand going to a single splitter.

This could be modelled as a tree:

• an "interface" for the physical port
• two child "interfaces" for the GPON and XGS-PON active interfaces, with parent as the physical port
• N x GPON child interfaces and N x XGS-PON child interfaces, with parents as the GPON or XGS-PON master interface

Or you could model it as two separate interfaces, but then you'd have to connect them to a separate WDM mux device, which would look like a reverse splitter. Internally, that is exactly what's going on of course.

[jahknem]

Hey, thanks for the feedback!
I know that I can create virtual subinterfaces already, the mapping is the only thing causing me problems. Previously I tried creating custom object fields which let me choose interfaces, but I can't filter which interfaces may be chosen. In our instance we have multiple thousand interfaces, so that would not be feasable, especially as these interfaces often have the same names, with the differentiating feature being what device they are attached to.. I've done such filtering in a script, which is why I believe that doing so should be possible within a plugin.
I'd rather not use VLANs, as we already use the VLAN model to model VLANs. It's just not as clean. Also we have multiple VLANs going over that connection, so that may cause confusion.

As to the 5 position port: Indeed, tracing from the OLT to the ONTs is currently only possible by hops. But using the 5 position port I can trace what OLT the ONT is assigned to. As this is the model we are currently using in our test instance, I can tell that it already works.
If I were to instead create a switch like device, tracing would not work in either direction. Maybe an additional plugin enabling multi path traces would be needed for this use cases, but it would have to create a separate trace model as core models may not be changed by plugins.

As for the combo ports, I believe that is a separate issue. I completely agree that this would be useful, but I don't think it is within the scope of a hypothetical logical mapping plugin