Multiple MAC addresses on interface #3870

New Issue

adam · 2025-12-29T18:31:41+01:00

adam commented

2025-12-29 18:31:41 +01:00

Originally created by @lps-rocks on GitHub (Jul 18, 2020).

Originally assigned to: @bctiemann on GitHub.

Environment

Python version: 3.7.6
NetBox version: 2.8.7

Proposed Functionality

Allow for multiple MAC addresses to be specified per physical interface. Enable the ability to tag a mac address as physical or virtual. Physical mac addresses are permanent and are unique in Netbox, Virtual mac addresses may be duplicated across devices in Netbox.

Use Case

In situations where devices use 'Virtual' MAC addresses (e.g. hot/standby firewall configurations). Documenting both the physical device MAC as well as the 'Virtual' MAC address to a physical interface would be beneficial for tracing. Allowing a 'Virtual' mac address to exist on multiple devices allows for searching and tying clustered hot/standby devices together transparently.

Database Changes

Would probably require a new one->many relationship of interface->mac address as well as fields on a mac address to permit flagging as physical or virtual.

External Dependencies

Originally created by @lps-rocks on GitHub (Jul 18, 2020). Originally assigned to: @bctiemann on GitHub.  ### Environment * Python version: 3.7.6 * NetBox version: 2.8.7  ### Proposed Functionality Allow for multiple MAC addresses to be specified per physical interface. Enable the ability to tag a mac address as physical or virtual. Physical mac addresses are permanent and are unique in Netbox, Virtual mac addresses may be duplicated across devices in Netbox.  ### Use Case In situations where devices use 'Virtual' MAC addresses (e.g. hot/standby firewall configurations). Documenting both the physical device MAC as well as the 'Virtual' MAC address to a physical interface would be beneficial for tracing. Allowing a 'Virtual' mac address to exist on multiple devices allows for searching and tying clustered hot/standby devices together transparently.  ### Database Changes Would probably require a new one->many relationship of interface->mac address as well as fields on a mac address to permit flagging as physical or virtual.  ### External Dependencies

adam added the status: accepted type: feature complexity: medium netbox labels 2025-12-29 18:31:41 +01:00

adam closed this issue

2025-12-29 18:31:41 +01:00

adam commented

2025-12-29 18:31:41 +01:00

@jeremystretch commented on GitHub (Jul 20, 2020):

I think it'd be reasonable to change mac_address from a single value to an array field capable of holding zero or more MAC addresses.

Enable the ability to tag a mac address as physical or virtual.

This doesn't seem necessary, since it's typically implied the OUI (the first 24 bits of the address). It would also necessitate the creation of a separate MAC address model, which, while not unreasonable, would be a much more substantial change.

@jeremystretch commented on GitHub (Jul 20, 2020): I think it'd be reasonable to change `mac_address` from a single value to an array field capable of holding zero or more MAC addresses. > Enable the ability to tag a mac address as physical or virtual. This doesn't seem necessary, since it's typically implied the OUI (the first 24 bits of the address). It would also necessitate the creation of a separate MAC address model, which, while not unreasonable, would be a much more substantial change.

adam commented

2025-12-29 18:31:41 +01:00

@lps-rocks commented on GitHub (Jul 20, 2020):

I totally understand and appreciate the idea of keeping the change as
minimal and simple as possible.

The advantage to creating a separate MAC address model would allow for the
model to Eventually be referenced. There’s situations where a physical
interface may have multiple MACs assigned to it and an IP assigned to each
MAC. (Shared IPMI ports as an example).

It would also allow for MAC addresses to be more efficiently searched.
Right now I can’t search by MAC address :( makes me sad. That’s one of the
primary things network admins like to search by. (Another feature request
I’m going to put in)

The downside of using the first 24 bits for implied virtualization is it
would require maintaining code that knows if it’s virtual or not (IIRC
there’s 4 specific hunks of MAC space for Locally Administered MAC
Addressing) and a number of vendors and FOSS projects violate that
specification.

@lps-rocks commented on GitHub (Jul 20, 2020): I totally understand and appreciate the idea of keeping the change as minimal and simple as possible. The advantage to creating a separate MAC address model would allow for the model to Eventually be referenced. There’s situations where a physical interface may have multiple MACs assigned to it and an IP assigned to each MAC. (Shared IPMI ports as an example). It would also allow for MAC addresses to be more efficiently searched. Right now I can’t search by MAC address :( makes me sad. That’s one of the primary things network admins like to search by. (Another feature request I’m going to put in) The downside of using the first 24 bits for implied virtualization is it would require maintaining code that knows if it’s virtual or not (IIRC there’s 4 specific hunks of MAC space for Locally Administered MAC Addressing) and a number of vendors and FOSS projects violate that specification.

adam commented

2025-12-29 18:31:42 +01:00

@jeremystretch commented on GitHub (Jul 20, 2020):

It would also allow for MAC addresses to be more efficiently searched. Right now I can’t search by MAC address

There are mac_address filters on the device, VM, and interface models today which support this.

@jeremystretch commented on GitHub (Jul 20, 2020): > It would also allow for MAC addresses to be more efficiently searched. Right now I can’t search by MAC address There are `mac_address` filters on the device, VM, and interface models today which support this.

adam commented

2025-12-29 18:31:42 +01:00

@jeremystretch commented on GitHub (Sep 1, 2020):

As there has been no further feedback, let's proceed with the ArrayField approach to assigning multiple MAC addresses. As this will effect both database and REST API changes, this proposal is awaiting milestone assignment.

@jeremystretch commented on GitHub (Sep 1, 2020): As there has been no further feedback, let's proceed with the ArrayField approach to assigning multiple MAC addresses. As this will effect both database and REST API changes, this proposal is awaiting milestone assignment.

adam commented

2025-12-29 18:31:42 +01:00

@bryanward-net commented on GitHub (Jun 29, 2023):

I have some very unfortunate Audio/Video devices that have multiple MAC Addresses on a single interface and use a separate IP Address for each MAC Address. (Internally, there's a mini switch to 1 or more CPUs, or they're running multiple software processes at Layer-2, or it's running VMs/containers and we just don't know it.) They are all on the same, untagged, VLAN. I'm trying to model the devices and connections for the purposes of assigning Fixed DHCP Reservations.

The MAC Address field on the Interface object is just plain text, but it's validating that a single valid MAC Address was entered.
Use of Child/Parent interfaces might be a workaround, but there's no single API call I can make, from what I can tell, to determine if an interface has children.

An interface can have multiple IP Addresses assigned, but no way to correlate them to a specific MAC Address (for fixed DHCP leases). I can add a MAC Address custom field to the IP Address model, but that doesn't seem like an elegant fix either.

Adding a MAC Address model and allowing multiple MAC Addresses to be assigned to an interface, and additionally linked to one or more IP Address objects (in the case of something like Cisco's ip address 192.168.1.1/24 secondary), would be an elegant fix.

Incorporating an OUI Lookup feature would be a nice cherry on top. (So that wherever a MAC Address is displayed it displays the Vendor, or decodes the global/local bits, etc.) This might also have some nice implications for modelling Multicast groups.

Essentially, trying to model the intended state of the CAM and ARP tables is my goal.

@bryanward-net commented on GitHub (Jun 29, 2023): I have some very unfortunate Audio/Video devices that have multiple MAC Addresses on a single interface and use a separate IP Address for each MAC Address. (Internally, there's a mini switch to 1 or more CPUs, or they're running multiple software processes at Layer-2, or it's running VMs/containers and we just don't know it.) They are all on the same, untagged, VLAN. I'm trying to model the devices and connections for the purposes of assigning Fixed DHCP Reservations. The MAC Address field on the Interface object is just plain text, but it's validating that a single valid MAC Address was entered. Use of Child/Parent interfaces might be a workaround, but there's no single API call I can make, from what I can tell, to determine if an interface has children. An interface can have multiple IP Addresses assigned, but no way to correlate them to a specific MAC Address (for fixed DHCP leases). I can add a MAC Address custom field to the IP Address model, but that doesn't seem like an elegant fix either. Adding a MAC Address model and allowing multiple MAC Addresses to be assigned to an interface, and additionally linked to one or more IP Address objects (in the case of something like Cisco's `ip address 192.168.1.1/24 secondary`), would be an elegant fix. Incorporating an OUI Lookup feature would be a nice cherry on top. (So that wherever a MAC Address is displayed it displays the Vendor, or decodes the global/local bits, etc.) This might also have some nice implications for modelling Multicast groups. Essentially, trying to model the intended state of the CAM and ARP tables is my goal.

adam commented

2025-12-29 18:31:42 +01:00

@ITJamie commented on GitHub (Jun 29, 2023):

Another example are some servers with shared OOB and lan ports.

Where there is an OOB/idrac running off the same physical port used by the server os.

There are separate macs for the drac vs the nic presented to the os

I have seen this on dell servers

@ITJamie commented on GitHub (Jun 29, 2023): Another example are some servers with shared OOB and lan ports. Where there is an OOB/idrac running off the same physical port used by the server os. There are separate macs for the drac vs the nic presented to the os I have seen this on dell servers

adam commented

2025-12-29 18:31:42 +01:00

@llamafilm commented on GitHub (Jul 26, 2024):

I don't think this proposal would be useful for shared OOB interfaces, because the OOB interface may be tagged with a different VLAN. I have been adding another virtual interface for that, with the primary interface as its parent. Does that work for you @ITJamie ? The only issue with that is I can't model it on the Device Type; I have to do it on each Device. See here: https://github.com/netbox-community/netbox/discussions/17001

@llamafilm commented on GitHub (Jul 26, 2024): I don't think this proposal would be useful for shared OOB interfaces, because the OOB interface may be tagged with a different VLAN. I have been adding another virtual interface for that, with the primary interface as its _parent_. Does that work for you @ITJamie ? The only issue with that is I can't model it on the Device Type; I have to do it on each Device. See here: https://github.com/netbox-community/netbox/discussions/17001

adam commented

2025-12-29 18:31:42 +01:00

@jeremystretch commented on GitHub (Oct 17, 2024):

We discussed this briefly in today's maintainer meeting, and we may be leaning toward introducing a separate MACAddress model (similar to the IPAddress model) to provide more robust functionality. There are, however, some trade-offs.

Pros

MAC addresses become "first class citizens"
Easy to enforce uniqueness
Can attach extra information to an address (e.g. a description)
Robust filtering support

Cons

Introduces more overhead when dealing with interfaces (separate table)
Potentially a more disruptive change than the array approach
Complexity of relating MACAddress to both Interface and VMInterface

@jeremystretch commented on GitHub (Oct 17, 2024): We discussed this briefly in today's maintainer meeting, and we may be leaning toward introducing a separate MACAddress model (similar to the IPAddress model) to provide more robust functionality. There are, however, some trade-offs. ### Pros - MAC addresses become "first class citizens" - Easy to enforce uniqueness - Can attach extra information to an address (e.g. a description) - Robust filtering support ### Cons - Introduces more overhead when dealing with interfaces (separate table) - Potentially a more disruptive change than the array approach - Complexity of relating MACAddress to both Interface and VMInterface

adam commented

2025-12-29 18:31:42 +01:00

@ITJamie commented on GitHub (Oct 17, 2024):

A separate model would help a lot of other usecases. We got burnt today ironically where two vms had the same mac address autogenerated and ended up in the same vlan. With netbox having mac uniqueness it would have given an error during our sot/sor syncs when attempting to create that duplicate mac interface assignment.

We also have an official mac address prefix, being able to track the usage of those in a native way in netbox would be great, especially if there was a "next available mac address" endpoint which would generate the next available one from our mac prefix assignment

@ITJamie commented on GitHub (Oct 17, 2024): A separate model would help a lot of other usecases. We got burnt today ironically where two vms had the same mac address autogenerated and ended up in the same vlan. With netbox having mac uniqueness it would have given an error during our sot/sor syncs when attempting to create that duplicate mac interface assignment. We also have an official mac address prefix, being able to track the usage of those in a native way in netbox would be great, especially if there was a "next available mac address" endpoint which would generate the next available one from our mac prefix assignment

adam commented

2025-12-29 18:31:42 +01:00

@bryanward-net commented on GitHub (Oct 22, 2024):

We also use MAC address assignments for VTEP interfaces. Folks using VRRP might also have a desire for a MAC Address model.
VM Admins might want to document (or assign next-available) MAC Addrs to their VMs too.

@bryanward-net commented on GitHub (Oct 22, 2024): We also use MAC address assignments for VTEP interfaces. Folks using VRRP might also have a desire for a MAC Address model. VM Admins might want to document (or assign next-available) MAC Addrs to their VMs too.

adam commented

2025-12-29 18:31:42 +01:00

@bctiemann commented on GitHub (Oct 25, 2024):

I'm thinking to split this into two FRs -- one for the main functionality of multiple MACAddress models linked to Interfaces and VMInterfaces, and then a second FR for later to add linkage to IPAddresses (as noted by @bryanward-net this would be a useful additional piece, but it's not clear to me what shape the data should take — a M2M relation between MACAddresses and IPAddresses? Many-to-one? One-to-many?)

For the time being and the initial feature work, my plan is for the MACAddress model to look like this (paraphrased):

class MACAddress(models.Model):
    mac_address = MACAddressField()
    interface = models.ForeignKey('dcim.Interface', null=True)
    vm_interface = models.ForeignKey('virtualization.VMInterface', null=True)

In other words, a many-to-one relationship where an Interface or VMInterface can have many MACAddresses. And then Interface and VMInterface would each have a primary_mac_address FK which points to one of the MACAddresses linked to that (vm)interface.

The existing mac_address field will be removed; in the data migration that field will get renamed to _mac_address or legacy_mac_address and the data populated into MACAddress objects, and then the legacy field will be deleted. Then Interface.mac_address will become a @property that reflects the value of primary_mac_address.mac_address, which would preserve backward compatibility of behavior.

Does that sound like a reasonable first pass?

@bctiemann commented on GitHub (Oct 25, 2024): I'm thinking to split this into two FRs -- one for the main functionality of multiple MACAddress models linked to Interfaces and VMInterfaces, and then a second FR for later to add linkage to IPAddresses (as noted by @bryanward-net this would be a useful additional piece, but it's not clear to me what shape the data should take — a M2M relation between MACAddresses and IPAddresses? Many-to-one? One-to-many?) For the time being and the initial feature work, my plan is for the `MACAddress` model to look like this (paraphrased): ``` class MACAddress(models.Model): mac_address = MACAddressField() interface = models.ForeignKey('dcim.Interface', null=True) vm_interface = models.ForeignKey('virtualization.VMInterface', null=True) ``` In other words, a many-to-one relationship where an `Interface` or `VMInterface` can have many `MACAddress`es. And then `Interface` and `VMInterface` would each have a `primary_mac_address` FK which points to one of the `MACAddress`es linked to that (vm)interface. The existing `mac_address` field will be removed; in the data migration that field will get renamed to `_mac_address` or `legacy_mac_address` and the data populated into `MACAddress` objects, and then the legacy field will be deleted. Then `Interface.mac_address` will become a `@property` that reflects the value of `primary_mac_address.mac_address`, which would preserve backward compatibility of behavior. Does that sound like a reasonable first pass?

adam commented

2025-12-29 18:31:42 +01:00

@sleepinggenius2 commented on GitHub (Nov 19, 2024):

I unfortunately was not able to catch this before it got closed, but just wanted to say that this model as proposed would not work in our environment. We have thousands of switch devices where all the physical interfaces on a given device share the same MAC address, so we would need the relationship between MACAddress and Interface to be M2M.

@sleepinggenius2 commented on GitHub (Nov 19, 2024): I unfortunately was not able to catch this before it got closed, but just wanted to say that this model as proposed would not work in our environment. We have thousands of switch devices where all the physical interfaces on a given device share the same MAC address, so we would need the relationship between MACAddress and Interface to be M2M.

adam commented

2025-12-29 18:31:42 +01:00

@bctiemann commented on GitHub (Nov 19, 2024):

There is not a uniqueness constraint on the actual mac_address value, so there can be an arbitrary number of MACAddress objects each linked to a different interface.

@bctiemann commented on GitHub (Nov 19, 2024): There is not a uniqueness constraint on the actual mac_address value, so there can be an arbitrary number of `MACAddress` objects each linked to a different interface.

adam commented

2025-12-29 18:31:43 +01:00

@sleepinggenius2 commented on GitHub (Nov 19, 2024):

Thanks, I missed that uniqueness was not being enforced on the value! Really looking forward to MAC addresses becoming first-class citizens, and especially once the relationship to IP addresses it added, so we can finally track static DHCP reservations properly.

@sleepinggenius2 commented on GitHub (Nov 19, 2024): Thanks, I missed that uniqueness was not being enforced on the value! Really looking forward to MAC addresses becoming first-class citizens, and especially once the relationship to IP addresses it added, so we can finally track static DHCP reservations properly.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#3870