DHCP relay IP and gateway IP, possible bad logic?
aland at deployingradius.com
Mon Mar 4 23:34:56 CET 2013
Phil Mayers wrote:
> Perhaps I've misunderstood, but this doesn't reflect the DHCP behaviour
> I've seen on "normal" clients.
> As far as I know, it goes (starting from INIT, as opposed to INIT-REBOOT
> which effectively starts from step 4):
> 1. Client sends DISCOVER to broadcast
> 2. NAS forwards to server; giaddr==1, srcip==2
> 3. Server sends DHCPOFFER; dstip==giaddr, server_id=$SERVER
> 4. Repeat 1-3 with DHCPREQUEST/ACK
> 5. Client comes to t1 - unicast DHCPREQUEST dstip=$SERVER
> 6. If no reply, at t2 - broadcast DHCPREQUEST
> i.e. AFAIK, the client *always* sends packets to broadcast or to the
> server ident (DHCP option 54). Note the latter is mandatory in all DHCP
That's the usual practice... but some clients may be weird.
> There are a bunch of subtleties in this whole area - some devices offer
> knobs to control giaddr in the case of multinettings, and some devices
> offer knobs to control srcip - but, in my experience, you are asking for
> trouble if giaddr is not valid for accepting relayed replies. We've had
> significant problems with setups where this is difficult or impossible
> to achieve as a result. Multinetting a private and public range onto the
> same interface falls into exactly that category.
Maybe I got parts of the explanation wrong, but the DHCP handling of
giaddr is just weird.
More information about the Freeradius-Users