Improvement for MAC address uniqueness of if_epair(4)

[hrs]

Summary

Problem description:

When creating multiple if_epair(4) interfaces, MAC addresses which
conflict with each other can be generated in the following scenarios:

1. Successive if_clone_create() and if_vmove()
   
   Some users have experienced duplicated MAC addresses upon creation of vnet jails by using "ifconfig epairN create" in exec.start and "vnet.interface=epairNb" in /etc/jail.conf. This causes creation of an if_epair(4) and then if_vmove() repeatedly on host environment, so the same ifindex is re-used and it results in the same MAC addresses.
2. if_epair(4) created in a vnet jail
   
   ifindex is not unique in a system-wide basis because cloner of if_epair(4) is vnet-local. This means that the same MAC address is generated on host environment and in a vnet jail if an if_epair(4) interface is crated in the jail.
   
   There are related PRs such as PR 184149.

Implementation of fix:

• Use a system-wide counter of the number of if_epair(4) interfaces instead of ifindex. This guarantees that MAC address is unique.
• Use cr_prison->pr_id in organizationally unique identifier in a MAC address. This information is helpful to identify where the interface is created and/or comes from.

Questions:

I am wondering why a part of eaddr is not initialized in
epair_clone_create() in the current implementation. It generates
unstable results in the organizationally unique identifier. Is this
intentional or just forgotten? In this patch, eaddr is zero'd first.

[bz]

I wonder if we should snag a selection of the FreeBSD ethernet address assignment space (talk to gnn) and do the right thing rather than having a locally administered?

Also I'd rather have a random local part with the slight chance of collisions rather than something deterministic as the moment you bridge them out to a real ethernet you get a lot of conflicts if you have multiple net machines on the same VLAN.

The only real solution to avoid long-term conflicts for people is to have their own management and statically assign the ether address to the jail to avoid us having to guess one.

Other virtual interfaces (e.g. if_bridge) should probably need a similar solution?

[wollman]

In D1858#35577, @bz wrote:

Also I'd rather have a random local part with the slight chance of collisions rather than something deterministic as the moment you bridge them out to a real ethernet you get a lot of conflicts if you have multiple net machines on the same VLAN.

The only real solution to avoid long-term conflicts for people is to have their own management and statically assign the ether address to the jail to avoid us having to guess one.

What he said.

[eugen_grosbein.net]

This was fixed long time ago, please close.

[hrs]

Fixed in a different way in r334094.