Interface Type Addition: 100Base-FX (Fast Ethernet over Fiber)

[danner26]

We have some legacy hardware that runs on 100Base-FX (Fast Ethernet over Fiber). We would like to request the interface type be added.

Use case
We have some Allied Telesis AT-FS202's in the field that we are looking to record. These have 100Base-FX connection for their Port1 and 10Base-T/100Base-TX for their Port 2

[SleptsovVV]

In my opinion, it would be a good idea to allow users to add interface types (physical, virtual, wireless) themselves via a configuration file. Similar to your case, we use legacy equipment (with V.35, V.24 etc. interfaces), the inability to add custom interface types is the only reason that stops us from moving to a netbox.

[candlerb]

User-created interface types has been rejected as a feature in the past multiple times - you're told to use interface type "Other" for any case not covered (possibly in conjunction with a custom field). Since then there has been some relenting, at least for custom status values.

OTOH, reasonable requests for new interface types are often accepted. I note that the recently-released Netbox 3.4.3 has added the new 100M interface type requested above, which was raised as FR #11371.

IIRC, V.35 and V.24 are serial interfaces (on DB37 and DB25 connectors?) but by the time you've put HDLC or PPP on top, you've got an IP interface. So in principle, I don't see why they can't be added.

However, Netbox does take some liberties in mixing the concepts of a physical port and a logical interface. For example, there's an existing interface type "E1 (2.048Mbps)" but that's really more of a logical circuit type, rather than a physical presentation (e.g. it could be presented as coax or twisted pair); whilst at the other end there are a whole bunch of proprietary stacking connectors which clearly aren't IP interfaces at all.

Hence it's unclear whether the feature you want would be added as "V.24", or "DB25 / DB9", or "E0 (64kbps)". Perhaps even just "Serial (other)", with the speed, framing and physical connectors left to custom fields - or to the attached Circuit / Circuit Termination.

[jeremystretch]

Please see this FAQ for the list of reasons custom interface types are not permitted.

[SleptsovVV]

IIRC, V.35 and V.24 are serial interfaces (on DB37 and DB25 connectors?) but by the time you've put HDLC or PPP on top, you've got an IP interface. So in principle, I don't see why they can't be added.

We use Cisco 4000-series routers exclusively at Layer 2 as Frame Relay switches, how do we represent this in a netbox then?

Please see this FAQ for the list of reasons custom interface types are not permitted.

Regarding FAQ:

1. Interface types V.35, V.24(EIA/TIA-232), V.36(EIA/TIA-449), X.21, EIA/TIA-530, EIA/TIA-485 exist in the real world, specifically we use these.
2. If the addition of interface types is implemented by analogy with Field Choices (via the configuration file), there will be no duplication and redundancy.
3. I do not think that adding 5-10 types of interfaces can greatly affect performance, given that each user will only add their own specific types of interfaces.
4. Adding custom interface types to the device library is not suggested by anyone, naturally, it is logical to use only existing interface types in the device library.
5. In my opinion, the lack of certain types of interfaces provided to users by companies such as Cisco still puts NetBox in the category of sources of "half-truths".

I'm not a developer, but I think the NetBox team (who implemented more complex stuff) could easily add this functionality.

[jeremystretch]

1. Interface types V.35, V.24(EIA/TIA-232), V.36(EIA/TIA-449), X.21, EIA/TIA-530, EIA/TIA-485 exist in the real world, specifically we use these.

As mentioned, you're welcome to submit a feature request to add any real-world interface types.

2. If the addition of interface types is implemented by analogy with Field Choices (via the configuration file), there will be no duplication and redundancy.

Field choices do nothing to prevent this: Consider for example a situation where one user defines a "Fast Ethernet" type and another defines "100M Ethernet." You now have two redundant definitions for the same type. Limiting interfaces to carefully curated types prevents this.

3. I do not think that adding 5-10 types of interfaces can greatly affect performance, given that each user will only add their own specific types of interfaces.

The performance impact arises from the (presumed) introduction of a new database relationship, not the number of types. (Note that this was written prior to the introduction of customizable field choices, though the point stands.)

4. Adding custom interface types to the device library is not suggested by anyone, naturally, it is logical to use only existing interface types in the device library.

But if they're legitimate interface types, why wouldn't we add them?

5. In my opinion, the lack of certain types of interfaces provided to users by companies such as Cisco still puts NetBox in the category of sources of "half-truths".

And in my opinion, it would be the introduction of arbitrary new types masquerading as canonical definitions that does exactly that. We'll have to agree to disagree.

[SleptsovVV]

As mentioned, you're welcome to submit a feature request to add any real-world interface types.

I already submitted a feature request to add these types of interfaces #9315 but it was ignored. I can create it again...

Field choices do nothing to prevent this: Consider for example a situation where one user defines a "Fast Ethernet" type and another defines "100M Ethernet." You now have two redundant definitions for the same type. Limiting interfaces to carefully curated types prevents this.

I understand that Field Choices does nothing to prevent duplication of interface types. Speaking about Field Choices, I meant the principle of adding interface types by changing the configuration file. As for adding the same types with different names, I think this is an organizational issue (if 2 or more NetBox administrators cannot agree on what to add and what not), otherwise the same can be said about Field Choices.

The performance impact arises from the (presumed) introduction of a new database relationship, not the number of types. (Note that this was written prior to the introduction of customizable field choices, though the point stands.)

As I wrote above, I am not a developer and I will not argue with you on this topic. But perhaps there are statistics of users who encountered a performance problem?

But if they're legitimate interface types, why wouldn't we add them?

Yes, it would not be bad, but for this we need to solve the first point...

[adrienbousez]

In OT technology, a lot of devices still have 100BASE-FX for SFP ports. At this time we're not able to document this with netbox and have to choose an other type which doesn't represent the real interface of the device (SPF 100ME) ...

[jeremystretch]

The 100Base-FX interface type was added recently, in NetBox v3.4.3 (see #11371).

[adrienbousez]

Yes, indeed in the Ethernet fixed types, but not in the modular range

[jeremystretch]

Ah, you're conflating the interface type with the media type. The interface type is an SFP standard and doesn't change, whereas the media type can vary depending on what SFP is installed.