# snmpwalk -v2c -c xxxxxxxxxxx -On 10.10.216.243 1.3.6.1.4.1.14988.1.1.3.15
.1.3.6.1.4.1.14988.1.1.3.15 = No Such Object available on this agent at this OID
When walking the 1.3.6.1.4.1.14988.1.1.3 OID, a couple of them are missing:
When I run snnmpwalk on 750r3 I can see unknown .1.3.6.1.4.1.14988.1.1.3.14.0 OID, which is 880 in my case, and neither description no even looks-like value can be found. At the same time
/system health print oid
gives me plenty of OIDs and most of them not even appears to be supported on this model:
I opened #2019032822004818 a few months ago, many SNMP hardware OIDs are missing for the CCR1072, compared to what Winbox shows :
Board temperature
Board temparature 2
Fan speed 3
Fan speed 4
PSU1 status (should be OID .15 (*))
PSU2 status (should be OID .16 ())
() as seen on other models such as the CRS317-1G-16S+.
We are then clearly at risk with our CCR1072-1G-8S+, not being able to monitor all their hardware components, which is a rather tricky situation for core devices.
I would not say it is better, I agree there should be more SNMP OIDs available, but when it is the only thing that works it could be better.
I remember there is an obscure feature that allows to call a script when a certain range of SNMP OIDs is polled and return the value that script returns.
However, I never understood how that should work.
Actually we do
Deploying custom scripts on routers themselves to populate one branch of the SNMP tree with OIDs which should be there at their right place by default is IMO a rather “crappy” workaround…
In addition, CCR1072 seems to be the only device with missing hardware OIDs. At least we did not encounter other ones yet. So it does not really make sense to manage / maintain an exception.
Having properly defined OIDs is the expected behavior on devices supporting SNMP, so IMO this is the way to go on CCR1072
We would then be able to fully monitor it, in a proper and reliable way, as with any other Mikrotik router.
I agree that this particular case should be (and should be easily) solved.
However, there are a lot of other things that cannot be monitored using SNMP in MikroTik.
Maybe some of these things are really so seldomly used that it would be warranted to make custom scripts for them.
I’m not sure where to find the hint that this is possible. I once read it in a release note I think, but maybe I just misunderstood what it was meant to say.
Almost sure this would not take more than 0.5 or 1 day for one developer to implement this.
At least for now we manage to grab everything we need (system and hardware health, interfaces’ traffic and errors, updates…).
But there may exist some specific cases I agree.
Browse the Mikrotik MIB and you’ll find it
Corresponding entry is mtxrScriptRun (.1.3.6.1.4.1.14988.1.1.18), which provides a table of custom scripts, with ability to run them and get their output back.
Ahh yes, that rings a bell. I invite you to make a working proof of concept
(I wasn’t able to get it to work back when this was added)
For example it would be nice to monitor some of the behaviour of BGP (peers connected or not, number of prefixes per peer, etc) and it can be done via API but not via SNMP.