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

MAC Address Functionality Extension #8085

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

Originally created by @pboulos on GitHub (May 17, 2023).

NetBox version

3.4.7

Feature type

New functionality

Proposed functionality

At Kepler, we use NetBox for managing our network infrastructure. Recently, we've needed a more granular approach to managing the administration of MAC addresses for our devices. We've built a plugin to extend the base functionality of MAC addresses to be more similar to how IP addresses are handled within NetBox. As we began discussions to open source the code, we realised that it may make more sense for this extension to be part of the main application, rather than as a plugin.

We have the code written for the plugin, and it looks as the below:
image
image
image
image
image
image
image

Use case

  • Commenting/tagging/tenancy/device fields to the model element for MAC addresses (previously MAC addresses were relegated to being attributes on interfaces in NetBox).
  • Subdivision of MAC address ranges into aggregates (28 bits assigned by regional internet registry) and prefixes (32 bits and beyond).
  • Parent/child relationships between MAC addresses, and their respective prefixes and aggregates.

Database changes

This will require three new fields to be created:

  • MACAggregate
  • MACPrefix
  • MACAddress (a foreign key to the existing attribute on Interfaces)

External dependencies

This will require changes to the netaddr 3rd party library to support the concept of a MAC Prefix. Currently, in our plugin implementation, we have a helper module in the plugin definition to include the extensions required. We have an open issue on the netaddr repository in GitHub as to whether the extension makes sense to be part of that library. You can see more about it here.

Originally created by @pboulos on GitHub (May 17, 2023). ### NetBox version 3.4.7 ### Feature type New functionality ### Proposed functionality At [Kepler](https://www.kepler.space), we use NetBox for managing our network infrastructure. Recently, we've needed a more granular approach to managing the administration of MAC addresses for our devices. We've built a plugin to extend the base functionality of MAC addresses to be more similar to how IP addresses are handled within NetBox. As we began discussions to open source the code, we realised that it may make more sense for this extension to be part of the main application, rather than as a plugin. We have the code written for the plugin, and it looks as the below: <img width="1252" alt="image" src="https://github.com/netbox-community/netbox/assets/11529535/0ea1dcb8-f07d-4d04-b077-c9b0bbcc4086"> <img width="1262" alt="image" src="https://github.com/netbox-community/netbox/assets/11529535/f176454c-ce5b-41b8-a912-42cb824dfe47"> <img width="1262" alt="image" src="https://github.com/netbox-community/netbox/assets/11529535/91f2645d-5231-45c7-96bb-e0c60cead25b"> <img width="1262" alt="image" src="https://github.com/netbox-community/netbox/assets/11529535/bd1eebb7-29eb-41e6-ae1a-561675438f0d"> <img width="1262" alt="image" src="https://github.com/netbox-community/netbox/assets/11529535/10a63263-37e5-4372-8a49-fbeb84e9e2dd"> <img width="1262" alt="image" src="https://github.com/netbox-community/netbox/assets/11529535/76291f2d-d88a-4b53-b91c-bf7de64256c9"> <img width="1262" alt="image" src="https://github.com/netbox-community/netbox/assets/11529535/2f5c8535-6880-46ca-996a-bc9f3dd43f0b"> ### Use case - Commenting/tagging/tenancy/device fields to the model element for MAC addresses (previously MAC addresses were relegated to being attributes on interfaces in NetBox). - Subdivision of MAC address ranges into aggregates (28 bits assigned by regional internet registry) and prefixes (32 bits and beyond). - Parent/child relationships between MAC addresses, and their respective prefixes and aggregates. ### Database changes This will require three new fields to be created: - MACAggregate - MACPrefix - MACAddress (a foreign key to the existing attribute on Interfaces) ### External dependencies This will require changes to the netaddr 3rd party library to support the concept of a MAC Prefix. Currently, in our plugin implementation, we have a helper module in the plugin definition to include the extensions required. We have an open issue on the `netaddr` repository in GitHub as to whether the extension makes sense to be part of that library. You can see more about it [here](https://github.com/netaddr/netaddr/issues/254).
adam added the type: featurepending closurestatus: under review labels 2025-12-29 20:32:09 +01:00
adam closed this issue 2025-12-29 20:32:09 +01:00
adam commented 2025-12-29 20:32:10 +01:00
Author
Owner
Copy Link

@apellini commented on GitHub (May 18, 2023):

Could be an enhancement also having default MAC Prefix (OUI) taken from a repo (like MAC Vendor). Non default MAC are sysadmin configured... And also to be added to NAPALM plugin in order to collect information from devices (if you don't do that it is a crazy work) and from this point could be thought how to relate to interface (because in traditional network you have uplink).

@apellini commented on GitHub (May 18, 2023): Could be an enhancement also having default MAC Prefix (OUI) taken from a repo (like MAC Vendor). Non default MAC are sysadmin configured... And also to be added to NAPALM plugin in order to collect information from devices (if you don't do that it is a crazy work) and from this point could be thought how to relate to interface (because in traditional network you have uplink).
adam commented 2025-12-29 20:32:10 +01:00
Author
Owner
Copy Link

@ThomasADavis commented on GitHub (May 18, 2023):

I can see this as a way to help manage a virtual machine manager mac address pools..

@ThomasADavis commented on GitHub (May 18, 2023): I can see this as a way to help manage a virtual machine manager mac address pools..
adam commented 2025-12-29 20:32:10 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (May 19, 2023):

The fact that this relies on the modification of the upstream library makes this a no go for me.

Would you mind giving more information on the use cases behind the tracking with such level of details of mac-addresses ?

@jsenecal commented on GitHub (May 19, 2023): The fact that this relies on the modification of the upstream library makes this a no go for me. Would you mind giving more information on the use cases behind the tracking with such level of details of mac-addresses ?
adam commented 2025-12-29 20:32:11 +01:00
Author
Owner
Copy Link

@pboulos commented on GitHub (May 19, 2023):

Well, we don't necessarily need to modify netaddr to implement this. In fact, currently, our implementation simply relies on a helper module to provide the extended functionality we need - it doesn't actually modify netaddr itself. It would probably be cleaner to make upstream changes to netaddr, but that is somewhat of a can of worms as the library's development appears to be dormant. This also raises a discussion for NetBox as a whole since the application's IPAM functionality relies on netaddr, when perhaps it should be explored that this portion is moved to the Python standard library's ipaddress?

With regards to use cases, we are a vendor manufacturing network devices, and as such we regularly assign MAC addresses to devices and interfaces. In cases where we are developing and testing, we need to keep track of what addresses have already been assigned so as to prevent collisions in production. The corollary of this is that we have subsets of MAC addresses that are specifically allotted for the purposes of development and testing. In this way, we make it impossible to ultimately collide with a production MAC address.

Subsequently, for the associated metadata for MAC addresses, by allowing tagging and descriptions, we are able to categorise how addresses (and by extension prefixes and aggregates) are used as part of our development process. In general, would we ask similar questions for IPAM functionality with regards to tagging and descriptions? For MAC addresses, the attributes would be used in similar ways.

@pboulos commented on GitHub (May 19, 2023): Well, we don't necessarily need to modify `netaddr` to implement this. In fact, currently, our implementation simply relies on a helper module to provide the extended functionality we need - it doesn't actually modify `netaddr` itself. It would probably be cleaner to make upstream changes to `netaddr`, but that is somewhat of a can of worms as the library's development appears to be dormant. This also raises a discussion for NetBox as a whole since the application's IPAM functionality relies on `netaddr`, when perhaps it should be explored that this portion is moved to the Python standard library's `ipaddress`? With regards to use cases, we are a vendor manufacturing network devices, and as such we regularly assign MAC addresses to devices and interfaces. In cases where we are developing and testing, we need to keep track of what addresses have already been assigned so as to prevent collisions in production. The corollary of this is that we have subsets of MAC addresses that are specifically allotted for the purposes of development and testing. In this way, we make it impossible to ultimately collide with a production MAC address. Subsequently, for the associated metadata for MAC addresses, by allowing tagging and descriptions, we are able to categorise how addresses (and by extension prefixes and aggregates) are used as part of our development process. In general, would we ask similar questions for IPAM functionality with regards to tagging and descriptions? For MAC addresses, the attributes would be used in similar ways.
adam commented 2025-12-29 20:32:11 +01:00
Author
Owner
Copy Link

@lungj commented on GitHub (May 23, 2023):

I can see this as a way to help manage a virtual machine manager mac address pools..

I'm also from Kepler Communications (I work with @pboulos ). I figured MAC address assignment by vendors would be a fairly limited use case, but that VM MAC address management would be a lot more prevalent as a use case.

For example, if you have multiple clusters per tenant, one can do this in Ansible to pick a MAC address with a particular prefix: {{ cluster_prefix | community.general.random_mac(seed=inventory_hostname) }}. I can see other people wanting to fetch cluster_prefix from NetBox to use MAC address prefixes to, for example, distinguish between geographic regions or ESXi vs. Xen vs. tunnel interfaces.

@lungj commented on GitHub (May 23, 2023): > I can see this as a way to help manage a virtual machine manager mac address pools.. I'm also from Kepler Communications (I work with @pboulos ). I figured MAC address assignment by vendors would be a fairly limited use case, but that VM MAC address management would be a lot more prevalent as a use case. For example, if you have multiple clusters per tenant, one can do this in Ansible to pick a MAC address with a particular prefix: `{{ cluster_prefix | community.general.random_mac(seed=inventory_hostname) }}`. I can see other people wanting to fetch `cluster_prefix` from NetBox to use MAC address prefixes to, for example, distinguish between geographic regions or ESXi vs. Xen vs. tunnel interfaces.
adam commented 2025-12-29 20:32:11 +01:00
Author
Owner
Copy Link

@eronlloyd commented on GitHub (Jun 7, 2023):

MAC address management in virtual environments is absolutely a perfect use case for this. I just got done realizing this while trying to figure out how to have my VyOS VMs properly detect network adapters, which apparently requires UAAs instead of LAAs, so I had to begin prefixing all my VMs with a VMware OUI.

While the probability of Proxmox creating duplicate IPs is low, the cluster does not track MAC usage and instead generates random addresses. Having something like this directly allows for the proper management of all Layer 2 addressing, and is something I would appreciate from a service provider perspective, in general.

@eronlloyd commented on GitHub (Jun 7, 2023): MAC address management in virtual environments is absolutely a perfect use case for this. I just got done realizing this while trying to [figure out how to have my VyOS VMs properly detect network adapters](https://forum.vyos.io/t/automatically-adding-detected-interfaces-to-the-configuration-on-proxmox/11088/11?u=eronlloyd), which apparently requires UAAs instead of LAAs, so I had to begin prefixing all my VMs with a VMware OUI. While the probability of Proxmox creating duplicate IPs is low, the cluster does not track MAC usage and instead generates random addresses. Having something like this directly allows for the proper management of all Layer 2 addressing, and is something I would appreciate from a service provider perspective, in general.
adam commented 2025-12-29 20:32:11 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Jul 3, 2023):

Thanks for your various input. I think we need to discuss this further prior to implementing this but I would like it if @pboulos could document how you implemented your workaround/wrapper.

@jsenecal commented on GitHub (Jul 3, 2023): Thanks for your various input. I think we need to discuss this further prior to implementing this but I would like it if @pboulos could document how you implemented your workaround/wrapper.
adam commented 2025-12-29 20:32:12 +01:00
Author
Owner
Copy Link

@pboulos commented on GitHub (Jul 13, 2023):

Certainly.

At a high level, what we did was replicate a lot of the IP address functionality for the following classes in netaddr: IPSet, IPRange, IPNetwork. We essentially just lifted and shifted a lot of the content in those classes to extend to EUI objects, so EUISet, EUIRange, and EUIPrefix (an "equivalency" to IPNetwork). This approach was both reasonably straightforward, and allowed for roughly the same interface within NetBox when implementing this functionality within the broader application as compared to IP addresses.

I'm happy to elaborate further on any details.

@pboulos commented on GitHub (Jul 13, 2023): Certainly. At a high level, what we did was replicate a lot of the IP address functionality for the following classes in `netaddr`: `IPSet`, `IPRange`, `IPNetwork`. We essentially just lifted and shifted a lot of the content in those classes to extend to `EUI` objects, so `EUISet`, `EUIRange`, and `EUIPrefix` (an "equivalency" to `IPNetwork`). This approach was both reasonably straightforward, and allowed for roughly the same interface within NetBox when implementing this functionality within the broader application as compared to IP addresses. I'm happy to elaborate further on any details.
adam commented 2025-12-29 20:32:12 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 12, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Oct 12, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:32:12 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 12, 2023):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Nov 12, 2023): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review 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#8085
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?