“I am ranting, because I don’t understand VLAN and because of that think that I am the only person in the whole wide world and thousands of customers, but I am the poor special snowflake, where not only one, but ALL devices lose their settings after a power loss!”
If that is what you want instead of finding out what you messed up with VLANs, that it totally fine be me. Have fun, I am out.
@ThisMightBeAFish - stating “That is not how it works. You’re wrong. I’m singling you out as the one affected person.” has ALWAYS worked in trying to provide constructing feedback. Or are we just looking at trying to assert that someone else doesn’t know anything?
There are so many ways to articulate a point and you chose violence.
I legitimate wanted to learn about this because I run Unifi in my infra… but now I don’t care anymore. Cheers.
My educated guess here would be that although the APs boot up with their config and should still work when they cant connect to the controller, because you have multiple APs that all booted up and couldnt connect to a DHCP server they all went to their firmware coded fallback IP. Then you ended up with a bunch of devices all saying they were the same IP, which caused a bunch of other issues on the network. I dont remember if UniFi detects the fallback IP already in use or not, either way it seems like in this instance they all wanted to stay as 192.168.1.20.
A simple reboot of the APs after the rest of the equipment was booted up probably would have fixed everything. If your switches dont have the ability to do a power cycle of a poe port, then just unplug the cable from the switch port to kill power and plug them back in.
This is one reason I dont like network hardware to be all set to be DHCP addresses. I know there are pros and cons to every method of getting addresses to network hardware, and many people dont like assigning static IPs because of the drawbacks associated with them when changing network configurations around. But in the case of UniFi since they only support DHCP and static, no DHCP Reservation for their network hardware (only end devices can be set that way), I prefer static over plain DHCP. It prevents issues like some hardware booting before the DHCP Server has booted. It also lets you use static routes if you need to and makes firewall rules easier.
With UniFi I have the network hardware on a different network, but I dont use 192.168.1.x for anything when using a UniFi system. I keep that as a reserved VLAN nothing ever goes on, with firewall rules only allowing 192.168.1.20 address from that VLAN to reach out to the management VLAN. That way if something does end up in a fallback mode I can still reach it successfully without any major issues.
That may seem like some crazy thing and “why would UniFi be like that?”, but every manufacturer seems to have their quirks and preferential ways of doing things. So I just see it as one of those things.
Voilence? Hahaha
Provocative? Certainly. Rude? Maybe. But voilence?
Jesus christ, these american snowflakes are really something else. Ups, was the again voilence?
IMHO it was worth a try, that might convince OP to go from rage mode into learning mode. Apprently not.
My educated guess would be that you are 100% spot on.
Yes, if your Switch is slower booting than the AP and because of that, the AP comes back online and has no working DHCP because the DHCP or the network is not yet ready, it will fall back.
This is most often not an issue, since in a none consumer environment
your DHCP is USV protected, thous always online
your APs are behing a PoE switch, which makes it impossible for the AP to be faster than the switch.
Whatever happens with the IP part, the settings themselves are not affected. So they don’t fall into factory mode. Maybe your switches detect IP collisions. I don’t know how long it will take them to ask again for DHCP or if they ever do, which would make them online again. I personally don’t like that behavior of Unifi, but at the same time could also not care less, since I would neither use VLAN1 nor 192.168.1.0/24 because of exactly such issues.
But now we are probably drifting of way to troubleshooting, when we just wanted to vent about Unifi. And trust me, there is a lot to vent about Unifi!
I had something similar and found the cause. In my(?) Unifi controller setting (self hosted) there is a check enabled by defaut if the gateway (which was my ISP router because I have very basic network setup) is not reachable the APs will shut down after a certain time - they show as connected and are adopted but won’t broadcast anything. Unfortnuately you cannot disable this setting, only change it to check the IP of another device - the implementation is really stupid > I want to use my wireless network even if the Internet or a connected device is not available and the Unfi portal doesn’t show you this status at all. Dunno if this changed in newer version or Unifi OS.
It is, if connection monitor (or whatever this feature is renamed to nowadays) is active according to this forum post. This was exactly my issue. But I ran a old version if the Unifi controller till recently, so I dunno if newer versions will behave the same.
Edit: I might be wrong and the APs were displayed as offline during my issue.
Since there is only one 5y old entry, I am going to assume that he/she enabled that setting without a real understanding of it. Otherwise, there would be more forum entries from people suffering from this issue.
Either way, the feature is AFAIK missing or with a differnet name now.
And I can also say that at least in the last 3y, this feature was not enabled by default for me. Neither of my selfhosted baremetal, selfhosted podman, nor Unifi gateway devices.
Again, not defending Unifi. I think their software is pretty poor.