dhcpd and relayed responses from multi-interface Linux server

[Neufeld, Keith]

Does anyone have dhcpd (server, not client) successfully running on a Linux server built in the last few years (recent enough to use LPF, which you can see in the log file at server start) in an environment with relayed clients?

I'm surprised if this hasn't been covered before, but my search-fu isn't good enough to find it in the list archives.


We're prepping a pair of new ISC DHCP servers on RHEL 8.  We originally tried RH's bundled DHCP 4.1.5 and have since updated to 4.4.2, with the same results (described below)

The DHCP servers have two interfaces (I'm renaming them from their autogenerated names for conversational simplicity), 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 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*.

Since our servers are set up with the default route out eth0, eth0's IP gets used as the source IP on the relay responses (OFFERs).  It appears that the relay agent in our LAN routers keeps a state table and checks the source IP of relay responses.  Since the OFFER is coming from a different IP (10.1.61.16) than the DISCOVER was relayed to (10.1.69.16), the router doesn't relay the response back to the client and the client never completes the conversation to get a lease.

When we temporarily change the server host's default route to eth1, the client gets the relayed responses, continues the conversation (broadcast/relay REQUEST/ACK), and gets its lease as it normally would.


It seems to me that our scenario -- a multi-interface server running LPF plus fallback socket and needing to handle relayed communication -- is bound to fail under the current code.  (Therefore not many people must be doing it. :-) )

It seems to me that fixing it would require building an array of UDP INET sockets (for the sake of conversation, call it the fallback array, though maybe conceptually it's no longer fallback), one on each interface on which dhcpd is listening; and matching unicast transmissions, at least *relayed* ones, to send out the interface on which they were received in order to ensure that their source IP is correct.

It's been way too long since I studied sockets for me to remember whether it's possible that dhcpd could instead write the desired source IP into the response packet and it would be preserved by the server host even when sending it out a different interface.  If this would work, it would be a much less invasive code change.


Has this come up on the list before?  Anyone else run across it?  Am I overlooking a simple workaround (other than changing our server routing or running dhcpd in a single-interface virtual jail)?

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