3

I have a machine with CoreOS 1800(or 1855) installed onto disk, and with following systemd-networkd config (there is only one network interface in the machine):

$ cat /etc/systemd/network/zz-default.network
[Network]
DHCP=yes

[DHCP]
ClientIdentifier=mac
UseMTU=true
UseDomains=true

Another notable thing is that this machine is also configured with PXE boot but PXE server will reject boot so it will finally boot from disk.

When I restart the machine, there will be two DHCP IPs allocated for it, I confirmed it by checking /var/lib/dhcpd.leases in DHCP server:

lease 100.79.223.152 { 
  starts 5 2018/09/28 02:34:00; ends 6 2018/09/29 02:33:59; tstp 6 2018/09/29 02:33:59; cltt 5 2018/09/28 02:34:00; 
  binding state active; next binding state free; rewind binding state free; 
  hardware ethernet 08:9e:01:d9:28:64; 
  option agent.circuit-id 0:5:8:b9:1:0:29;
}
lease 100.79.223.150 { 
  starts 5 2018/09/28 02:34:29; ends 6 2018/09/29 02:34:28; tstp 6 2018/09/29 02:34:28; cltt 5 2018/09/28 02:34:29; 
  binding state active; next binding state free; rewind binding state free; 
  hardware ethernet 08:9e:01:d9:28:64; uid "001010236001331(d"; 
  option agent.circuit-id 0:5:8:b9:1:0:29;
}
  • The lease record 100.79.223.152 is requested by the PXE loader, though rejected by DHCP server.
  • The lease record 100.79.223.150 is requested by systemd-networkd of CoreOS. (I can confirm it by running systemctl restart systemd-networkd and watch the leases file)

All seems fine, but the PXE lease record 100.79.223.152 cause other problem (when really PXE boot the machine and deploy another OS to it then it will get the 100.79.223.152 instead of 150, then cause other private problem).

If I install other OS which does not use systemd-networkd, then the reboot only cause 1 lease record.

You can see the lease 100.79.223.150 has a field uid "001010236001331(d", which means let DHCP server allocate IP by the uid (client identifier), currently it is actually same content of mac address, just be printed as octet.

This is the root cause of two IPs.

To prevent this two IP problem, I've tried to set deny duplicates in /etc/dhcp/dhcpd.conf in DHCP server, but nothing changes.

I was wandering that if it is possible to tell systemd-networkd not to send uid (client identifier). According to source of systemd, it is intentionally implemented to "always send client identifier",

given such condition, how can I prevent systemd-networkd from sending client identifier?

EDIT 2019/02/17: I found that I misunderstood the meaning of deny duplicates, it does not help this problem.

I remembered I had ever tested another option first but not works.

ignore-client-uids on;

The ignore-client-uids statement

ignore-client-uids flag;

If the ignore-client-uids statement is present and has a value of true or on, the UID for clients will not be recorded. If this statement is not present or has a value of false or off, then client UIDs will be recorded.

https://www.isc.org/wp-content/uploads/2017/08/dhcp43.html

The DHCP server version is isc-dhcpd-4.2.4

EDIT 2019-03-12: I had some mistaken and found something, so answered this question myself. Simple answer is ignore-client-uids true; on server side works well, ClientIdentifier=mac on client side does not work well.

osexp2000
  • 2,910
  • 30
  • 29

3 Answers3

2

Have you tried setting the client identifier to (empty)?

$ cat /etc/systemd/network/zz-default.network
[Network]
DHCP=yes

[DHCP]
ClientIdentifier=
UseMTU=true
UseDomains=true
John Greene
  • 2,239
  • 3
  • 26
  • 37
  • thank you for your suggestion, I have not tried this empty setting. I'll try it later and feed back. – osexp2000 Oct 17 '18 at 12:40
  • @osexp2003 , believe it or not, I figure out a lot of undocumented “features” by reading the source code directly. – John Greene Feb 27 '19 at 12:35
2

After many times of experiments, I found that only ignore-client-uids true; works constantly, all mystery disappeared., when you set it, you can confirm that no uid "....." appear in /var/lib/dhcp/dhcpd.leases` file, the server completely ignore the client identifier sent from client and just use MAC to determine how to allocate IP.

If you insist on using ClientIdentifier=mac, you can take a look at what I found:

  • specifying ClientIdentifier=mac (on client *.network) does let me get same IP as before. The reason why I said it does not work is probably because I have another NIC which also enabled DHCP by default hence caused a new IP.

/lib/systemd/network/zz-default.network

[Network]
DHCP=yes

[DHCP]
UseMTU=true
UseDomains=true

After I change above file to 

[Network]
DHCP=no

I got only 1 and same IP as before.

  • The client identifier will be a string "\0x1" + MAC, you can confirm it grep uid "..." in /var/lib/dhcp/dhcpd.leasesfile, e.g.,uid "001304TDD210272"`, for any non-printable char it will be encoded as 3 digits Octal such as 304. Some client automatically generate an client identifier like this "\0x1" + "MAAS" + MAC ...

  • The most unfortunate thing is: once a client send client identifier, for the same MAC, if the client send anther request WITHOUT client identifier, it will get new IP.

  • Considering DDNS, for same MAC, the DHCP request with and without client identifier are treated as different client when DHCP server composing DNS update request for it. Simply speaking,

    • for DHCP request without client identifier -> server send DDNS request with a hash of the MAC -> DNS server: OK
    • for DHCP request with client identifier -> server send DDNS request with a hash of the client identifier -> DNS server: rejected due to the hash is not same, for security.

That is all I found, hope it helpful.

osexp2000
  • 2,910
  • 30
  • 29
  • So this is the better solution? Gonna try that. But this would be only if one has ability to change the server-side, correct? – John Greene Apr 10 '20 at 12:09
0

You can also check if there is configuration under the /run/.../systemd/network/*.network, I had the same issue because of netplan putting a configuration network file in the /run which is applied instead of the etc or lib one. The solution in this case is to add the dhcp-identifier: mac in the the netplan yml configuration

visibog
  • 1
  • 1