dhcpd sending on the same IP it receives on

Jared Gillis jared at sonic.net
Tue Feb 5 18:23:54 UTC 2008


I am having a similar problem as initially discussed in this thread:

I have a linux DHCP server that has two uplinks, each of which goes to a router that is relaying DHCP requests to the DHCP server. Router A is on eth0, Router B is on eth1. The DHCP server's default gateway points at Router A. There is a very small corner case in which this causes a problem:

Router B gets a broadcast DHCPDISCOVER, and relays the request to the DHCP server, then takes the reply and hands it to the client. The client's DHCP implementation then switches to unicast for further DHCP traffic, sending to the server's eth1 address. The client sends a DHCPREQUEST packet to the server to renew the lease, and the server replies, but from eth0's IP address.

This *is* broken, as we are talking about unicast IP traffic, and if the DHCP client happens to be behind a stateful packet inspection firewall, the DHCP reply gets dropped, and the client never receives the response.

I looked into the local-address configuration option, but since we are answering DHCP requests on both interfaces, that would mean we'd have to run two daemons, which is not a good solution for us.

Does anyone know of a workaround/fix for this, and if not, where can I submit a bug report? =)


Quote from MARC:

Glenn Satchell wrote:
>> Date: Tue, 11 Dec 2007 12:04:29 -0800
>> From: Scott Baker <bakers at web-ster.com>
>> To: dhcp-users at isc.org
>> Subject: dhcpd sending on the same IP it receives on
>> My DHCP server has multiple ips on its primary NIC. For example:
>> eth0   =
>> eth0:0 =
>> I have my access equipment set to send DHCP relay to, but
>> when the DHCP server responds it sends the response packet out via
>> the address since that is the primary address on that NIC.
>> This causes my access equipment to drop the packet because the IP it
>> sent to, and got the response from do not match.
>> Is there way to tell the dhcpd daemon to send the packets outbound
>> using the same IP (interface) that it received the packet on?
>> The simple answer is to reverse the IPs so that is the
>> primary, but that's not really feasible since I have other services
>> that require that be the primary IP.
>> -- 
>> Scott Baker - Canby Telcom
>> RHCE - System Administrator - 503.266.8253
> Have a look at the server-identifier statement, and maybe the
> local-address statement. Between them they may do what you want.
> In general though, the source address on an IP packet is a function of
> the IP kernel driver and not the application. Virtual interfaces are
> not like separate physical interfaces, the packets always go in and out
> via eth0, it's just that it will accept packets with either IP
> address.

That's not entirely true. The source IP is a function of the socket bound IP. If this is INADDR_ANY, it'll default to an in-kernel decision. AFACIT dhcpd binds a single FD to INADDR_ANY.

I have tried to use dhcpd in various policy-routed ways in the past, and it is hard. It would be nice if dhcpd behaved in a similar manner to bind/named and ntpd, and bound a file descriptor to each IP (re-discovering the IPs every N minutes) and always replied via the same file descriptor the request came in on. 

More information about the dhcp-users mailing list