Hello -

I've been troubleshooting an issue in which I cannot query ROS with MRTG using SNMPv2C, and after some kindly help from the MRTG developers, it appears the issue may be that the current stable version of ROS only offers psuedo-support of SNMPv2C:

snmpwalk -c public -v 2c r1.0
SNMPv2-MIB::sysDescr.0 = STRING: router
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.14988.1
SNMPv2-MIB::sysUpTime.0 = Timeticks: (161707400) 18 days, 17:11:14.00
...etc

snmpbulkwalk -c public -v 2c r1.0
Timeout: No Response from r1.0

...and querying the counters with MRTG mod'ed to not use getbulk:

--base: snmpget public@r2.0:::::2:v4only for ifHighSpeed.24 -> 0 Mb/s
--base: snmpget public@r2.0:::::2:v4only for ifHCInOctets.24 -> 1239398008
--base: check for HighspeedCounters failed ... Dropping back to V1
--base: snmpget public@r2.0:::::2:v4only for ifHighSpeed.25 -> 0 Mb/s
--base: snmpget public@r2.0:::::2:v4only for ifHCInOctets.25 -> 2258087578
--base: check for HighspeedCounters failed ... Dropping back to V1

..etc. I think that proper support for this protocol is important!

Thanks!

Ed

ROS only supports SNMPv1 as far as I know

ROS only supports SNMPv1 as far as I know

Clearly it does offer support for v2C, perhaps with some limits, see above test with snmpwalk as well as other posts around this board. But it does appear to need some work.

I've moved this discussion to here: http://forum.mikrotik.com/viewtopic.php?f=1&t=32647, because the proper support of SNMPv2C in ROS is feature request for the next verision.

I second this support!
MikroTik, please remove whatever hacks you did to the SNMPv1 protocol to make it appear like SNMPv2C, and make a proper SNMPv2C implementation (and implement the BGP MIB while you're at it...)!

Good news - I've received notice form MikroTik techinical support that they are working on full SNMPv2C compatibility.

Hooray!

SNMP v2c read only?

SNMP on RB493 with v.3.14 works fine.
But on x86 with v.3.25 does not want to work "Timeout: No Response from xx.xx.xx.xx"
It's my mistake or SNMP is not working on x86?

3.25, x86 - works fine for me

3.25, x86 - works fine for me

Ok.Thanks!
I will search for a problem at myself.

The changelog for the latest release (v3.27) does not say anything about snmpv2c support improvements. Mikrotik, can you tell us, in what version can we expect this?

Thanks!

Ed

I was attempting to use v2c on various routerboards. 'snmpwalk' using v2c gets responses but MRTG's configmaker does not. I sniffed the traffic to discover that it doesn't respond to getBulkRequest as the original poster points out.

Could we get an official response as to weather real snmp v2c support is on the roadmap?

I'm having the same issue here -- I'm trying to add my new RB to Cacti using SNMPv2c, but it is not responding properly to the getBulkRequest in the interface query. I can add it as an SNMPv1 device and then switch to v2c for graphing, but it would be nice if the implantation was done properly.

I have not yet tested bandwidth over 114Mb/s to see if the 64-bit counters are working properly, but hopefully that will work as expected.

According to the release notes for RouterOS v5 Beta 6, bulk get has been added: I haven't tested it yet.

* http://www.mikrotik.com/download/CHANGELOG_5
* http://forum.mikrotik.com/viewtopic.php?f=1&t=44103

falz - I just tested the new release with SNMP Bulk Gets and can confirm that it works as advertised. Thanks for the heads-up.

Only one problem - All my Cacti graphs that are still trying to connect to the 5.0beta6 with Version 1 now fail.

My Cacti log now fills up with SNMP timeouts and invalid results. And empty graphs.

The SNMP requests just timeout when trying to connect with Version 1.

Deleted my graphs and data sources and recreated with Version 1 - No difference.

Deleted my graphs and data sources and recreated with Version 2 - Still no usable results. Now log reads Result from SNMP not valid.

Even if that worked, I'm graphing hundreds of Mikrotik devices - It is simply not practical to rebuild all the graphs just for a version upgrade - This is definitely a show stopper.

Same problem here -- Even though bulk requests work fine now, the SNMP polls themselves fail with beta6.