dhcpd and relayed responses from multi-interface Linux server

[Neufeld, Keith]

> On Jun 3, 2020, at 09:44 , Simon Hobson <dhcp1 at thehobsons.co.uk> wrote:
> 
>> The DHCP servers have two interfaces ..., one for administrative access and one for application service access:
>> 
>> eth0 -- 10.1.61.16 -- admin
>> eth1 -- 10.1.69.16 -- service
>> 
>> We have subnet declarations for each interface because we need to serve clients on each of those subnets; but dhcpd is being invoked with eth1 on its command line
> 
> Is there a specific reason for doing it this way ? While it's easy to reply with what is in effect "you're building the network wrong", that does seem to be the fundamental issue here.

Our server team operates many servers with multiple interfaces ... as have I over the last thirty years ... and I haven't regarded it as "building the network wrong."  Could you say more about how that's inappropriate?



>> and appears to be listening only on eth1 as desired:
>> 
>> Jun  1 16:26:18 netsvc-516 dhcpd[704228]: Listening on LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
>> Jun  1 16:26:18 netsvc-516 dhcpd[704228]: Sending on   LPF/eth1/00:50:56:be:43:d6/10.1.69.0/24
>> Jun  1 16:26:18 netsvc-516 dhcpd[704228]: Sending on   Socket/fallback/fallback-net
>> 
>> The problem is with the "fallback" UDP socket used for transmitting unicast messages, when it needs to send responses to relayed DISCOVERs.  In common/socket.c, in the function maybe_setup_fallback(), a UDP INET socket is created but not bound to any specific interface.  Then when packets are transmitted out the fallback socket, it appears that the behavior is to use the server host's route table to decide which interface to send the packet out of, *and to use that interface's IP as the source IP*.
> ...
>> Has this come up on the list before?
> 
> I don't recall seeing this before on the list. But then it would be normal to serve the locally connected devices directly rather than via a relay agent - hence few would hit the problem.

Oh, you've mistaken my meaning.  We expect local devices to be served locally.

At least on this platform, dhcpd does not respond correctly to *any* relayed message to a multi-interface DHCP server unless the messages are relayed to the interface that is the server host's default route out.

This means, for example, that you cannot relay to multiple interfaces on the same DHCP server ... which I would like to be able to do temporarily while migrating the server from an old IP in an old subnet to a new IP in a new subnet, serving both at the same time while phasing the updates of the routers' IP helper / DHCP relay statements.

I'd expected others might have other use cases; but from the lack of prior conversation about this, apparently not.

-- 
Keith Neufeld
Director of Networking and Telecommunications
Wichita State University