LAN interface and DHCP issues, phone it taking the LAN IP.

canadianllama

@johnpoz yeah we had issues with all the unifi equipment adopting, even new stuff added after the subnet changed to /23. Did this at 2 locations both have pfsense routers. So we just set up static ips on all the equipment through DHCP reservation on the router, no more adoption issues.
I agree it should work without the static ips as it's all on the same network, but something with the /23 subnet they didn't seem to like.

canadianllama

@SteveITS I didnt know about pools. That's cool. If we can't fix it properly then we may just try that.

johnpoz

@canadianllama said in LAN interface and DHCP issues, phone it taking the LAN IP.:

but something with the /23 subnet they didn't seem to like.

But they are on a /23 now - you just reserved a specific IP for them... I have no idea what is actually going on.. But /23 is not the problem - and if you set a reservation for them - they are still on a /23..

How are you doing your inform? Via dhcp option, pointing to some old IP? Is your controller not discoverable at L2?

The mask of the network your on has zero to do with it, be it a /24 a /23 a /22 or a /25 or 16 etc.. You might have some issues during transition period when some are on mask A and others are on mask B, etc. or if you had dns or IP pointing to something and that is now wrong if that something IP changed, etc.. But the mask/size of the numbers of the IPs possible on the network has zero to do with it.

canadianllama

@johnpoz We are using the DHCP server on pfsense, we changed the LAN to /23, deleted all DHCP and ARP reservations, and they still wouldn't adopt. So yeah, we just did the static IP's. It's totally possible I did something wrong but can't figure out what it is. Anyways, we are going on-site this evening and will work on it till we get it fixed.

Thank you for all your replies.

johnpoz

@canadianllama static IPs are still in the same network, ie a /23 doesn't matter if they got it from dhcp or not.

You have something going on with how the devices find the controller, the inform is what tells devices which to controller to talk to.. This can be handed out via a dhcp option, it can be a dns record. Or the controller can be found via L2 discovery. None of which matters what size network your unifi devices are on.

Maybe you manually set the inform on the AP to your controllers IP, and now that IP changed so yeah you could have a bad day. Maybe you blew away a dhcp option that was set, believe option 43 or 60 can be used.

But typically the controller when on the same network as devices you want to manage, AP or Switches, etc. this is just done via L2 discovery.

There is also DNS - which would normally be used via L3 adoption, ie controller and devices are on different networks.

Like I said, not exactly sure what issue your running into - but it has zero to do with what size network your using /24 or /23, etc. Or be it the IP of the controller or devices are gotten via dhcp or manually set on them.

Out of the box http://unifi:8080/inform is the default inform that devices send to, but for that to work it L2 has to work, ie that name unifi needs to be resolvable to the IP of the controller. If you do not have that enabled on your controller, either enable it or use one of the other methods.

SteveITS

@johnpoz Or maybe some device involved still has a /24 mask? We expanded a network once a while back and had a few straggling printers and other things that needed updating. It helped in our specific case that we left all the static stuff on the original /24 and moved DHCP to the added-on bits.

johnpoz

@SteveITS exactly - and I agree mismatched masks can cause you all sorts problems. I have mentioned that a few times now ;)

canadianllama

@johnpoz Well I just looked and this is NOT check marked, so I'll turn that on and maybe that will fix the issue as well. Funny thing is, it all worked and discovered fine until the /23 change so I assumed that was the issue.

canadianllama

@SteveITS Yeah we found some printers didn't work right after the expansion as well. SO maybe they were holding onto the wrong subnet. We even went as far as to put some computers on static IPs to get the printers to work. I assumed if we deleted the DHCP Leases and rebooted the machines, they would be fine. But we had a lot of static IPs so maybe some of those hung onto the old settings. I've expanded 2 networks this year, but never before in my 20+ years of IT have I ever done that. But it's going to happen more and more I think with all the devices we have nowadays.

johnpoz

@canadianllama printers are many times set on the device, so yeah everyone one of those would have to be touched. Your need to change the mask is why you shouldn't set stuff static on the device ;) Just set a reservation for something that needs a specific IP. Then edit the reservation.

We ran into a printer issue one time that had nothing to do with the mask on the network - the customer had set printers as static - but never set a gateway. Had been relying on proxy arp that there old 6509 default to having on. When we were changing that to a nexus setup - proxy arp was no longer on by default. As temp fix we turned it on - but told them they needed to set gateways on printers.. And also to change the mask - they had been using a /16 for their printer segment <rolleyes>, They had at most maybe a 100 printers in the building..

canadianllama

@johnpoz We do prefer doing static IPs on the router and mostly do it that way. We aren't full-time tech,s so sometimes the client does whatever they want as well.

canadianllama

@johnpoz We spent 6 hours trying to get this to work 2 nights ago. Anytime we changed the LAN Interface IP to 10.0.14.1, all our UNIFI equipment went to 192.168.1.20 IP range, and stopped working. rebooting, resetting and re-adding them to the cloud key, clearing DHCP reservations. I tried pretty much everything I could think of. We even tried giving the LAN Interface 10.0.15.254 IP to keep it in the old range, but that didn't work either.

It's possible something in the cloud key isn't getting updated... I'm not sure how that works with the network gear getting the IP from the router, but then talking to the controller.

Anyways, we are going to set up a test environment and work more on it.

Thanks for all your guys insights.

SteveITS

@canadianllama Do you mean DHCP reservations? Yeah we started doing that at some point, after a Windows 10 feature update helpfully removed static IPs by creating a new NIC. That was annoying.

johnpoz

@canadianllama is your unifi gear set to static now? Or just dhcp, or a reservation? I believe the cloudkey default fall back IP is 192.168.1.30 - did you mean that vs .20?

https://dl.ubnt.com/qsg/UC-CK/UC-CK_EN.html

Note: The default fallback IP address of the UniFi Cloud Key is 192.168.1.30.

Why don't you just set your laptop to a 192.168.1.x IP and connect to it and change it to a static IP that you want to use on your new 192.168.14/23 network

canadianllama

@johnpoz Yes we have them as static DHCP reservation on the router. But I removed them from that when we tried to fix this issue.
All the devices (WAPs and network switches) went to the IP of 192.168.1.20... every single one of them. (We could see that on the cloud key, so we still had cloud key access somehow, but basically the entire network went down and just stopped working). We can try set the cloudkey IP static on the device, ill look into doing that.

Im assuming the unifi devices talk to the router first to get their IP's, then talk to the cloudkey for other stuff, as you can run the equipment without the cloudkey.

We are setting up a test lab today so hopefully can figure it out.