dhcpd and relayed responses from multi-interface Linux server

Simon Hobson dhcp1 at thehobsons.co.uk
Thu Jun 4 15:23:56 UTC 2020


Neufeld, Keith <Keith.Neufeld at wichita.edu> 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?

In this case I think there is an argument that you are building the network wrong. I read that you have devices that are connected to the network on eth0 but are being services via relay agents forwarding requests via the network on eth1. In your original message you wrote :
> 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 so I assumed we were talking about clients in the eth0 network.

For these, relaying requests that could be handled directly could be considered "building the network wrong".


> 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.

Ah, now I understand !

I think the simple answer is that it should not matter what source address is used - only the destination address which routes the packet back to the relay agent. In terms of protocol spec, that is the case - there's an implicit assumption that regardless of the source address, the routing will get it to where it needs to be.
Your problem is that your relay agents impose restrictions which are outside of the spec - and yes, I understand your problem now. It's neither the multi-homing nor the relay security that's causing the problem - but the combination of both of them. I suspect there will be many setups with one or the other in place - but few with both, and hence the problem you see.

The only solution I can think of is as I described in my earlier post - use the output mangle table to alter the source address. In a "stable" setup I think it should be as simple as "protocol=UDP and source port=67" -> "set source address to 10.1.69.16". As long as the server only has one address it uses for DHCP service then that ought to work.

Now, for your potential migration setup I think it gets a bit more complicated. You might need to expand that logic along the lines of :
"protocol=UDP and source port=67 and dest IP in 10.0.0.0/8" -> "set source address to 10.1.69.16"
"protocol=UDP and source port=67 and dest IP in 172.16.0.0/12" -> "set source address to 172.17.69.16"

Is that any help ?



There is one thing that also comes to mind. AIUI the ISC DHCP server is more or less out of active development, with Kia having taken over as the actively developed ISC DCHP server going forwards. TBH I think it's done marvellous duty seeing as it was originally intended as a reference implementation of the RFC.
I've not kept up with how Kia is doing - last I read it was ahead on some features and behind on others. It might be worth looking into whether Kia operates the same or differently in this respect, and if it has the same issue, whether ISC might take on the problem as a feature request (though their policy is AIUI, "you want it, you sponsor it"). If you have some bright CS people in the Uni, could it become part of a project for a small group of them ?

Just tossing ideas out there in case any of them are suitable for your situation.



More information about the dhcp-users mailing list