DHCP server on a different subnet
alex at alex.org.uk
Thu May 12 07:04:44 UTC 2011
--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
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.
More information about the dhcp-users