SevOne NMS provides trap revisions - one, three, and four. The Cluster Manager > Cluster Settings tab > Alerts subtab, enables you to select which trap revision to use. If you change the trap revision you will need to update how your fault management system receives traps from SevOne NMS.
Revision One traps provide the following fields.
s1TrapHistoryThresholdR1Severity
s1TrapHistoryThresholdR1Action
s1TrapHistoryThresholdR1Type
s1TrapHistoryThresholdR1GmtTime
s1TrapHistoryThresholdR1UserName
s1TrapHistoryThresholdR1MessageText
s1TrapHistoryThresholdR1PeerName
s1TrapHistoryThresholdR1PeerId
s1TrapHistoryThresholdR1PeerIp
s1TrapHistoryThresholdR1DeviceName
s1TrapHistoryThresholdR1DeviceId
s1TrapHistoryThresholdR1DeviceIp
s1TrapHistoryThresholdR2ThresholdName
s1TrapHistoryThresholdR2ThresholdDesc
s1TrapHistoryThresholdR2DeviceGroupID
s1TrapHistoryThresholdR2DeviceGroupName
s1TrapHistoryThresholdR2ObjectGroupID
s1TrapHistoryThresholdR2ObjectGroupName
s1TrapHistoryThresholdR2DeviceAltName
s1TrapHistoryThresholdR1PluginName
s1TrapHistoryThresholdR1PluginId
s1TrapHistoryThresholdR1PluginDescription
s1TrapHistoryThresholdR1ObjectName
s1TrapHistoryThresholdR1ObjectId
s1TrapHistoryThresholdR1ObjectDescription
s1TrapHistoryThresholdR1IndicatorName
s1TrapHistoryThresholdR1IndicatorId
s1TrapHistoryThresholdR1IndicatorDescription
s1TrapHistoryThresholdR2ConditionID
s1TrapHistoryThresholdR2ConditionType
s1TrapHistoryThresholdR2ConditionValue
s1TrapHistoryThresholdR2ComparisonValue
s1TrapHistoryThresholdR2ConditionUnits
s1TrapHistoryThresholdR2ConditionAggregation
s1TrapHistoryThresholdR2ConditionTimeframe
Revision Three traps provide the fields listed above in addition to the following fields.
s1TrapHistoryThresholdR1PeerIp and s1TrapHistoryThresholdR1DeviceIp are always blank when using Revision Three traps.
s1TrapHistoryThresholdR3PeerAddress
s1TrapHistoryThresholdR3DeviceAddress
s1TrapHistoryThresholdR3PolicyID
s1TrapHistoryThresholdR3ThresholdID
s1TrapHistoryThresholdR3ThresholdDescription
Revision Four traps has removed the following fields from the new sevoneTrapNotificationThresholdRevision4. By doing this, SNMP/Other traps can be sent from SevOne NMS with fewer varbinds so that the sent traps have a lower chance of exceeding the network interface MTU.
s1TrapHistoryThresholdR1Index
s1TrapHistoryThresholdR1PeerId
s1TrapHistoryThresholdR3PeerAddress
s1TrapHistoryThresholdR2DeviceAltName
s1TrapHistoryThresholdR1PluginDescription
s1TrapHistoryThresholdR1IndicatorDescription
s1TrapHistoryThresholdR2ConditionID
s1TrapHistoryThresholdR2ConditionType
s1TrapHistoryThresholdR2ConditionValue
s1TrapHistoryThresholdR2ComparisonValue
s1TrapHistoryThresholdR2ConditionUnits
s1TrapHistoryThresholdR2ConditionAggregation
s1TrapHistoryThresholdR2ConditionTimeframe
For the Flow traps, the following fields have been removed from the new sevoneTrapNotificationFlowThresholdRevision2. By doing this, Flow traps can be sent from SevOne NMS with fewer varbinds so that the sent traps have a lower chance of exceeding the network interface MTU.
s1TrapHistoryThresholdR1PeerId
s1TrapHistoryThresholdR3PeerAddress
s1TrapHistoryThresholdR2DeviceAltName
s1TrapHistoryThresholdR1PluginDescription
s1TrapHistoryThresholdR1IndicatorDescription
s1TrapHistoryThresholdR2ConditionID
s1TrapHistoryThresholdR2ConditionType
s1TrapHistoryThresholdR2ConditionValue
s1TrapHistoryThresholdR2ComparisonValue
s1TrapHistoryThresholdR2ConditionAggregation
s1TrapHistoryThresholdR2ConditionTimeframe
sevoneTrapHistoryFlowThresholdR1ConditionElementId