Interface metadata like MTU and mac learning limit

[lampwins]

Issue type: feature request

I need to be able to include certain pertinent information about an interface, like it's MTU and mac learning limit. I am sure there is other data that would be applicable here but these are the two that come to mind for my immediate needs. So initially, this sounds like it would need to be some kind of one-to-many relationship to an interface metadata model.

This is to aid in using netbox as the source of truth for automation.

[snazy2000]

Custom Fields?

[jeremystretch]

@lampwins Is MAC learning limit something that's associated with individual interfaces? In my experience this has been more of a system limitation.

@snazy2000 Custom fields are not supported on interfaces and other device component models. Also, there's a good argument to add at least an MTU field since it's something many users may want to track.

[lampwins]

Many vendors (like Juniper) will allow it to be configured on a per interface basis. See: https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/layer-2-services-mac-bridge-domain-as-switch-with-trunk-ports-limiting-addresses-learned-from-a-trunk-port-on.html

In support of a more generic approach, this could also be used to define a field in which a list of VLAN ID's could be added and it could also be used to signify if the interface is a trunk or access port by way of a checkbox.

[snazy2000]

@jeremystretch would it not make sense to add support for custom fields then anything can be added that anyone wants to the interface?

[jeremystretch]

@snazy2000 No. Custom fields are only supported on primary models for performance reasons.

[candlerb]

@jeremystretch

Custom fields are only supported on primary models for performance reasons.

A case of premature optimisation? How much would performance suffer exactly if interfaces had custom fields? If it serves a use case but slows the UI by 0.1 seconds, maybe it's acceptable. Databases are pretty fast these days, and the whole Netbox database will probably sit in RAM anyway.

Custom fields might avoid cluttering the main model and UI, to the benefit of the majority of users, whilst giving greater flexibility for those with special requirements.

Alternatively, it would be possible to implement custom fields differently, say as a single JSON column - which incidentally would be a lot more convenient to work with than the current multi-level join. Postgres has deep JSON support and can index JSON fields efficiently.

@lampwins

Many vendors (like Juniper) will allow it [mac learning limit] to be configured on a per interface basis.

Today, Netbox as DCIM primarily records the physical connection from interface A to interface B, and hence the physical type of each interface.

The question is, how much information about the soft configuration of an interface should be recorded in the Netbox core model? That is, stuff which reflects the running-config as opposed to the intrinsic physical setup?

There is much other data about the interface configuration which could be recorded. Top of the heap as you have already mentioned is VLAN config, i.e. which VLANs are tagged on the interface, and what the native VLAN is. However this then can get very hairy: for example, tags can be stacked.

What about IPs - aren't they soft configuration? Well yes, Netbox does have an IPAM module, and as a convenience, IP addresses can be associated with interfaces. But these are still physical interfaces.

It's common that an IP address is configured directly on a physical interface. But if you have tagged subinterfaces they don't exist in the model. You can only associate each address directly with the physical interface. You can probably infer the VLAN from the IP -> prefix -> VLAN association (although not whether it's tagged or not). But if this is a layer 2 connection (e.g. VLAN trunked through a switch) there's no way to model this; and I think this was by design.

MTU is perhaps slightly different. You could argue that the maximum MTU is part of the hardware capabilities of the interface, and therefore could be recorded as a physical characteristic. But the configured MTU may of course be lower. I suspect if the database held the interface MTU, most people would sore the configured MTU, not the physical MTU limit. And this is quite reasonable, if they find it helpful.

Of course, everything you record that relates to the soft configuration of the device is something which has the potential to become out-of-date with respect to reality, unless you are either collecting this information from the device, or generate device configs directly from the data in Netbox.

In the latter case, you probably need a much more expressive data model to do service provisioning (linking interfaces to sub-interfaces, services, customers, line profiles, SLAs etc), and I think this belongs in a different system.

[jeremystretch]

Guys, we're not adding custom fields to interfaces. Please stop asking.

[jeremystretch]

I'm going to define the scope of this request as simply adding an unsigned integer mtu field to the Interface model. I think that's reasonable.

[jeremystretch]

Merging #1147 with this FR. So we're adding two fields to the Interface model: status (enabled or disabled) and MTU (an unsigned integer).

[jeremystretch]

Added enabled and mtu fields to the Interface model in 229e680.