DHCP relay with two interfaces
bjorn at iki.fi
Tue Apr 24 18:38:47 UTC 2007
On 4/24/07, David W. Hankins <David_Hankins at isc.org> wrote:
> On Tue, Apr 24, 2007 at 02:53:14PM +0300, Bjorn Andersson wrote:
> 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).
Ok, thanks for the pointer, I will have a look at this. This sounds
what I am looking for.
> 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.
I wasn't aware of the draft, but his actually just what I was doing
with my relay.
> Most people would have to be careful about doing that - because
> this makes every renew look like a rebind, even though it isn't.
Ok, I have to figure out the implications of this then.
> 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.
This will not be problem in my case.
More information about the dhcp-users