Hello, that are my first steps in Ubiquity world. I decided to go with Unifi products, so I’ve got three UniFi Switch 8 and AP-AC-LR.
My first impressions are that, Ubiquity do the VLAN tagging/untagging via profiles, and If I understood correctly (based on my humble experience) the management traffic should be untagged. By the way these switches cannot change their management vlan, but the AP can.
So what was my pain today? I’ve played with changing vlans/profiles and so on, and I end up with broken configuration for one of the switches, my switch cannot speak to the controller anymore.
First thoughts are to use another port on the same switch, but for security reasons I disabled all the other ports ;> Then I decided to reset the switch and I did it.
In meantime I reverted back the working configuration for this switch from the controller, so I expect after the switch was reset to factory defaults, to get the right config from the controller. Unfortunately, the switch ended up with status “adopting” and nothing happened. Tried to restart the switch two or three times, but this doesn’t help. So I have to “forget this device”, afterwards to do adopting again, and re-create the configuration by head.
Few questions appeared in my mind:
Am I right about the management traffic? It have to be untagged?
Is there any easy way to back-up configuration for particular item as file, or to set this configuration as deprecated, and later on after adopting to use it again?
In the scenario posed however, I don’t think a controller backup would help. The reason is the same as why a device that is reset has to also be forgotten: when a device is adopted by Unifi, it is given its own key, that it must use in the future. If the device is reset, it no longer has the key. The reason why it looks like this should work the way you want, why it says “Adopting” after the device is reset but before it is forgotten, is that every time a device goes offline and comes back it is always “Adopted” again, meaning it is sent the full configuration, but sending the key only happens the first time. You can see this in the events log whenever a device comes back from being offline (unplug an AP for 5-10 minutes). A malicious attacker could intercept and then later spoof the device’s identifier (which might be the MAC or might be something else, either way it never changes) so the key is needed for security.
So suppose you took a controller backup, and then lost remote access to the switch (caused the switch to not be able to contact the controller, via a change to that switch and not due to an uplink device) - the backup would not help you. If you restored the backup, it wouldn’t matter because the switch still can’t access the controller. If you reset the device and restored the controller, it wouldn’t matter because the device no longer has its key.
Bottom line, if you reset a device, it has lost its key, and will need to be forgotten.
Thanks for the detailed clarification @brwainer. Using key / hash for security reasons sounds like a logical solution, but I don’t expected that, that’s why I tried to reset the switch, and adopt it again stupid me…
So for your post I realize that, the only one way to get your device communicating to the controller is to reset it, forget it from the controller perspective and re-adopt it again.
And there is no way to keep the configuration only for this particular device, correct me if I’m wrong.
Hey @LTS_Tom thanks for the reply. I will try to set different management VLAN for my devices.
About the backing up the controller configuration, it wont help as we agreed, because not entire config is bad, but the config for only specific object in that case, the switch. So backup up specific object to the time being seems to be impossible.
I only notice that, I can replicate other switch profile to the current one, so maybe if there is a way to invalidate the bad config, and reset the device, adopt it, afterwards to tell the controller to apply this config to newly attached device, it will help…
If you can’t regain communication via some other means (by moving to another port on the switch, or finding some creative solution like changing the upstream port to be untagged for some other VLAN, entirely dependent on the situation) then the only option is to forget it and reset.
Other systems handle the key issue differently. Meraki puts a private key signed by them onto each device, which works because Meraki devices can only communicate with their own cloud. This means a Meraki device does work the way you’re wanting, where they can be reset without forgetting all the config for the device. (Meraki also has a lot of tricks to reestablish communication, like rolling back to the last known good config and enabling DHCP on every VLAN it sees)
Good point @brwainer, thanks for the clarification again.
In the future I will be very careful when I’m going to change some settings.
Because this is my first time when I have to managed devices which works with let say “remote management” I’m a little bit confused, but I will get used to it.
I come from Mikrotik world, where you have little exe file which you run on your local machine, access your device by IP or MAC, and do all the configuration. Last but not least, the configuration is saved to the device in binary and human readable format, and for you is very easy to change it.
I’m familiar with Mikrotik, its my favorite router and swiss army knife brand.
One option to keep in mind is that you can also SSH into the Unifi devices and do some local configuration changes. You have to enable SSH from the controller, and make sure you know the credentials - that’s why it isn’t helpful from a completely new user’s perspective. Once you log in, the commands are the same as on EdgeSwitches or EdgeRouters. So if its really necessary you can get in and change whatever is wrong to re-establish access to the controller. Once it talks to the controller again, the controller provisioning takes effect, so also make sure you fixed the issue in the controller first.
stupid me…