Spectrum discards SNMPv3 responses even with correct EngineID
Article ID: 262000
Updated On:
Products
Issue/Introduction
We are having an issue with 1 device that is working with CA Performance Manager, but the same device is failing SNMPv3 with Spectrum.
We have verified that the EngineID conforms with the RFC standards of
As per RFC, the engineID should have only hexadecimal values ranging from 0 to F's and should follow a standard with a minimum of 5 octets and maximum of 12 octets.
Under TCPDump we can see that Spectrum initiates a Get-Request and the device responds with a Get-Response and then Spectrum will immediately send a REPORT 1.3.6.1.6.3.15.1.1.4 (usmStatsUnknownEngineIDs).
Why is this device not working under Spectrum but is working with Performance Manager and how can we fix this?
Environment
Release : 21.2.x / 22.2.x
Spectrum Core SNMPv3
Cause
When the device responded to the Spectrum Get-Request with the Get-Response the device was setting the Reportable Flag as seen in a tcpdump opened under wireshark.
As mentioned in RFC 3412 regarding the Reportable Message Flag
The reportableFlag is a secondary aid in determining whether a Report PDU MUST be sent. It is only used in cases where the PDU portion of a message cannot be decoded, due to, for example, an incorrect encryption key. If the PDU can be decoded, the PDU type forms the basis for decisions on sending Report PDUs.
Resolution
We have requested the vendor not to set the Reportable Flag when it responds to an SNMPv3 Get-Request as when the Reportable Flag is set then Spectrum must respond back with a Report PDU.
Performance Manager is not affected because they currently do not support SNMPv3 Informs.
The vendor has patched their firmware to not send the Reportable Flag and all is working fine in Spectrum now.
Feedback
