SNMPv3 trap standard compliance FAIL !

[DonL]

Hello, 

We have traps being sent from the Meraki dashboard to a trap receiver for a variety of conditions. 

Every trap received from the Dashboard can have a combination of some Engine ID and any number of EngineBoots and Enginetime values ???
Any valid SNMPv3 trap from a reliable "Source" should have an EngineID and proper elapsed time and consistent EngineBoots value from trap to trap. ( Or Poll to Poll ) 

Trap coming from the Meraki Dashboard seem to have an EngineID that might be associated with what ever Dashboard is active that the trap was sent from BUT the EngineBoots and Enginetime may be that of the Device against which the trap *would* be asserted - WRONG !!!!!

The V3 data should either be ALL from the Device or ALL from the Dashboard - Pick one... Or why bother Pretending to adhere to the SNMPv3  standard when the receiver has to Ignore the Security mechanism were trying to implement.

Will this ever be corrected ? 
Is it worth opening an actual case ? 

Thanks, 

[GreenMan]

Meraki provides options to have SNMP handled via the  Dashboard and/or the Device (concurrently).

A Support case would indeed be the way to go, in the first place to establish if what you're seeing would be expected, from the Meraki side.

[DonL]

Hello Mr. Green 🙂 

This would / should Never be expected - the Standard state how it should work 🙂 
This is Not working as defined in the IETF standard- 
https://datatracker.ietf.org/doc/rfc3414/

I'll open a case then. 
- thank you 
Don

[PhilipDAth]

Hi Don.

Meraki SNMP support is not great.  It has never been great.  It is what I would describe as passable rather than compliant.  I don't ever seen this changing.

Monitoring is best done using applications that natively support the Meraki API (check yours - many do).  IMHO, Meraki regard SNMP as a legacy monitoring option, and it gets no love as a result.

[DonL]

Indeed Phillip, 

Sad but probably true...