RouterOS Agent Script Help

Plugins
,
1

I have four RouterOS devices:
CCR2116-12G-4S+, CRS326-24S+2Q+, and two CRS310-8G+2S+
All devices are running RouterOS 7.18
I have SNMP v3 working and enabled on all four devices.
I have SNMP limited to only LibreNMS box.
I have given my SNMPv3 user read/write privileges

I have installed the agent script for LibreNMS via this link:
https://docs.librenms.org/Support/Devic … /Routeros/
This works for the CCR2116-12G-4S+ and both CRS310-8G+2S+…
However I cannot get it to work with my CRS326-24S+2Q+
I have compared the SNMP settings, user, script ownership, the script itself. All are the same.
When I look at the run count for the script, the run count is going up much faster than the other boxes.

When I install the script, the script, the job and “txtContent” environment gets created.
If I run the script manually, the “vlansu” and “vlanst” environments get created.
If I let LibreNMS run the script, the “vlansu” and “vlanst” environments do NOT get created.

Seems like a permissions issue, but I can’t seem to figure it out yet.
I have disabled write, saved, enabled write,save on the SNMPv3 user to see if that helps.
I know the SNMPv3 user works because everything else for the CRS326-24S+2Q+ populates in LibreNMS correctly.

Observations (Edited to add info):
The script user owner is a “full” group member. (I removed “admin”) and both the user and the group is exactly the same across all four devices.
I removed the script, job, and all three created environments and re-added the script. Then ran rediscovery in LibreNMS.
I re-applied the SNMPv3 secrets again. No change.

2

Still no luck. This has me perplexed.

3

I have a similar problem - mine is identical
Some Mikrotik switches are identical and some return results from the LNMS vlan script via OID .1.3.6.1.4.1.14988.1.1.18.1.1.2.1 and some do not…
That’s just the world of Mikrotik

4

Hi all,

I solved the problem today. It was not an issue with LibreNMS or the MikroTik itself, but with the MTU on the path between LibreNMS and the MikroTik.

When performing SNMP queries (for example, VLAN discovery), the MikroTik returns relatively large SNMP responses. If the MTU on the path is too low, these packets get fragmented or dropped. As a result, LibreNMS receives incomplete or corrupted SNMP data, which shows up as various strange errors.

In my case, the issue was caused by a lower MTU/L2MTU on one of the devices along the path. After setting:

  • MTU = 1594

  • L2MTU = 1594

the communication stabilized, and LibreNMS could reliably retrieve the SNMP responses. Since then, everything has been working perfectly.

The takeaway is that if there are different MTU values along the path, large SNMP responses from MikroTik may not be delivered correctly. Therefore, I recommend checking the MTU/L2MTU settings across the entire path between LibreNMS and MikroTik.