After swapping out the 9U network equipment rack in the House for a deeper, 12U alternative (to house some extra equipment in the House and free up the 9U unit for the Outbuildings) – which meant powering-off the network switches for a few hours – one of the two switches wasn’t connecting back to the UniFi Controller afterwards. Since the other switch and all of the Wireless Access Points connected OK, that ruled out issues with the DHCP server and the Controller itself, and pointed to a configuration issue with that one switch – especially since the other switch was actually connecting via the problematic switch’s network cabling.

In operational terms, the switch was working fine, passing traffic as expected, but was ‘unmanageable’ in that there was no way to change any of its settings, which I knew was going to be a problem.

While the switches were removed from the rack, I’d noticed they have an RJ45 port on the back, labelled ‘Console’. Using that with a ‘rollover’ RJ45-to-DB9 adaptor, connected via a USB to RS-232 lead, I was able to connect to the CLI via a terminal emulator and login with the same credentials used to login to the Controller.

After a lot of head-scratching, I concluded the switch’s management interface (eth0) probably wasn’t on the correct VLAN – I could see it sending DHCP request packets but they weren’t showing up in the right place on the DHCP server. The management interface is intended to be moved to a non-standard management VLAN via a ‘Network Override’ setting in the configuration for the switch (and I could see switch.managementvlan set correctly in file /tmp/system.cfg). What I failed to un-pick was the mechanism by which that management interface gets placed on the correct VLAN – I had hoped to be able to see what was happening and try to correct it.

The solution came by finding references to the ‘enable’ configuration utility which looks like it’s meant to make UniFi switches behave similarly to other brands. There’s a good summary here: https://dan.langille.org/2018/01/12/getting-into-the-cli-for-a-unifi-switch/ – which includes the specific commands for changing the VLAN of the management interface (which had indeed reverted to the default, VLAN 1). After changing the setting (and running write memory) everything started working (the switch retries the DHCP request automatically).

So, in summary: it’s not clear why it lost that one setting (while retaining all the others) but it’s good that there was a way to get things working again without having to factory-reset the switch and re-specify all the configuration.