XP clients sometimes ignore DHCPOFFERs
coreyg at iowatelecom.com
Tue Mar 21 17:34:58 UTC 2006
I've taken a different approach to this issue with win32 dhcp clients.
All of our clients get addresses that are forwarded by cisco
dhcp-helper. I set the dhcp-server option to the ip address of the
client machine's gateway, which seems to universally solve problems with
Windows machines ignoring offers for a lease (windows firewalls present
a different problem). I'm not sure why at the moment, but setting the
broadcast address of your routers to 255.255.255.255 seems like a bad idea.
John Wobus wrote:
> Hi Tom,
> I'm cc'ing this to the DHCP list in case others could use the info.
> I posted some of this before, but when I was hunting for
> solutions online, I came up with very little, it it would be
> very good to have a bit about this in the mailing list archive.
> We made the change (xx.xx.xx.255 broadcast addresses
> to 255.255.255.255 broadcast addresses in the routers)
> a few months ago and it appears to have fixed the problem
> of Windows clients sometimes ignoring DHCPOFFERS.
> We made the change campus-wide, the change forced very little other
> reconfiguration: throughout the campus, with tens of
> thousands of devices, I heard about just one department
> that had to reconfigure just one device that listened
> to our routers' RIP broadcast of the default route,
> and needed a configuration change to match.
> I was loaned a laptop that exhibited the DHCP problem,
> thus I had the chance to watch instances of the failure,
> try things, do various status commands, capture packets,
> etc., and discover what was going on. When we
> reconfigured the broadcast address on one subnet, the
> laptop no longer had problems on that subnet.
> Then we announced the change to technical staff
> across campus and rolled the change out campus wide, but
> unfortunately, I receive limited feedback from the campus
> at large. In general, if someone has problems, it might be
> reported; if things go right, we're likely to hear nothing.
> If we were truly successful eliminating a problem,
> we will receive fewer problem reports about our DHCP
> service in the future than we would have without
> this change. I asked a few folks who had reported
> past problems, but received no definitive feedback regarding
> whether the specific problems had gone away.
> Someone on staff here recalled that specific past versions of
> Windows clients had this particular issue and that
> current versions do not. I did not experiment with
> a variety of versions: only one, which I don't recall,
> but I'm pretty sure it was not current. Naturally, given the
> solution was so painless that we were going to do it
> in any case, spending effort getting the exact list
> of clients to be "helped" was of less use.
> The failure was non-deterministic: it looked to me like
> Windows' DHCP handling raced with its APIPA handling,
> and if APIPA won, Windows had an address & mask that
> would not accept the router's broadcast address. The
> laptop I borrowed had a tendency to fail but occasionally succeeded.
> I can easily believe that the exact timing that determines
> whether the failure occurs in any particular instance could
> depend upon processor speed, other startup software installed, etc.
> I could also easily believe that various Windows versions
> have the problem to varying degrees. However this
> is my own speculation.
> P.S. There are excellent explanations of Windows' APIPA
> feature that Googling "APIPA" will turn up.
> On Mar 21, 2006, at 9:36 AM, Tom Greaser wrote:
>>your quite today.. ive been following this thread.. just wanted to
>>know if the bcast fixed your problem.. Im having what seems to be
>>the same kinda problem..
Corey Gillespie Desk: 641-269-7599
Systems Engineer Cell: 641-990-5217
Iowa Telecom coreyg at iowatelecom.com
More information about the dhcp-users