Duplicate mac addresses that could cause network issues

Not sure whether it is common standard/practice but apparently in the TO any interface on top of the hardware layer/device is given the same mac address as the hardware layer, e.g. eth0.x vlans are featuring the same mac address as eth0 as well as br-lan when enslaving eth0.

This would not be problem yet since out of those only br-lan gets an ip assigned. Adding however another bridge to the same layer chain, e.g. br-foobar enslaving eth0.2 will be assigned the same mac as br-lan, and thus having suddenly 2 interfaces with the same mac address but different ip.
Something less than ideal and which could cause some grievance in the network layout/operation.

However, it can be worked around by setting a different mac (option macaddr) on any such interface duplicating a mac address from an ip interface already being assigned that mac.

Hi @anon50890781

Thank you for this useful hint.

Are there some rules to be followed to choose the value of the new MAC address?

it seems to be common practice

unsure why/if this is a problem

a safe bet is to increment one of the lower values, like onmia does by default for its eth interfaces.
eg. 4d:ef:c0:a1:ae:d34d:ef:c0:a1:ae:d4

but the probability for a collision with a completely random address are miniscule.

It can be a problem. For example you can have more bridge ifaces getting IP from DHCP. Then DHCP server see one MAC only and tries to assign same IP for all ifaces.

1 Like

Something like this can happen

I could hardly imagine all the grievance in a network caused if it was common practice. It seems rather that mac address pools are the standard to avoid mac address duplications and thus any oddities that may result from those.

it also sucks differently with each kernel :wink:

How so, that is about the Cumulus distro in particular and not the Linix kernel in general?