Windows ignoring DHCPOFFER is broadcast
jsavage at yorku.ca
Thu Mar 27 19:09:48 UTC 2008
David!.........removing the ip broadcast-address did the trick!!!!
My traffic captures showed the packets being broadcast to 22.214.171.124 but
when that statement is removed the packets are now broadcast to
Putting this statement on all router interfaces is something we've done
all along so I included it as usual. It's a statement we viewed as
important a long time ago but we can probably live without it now.
........thanks so much, I've been messing around with this for
James Savage York University
Senior Communications Tech. 108 Steacie Building
jsavage at yorku.ca 4700 Keele Street
ph: 416-736-2100 ext. 22605 Toronto, Ontario
fax: 416-736-5701 M3J 1P3, CANADA
"David W. Hankins" <David_Hankins at isc.org>
Sent by: dhcp-users-bounce at isc.org
03/27/2008 02:35 PM
Please respond to
dhcp-users at isc.org
dhcp-users at isc.org
Re: Windows ignoring DHCPOFFER is broadcast
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
> 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,
> 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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users