Slow DHCP with dynamic vlans

[Kipling]

Hi all,

I’m looking for some help with a slow DHCP problem.

We’re using mac-based authentication, procurve switches and IAS. 30 vlans dynamically allocated, the 30 subnets managed by server 2008 DHCP.
Everything works fine except DHCP is slow, not hideously slow, but can be 10 to 30 seconds or so. This was never a real problem and got put on the back burner; but we’re now running a few thin clients which ask for an address twice during boot (one for pxe, one for the thinclient os) and so its time to pin it down.


In a nut shell,
If a machine is put in a vlan dynamically then DCHP is slow.
If the same machine is forced (port untagged) into a vlan then DHCP works as it should.
IAS validates the machines immediately so the delay isn’t there (dhcp is slow even if I randomly /release /renew after a while).
There’s nothing obvious shouting out of the DHCP logs – though I haven’t been through them with a fine tooth comb.

I’ve had a Google around and nothing stands out.
DMcCoy, I think we have a similar setup to you; did you experience anything like this?
Anyone got any ideas?


Edit: just found a slightly later firmware for the 2626’s (the changes log doesn’t mention fixing a dhcp problem but you never know…), I'll try that on monday...

[DMcCoy]

Hi all,

I’m looking for some help with a slow DHCP problem.

We’re using mac-based authentication, procurve switches and IAS. 30 vlans dynamically allocated, the 30 subnets managed by server 2008 DHCP.
Everything works fine except DHCP is slow, not hideously slow, but can be 10 to 30 seconds or so. This was never a real problem and got put on the back burner; but we’re now running a few thin clients which ask for an address twice during boot (one for pxe, one for the thinclient os) and so its time to pin it down.

Is the DHCP server for authenticated and unauthenticated vlans 2008 DHCP? I had issues with getting NACKs back from the windows server when the client requests the same address on the wrong vlan. My unauthenticated vlan is running a non MS DHCP server (only dhcp part, not dns) (SourceForge.net: Dual DHCP DNS Server). This stops the nack issue and clients get an address much faster.

This has happend with my 802.1x vlans, although it's the same issue with MAC auth due to the vlan change - I just happend to only have non windows clients using MAC auth which are not affected and behave in a sensible manner unlike windows.

[Kipling]

Thanks, Yeah the DHCP for all vlans is server 2008, although we had the same problem last year before we upgraded to 2008 (it was a 2003 dhcp back then).

Is the DHCP server for authenticated and unauthenticated vlans 2008 DHCP? I had issues with getting NACKs back from the windows server when the client requests the same address on the wrong vlan.

Not sure I follow that; the vlan is set by the IAS before the DHCP discover is broadcast by the client so it shouldn’t ever change. You think it might be changing, causing the dhcp to send a nak and causing the client to start the whole dhcp discover again?

[DMcCoy]

Thanks, Yeah the DHCP for all vlans is server 2008, although we had the same problem last year before we upgraded to 2008 (it was a 2003 dhcp back then).



Not sure I follow that; the vlan is set by the IAS before the DHCP discover is broadcast by the client so it shouldn’t ever change. You think it might be changing, causing the dhcp to send a nak and causing the client to start the whole dhcp discover again?

You may find that windows is dropping the link when the driver starts, see if the event log for the switch stays on the correct vlan during boot. Do you have spanning tree turned on? If you do make sure the ports for machine are set to edge. Are there any dhcp errors in the event log on the affected machines?