Keeping it on-list


Rod Rodolico <rodo@???> wrote:

> Stupid question, but do you have a static MAC address assigned to your
> virtual? My dhcp server reads the MAC, then determines what IP to give
> it. Xen gives random MAC addresses if you do not assign one. Assuming
> KVM does it also.
>
> Xen has the block 00:16:3e:* reserved for it, so I wrote a little Perl
> script to randomly generate one every time I build a virtual, since the
> MAC should be unique in a network.

Yes, I've given it a fixed MAC, and I've set it's lease as reserved on the server. BTW, if the 7th bit is set, then that signifies locally managed MAC addresses - so mine are now 02:xx:xx:xx:xx:xx.

The problem is triggered by a change in DCHP Client behaviour. It used to be that the ISC client did **NOT** send a Client-ID by default - which meant various problems when multi-booting with other OSs that send the hardware address by default.
Now the ISC client sends a DUID-LLT value by default. This is a combination of hardware address and time, the theory being that it remains constant even if the MAC address changes. If there's a Client-ID then the server uses this as the primary lease key and does not consider the hardware address at all.

The behaviour I've been seeing is consistent with the DHCP client being started before it's local lease database is available - and so it has no access to the stored DUID. As a result, it generates a new one, and obviously the time will be different to the previous ones - hence as far as the server is concerned, on each boot it's a different client and gets a different address.
Manually dropping and restarting the interface means the client gets access to it's lease database, so it uses the stored DUID, and so it gets the reserved address.

I've been trying to debug the issue by adding logging to both /etc/network/interfaces and /etc/init.d/network - try doing that with SystemD :D As soon as I tried that, on the next boot it worked as it should :-/ Then it didn't work on the next boot.
I can't help thinking that something is bringing up eth0 before the disk filesystems are mounted (i.e. while it's still running from it's initramfs) - but I just can't find any evidence of that other than the interface already being up when /etc/init.d/networking is run to bring up networking.

I'll have another go at it when I next get a bit of spare time.

Simon