I have been using PRTG Network Monitor to collect via SNMP interface (bandwidth) statistics.
Since some time yesterday after upgrade to v6.17, the interfaces are no longer reporting via SNMP.
I’ve deleted all SNMP “sensors” and re-run an auto-discovery and it has not found any of the interfaces as “sensors” to monitor?
I had the same problem with 6.16. I lost all 64bit (HC) counters. When upgrading to 6.17 this was fixed. It was probably the reboot itself that fixed this.
Use Zabbix SMNP for control flowrate on RB-751.
After upgrade on 6.17 version we have not graphics interface load.
The DUDE internal SMNP scanner can not find OID’s for interface counter packet
This is not good 
After upgrade 6.15 → 6.17 we have a problem with SMNP agent Zabbix.
OID’s flowrate counter not found.
I can try scan Mikrotik RB751 from internal DUDE SMNP scaner,but information about counters from interface not found.
We can wait fix this bug 
what OIDs you are/where checking?
with what settings?
can you connect to the router with tools like snmpwalk?
I posted about this bug in the sticky about 6.17
After upgrading only few mibs are shown using snmpwalk. I can post them here, but while their number is very low it is still above 50. The interface statistics are not shown at all. No matter what is the interface.
I can not still determine how I fix the problem. Sometimes 1 additional reboot after upgrading fixes it, sometimes 2 reboots are needed. Sometimes all I need to do is disable/enable snmp and change some setting, but that doesn’t always help.
we have the same problem with 6.16 and 6.17 in the dude
so, to get behaviour you are describing i have to upgrade from 6.16 6.15) to 6.17
and then i will get 50 or so OIDs
well i am on 6.18rc1 already (w/o reboots) directly after upgrade on CRS125:
$ snmpwalk -v1 -c public 192.168.88.99 |wc -l
1154
Device: RB751U-2HnD
After upgrade 6.15 → 6.17 i have from DUDE SNMP scanner next information:
Counters of IfInterface was lost from MIB in f/w v 6.17
Wait fix this bug.
Very interesting OID from RFC1213-MIB section:
iso.org.dod.internet.mgmt.mib-2.system.sysObjectID.0 = iso.org.dod.internet.private.enterprises.mikrotik.mikrotikExperimentalModule
ExperimentalModule 
if yo can, reboot the router and see if then you see all the desired OIDs responding. Also, you could send in a support output file of the current state of the router.
Ok, SMNP lets work after next step:
Just upgraded a RB911G from v6.15 to v6.17
SNMP works fine, but I remember that I already had the snmp problem when upgrading from v6.7 to v6.15 on that particular device, so it seems it happens only once.
I still have a lot of devices to upgrade, waiting for convenient time to do them. If I encounter the problem somewhere else i will give all relevant info - oid count before upgrade, oid count after upgrade before reboot, oid count after reboot, supout.rif when oids are missing.
This is not a bug, but a feature that improves previous SNMP problems. Now, if you query by SNMP, and SNMP can’t get the required information from some specific RouterOS program in the required amount of time, it will just time out this specific item. Previously you would not get any result at all, now only the specific info is missing. We will improve the timeouts in v6.18 to be more optimal.
So if for example the “health” program is timing out, your SNMP walk will not return any health results, previously the SNMP walk would time out altogether.
Ok, here it is :
Upgraded RB433 from v6.7 to v6.17.
OID count before upgrade :
root@clients:/etc/sysconfig/htb# snmpwalk 192.168.9.118 -v1 -c public|wc -l
1602
OID count after upgrade :
root@clients:/etc/sysconfig/htb# snmpwalk 192.168.9.118 -v1 -c public|wc -l
47
Attached supout.rif when oid count is 47 (can’t attach the rif file here, but I can send if needed)
OID count after enabling wireless-fp, upgrading firmware and reboot :
root@clients:/etc/sysconfig/htb# snmpwalk 192.168.9.118 -v1 -c public|wc -l
83
OID count after 2nd reboot :
root@clients:/etc/sysconfig/htb# snmpwalk 192.168.9.118 -v1 -c public|wc -l
83
At the moment this board is stuck with oid count of 83 and nothing helps - enable/disable snmp from winbox, changing settings, 2 reboots. Maybe a few more reboots or some change in settings will fix it, that is what I did in all my previous upgrades, but I only upgraded this board to give you the info, I don’t really need snmp info from it so I am stopping with attempts for now.
P.S. So I guess this will be fixed in v6.18, sorry I did not see that info because I started to write the message and collecting info before your answer is posted Normis.
From this I could speculate that 1555 interfaces didn’t answer in timely manner, and were excluded.
No there are only the 3 ethernet interfaces, 2 wireless cards + 1 virtual ap and 1 bridge.
Maybe the count is so high because there are around 400 entries in bridge mac table.
Anyway, I hope you understand what causes this. In general it means some processes were busy, and to not interrupt RouterOS operation, their query timed out. We will improve the situation in the next release.
Hi guys,
I also have this issue - but not on all of my Routerboards. All RB’s are running 6.17 and were working fine up to release 6.15. I’m running SNMPv2.
RB2011UAS: Started working after two reboots.
751U-2HnD: Several reboots, only gives me 112 lines when doing a snmpwalk.
750: Several reboots, gives me 81 lines on a snmpwalk.
I don’t know if it’s relevant, but on the RB’s with the fault, the last OID i get on a snmpwalk is this one before it stops:
iso.3.6.1.2.1.9999.1.1.1.1.0 = STRING: “MikroTik DHCP server”
iso.3.6.1.2.1.9999.1.1.1.2.0 = OID: iso.3.6.1.4.1.14988.1
Kristofer
Just upgraded from v6.14 to v6.17 and hit the same SNMP OID problems too.
This fixed it for me.
I had some more time to play with this too.
Another way to fix it is to disable snmp, wait a few minutes and enable it again. Works without restart. But for some reason if you do it quickly - just disable/enable in a few seconds it doesn’t work. Just tested this method on 2 boards and it works. Doesn’t sound very logical, but it does the job.
I haven’t tried the v6.18rc versions maybe it is already fixed there, but for the time being this is some sort of a solution.