Windows ignoring DHCPOFFER is broadcast
David W. Hankins
David_Hankins at isc.org
Thu Mar 27 18:34:58 UTC 2008
On Thu, Mar 27, 2008 at 02:17:32PM -0400, Jamie Savage wrote:
> I have a situation where I have setup a subnet with DCHP
> relay...ie....A Cisco router in this case with the subnet interface
> config'd with the IP-helper command pointing to a DHCP server on another
> subnet. I fire up my XP-SP2 laptop which starts looking for an IP
> address. The 'remote' DHCP server sees the DHCPdiscover come in and sends
> out a DHCPoffer which is broadcast out to the originating subnet. My
> XP-SP2 machine sees the broadcast (which carries the laptops MAC address
> buried in the Bootstrap Protocol portion of the frame) but ignores
> it...ie...it does not send a DHCPrequest back. However, when I plug a
first thing to check; do you have 'ip broadcast-address' configured
on the first Cisco with the ip-helper set up?
Windows boxes, when they receive broadcasts, are very conservative in
what they receive; it MUST be sent to 255.255.255.255 as dictated in
rfc2131, and cisco relays in this configuration will use the
configured broadcast address instead.
> with their MAC in the Bootstrap Protocol should respond. Should
> DHCPoffers be unicast or broadcast or both?? Can someone point me in a
> direction to start looking?....I'm not sure if this is a Windows issue, a
> DHCP server issue or some networking issue.
DHCP is a funny protocol. clients have to be able to talk and get
replies using IP without having an IP address. servers have to be
able to send replies to the client when it might not be ARPing for
the address they want to unicast to yet (unicast offers go to the
IP destination of the offered address, with the ethernet mac
destination of the client).
the easy rules of thumb;
- if the client set the broadcast bit, replies are broadcast. this
bit is an advertisement that the client cannot receive unciasts when
it is not yet configured with an ip address.
- if the server or relay can not support unicasting a specific ip
address and mac address pair without arping, then the server or relay
may still elect to broadcast even if the bit is cleared.
- if an administrator has over-ridden any of the above (for example
in ISC DHCP with the always-broadcast config option), then obviously
these replies are always broadcast. these are generally used as
workarounds to the above (clients that do not set the broadcast bit,
but do rely upon broadcasts, relays or servers that think they can
unicast without arping - but are wrong for some reason).
in the future, i expect we are going to have to create an
always-unicast flag, as we have discovered that windows Vista does
set the broadcast bit (which is strange since XP doesn't), but does
not require a broadcast response.
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
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