No IPv4 data from WS-C3850-12S

Tags: #<Tag:0x00007fb440f5ddf8>

Hi, loving LibreNMS but having trouble with one particular device - a Cisco WS-C3850-12S. All my other Cisco switches report their IPv4 traffic stats back to LibreNMS except for this one. I spent some time looking at MIB but that doesn’t seem to be the right direction to go based on warnings and whatnot.

Any recommendations are greatly appreciated.

validate.php says

====================================

Component Version
LibreNMS 1.51
DB Schema 2019_02_10_220000_add_dates_to_fdb (132)
PHP 7.2.16
MySQL 5.5.60-MariaDB
RRDTool 1.4.8
SNMP NET-SNMP 5.7.2

====================================

[OK] Composer Version: 1.8.5
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database schema correct

discovery.php output is here
https://p.libren.ms/view/9589df59

poller.php output is here
https://p.libren.ms/view/dcaa1dd1

Hey, I’m wondering if your issue may already be resolved by my PR: https://github.com/librenms/librenms/pull/10197

The "" between ‘udp:HOSTNAME:161’ and the first OID in the SNMPGET command in your poller debug is very similar. It looks like you’re on stable releases so even though this was merged you probably won’t get it until the end of the month unless you manually apply or switch to the dev releases.

Cool, thanks for the info. I’ll hang out until I see the next patch become available and give it a try. Will report back later. Thanks!

I believe I’m up-to-date now, but still not seeing any IPv4 data from this one Cisco switch.

====================================

Component Version
LibreNMS 1.52
DB Schema 2019_02_10_220000_add_dates_to_fdb (132)
PHP 7.2.16
MySQL 5.5.60-MariaDB
RRDTool 1.4.8
SNMP NET-SNMP 5.7.2

====================================

[OK] Composer Version: 1.8.5
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database schema correct

Can you post a new poller debug?

Absolutely!

https://p.libren.ms/view/45e0f9eb

edit

maybe try this link instead…

https://p.libren.ms/view/185d36e2

That’s pretty strange. It looks better than before. It’s actually getting netstats SNMP data now and it looks like it’s good to write it to RRD. Here’s the netstats-tcp section for example…

NETSTATS-TCP BEFORE:

TCPSNMP[[0;36m’/usr/bin/snmpget’ ‘-v2c’ ‘-c’ ‘COMMUNITY’ ‘-OQUs’ ‘-m’ ‘TCP-MIB’ ‘-M’ ‘/opt/librenms/mibs:/opt/librenms/mibs/cisco’ ‘udp:HOSTNAME:161’ “” ‘TCP-MIB::tcpActiveOpens.0’ ‘TCP-MIB::tcpPassiveOpens.0’ ‘TCP-MIB::tcpAttemptFails.0’ ‘TCP-MIB::tcpEstabResets.0’ ‘TCP-MIB::tcpCurrEstab.0’ ‘TCP-MIB::tcpInSegs.0’ ‘TCP-MIB::tcpOutSegs.0’ ‘TCP-MIB::tcpRetransSegs.0’ ‘TCP-MIB::tcpInErrs.0’ ‘TCP-MIB::tcpOutRsts.0’ ‘tcpHCInSegs.0’ ‘tcpHCOutSegs.0’[0m]

NETSTATS-TCP AFTER:

TCPSNMP[’/usr/bin/snmpgetnext’ ‘-v2c’ ‘-c’ ‘COMMUNITY’ ‘-OQUs’ ‘-m’ ‘TCP-MIB’ ‘-M’ ‘/opt/librenms/mibs:/opt/librenms/mibs/cisco’ ‘udp:HOSTNAME:161’ ‘tcpActiveOpens’ ‘tcpPassiveOpens’ ‘tcpAttemptFails’ ‘tcpEstabResets’ ‘tcpCurrEstab’ ‘tcpInSegs’ ‘tcpOutSegs’ ‘tcpRetransSegs’ ‘tcpInErrs’ ‘tcpOutRsts’]

TCPHCSNMP[’/usr/bin/snmpgetnext’ ‘-v2c’ ‘-c’ ‘COMMUNITY’ ‘-OQUs’ ‘-m’ ‘TCP-MIB’ ‘-M’ ‘/opt/librenms/mibs:/opt/librenms/mibs/cisco’ ‘udp:HOSTNAME:161’ ‘tcpHCInSegs.0’ ‘tcpHCOutSegs.0’]

tcpActiveOpens.0 = 0
tcpPassiveOpens.0 = 232
tcpAttemptFails.0 = 1
tcpEstabResets.0 = 13
tcpCurrEstab.0 = 0
tcpInSegs.0 = 15918
tcpOutSegs.0 = 18328
tcpRetransSegs.0 = 180
tcpInErrs.0 = 0
tcpOutRsts.0 = 0

RRD[update 192.168.100.4/netstats-tcp.rrd N:0:232:1:13:0:15918:18328:180:0:0 --daemon unix:/var/run/rrdcached/rrdcached.sock]
[RRD Disabled]

Not sure if we’d see something more if RRD was enabled in the debug.

hmm, is this one any more informative?

https://p.libren.ms/view/a53b3092

404 for me on that one. :frowning:

Sorry, made it expire too quickly I guess. Here’s a fresh one:

https://p.libren.ms/view/433f0187