Ubiquiti UniFi Network Switch Management VLAN Issues

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.

Update 2025-11-10

The same thing happened to the ‘other’ switch – it reverted the Management VLAN to 1. The same fix worked, but just in case the referenced web page goes away here’s a summary of the steps required:

  1. Connect to the switch’s Console port using a serial cable and ‘rollover’ adaptor
  2. Login using the same credentials used for the UniFi Controller
  3. Telnet to the switch to get the management interface:
    • telnet 127.0.0.1 2222
    • (Hit ‘enter’ a second time to display the command prompt)
  4. Run the enable command to get into configuration mode
  5. Run the show network command to check the current settings
  6. Run the network mgt_vlan 254 command to set the correct management vlan
  7. Run the write memory command to save the changes
  8. Run the exit command (twice) to back out of the management interface
  9. Wait for the DHCP request to work on the right VLAN

Solar PV Export Tariff Options

When the solar panels on the House were commissioned in 2017, the UK’s Feed-In-Tariff (FIT) arrangement was still available so currently (2024-25 pricing) that system generates payments based on:

  • 5.87p per kWh of Generation, as reported by the dedicated generation meter
  • 7.14 p per kWh of Export, based on 50% of generation being treated as “deemed export”

When the new solar panels on the Outbuildings get commissioned later in 2025, those will not be eligible for any sort of FIT payments – but they will be able to generate revenue based on the actual exported energy, as reported by the SMETS2 Smart Meter.

Since the Smart Meter won’t be able to distinguish an export originating from the ‘new’ solar panels from one originating from the ‘old’ ones, it’s not possible to continue on the 50% “deemed export” basis for the older installation; the whole site needs to be switched to a tariff which makes payments based on actual, measured export.

The question then is whether it’s worth swapping over now, or waiting until the new panels are commissioned in about 6 months time – which depends on:

  • The relative rates per kWh for a metered-export tariff versus the deemed-export tariff
  • Whether the site is actually exporting (more than) 50% of generation or not

The electricity supplier is currently Octopus Energy, and the import tariff is Intelligent Octopus Go, which is very good for overnight EV charging. Octopus offer quite a wide range of export tariffs. The ‘best’ ones being:

  • Octopus Outgoing, which pays a flat rate of 15p per kWh exported
    • This is generally the best option for sites with no battery
  • Octopus Outgoing Agile, which pays a variable rate based on half-hourly electricity prices
    • This is generally preferred when there is a battery which can store a significant proportion of the solar PV generation during the middle of the day then export that in the early evening, when export prices are often (but not always) higher than 15p

On the face of it, 15p per kWh is significantly better than 7.14p per kWh, and spring-into-summer is generally very good for solar generation so a greater proportion of generated power is likely to be exported – which implies it would be beneficial to switch sooner rather than later, as long as Octopus Outgoing is compatible with Intelligent Octopus Go.