For several years now, I've been enjoying the fact that the systemd-networkd DHCP server seems to do the right thing, but a question has arisen, and I'm getting results that I can't explain.

Basically, the embedded system we've assembled has a WAN interface and one or more client interfaces, and the client devices get a local IP address and are then routed/NATted out the WAN interface -- real simple stuff. The WAN interface usually gets its IP address by DHCP, and when the client device gets its address from our DHCP server, the DNS received from the WAN is included in the DHCP lease for the client.

Sometimes this isn't happening, however; sniffing the DHCP request/ack exchange on the client system, I see no DNS address at all, even though the lease packets from the WAN do indeed have DNS address(es) in them. The only possible cause I've found is that when this has happened, the WAN's default gateway isn't able to go anywhere -- but I can see no mechanism that would communicate this situation to our device.

Picture:

Internet
     |
Corp GW
     |  10.1.10.1/24
     |
     |  10.1.10.230/24
Lab Router
     |  192.168.11.1/24
     |
     |  192.168.11.123/24
Embedded Device
     |  192.168.247.1/24
     |
     |  192.168.247.101/24
Client  Device

Everything here has a DHCP client on the top side and a DHCP server on the bottom side except for Corp GW and Client Device. There's a DHCP server somewhere on the corporate LAN, but that's out of my scope. In its DHCP server role, Lab Router always includes "192.168.11.1" as DHCP option 6 (DNS) in its DHCP ACK packets. Sometimes Embedded Device emits that in its DCHP ACK packets, and sometimes it doesn't. As I said above, if the cable on Lab Router's 10.1.10 interface is disconnected, that's when it seems to happen -- but not always.

For what it's worth, our DHCPServer section of the .network file looks like this:

[DHCPServer]
EmitRouter=yes
EmitDNS=yes
EmitNTP=yes
PoolOffset=100
PoolSize=50
DefaultLeaseTimeSec=20
MaxLeaseTimeSec=20

(Yes, I know that a 20-second lease time seems insane. I won't try to explain it here.)

Thanks in advance for any insight.

--
Bruce A. Johnson
Chantilly, Virginia, USA
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to