<br><font size=2 face="sans-serif">David!.........removing the ip broadcast-address
did the trick!!!! </font>
<br>
<br><font size=2 face="sans-serif">My traffic captures showed the packets
being broadcast to 1.2.3.255 but when that statement is removed the packets
are now broadcast to 255.255.255.255.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">........thanks so much, I've been messing
around with this for some........................Jamie</font>
<br>
<br>
<br><font size=2 face="sans-serif">James Savage
York University <br>
Senior Communications Tech. 108 Steacie Building<br>
jsavage@yorku.ca
4700 Keele Street<br>
ph: 416-736-2100 ext. 22605 Toronto,
Ontario<br>
fax: 416-736-5701
M3J 1P3, CANADA
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"David W. Hankins"
<David_Hankins@isc.org></b> </font>
<br><font size=1 face="sans-serif">Sent by: dhcp-users-bounce@isc.org</font>
<p><font size=1 face="sans-serif">03/27/2008 02:35 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
dhcp-users@isc.org</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">dhcp-users@isc.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: Windows ignoring DHCPOFFER is broadcast</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>On Thu, Mar 27, 2008 at 02:17:32PM -0400, Jamie Savage
wrote:<br>
> I have a situation where I have setup a subnet with DCHP
<br>
> relay...ie....A Cisco router in this case with the subnet interface
<br>
> config'd with the IP-helper command pointing to a DHCP server on another
<br>
> subnet. I fire up my XP-SP2 laptop which starts looking for
an IP <br>
> address. The 'remote' DHCP server sees the DHCPdiscover come
in and sends <br>
> out a DHCPoffer which is broadcast out to the originating subnet.
My <br>
> XP-SP2 machine sees the broadcast (which carries the laptops MAC address
<br>
> buried in the Bootstrap Protocol portion of the frame) but ignores
<br>
> it...ie...it does not send a DHCPrequest back. However, when
I plug a <br>
<br>
first thing to check; do you have 'ip broadcast-address' configured<br>
on the first Cisco with the ip-helper set up?<br>
<br>
Windows boxes, when they receive broadcasts, are very conservative in<br>
what they receive; it MUST be sent to 255.255.255.255 as dictated in<br>
rfc2131, and cisco relays in this configuration will use the<br>
configured broadcast address instead.<br>
<br>
> with their MAC in the Bootstrap Protocol should respond. Should
<br>
> DHCPoffers be unicast or broadcast or both?? Can someone point me
in a <br>
> direction to start looking?....I'm not sure if this is a Windows issue,
a <br>
> DHCP server issue or some networking issue. <br>
<br>
DHCP is a funny protocol. clients have to be able to talk and get<br>
replies using IP without having an IP address. servers have to be<br>
able to send replies to the client when it might not be ARPing for<br>
the address they want to unicast to yet (unicast offers go to the<br>
IP destination of the offered address, with the ethernet mac<br>
destination of the client).<br>
<br>
the easy rules of thumb;<br>
<br>
- if the client set the broadcast bit, replies are broadcast. this<br>
bit is an advertisement that the client cannot receive unciasts
when<br>
it is not yet configured with an ip address.<br>
<br>
- if the server or relay can not support unicasting a specific ip<br>
address and mac address pair without arping, then the server
or relay<br>
may still elect to broadcast even if the bit is cleared.<br>
<br>
- if an administrator has over-ridden any of the above (for example<br>
in ISC DHCP with the always-broadcast config option), then
obviously<br>
these replies are always broadcast. these are generally
used as<br>
workarounds to the above (clients that do not set the broadcast
bit,<br>
but do rely upon broadcasts, relays or servers that think
they can<br>
unicast without arping - but are wrong for some reason).<br>
<br>
in the future, i expect we are going to have to create an<br>
always-unicast flag, as we have discovered that windows Vista does<br>
set the broadcast bit (which is strange since XP doesn't), but does<br>
not require a broadcast response.<br>
<br>
-- <br>
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.<br>
Why settle for the lesser evil?
https://secure.isc.org/store/t-shirt/<br>
-- <br>
David W. Hankins
"If you don't do it right the first time,<br>
Software Engineer
you'll just have to do it again."<br>
Internet Systems Consortium, Inc.
-- Jack T. Hankins<br>
<br>
</font></tt>
<br>