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

[jeremystretch]

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

[ITJamie]

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

[bryanward-net]

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.

[bctiemann]

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?

[sleepinggenius2]

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.

[bctiemann]

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.

[sleepinggenius2]

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.