slow dhcp on 1G backbone.

Blake Hudson blake at ispn.net
Fri Jul 24 20:51:40 UTC 2009


-------- Original Message  --------
Subject: Re: slow dhcp on 1G backbone.
From: Dean Montgomery <dmonty at sd73.bc.ca>
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Date: Friday, July 24, 2009 3:23:15 PM
>> Where are these 12 second delays in your capture/syslog? Are the
>> clients  sending requests that are not seen by the server?
>>     
>
> This could be the case - dhcp traffic is not traveling over the LAN in a timely manner.  and/or dhcp traffic is being lost by the Procurve switches.
>
> Just before bios pxeboot & kernel's dhcprequest, the link-light turns off then on again.  It may be the switch is slow trying to re-negotiate link speed with the client.
>
>   
This is very likely the problem. Some network cards/drivers reset the 
link at different stages of bootup and this resets the link. In these 
cases it is crucial that the port initializes and is able to pass 
traffic prior to DHCP requests to prevent lost packets. Does your PXE 
boot show that requests are being made and timing out, or is it not that 
verbose?

Running standard spanning tree, most ports take 30-45 seconds to come 
up, portfast reduces this to ~ 10-15 seconds in my experience. Again 
there are other things besides spanning tree that could be delaying the 
time a port is ready to pass data (such as VLAN, trunking, or 
aggregation negotiation protocols).

Can you try putting a hub or linksys switch (whose ports come up 
basically instantly) between the PC and your HP switch to see if that 
speeds up the DHCP process?

> ==
> I tried changing the switch configured speed on port16 from "Auto" to "100Fd".  This made the client on port16 continually loose it's link.
>   
as mentioned previously, both ends need to be set to auto or manual - 
mixing will usually cause problems (duplex/speed mismatches)
> ==
> * All switches have the latest firmware.
>
> * All switches have factory default settings (except we turn on spanning tree).  We tested spanning tree off earlier and it is not the cause.
>
> ==
> NOTE: This slow dhcp has been an "ignored issue" for 4 years in many schools.  I now have a bit of free time to see if it can be resolved.
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090724/f62aa136/attachment.html>


More information about the dhcp-users mailing list