Issues
Add full trapoid for Snmp V1
Description
Acceptance / Success Criteria
Sending SNMP traps like :
snmptrap -v1 -c public 127.0.0.1 .1.3.6.1.4.1.9.9.276 127.0.0.1 6 1 '' should result in trapoid as .1.3.6.1.4.1.9.9.276.0.1
Lucidchart Diagrams
Details
Details
Assignee
Reporter
Story Points
Sprint
Fix versions
Affects versions
Priority
MajorPagerDuty
PagerDuty
Activity
Jeff Gehlbach July 13, 2022 at 3:21 PM
This work was originally intended for back-port to Meridian 2019 and later, but the team deemed the changes too risky. Therefore it went only into the release-28.x branch, meaning it's in Horizon from 28.1.1 and in Meridian from 2022.1.0.
JianYet October 4, 2021 at 10:12 PM
Tested field %trapoid% across SNMP V1, V2 and V3 traps. All results show the corresponding values and are within the spec.
Chandra Gorantla September 28, 2021 at 10:17 PM
Shreyance Rai September 27, 2021 at 4:44 PMEdited
Here is the communication and response from the customer
Do you expect to use one field which is the %trapoid% in logmsg for parsing across all SNMP versions? - _*Yes*_
In the case of SNMPv1, do you expect the full trap oid to show up in %trapoid%? _*Yes*_ If so, as SNMPv1 or SNMPv2 format? SNMP v2 Format.
In the case of SNMPv1, the conversion to SNMPv2 would follow what was laid out by David in his email which depends on the generic type. Below is a snapshot of that conversion. Are you okay with that?
OK ; would it be possible to share the results of your internal testing showing the value of %trapoid% for a sample SNMP v1, v2 and v3 trap?
As part of NMS-13422 , we have added support for trapoid when sub-id(0) is part of oid. But this doesn't work for V1.
For SNMP V1, we need to consider following and create full trapoid.
Conversion defined in RFC2576
…
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)',
the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of
the SNMPv1 enterprise parameter and two additional sub-
identifiers, '0', and the SNMPv1 specific-trap parameter.
(3) If the SNMPv1 generic-trap parameter is not '
enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL
be the corresponding trap as defined in section 2 of RFC1907
[12]:
generic-trap parameter snmpTrapOID.0
====================== =============
0 1.3.6.1.6.3.1.1.5.1 (coldStart)
1 1.3.6.1.6.3.1.1.5.2 (warmStart)
2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)
The %trapoid% parameter will be pulled directly from snmpTrapOID parameter in the SNMP v2c/v3 Notification and will be created from an SNMP v1 Trap PDU using the algorithm defined in the above RFC. This will uniquely identify Trap based events.