In the case of SNMPv2 traps, the replacement token %id% currently shows only the enterprise id. For example,sending a ciscoIfExtensionMIBNotifications will yield
Log Message
Notice that the sub-id 0 is disregarded by OpenNMS. One of our customer's use case is to parse the Log Message field of an event for the full trap oid instead where full trap oid is enterprise id + sub-id + specific id. Many vendors but not all adopt the convention where sub-id = 0. For examples,
Since OpenNMS %id% token is only displaying the enterprise id and there's no other way to display the full trap id without manually hardcoding most of the event files, customer is not able to make use of parsing the logmsg field as parsing the full trap id is required. It would be helpful for customer if one additional token can be added to distinguish between the more generic %id% token and the more SNMPv2 specific full trap oid token.
Acceptance / Success Criteria
None
Attachments
1
Lucidchart Diagrams
Activity
Show:
Chandra Gorantla October 26, 2021 at 2:18 PM
Edited
. Since this is a feature, we intentionally not back-porting the changes to foundation-2021
I reverted the PR that got merged in foundation-2019.
This currently exist only release-28 and beyond.
Please check with to know what build customer is getting. We can provide what is necessary.
In the case of SNMPv2 traps, the replacement token %id% currently shows only the enterprise id. For example,sending a ciscoIfExtensionMIBNotifications will yield
Log Message
Notice that the sub-id 0 is disregarded by OpenNMS. One of our customer's use case is to parse the Log Message field of an event for the full trap oid instead where full trap oid is enterprise id + sub-id + specific id. Many vendors but not all adopt the convention where sub-id = 0. For examples,
Fortigate - https://oidref.com/1.3.6.1.4.1.12356.101.2.0.301
F5 - http://oidref.com/1.3.6.1.4.1.3375.2.4.0.12
Cisco - http://oidref.com/1.3.6.1.4.1.9.9.276.0.1
Since OpenNMS %id% token is only displaying the enterprise id and there's no other way to display the full trap id without manually hardcoding most of the event files, customer is not able to make use of parsing the logmsg field as parsing the full trap id is required. It would be helpful for customer if one additional token can be added to distinguish between the more generic %id% token and the more SNMPv2 specific full trap oid token.