Chromebooks DHCP Lookup failure

[TMBS]

Hi

 

We have 200 Chromebooks on site and have recently been having DHCP lookup failures on them. Sometimes just the odd one, or two but other time the whole class so it can be quite disruptive for the teacher.

 

They're setup via a static IP to allow through our firewall and filtering set up via Netsweeper.

 

We use Unifi wireless APs.

 

Any ideas what could be causing the issue?

 

Thanks

[SchoolsBroadband]

have you run out of unallocated IP's from the DHCP pool? i.e. there's no more to give? you might want to look at your dhcp timeout settings and reduce accordingly or make the pool size bigger.

[PotNoodleTech]

Very unusual to set up chromebooks with static IPs. Most people would use DHCP for that?

[Opendium_Steve]

Check there isn't a rogue DHCP server on the network. If there is it could be responding to clients with refusals before the legitimate DHCP server replies.

[bald_pig]

have you run out of unallocated IP's from the DHCP pool? i.e. there's no more to give? you might want to look at your dhcp timeout settings and reduce accordingly or make the pool size bigger.

 

Check there isn't a rogue DHCP server on the network. If there is it could be responding to clients with refusals before the legitimate DHCP server replies.

If they are set up with static IPs as OP states then they shouldn't be trying to contact a DHCP server.

[Opendium_Steve]

If they are set up with static IPs as OP states then they shouldn't be trying to contact a DHCP server.

I think the OP means that they each have a reserved IP address set up on the DHCP server, and holes poked in the firewall for those IP addresses.

[TMBS]

have you run out of unallocated IP's from the DHCP pool? i.e. there's no more to give? you might want to look at your dhcp timeout settings and reduce accordingly or make the pool size bigger.

I'd checked the DHCP and we still have plenty of IPs. Will check timeout settings.

 

Thanks!

 

- - - Updated - - -

 

Check there isn't a rogue DHCP server on the network. If there is it could be responding to clients with refusals before the legitimate DHCP server replies.

How do I check for a rogue DHCP server?

 

Thanks

[Opendium_Steve]

How do I check for a rogue DHCP server?

 

Slightly technical, but: Run Wireshark (or similar) on a workstation that is sending DHCP requests and watch to see if you get several DHCP replies coming back with different source MAC addresses. Note that you need to run wireshark on the machine that's making the DHCP requests, not a random other machine on the network - the replies are not broadcasts, so you can't guarantee that another machine will receive them.

 

(I'm sure there's got to be an easier way, but can't think of one off the top of my head - there may be some tools out there to do all this for you of course

 

Other things to try:

- Run Wireshark on the DHCP server itself and look to see if the DHCP requests are even getting to the server.

- Check the spanning tree status on your switches - I've seen weirdo problems involving misconfigured wifi accesspoint meshing before which can cause spanning tree to disable ports, leading to intermittent and hard to diagnose network problems (this wouldn't _just_ affect DHCP though, but it may be the most obvious symptom).

[MatrixNate]

OP, You might also check the Firmware Revision for your Unifi AP's. The new 4.42 firmware is stable for the USG's and Switches, but it's a hot mess for WiFi with LOTS of complaints of slow speeds and/or DHCP latency. If you've already upgraded to 4.42, then I'd start by flashing back to 4.21 as it's stable. The other advice that's been common lately is to go in to the Site configuration on your controller and disable the "Site Optimization". Hope this helps!

[Mr.Ben]

OP, You might also check the Firmware Revision for your Unifi AP's. The new 4.42 firmware is stable for the USG's and Switches, but it's a hot mess for WiFi with LOTS of complaints of slow speeds and/or DHCP latency. If you've already upgraded to 4.42, then I'd start by flashing back to 4.21 as it's stable. The other advice that's been common lately is to go in to the Site configuration on your controller and disable the "Site Optimization". Hope this helps!

I agree here, the 4.0.42 update has been awful, breaking captive portal as well as a host of other things