When creating multiple if_epair(4) interfaces, MAC addresses which
conflict with each other can be generated in the following scenarios:
- 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.
- 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.
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.