starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Interface metadata like MTU and mac learning limit #834

New Issue
Closed
opened 2025-12-29 16:26:10 +01:00 by adam · 10 comments
adam commented 2025-12-29 16:26:10 +01:00
Owner
Copy Link

Originally created by @lampwins on GitHub (Apr 5, 2017).

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.

Originally created by @lampwins on GitHub (Apr 5, 2017). <!-- Please note: GitHub issues are to be used only for feature requests and bug reports. For installation assistance or general discussion, please join us on the mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please indicate "bug report" or "feature request" below. Be sure to search the existing set of issues (both open and closed) to see if a similar issue has already been raised. --> ### 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.
adam added the type: feature label 2025-12-29 16:26:10 +01:00
adam closed this issue 2025-12-29 16:26:11 +01:00
adam commented 2025-12-29 16:26:11 +01:00
Author
Owner
Copy Link

@snazy2000 commented on GitHub (Apr 5, 2017):

Custom Fields?

@snazy2000 commented on GitHub (Apr 5, 2017): Custom Fields?
adam commented 2025-12-29 16:26:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 5, 2017):

@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.

@jeremystretch commented on GitHub (Apr 5, 2017): @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.
adam commented 2025-12-29 16:26:11 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Apr 5, 2017):

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.

@lampwins commented on GitHub (Apr 5, 2017): 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.
adam commented 2025-12-29 16:26:12 +01:00
Author
Owner
Copy Link

@snazy2000 commented on GitHub (Apr 5, 2017):

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

@snazy2000 commented on GitHub (Apr 5, 2017): @jeremystretch would it not make sense to add support for custom fields then anything can be added that anyone wants to the interface?
adam commented 2025-12-29 16:26:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 5, 2017):

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

@jeremystretch commented on GitHub (Apr 5, 2017): @snazy2000 No. Custom fields are only supported on primary models for performance reasons.
adam commented 2025-12-29 16:26:12 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Apr 13, 2017):

@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.

@candlerb commented on GitHub (Apr 13, 2017): @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.
adam commented 2025-12-29 16:26:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 13, 2017):

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

@jeremystretch commented on GitHub (Apr 13, 2017): Guys, we're not adding custom fields to interfaces. Please stop asking.
adam commented 2025-12-29 16:26:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 23, 2017):

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 commented on GitHub (Jun 23, 2017): 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.
adam commented 2025-12-29 16:26:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 23, 2017):

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 commented on GitHub (Jun 23, 2017): Merging #1147 with this FR. So we're adding two fields to the Interface model: status (enabled or disabled) and MTU (an unsigned integer).
adam commented 2025-12-29 16:26:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 23, 2017):

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

@jeremystretch commented on GitHub (Jun 23, 2017): Added `enabled` and `mtu` fields to the Interface model in 229e680.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#834
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?