Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
-
Cisco Small Business 2.5.0.90 (SG350-10-K9)
Description
This looks related to ticket OBS-4391 - which is closed as "resolved" but appears to be still an issue.
What version of Observium: 23.8.12912 (2nd August 2023)
When did this start:
This was working before an update to Observium sometime in Q1 of 2023, after that time this issue appeared.
Issue description:
On all of our 200+ Cisco Small Business switches the port vlan information is incorrectly reporting as "VLAN1". This is visible when viewing port details. When viewing VLANs details the vlans are correctly discovered, but ports with vlan configuration are visible twice - once in vlan1 and once in their correct vlan.
Attached documentation:
I've attached the output of
./discovery.php -d -h <device>
./poller.php -d -h <device>
I've also attached screenshots of an example device, along with the interface config from this device. Additionally, I've attached the output of the port info obtained through an API call to the endpoint "/ports/{port_id}/". In this output you can see the port is reporting ifVlan = 1
Attachments
Issue Links
- mentions
-
OBS-4391 Vlans of Cisco Small Busniess 250 all show under VLAN 1
-
- Resolved
-
Activity
Yah, I forgot that this devices have troubles with full snmp walks..
pls try walk only vlan specific mib (.1.3.6.1.4.1.9.6.1.101.48):
snmpwalk -v3 <your_v3_auth> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1.9.6.1.101.48 >> myagent.snmpwalk
|
Hey Mike, sorry for the delayed response. I ran into an issue running the command since our devices are using snmp v3, once I figured out how to run it with the authentication creds I needed, the walk seems to be running forever. (After 10 mins of my terminal hanging, I stopped it and ran it again without exporting to "myagent.snmpwalk" so I could see what was happening, and then I let it run for a solid hour and it showed no sign of stopping, so something must be wrong.)
Is there some other way I can provide you the info you need to see what's happening with how the vlans are being reported by Observium?
Your issue not fully related with previous issue, but your device not report required Oids:
snmpbulkwalk ... -Pud -OQUs -m CISCOSB-vlan-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp:/opt/observium/
|
mibs/ciscosb 'udp':'adalb-kv01-1e-11':'161' vlanTrunkPortModeNativeVlanId
|
vlanTrunkPortModeNativeVlanId = No Such Instance currently exists at this OID
|
|
|
snmpbulkwalk ... -Pud -OQUs -m CISCOSB-vlan-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp:/opt/observium/
|
mibs/ciscosb 'udp':'adalb-kv01-1e-11':'161' vlanAccessPortModeVlanId
|
vlanAccessPortModeVlanId = No Such Instance currently exists at this OID
|
For check (and improve) please make full snmpdump as Bot requested.
You can send this dump me personally at email: mike@observium.org
(or attach it here).
General questions and device support can be discussed in our Discord channel, click here to join.
Please make and attach additional information about the device:
- full snmp dump from device:
snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1 > myagent.snmpwalksnmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalkIf device not support SNMP version 2c, replace -v2c with -v1.
- If you have problems with discovery or poller processes, please do and attach these debugs:
./discovery.php -d -h <device>./poller.php -d -h <device>
- additionally attach device and/or vendor specific MIB files
This comment is added automatically.
It should be polled in r13000.
But here used "slow" way, with many Oids.
Check polling times for ports module.