SNMP interface indexing bug(?)

[feld]

I've been adding additional monitoring to a network with OpnSense as the firewall and noticed a curious problem with the data I was receiving. The internet uplink / WAN is on interface ax1 and I was running network tests which should have shown multi-gigabit data transfer rates with my SNMP graphing and monitoring. However, it was not showing me this in the results. The correct data rates were found on the ax0 interface instead which is not possible because that interface is only gigabit.

I believe this situation was caused by my removal of the igb1 interface which was no longer being used. The igb interfaces are earlier in the SNMP IF-MIB::ifDescr table than the ax interfaces so this seems to make sense. My problem was resolved after restarting the snmpd service and running additional tests.

I think the correct solution here is to require a restart of the snmpd service every time an interface is created or destroyed to ensure the data being served is correct. However, this may produce interesting challenges for systems that only "walk" to learn the SNMP information periodically which I recall being the behavior of Observium/Librenms. I don't know if there's a good solution for that other than recommending that admins are aware they should manually run the SNMP discovery mechanism after interface changes on OpnSense to ensure their monitoring and graphing stays consistent with reality.

[feld]

I've witnessed this happening again so now I'm doubting the previous diagnosis. I think there's something wrong with the accounting of packets and octets for the ax driver on the DEC840. It doesn't seem to provide correct values for the ax1 interface.


edit: I wonder if these bogus errors are part of the problem too?

[rickygm]

I am monitoring with librenms, but it does not detect it correctly, it puts it as a freebsd pc