Community discussions

MikroTik App
 
TedRule
just joined
Topic Author
Posts: 15
Joined: Tue Nov 03, 2020 4:41 pm

SNMPv3 EngineID uniqueness issue

Fri Nov 05, 2021 11:03 am

The latest stable RouterOS v6.49 adds the ability to configure the SNMPv3 EngineID, as defined in RFC3411, especially Section 5, Page 41,42.

RouterOS enforces an EngineID prefix of "80 00 3A 8C 04", which translates as:

80 - top-bit == 1 == as defined in RFC3411
00 00 3A 8C == 14988 decimal == MikroTik Enterprise ID.
04 == Text.

The default EngineID suffix is an empty string, and hence the full default EngineID is the 5-Byte Hex String "80 00 3A 8C 04".

Prior to v6.49, it seems that the EngineID was always this fixed "80 00 3A 8C 04" Hex String.

The problem is that without explicit configuration, every MikroTik ends up with the same EngineID, which effectively violates the uniqueness referenced in RFC3411 Para 3.1.1.1:

3.1.1.1. snmpEngineID

Within an administrative domain, an snmpEngineID is the unique and
unambiguous identifier of an SNMP engine. Since there is a one-to-
one association between SNMP engines and SNMP entities, it also
uniquely and unambiguously identifies the SNMP entity within that
administrative domain. Note that it is possible for SNMP entities in
different administrative domains to have the same value for
snmpEngineID. Federation of administrative domains may necessitate
assignment of new values.

As it happens, the commonly used net-snmp library maintains a cache mapping of EngineID -> EngineBoots/EngineTime indexed purely on EngineID as far as I can tell.
This leads to a problem if two devices uses the same EngineID, but have different EngineBoots/EngineTime values, or even different SNMPv3 authentication parameters; SNMPv3
authentication breaks under certain conditions.

The common solution to this problem, as witnessed on numerous Cisco or Juniper devices, is to use EngineID "type" 3, which is the MAC address of the lowest interface on the device.
Even here the RFC is ambiguous; it says "lowest IEEE MAC address, canonical order" rather than more explicitly "IEEE MAC address of lowest interface, canonical order",
which is what Cisco/Juniper appear to adhere to. Despite this, we've seen issues on Juniper clusters where both halves of the cluster have the same MAC address on the lowest interface,
but the two halves of the cluster are in reality two different SNMP entities.

I believe RedHat, presumably using the method embedded in the net-snmp library, take a different approach with the SNMP agents on their machines, initialising the EngineID to a pseudo-random number at boot. Other manufacturers' methodology may vary.

The existing RouterOS EngineID is of "type" 4, which is a text field; changing that to "type" 3 is probably too radical. My suggestion is that where the EngineID is NOT explicitly configured, that the actual EngineID-suffix used by the SNMP engine be auto-configured to be either the text-string of the Serial No. of the device or the MAC address of the lowest physical interface.
My personal preference is for the Serial No., but I'm not vehemently wedded to this.

In either case, under these circumstances, dumping the device configuration should NOT display a configured EngineID. This allows for copy/pasting a device configuration from one device to another without the risk of creating two devices with the same EngineID.
 
Snoopy
just joined
Posts: 16
Joined: Sat Aug 25, 2012 3:28 pm

Re: SNMPv3 EngineID uniqueness issue

Sun Oct 02, 2022 7:41 pm

Since this is the first google hit for "mikrotik snmp v3 issue", posting my notes ;)

Stepped on this problem when configuring an old version of PRTG monitoring software. Added one Mikrotik device with fw 7.5, using snmp v3 with MD5/DES. So far no issues.

Then I tried to add another Mikrotik with fw v6.49.6, and it did not work - monitoring software reported "firewall or authentication" problems. Tried all available cypher combinations, different length keys - nothing. I see that monitoring server is receiving replies from Mikrotik, but somehow the answers are not decoded. At the same time, vendor's PRTG SNMP tester works fine! Monitoring with SNMP v1 also works fine.

Then I saw this post above, checked engine ID fields on both Mikrotiks - they were set to "". So I set engine ID = 12345678 on failing Mikrotik, and monitoring started to work.

Who is online

Users browsing this forum: adrianmartin16, almdandi, Amazon [Bot], marekm, pants6000 and 67 guests