Page MenuHomeFreeBSD

Improvement for MAC address uniqueness of if_epair(4)
AbandonedPublic

Authored by hrs on Feb 16 2015, 6:01 PM.

Details

Reviewers
wollman
bz
Group Reviewers
network
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.

Diff Detail

Repository
rS FreeBSD src repository
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

hrs retitled this revision from to Improvement for MAC address uniqueness of if_epair(4).Feb 16 2015, 6:01 PM
hrs updated this object.
hrs edited the test plan for this revision. (Show Details)
hrs added a reviewer: bz.
hrs updated this revision to Diff 3797.
hrs added a reviewer: network.Feb 20 2015, 1:37 AM
bz edited edge metadata.Mar 12 2015, 4:49 PM

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 requested changes to this revision.
wollman added a subscriber: 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.

This revision now requires changes to proceed.Sep 6 2015, 8:00 PM

This was fixed long time ago, please close.

hrs abandoned this revision.Mar 12 2019, 5:50 AM

Fixed in a different way in r334094.