Idea ID: 1657957

The 'Source Object' field in SNMP traps should be updated from 'none' to one of the traps varbinds

Status : Under Consideration
Under Consideration
See status update history
over 3 years ago

As of now, in SNMP Traps, the 'Source Object' field is always "none" - except for a few standard traps (CiscoLinkDown/Up, SnmpLinkDown/Up, SnmpLinkUp, SnmpAuthenticationFailure, CiscoWarmStart).

Also, when the default name of any of those SNMP Traps is changed, the field 'Source Object' becomes 'none' always.

It would be utmost helpful to be able to control the 'Source Object' field of a trap by using one of the trap's varbind values.

 

One prominent use case:

Interface traps for unmanaged interface will be suppressed/dropped by NNMi _only_ when the 'Source Object' is filled. 

  • For the standard SnmpLinkDown/Up trap, varbind-1 (1.3.6.1.2.1.2.2.1.1.[index]) is used to populate the 'Source Object' field with the interface name from NNMi database.
    Traps for unmanaged interfaces will not be presented.
     
  • For any other than above listed standard traps, the 'Source Object' field will be left 'none', even if the trap carries the same varbind-1 (1.3.6.1.2.1.2.2.1.1.[index]).
    Traps for both, managed and unmanaged interfaces will be presented - easily causing confusion and additional work. 

 

This is a request that came and comes up time and again, especially in relation to interface traps.

 

Labels:

Device Support – Monitoring
NW Technology
Resilience
User Experience
  • Thank you very much for the help. It is a good starting to solve a problem that we see daily in NNMi.
    In case of Huawei switches, the traps asociated to interfaces contains the varbind OID .1.3.6.1.2.1.47.1.1.1.1.7.x with the name of interface, and is important asociate those notification to the correct sub-element (ie. Interface).
    Best regards...
  • Thank you very much for the help. It is a good starting to solve a problem that we see daily in NNMi.

    In case of Huawei switches, the traps asociated to interfaces contains the varbind OID .1.3.6.1.2.1.47.1.1.1.1.7.x with the name of interface, and is important asociate those notification to the correct sub-element (ie. Interface).

  • The fix described in the comment on 2019-04-04 14:30 is available in later patches of all NNMi Versions afaik:

    NNMi 10.1x Patch 9, NNMi 10.20 Patch 8, NNMi 10.3x Patch 6, NNMi 10.4x Patch 3, NNMi 10.5x Patch 2, NNMi 2018.05.P02, NNMi 2018.11.P01, NNMi 2019.05, and later.

    Add the following property (in any of *.properties file in $NNM_PROPS).
    nnm.internal.event.trapsWithIfIndexSource=<trap oid>,<trapOid>

    For example,
    nnm.internal.event.trapsWithIfIndexSource=.1.2.3.4.5,.1.2.3.4.5.6

    If the traps .1.2.3.4.5 or .1.2.3.4.5.6 contain a vabind with varbind oid , .1.3.6.1.2.1.2.2.1.1.x (x is any suffix ) , the corresponding varbind value is taken as ifIndex value.

  • Is this idea was shelved in the trunk of memories ?.

  • For NNMi10.42 there is a hotfix available which allows to configure an additional property.
    This allows for configuring traps to be searched if varbind .1.3.6.1.2.1.2.2.1.1.[index] is included, and if yes, then use its value to populate the 'Source Object' field.

    This property is also included since NNMi10.10 Patch9 , NNMi10.20 Patch8, NNMi10.30 Patch6.