DHCP server on a different subnet

[Glenn Satchell]

On 05/11/11 18:03, Alex Bligh wrote:
> Is it legal (i.e. conformant with the RFCs) for a DHCP server to send back
> a DHCPOFFER / DHCPACK with a server identifier option, an IP source
> address,
> and field si_addr (in short hand "the server IP address") all set to the
> same value, but not on the same subnet as yiaddr (i.e. the offered DHCP
> address), PROVIDED THAT a routers options is specified such that the
> server is reachable via the router, and PROVIDED THAT it is reachable
> at L2? (so to be clear, there is more than one subnet on the same
> broadcast domain, so a 255.255.255.255 broadcast will still reach
> the server).
>
> As far as I can tell, this is (a) neither prohibited nor specifically
> allowed in the RFCs, and (b) is no worse than a response from a dhcp relay
> where si_addr and the server identifier may not be immediately reachable
> (and it is si_addr rather than the others that are meant to be used).
> The RFCs merely require si_addr to be reachable (which it is). This assumes
> that when the server adds its IP address, it also adds its routers (as
> opposed to setting the IP and netmask, then choosing to send a unicast
> DHCPACK, and only after that setting its default gateway, which would
> be pretty bizarre behaviour and which I think would break relay
> configs)
>
> What I am trying to do here is provide DHCP to a pile of /29s, and having
> already "wasted" one for a gateway, network and broadcast, I don't want
> to "waste" another for DHCP, and can't share the same IP as the router
> for technical reasons.
>
> Anyone know if I am likely to run into trouble here?
>
Sounds like it should work just fine. This is standard behaviour for 
remote subnets, for example. You can't always configure the dhcp server 
to have an interface on every subnet it serves.

-- 
regards,
-glenn