I’m using a physical interface on top of a bridge, then I’m using a stand-alone dnsmasq instance to allocate IP’s for containers launched on that bridge. It works fine, except it seems that each time a container is restarted, it’s issues a new “random” mac address.
If I set the “hwaddr” attribute on the container’s “eth-1”, then I get a consistent mac address each time the container is restarted.
Is this intended behaviour? / Is there a way to automatically make mac addresses persistent, or do I need to manually set “hwaddr” for each container when i create it … or do I create a container then “override” the hwaddr? (I’m a little frightened of the last option as overriding network setting seems to set off my ZFS lock-up problem)
Hmm. It would appear that if you create an interface on a managed bridge you do indeed get a prefix of 10:66:6a… , however if you create an interface on a physical network that backs onto a host bridge, you get a completely random mac.
There are no fully random MACs. The first few octets identify the vendor that has requested the range. If you have an unknown MAC, you can go to https://macvendors.com/ and identify the vendor.
Incus and other virtualization projects would use the allocation from (I think) the Xen project, and more recently there’s another allocation that was added.
Ok, so I think I understand what you’re saying … but this is what is confusing me;
$ ssh gw2
Linux gw2 6.1.0-37-arm64 #1 SMP Debian 6.1.140-1 (2025-05-22) aarch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jul 3 14:16:16 2025 from aa.bb.cc.dd
root@gw2:~# incus shell demo
root@demo:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1370
inet6 fe80::70:c9ff:fe28:7157 prefixlen 64 scopeid 0x20<link>
ether 02:70:c9:28:71:57 txqueuelen 1000 (Ethernet)
RX packets 21 bytes 2558 (2.4 KiB)
TX packets 15 bytes 2034 (1.9 KiB)
root@gw2:~# incus restart demo
root@gw2:~# incus shell demo
root@demo:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1370
inet6 fe80::ec2c:b5ff:fe10:5e45 prefixlen 64 scopeid 0x20<link>
ether ee:2c:b5:10:5e:45 txqueuelen 1000 (Ethernet)
RX packets 18 bytes 1548 (1.5 KiB)
TX packets 12 bytes 1296 (1.2 KiB)
Now what you seem to be saying is that the mac address should always be generated according to a set of rules, and these rules should at least ensure a consistent prefix. (although I’m not sure whether you are saying the remainder might be random)
There’s nothing exotic going on here, this is a clean install, Debian 12, Zabbly 6.14 on a Hetzner cloud instance. Container is a Debian 12 cloud instance with a single device level attachment. No overrides.
If this is the case (!), surely after a restart the container should at least retain the same prefix … what am I not getting?
Your smartphone and other such devices would do LAA for privacy purposes. The privacy reason is that if a mobile device emits the same WiFi MAC address, then others will be able to identify specific devices. Hence, there is randomization.
Linux distributions also have this feature for MAC address randomization. Definitely the desktop Linux distributions when they use NetworkManager. Do the rabbit hole search as to why you get those LAA addresses there, and how you may just disable this feature. There’s an easy option in NetworkManager, you would need to search a bit with other networking stacks.
Ok, thanks, I think I’m starting to get it. For managed networks Incus assigns a MAC address according to the specified template, but for unmanaged networks the address comes from the OS, and the default from the OS appears to be to use LAA addresses. (which are essentially random but from a specific LAA pool, so they kinda ‘look’ totally random … )
So, assuming I understand this correctly (?) the thing I’m still a little fuzzy on is “why”. I get the addressing thing re; making the OS provide DHCP for unmanaged networks (although using Incus DHCP would still be nice), but I’m not sure I get the logic of handing off MAC generation to the OS. My ‘expectation’ was that given Incus was in control of MAC addresses and by default is responsible for assigning them (indeed if you put ‘hwaddr’ in an eth device stanza it still does) it seems surprising that in this instance it releases responsibility which (at least to ‘this’ user) introduces somewhat unexpected behavior.
I understand this feature from a mobile phone perspective, just not sure how it would apply to containers running services.
)
