SNMPv3 tests that are in an unknown state unexpectedly
When troubleshooting SNMPv3 tests that are in an unknown state unexpectedly, the following information should help you get started.
Please review https://kaseya.zendesk.com/entries/94073587 and determine if turning off SNMP query optimization resolves the issue
A limitation of monitoring multiple SNMPv3 devices by the same poller (DGE or DGE-X) is that each individual SNMPv3 device will require a unique engineID. There is currently no reliable way to monitor two SNMPv3 devices that share an engineid due to the nature of the "handshake" and how SNMPv3 encryption works. A symptom of this is that one or more of the devices tests that share the same engineid will start to time out because results are then thrown away/rejected. Please review the engineID across all SNMPv3 devices provisioned on a specific DGE(-X) to make sure they are all unique.
Please note failover/redundant devices tend to share engineIDs.
Assigning an engineID based on the MAC address is recommended. For LINUX servers using the net-snmp agent, setting 'engineIDType 3' may accomplish this.
Confirm that one of the tests' OID responds to an snmpget within the Traverse MIB Browser.
- Make note of the OID or copy and paste it from the test settings page
- Navigate to STATUS > DEVICES
- Highlight the device in question by left-clicking the device row (not the hyperlink)
- A gear icon to the right should now be visible
- Left-click the gear icon and select 'Additional Tools'
- Click on 'go' under SNMP MIB Browser
- Paste the OID and into the OID field and select 'Get' as the operation. Click Go to confirm a result is retrieved
Please review the system' time settings on the SNMPv3 device to make sure it is accurate
Please review the device's system utilization or if any SNMP "low priority" configuration may be in place. This would be more relevant, but not limited to servers. If the SNMPv3 device may be having low system resources, SNMP queries may be ignored or slow to respond, leading to tests timing out.
Unfortunately, Traverse's java library/stack only supports AES-128.
All versions of Traverse