Ensure MAC address uniqueness

[Deever]

Hi folks!

I'm setting up a somewhat complex network and need ensure that all MAC addresses (of interfaces with an IP) are unique, including all cloned interfaces. While f.e. vlan(4) or lagg(4) devices inherit their MAC addresses from their underlying device (also "recursively" eth <- lagg <- vlan), it's not possible for devices like bridge(4) or tun(4)/tap(4). How can I still make sure that there won't be any collision? I'd also prefer not to have any means of book-keeping MAC addresses.

Greetings,
/dev

 

[Deever]

A bridge generally doesn't inherit MAC because bridge means also "cloned interfaces"

Yes. With cloned interfaces I refer to all interfaces that need a "create" verb to be used first, which is done in /etc/rc.conf by listing them in the cloned_interfaces variable

Cloned interfaces means they must have the same MAC...

No, cloning has nothing to do with MAC addresses by itself.

When you set the MAC address of the bridge , this will automatically reset and change the MAC address of any of the members of the Bridge.

And further, if you add a new member in the bridge on the fly, the MAC address of this interface will be automatically changed

I cannot replicate that behaviour here...
Which type of member interface did you use to encounter this?

[...]
If you set same MAC address on interfaces not included in a bridge, you will run in very very serious problems. This is a thing that you should never do.

That's why I'm asking this question. How can I make sure that all interfaces with an IP get their unique MAC address without inheriting them or some annoying book-keeping?

Greetings,
/dev

 

[olli@]

How can I make sure that all interfaces with an IP get their unique MAC address without inheriting them or some annoying book-keeping?

Actually it doesn't matter whether the bridge interface has an IP or not. Bridging happens on the link layer, not on the IP layer (if you want the latter, that would be routing instead of bridging). Actually, a bridge(4) interface often does not have an IP, although it can be assigned one if needed.

Regarding the MAC address, the bridge(4) manual page says:

    The if_bridge interface randomly chooses a link (MAC) address in the
    range reserved for locally administered addresses when it is created.
    This address is guaranteed to be unique only across all if_bridge
    interfaces on the local machine.  Thus you can theoretically have two
    bridges on the different machines with the same link addresses.  The
    address can be changed by assigning the desired link address using
    ifconfig(8).

    If sysctl(8) node net.link.bridge.inherit_mac has non-zero value, newly
    created bridge will inherit MAC address from its first member instead of
    choosing random link-level address.  This will provide more predictable
    bridge MAC without any additional configuration, but currently this
    feature is known to break some L2 protocols, for example PPPoE that is
    provided by ng_pppoe(4) and ppp(8).  Now this feature is considered as
    experimental and is turned off by-default.

That pretty much summarizes your options.

Alternatively, you can construct a MAC address for every virtual interface by using the prefix reserved for locally administered addresses and construct the suffix from the host's (primary) IP address which should be unique within your network.

 

[Deever]

Actually it doesn't matter whether the bridge interface has an IP or not. Bridging happens on the link layer, not on the IP layer (if you want the latter, that would be routing instead of bridging). Actually, a bridge(4) interface often does not have an IP, although it can be assigned one if needed.

Yes, it's needed. Without an IP address there couldn't be any conflicts and I wouldn't have asked.
net.link.bridge.inherit_mac would actually be great, but I have an setup as follows:

                                   +---------+   +-----------+
                                   |         |   |           |
                               +---+  vlan0  +---+  bridge0  |
                               |   |         |   |           |
                               |   +---------+   +-----------+
                               |
+--------+                     |   +---------+   +-----------+
|        |                     |   |         |   |           |
|  eth0  +---+                 +---+  vlan1  +---+  bridge1  |
|        |   |   +---------+   |   |         |   |           |
+--------+   |   |         |   |   +---------+   +-----------+
             +---+  lagg0  +---+
+--------+   |   |         |   |   +---------+   +-----------+
|        |   |   +---------+   |   |         |   |           |
|  eth1  +---+                 +---+  vlan2  +---+  bridge2  |
|        |                     |   |         |   |           |
+--------+                     |   +---------+   +-----------+
                               |
                               |   +---------+   +-----------+
                               |   |         |   |           |
                               +---+  vlan3  _---+  bridge3  |
                                   |         |   |           |
                                   +---------+   +-----------+

Here, all bridges obviously would inherit the same MAC address with net.link.bridge.inherit_mac.

Alternatively, you can construct a MAC address for every virtual interface by using the prefix reserved for locally administered addresses and construct the suffix from the host's (primary) IP address which should be unique within your network.

I think this is the path I'll eventually go. Still need to think through with Virtualization and VM migration (and thus MAC migration).

 

[phoenix]

And the problem with each bridge having the same MAC is ... ? They're all in separate vlans, with separate MAC/ARP tables.

It's no different than having a single physical NIC and creating 14 different vlan interfaces on top. They'd all have the same MAC as the physical interface, but they're all on different broadcast domains with different IPs in different subnets, so what's the issue?

Any VMs you create will have their own MACs attached to the virtual NICs, which would be attached to individual bridge interfaces, so there won't be anything to worry about there, either/