From https://forums.freebsd.org/threads/epair-and-mac-addresses.18419/
Fetched 2025-03-29
AndAlooongCameFreeBSD
    Mar 25, 2024 
    #3
Hijacking this old thread for visibility because I just had a
connectivity problem with custom MAC addresses on an epair used in a
bridge for a jail and I couldn't find obvious documentation about my
findings neither in epair(4) nor in ifconfig(8).
As we all know ifconfig epair0 create creates epair0a and epair0b with
a locally administered MAC address (a MAC address where the
second-least-significant bit of the MAC address is set to 1). This
means that the first octet of the MAC address could start with 02
(binary representation: 0000 0010).
epair(4) creates MAC addresses for epair0a and epair0b that end in :0a
and :0b, respectively. This seems to have relevance for epair(4)'s
internal mechanism that maps the a-side of the epair to its b-side.
I restart my jails and create epairs and bridges dynamically (sort of)
in my testing environment. So I was a little annoyed that external
functionality that depends on a consistent MAC address didn't work
anymore as each time an epair was (re-)created I got a new epair MAC
address.
So what I did in my jail.conf was:
#+begin_src ucl :eval no
exec.created += "ifconfig epair0a ether 02:de:ad:be:ef:0a";
exec.created += "ifconfig epair0b ether 02:de:ad:be:ef:0b";
#+end_src
Now epair0b's new custom MAC address happily presents itself to
external devices that depend on consistent MAC addresses while
epair(4) is able to map epair0a to epair0b, not breaking the
connectivity between the a-side and the b-side.
Note that ifconfig epair0[a|b] still shows a different hwaddr but the
external network (check using arp) sees the custom MAC address as
intended.
Also note from ifconfig(8):
> ether   Synonymous with link (with some exceptions, see -l).
> [...]
> link    Default, if inet is not available.
> lladdr  Synonymous with link.