Ubiquiti USW-48-POE detected as Generic MIPS

Ubiquiti Unifi USW-48-POE switches running 7.0.50 firmware [this is quite recent, last 6 months].
LibreNMS running in Docker.

Switches are detected as generic MIPS. The FDB tables are all missing Port entries.

librenms:/opt/librenms$ ./validate.php
===========================================
Component | Version
--------- | -------
LibreNMS  | 24.8.0 (2024-08-25T22:45:45+01:00)
DB Schema | 2024_07_19_120719_update_ports_stack_table (296)
PHP       | 8.2.20
Python    | 3.11.9
Database  | MariaDB 10.11.9-MariaDB-ubu2204
RRDTool   | 1.8.0
SNMP      | 5.9.4
===========================================

[OK]    Installed from package; no Composer required
[OK]    Database connection successful
[OK]    Database connection successful
[OK]    Database Schema is current
[OK]    SQL Server meets minimum requirements
[OK]    lower_case_table_names is enabled
[OK]    MySQL engine is optimal
[OK]    Database and column collations are correct
[OK]    Database schema correct
[OK]    MySQL and PHP time match
[OK]    Active pollers found
[OK]    Dispatcher Service is enabled
[OK]    Locks are functional
[OK]    No python wrapper pollers found
[OK]    Redis is functional
[WARN]  IPv6 is disabled on your server, you will not be able to add IPv6 devices.
[OK]    rrd_dir is writable
[OK]    rrdtool version ok
[WARN]  Non-git install, updates are manual or from package

Discovery:
https://p.libren.ms/view/a8554b26

Poller:
https://p.libren.ms/view/8f53ce68

OK, having walked this, I guess I can see why…there is not a lot to uniquely identify this switch!

SNMPv2-MIB::sysDescr.0 = STRING: Linux Switch1 3.18.24 #0 Thu Aug 30 12:10:54 2018 mips
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (484180000) 56 days, 0:56:40.00
SNMPv2-MIB::sysContact.0 = STRING: Default
SNMPv2-MIB::sysName.0 = STRING: Switch1


But I think that FDB port entries should be able to be populated by LibreNMS as they are in the BRIDGE-MIB:

BRIDGE-MIB::dot1dTpFdbAddress.'....L.' = STRING: 0:c0:8:a3:4c:cc
BRIDGE-MIB::dot1dTpFdbAddress.'..iO$M' = STRING: 0:e2:69:4f:24:4d
BRIDGE-MIB::dot1dTpFdbAddress.'.iz.f_' = STRING: 1c:69:7a:f2:66:5f
BRIDGE-MIB::dot1dTpFdbAddress.'N>^..v' = STRING: 4e:3e:5e:86:e:76
BRIDGE-MIB::dot1dTpFdbAddress.'P..t..' = STRING: 50:eb:f6:74:a:d7
BRIDGE-MIB::dot1dTpFdbAddress.'V..@81' = STRING: 56:ab:15:40:38:31
BRIDGE-MIB::dot1dTpFdbAddress.'l<...e' = STRING: 6c:3c:8c:0:1c:65
BRIDGE-MIB::dot1dTpFdbAddress.'l<.&..' = STRING: 6c:3c:8c:26:bb:a7
BRIDGE-MIB::dot1dTpFdbAddress.'t.y...' = STRING: 74:97:79:aa:ea:b1
BRIDGE-MIB::dot1dTpFdbAddress.'v..!.q' = STRING: 76:19:a5:21:c4:71
BRIDGE-MIB::dot1dTpFdbAddress.'...i..' = STRING: 88:e9:fe:69:8e:d
BRIDGE-MIB::dot1dTpFdbAddress.'..N...' = STRING: 9c:93:4e:dc:88:94
BRIDGE-MIB::dot1dTpFdbAddress.'...[.n' = STRING: ac:8b:a9:5b:fa:6e
BRIDGE-MIB::dot1dTpFdbAddress.'...a..' = STRING: ac:8b:a9:61:ac:c3
BRIDGE-MIB::dot1dTpFdbAddress.'...a..' = STRING: ac:8b:a9:61:b2:bf
BRIDGE-MIB::dot1dTpFdbAddress.'...~..' = STRING: b8:ae:ed:7e:f4:96
BRIDGE-MIB::dot1dTpFdbAddress.'.Q.v,.' = STRING: d6:51:b4:76:2c:f6
BRIDGE-MIB::dot1dTpFdbAddress.'.8.l..' = STRING: e4:38:83:6c:dd:83
BRIDGE-MIB::dot1dTpFdbAddress.'.8.l..' = STRING: e4:38:83:6c:dd:84
BRIDGE-MIB::dot1dTpFdbAddress.'......' = STRING: f2:e6:c8:1e:b1:ac
BRIDGE-MIB::dot1dTpFdbPort.'....L.' = INTEGER: 46
BRIDGE-MIB::dot1dTpFdbPort.'..iO$M' = INTEGER: 48
BRIDGE-MIB::dot1dTpFdbPort.'.iz.f_' = INTEGER: 10
BRIDGE-MIB::dot1dTpFdbPort.'N>^..v' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'P..t..' = INTEGER: 44
BRIDGE-MIB::dot1dTpFdbPort.'V..@81' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'l<...e' = INTEGER: 42
BRIDGE-MIB::dot1dTpFdbPort.'l<.&..' = INTEGER: 22
BRIDGE-MIB::dot1dTpFdbPort.'t.y...' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'v..!.q' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'...i..' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'..N...' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'...[.n' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'...a..' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'...a..' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'...~..' = INTEGER: 31
BRIDGE-MIB::dot1dTpFdbPort.'.Q.v,.' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'.8.l..' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'.8.l..' = INTEGER: 47
BRIDGE-MIB::dot1dTpFdbPort.'......' = INTEGER: 47

Can you post the output of:

/usr/bin/snmpget -M /opt/librenms/mibs -m SNMPv2-TC:SNMPv2-MIB:IF-MIB:IP-MIB:TCP-MIB:UDP-MIB:NET-SNMP-VACM-MIB -v2c -c COMMUNITY -OQnXUte -Pu udp:HOSTNAME:161 SNMPv2-MIB::sysObjectID.0

.1.3.6.1.2.1.1.2.0 = .1.3.6.1.4.1.8072.3.2.10

That’s the correct OID for edgeswitch detection, are you sure it’s being picked up as a generic device?

Yes.
image

FWIW, Unifi and Edgeswitch are different products lines, although the internals are probably identical.

What is the OS it’s supposed to be then? We have unifi detection but that’s for wireless devices.

I guess LNMS knows these as “Edgeswitch”. This is a different model:
image

which also happens to have the FDB entry port fields populated, not sure if that is related.

What does this give you:

/usr/bin/snmpget -M /opt/librenms/mibs -v2c -c COMMUNITY -OQnXUte -Pu udp:HOSTNAME:161 ENTITY-MIB::entPhysicalDescr.1

On USW-48-POE:

.1.3.6.1.2.1.47.1.1.1.1.2.1 = No Such Object available on this agent at this OID

On USW-16-150W:

.1.3.6.1.2.1.47.1.1.1.1.2.1 = UBNT EdgeSwitch 16-Port

We don’t have that exact model but do have a number of Unifi switches and the 2nd gen models are supported by LibreNMS much more thoroughly than 1st Gen models like the USW-48-POE.

In our case we have the following 2nd gen models which are fully detected:

USW-Pro-24-POE
USW-Pro-48-POE

  • Hardware lists the correct model number.
  • Operating system reports “EdgeSwitch 7.0.50.15613” or similar, (Unifi switches are basically Edgeswitch OS with the Web Interface ripped out)
  • Port names and statistics are reported.
  • Port FDB tables populated.
  • VLAN’s are reported.
  • LLDP neighbours are reported.
  • Inventory is reported.
  • Processor and Memory graphs.
  • Eight temperature readings.
  • Two fan readings.
  • Various state sensors (fans, etc)

The 1st gen switches seem to be barely recognised. We have some USW-24-POE and the following is reported in LibreNMS:

  • Hardware field (model number) not populated
  • Operating system is just “EdgeSwitch”
  • Port names and statistics are reported
  • Port FDB tables populated.
  • VLAN information NOT populated
  • LLDP neighbours tab not even present let alone populated
  • Inventory tab only lists a processor.
  • No processor or memory graph.
  • No temperature, fan or state information.

So the information for the 1st Gen (non-Pro) switches is pretty limited. Whether that’s because the information simply isn’t available or someone hasn’t worked out how to extract it I’m not sure.

What I do know is that the underlying Linux OS on the 1st Gen and 2nd Gen Unifi switches is VERY different and this may be related. If you dig into the cli of the 1st gen switches like the USW-24-POE it is quite limited compared to the PRO models and these differences are glossed over in the normal web UI.

I’m curious to see if recognition of the USW-24-POE and USW-48-POE can be improved and I can provide SNMP dumps of the USW-24-POE if that helps…

Ideally, if someone can provide an snmprec file for the devices that you are having an issue with so we can emulate the device then that would be good.

Or a complete snmpbulkwalk at the least.

I tried running snmpsim-record-commands, it ran for a long time saying processing OID 0/100, 0/200, 0/300 etc, I let it run until it got to several thousand and eventually stopped it.

It did generate a file about 235K in size with what looks like OID’s however I don’t know if it worked properly as I had to manually interrupt it and the documentation on how to use this record command is pretty sparse…

I am having a crack at this, will see what happens.

Some files can hit 1Mb or more so try and leave it running

I left it running for about half an hour to get what I did - so leave it running for a few hours ??

I’m not sure I understand how this differs from an snmpbulkwalk and why it would take so long.

I expect it’s taking long because of the poor snmp stack on the device, see how it gets on.

Basically the snmprec file allows us to emulate the device, an snmpwalk means we have to translate the output and write yaml / PHP blindly.

This took less than a minute and is 91kB so hopefully is what you are after.