Multiple MAC addresses on interface

[lps-rocks]

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

[jeremystretch]

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.

[lps-rocks]

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.

[jeremystretch]

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]

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.

[bryanward-net]

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.

[ITJamie]

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

[llamafilm]

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: #17001