DHCP server on a different subnet

[Alex Bligh]

--On 11 May 2011 20:50:21 -0500 Lyle Giese <lyle at lcrcomputer.net> wrote:

>>> 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.
>>
>> Thanks. I am familiar with remote subnets but they tend to use a proxy.
>> I am not using a proxy but relying on having an interface on the same
>> broadcast domain but not the same subnet. I can't see how a reasonable
>> client could differentiate this from a proxy, but as we all know not
>> all clients do reasonable things!
>>
> That is the purpose of the proxy.

I know that. I'm not using a proxy though.

> To be on the same network and when
> relaying the DHCP request identify to the DHCP server what subnet it came
> from.

When the client boots, it is on a network (i.e. a L2 broadcast domain)
but not a subnet (as it doesn't yet have an IP address). So all it
can do is identify the network.

> DHCP relay is normally handled by the router(default gateway)

Indeed, which I can't do here.

> But if an interface is on the same broadcast domain, but on a different
> subnet, how will that interface determine what subnet the broadcast
> packet came from?  I don't think it can.

In any configuration, when a DHCP DISCOVER comes in, it doesn't come
"from a subnet". It comes from a network. It's the server that determines
which subnet to use, normally using the hardware address (i.e. MAC
address) or client identifier, and the configuration file. What I am
asking is: is it possible for a server to return a yiaddr which is
reachable if options are processed, on the same network, but not on
the same subnet.

-- 
Alex Bligh