DHCP relay with two interfaces
David W. Hankins
David_Hankins at isc.org
Tue Apr 24 16:04:24 UTC 2007
On Tue, Apr 24, 2007 at 02:53:14PM +0300, Bjorn Andersson wrote:
> Is there a way to configure the server to function as I want?
> The simple relay is written by my self and I can easily
> modify its behaviour if needed.
If you use the server in ISC DHCP 3.1.0, then you can set giaddr to
the routable address, and supply a Relay Agent Information Option
Link Selection Sub-Option (RFC3527).
But if it were me, I'd also use unique networks, and ensure that
the DHCP server could route directly to the clients unhindered.
It's just simpler that way.
If you don't, then the clients will be unable to renew their
leases, as renewals are unicast directly between client and
One workaround for that presently seeking an IETF RFC
(draft-ietf-dhc-server-override-04) is to set the
dhcp-server-identifier to the relay agent's client-facing
address, so clients send their renewals to the relay to forward.
Most people would have to be careful about doing that - because
this makes every renew look like a rebind, even though it isn't.
It isn't appropriate for a DHCP server to perform "point of
attachment" calculation during renew like it is for init-reboot,
binding, or rebind...since the packet is unicast, it could arrive
at the server (or in this case relay) by any valid route. So,
"source interface" such as the server can do natively, or the
relay does in proxy by setting giaddr or link-selection, are of
questionable accuracy during renew.
In your case since the relay agent isn't reachable on the
private address unless it is got via the nat's private side, and
there is only one subnet there, it shouldn't be an issue.
But if you had more than one subnet in the private end, and for
example it were therefore possible that a host with two interfaces
might straddle both (and only install one default route) then you'd
have a problem. For example.
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
More information about the dhcp-users