If it has not already been suggested and/or implemented, I’d like to propose 64-bit counters, at least for octets in/out of interfaces and VLANs. I monitor that traffic by fetching it via SNMP with a tool like MRTG. Apparently the counters in ROS 3.x are 32-bit, which means that 5-minute sample intervals are too infrequent for traffic above 100Mbps, and 1-minute sample intervals are too infrequent for traffic approaching the mid-500Mbps mark (counters start to rollover multiple times between reads and data errors result). 64-bit counters would give greater flexibility on read intervals, and on a device like the RB1000 which is Gig-capable, 64-bits really should be standard.
When I try to query the RB1000 in SNMPv2c with MRTG, it does not respond:
–base: Get Device Info on public@r1.0:::::2
SNMP Error:
no response received
SNMPv2c_Session (remote host: “r1.0” [xxx.xxx.xxx.xxx].161)
community: “public”
request ID: 1806897419
PDU bufsize: 8000 bytes
timeout: 2s
retries: 5
backoff: 1)
at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_util.pm line 627
SNMPWALK Problem for 1.3.6.1.2.1.1 on public@r1.0:::::2:v4only
at /usr/local/mrtg-2/bin/cfgmaker line 915
WARNING: Skipping public@r1.0:::::2 as no info could be retrieved
I am able to query my mananged switches using SNMPv2 from this same station, so I know that it works. MRTG only reads 64-bit data in SNMPv2 and I think that this is the standard. Has anyone else been able to query ROS with SNMPv2?
Changing MaxBytes will not help if MRTG does not fetch a 64-bit value in v1 mode - the following is from the MRTG docs:
SNMPv2c
If you have a fast router you might want to try to poll the ifHC* counters. This feature gets activated by switching to SNMPv2c. Unfortunately not all devices support SNMPv2c yet. If it works, this will prevent your counters from wraping within the 5 minute polling interval, since we now use 64 bit instead of the normal 32 bit.
Ehm, MikroTik, if you could please support SNMPv2C and only return Counter64 varbinds in SNMPv2C. A lot of SNMP monitors don’t like receiving 64-bit counters in SNMPv1. Essentially, you are breaking the RFC’s here…
# snmpwalk -v 1 -c public 10.0.0.1 1.3.6.1.2.1.2.2.1.17.4
truncating unsigned value to 32 bits (2)
IF-MIB::ifOutUcastPkts.4 = Counter32: 41566728
Funny thing is, that this happens when specifying SNMPv2C mode too, which could mean that you don’t properly identify Counter64 when you send 64-bit values?
The other thing I discovered when investigating this is that I can’t even query ROS on a RB1000 with MRTG in SNMPc2C mode - I get errors like this:
SNMP Error:
no response received
SNMPv2c_Session (remote host: “r1.0” [xxx.xxx.xxx.xxx].161)
community: “public”
request ID: 1430634338
PDU bufsize: 8000 bytes
timeout: 2s
retries: 5
backoff: 1)
at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_util.pm line 627
SNMPWALK Problem for 1.3.6.1.2.1.1 on public@r1.0:::::2:v4only
at /usr/local/mrtg-2/bin/cfgmaker line 915
WARNING: Skipping public@r1.0:::::2 as no info could be retrieved
This appears to be an MRTG issue, not a ROS issue, and it persists even with the latest MRTG version. This is a bit off-topic, but has anyone else tried this?
Further tests indicated that SNMPv2C support in ROS is pseudo at best; you can get a response to some queries, but it does not support important features over v2C like getbulk and 64-bit counter value returns. One of the developers of the venerable MRTG was kindly working with me on this, and he said:
…for most queries, the only difference between SNMPv1 and SNMPv2c is one bit in the version field. But get-bulk is NOT OPTIONAL in SNMPv2c, in fact it is the MAJOR
advantage of SNMPv2c over SNMPv1 - the only other changes that come to my mind are better diagnostic returns and support for 64-bit integers.