Spectrum discards SNMPv3 responses even with correct EngineID
search cancel

Spectrum discards SNMPv3 responses even with correct EngineID


Article ID: 262000


Updated On:


CA Spectrum DX NetOps


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 (usmStatsUnknownEngineIDs).


Why is this device not working under Spectrum but is working with Performance Manager and how can we fix this?



Release : 21.2.x / 22.2.x

Spectrum Core  SNMPv3


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.


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.