Highlighted
Absent Member.. Absent Member..
Absent Member..
152 views

Trap payload gets "consumed" in trap engine

Hey Experts!

I've loaded CISCO-MAC-NOTIFICATION-MIB and its incidents into NNMi (v10.10) and I'm already obtainning MacFlap incidents as expected but...

1) When I configure message format to include the mac-address contained in 1.3.6.1.4.1.9.9.215.1.3.3.0 it shows "6K" instead of "001ebd364b1b".

2) Again in message formating: Regarding the OID 1.3.6.1.4.1.9.9.215.1.3.5.0 returns a "7", is there a way to "resolve" this into ifDesc that the output in the message is Gi1/0/6 instead of "7"?

 

I've collected the following outputs

a) switch logging message

b) wireshark capture @ NNMi

c) nnmtrapdump.ovpl -source 10.161.2.90 -t

d) NNMi Incident Custom Atributes

e) NNMi - Incident message - used $* in message format (output in CSV):

 

Thanks in Advance!

Nuno Marques

 

Outputs:

!!!!!!!!!!!!!!!!! Switch logging:

Dec 2 20:48:14: %MAC_MOVE-SP-4-NOTIF: Host 001e.bd36.4b1b in vlan 2314 is flapping between port Gi1/0/6 and port Po9

 

 

 

!!!!!!!!!!!!!!!!!!!!!!WIRESHARK Capture@NNMi:

Frame 507: 230 bytes on wire (1840 bits), 230 bytes captured (1840 bits) on interface 0

Ethernet II, Src: CiscoInc_ea:89:80 (00:08:7c:ea:89:80), Dst: Vmware_98:0f:2a (00:50:56:98:0f:2a)

Internet Protocol Version 4, Src: 10.161.2.90, Dst: 10.162.7.44

User Datagram Protocol, Src Port: 50868 (50868), Dst Port: 162 (162)

Simple Network Management Protocol

version: v2c (1)

community: ------

data: snmpV2-trap (7)

snmpV2-trap

request-id: 2806754

error-status: noError (0)

error-index: 0

variable-bindings: 7 items

SNMPv2-MIB::sysUpTime.0 (1.3.6.1.2.1.1.3.0): 835577810

Object Name: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0)

Value (Timeticks): 835577810

SNMPv2-MIB::snmpTrapOID.0 (1.3.6.1.6.3.1.1.4.1.0): 1.3.6.1.4.1.9.9.215.2.0.2 (SNMPv2-SMI::enterprises.9.9.215.2.0.2)

Object Name: 1.3.6.1.6.3.1.1.4.1.0 (SNMPv2-MIB::snmpTrapOID.0)

Value (OID): 1.3.6.1.4.1.9.9.215.2.0.2 (SNMPv2-SMI::enterprises.9.9.215.2.0.2)

SNMPv2-SMI::enterprises.9.9.215.1.3.3.0 (1.3.6.1.4.1.9.9.215.1.3.3.0): 001ebd364b1b

Object Name: 1.3.6.1.4.1.9.9.215.1.3.3.0 (SNMPv2-SMI::enterprises.9.9.215.1.3.3.0)

Value (OctetString): 001ebd364b1b

SNMPv2-SMI::enterprises.9.9.215.1.3.4.0 (1.3.6.1.4.1.9.9.215.1.3.4.0):

Object Name: 1.3.6.1.4.1.9.9.215.1.3.4.0 (SNMPv2-SMI::enterprises.9.9.215.1.3.4.0)

Value (Integer32): 2314

SNMPv2-SMI::enterprises.9.9.215.1.3.5.0 (1.3.6.1.4.1.9.9.215.1.3.5.0):

Object Name: 1.3.6.1.4.1.9.9.215.1.3.5.0 (SNMPv2-SMI::enterprises.9.9.215.1.3.5.0)

Value (Integer32): 7

SNMPv2-SMI::enterprises.9.9.215.1.3.6.0 (1.3.6.1.4.1.9.9.215.1.3.6.0):

Object Name: 1.3.6.1.4.1.9.9.215.1.3.6.0 (SNMPv2-SMI::enterprises.9.9.215.1.3.6.0)

Value (Integer32): 6658

SNMPv2-SMI::enterprises.9.9.215.1.3.7.0 (1.3.6.1.4.1.9.9.215.1.3.7.0):

Object Name: 1.3.6.1.4.1.9.9.215.1.3.7.0 (SNMPv2-SMI::enterprises.9.9.215.1.3.7.0)

Value (Integer32): 835588535

 

|||||||||||||||||||||| TRAPDUMP@NNMi

C:\Windows\system32>nnmtrapdump.ovpl -source 10.161.2.90 -t
Trap cmnMacMoveNotification (.1.3.6.1.4.1.9.9.215.2.0.2) at 3 de Dezembro de 2016 20:44:23 GMT from PCPRT9RT01A
Version: SNMPv2c
Varbinds:
state=HAS_VALUE type=TimeTicks oid=.1.3.6.1.2.1.1.3.0 value=844194738
state=HAS_VALUE type=OBJECT IDENTIFIER oid=.1.3.6.1.6.3.1.1.4.1.0 value=.1.3.6.1.4.1.9.9.215.2.0.2
state=HAS_VALUE type=OCTET STRING oid=.1.3.6.1.4.1.9.9.215.1.3.3.0 value=6K
state=HAS_VALUE type=INTEGER oid=.1.3.6.1.4.1.9.9.215.1.3.4.0 value=2314
state=HAS_VALUE type=INTEGER oid=.1.3.6.1.4.1.9.9.215.1.3.5.0 value=7
state=HAS_VALUE type=INTEGER oid=.1.3.6.1.4.1.9.9.215.1.3.6.0 value=6658
state=HAS_VALUE type=INTEGER oid=.1.3.6.1.4.1.9.9.215.1.3.7.0 value=844205463

 

 

 

!!!!!!!!!!!!!!!!!!!!!!!!!!! NNMi - Incident Custom Attributes

.1.3.6.1.4.1.9.9.215.1.3.3.0 (asn_octetstring)

36:4B

.1.3.6.1.4.1.9.9.215.1.3.4.0 (asn_integer)

2314

.1.3.6.1.4.1.9.9.215.1.3.5.0 (asn_integer)

7

.1.3.6.1.4.1.9.9.215.1.3.6.0 (asn_integer)

6658

.1.3.6.1.4.1.9.9.215.1.3.7.0 (asn_integer)

835588535

cia.snmpoid (String)

.1.3.6.1.4.1.9.9.215.2.0.2

cia.address (String)

10.161.2.90

cia.originaladdress (String)

10.161.2.90

cia.securityGroup.name (String)

GS-NETWORK-DC

cia.securityGroup.uuid (String)

377ac8b1-fb80-492d-8297-f1ec62042aed

 

 

 

 

!!!!!!!!!!!!!!!! NNMi - Incident message - used $* in message format (output in CSV):

 

Severity,Priority,Lifecycle State,Last Occurrence Time,Assigned To,Source Node,Source Object,Category,Family,Origin,Correlation Nature,Message,Notes

Major,None,Registered,02-12-2016 20:48:14, ,PCPRT9RT01A,none,Status,Node,SNMP Trap,Symptom,".1.3.6.1.4.1.9.9.215.1.3.3.0: 6K, .1.3.6.1.4.1.9.9.215.1.3.4.0: 2314, .1.3.6.1.4.1.9.9.215.1.3.5.0: 7, .1.3.6.1.4.1.9.9.215.1.3.6.0: 6658, .1.3.6.1.4.1.9.9.215.1.3.7.0: 835588535, cia.snmpoid: .1.3.6.1.4.1.9.9.215.2.0.2, cia.address: 10.161.2.90, cia.originaladdress: 10.161.2.90, cia.securityGroup.name: GS-NETWORK-DC, cia.securityGroup.uuid: 377ac8b1-fb80-492d-8297-f1ec62042aed",

0 Likes
2 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: Trap payload gets "consumed" in trap engine

Hi Nuno,

  The issue with the display of the octetstring can be resolved using the configuration file:

<NnmDataDir>/shared/nnm/conf/nnmvbnosrcenc.conf

Note the header comments:

# This file is used for configuring how particular SNMP trap varbind values of type ASN.1 OCTETSTRING
# are interpreted. The format of the file is a series of trap OID, varbind OID combinations for which
# to always display the value in hex, and not perform the character set conversion of that trap's varbind value
# using the encodings specified in the com.hp.nnm.sourceEncoding JVM property in nms-jboss.properties.
# For trap OID, varbind OID values specified within this file, the value of thevarbind will always be
# displayed as a hex value in the Custom Incident Attribute values on the Incident form.
# This file is only read when the the com.hp.nnm.sourceEncoding JVM system property is uncommented or enabled.
# Changes to this configuration file require a restart of jboss.

  So by adding the line:

.1.3.6.1.4.1.9.9.215.2.0.2  .1.3.6.1.4.1.9.9.215.1.3.3

  this should resolve this problem with the "6k" display.   Note you will need to restart NNMi and also enable the "com.hp.nnm.sourceEncoding" property in the  <NnmDataDir>/shared/nnm/conf/props/nms-jboss.properties file.  If its not already enabled.

  As for the mapping of "7" to ifDescr, this is not possible directly.   If the source object of the trap is being set to the interface ( which I sadly doubt ) you could use the event variable for ifDescr.  But without the mapping the source interface won't be known.  In which case if this is important you can run an action script, get the ifDescr from the DB using sql and the varbind value of 7 to identify the ifIndex of the associated interface, and finally create a new trap and send it back into NNMi for display with a suitable message now reporting the new varbind and ifDescr value it would carry.

  I hope this helps

Dave Y

MicroFocus Support
Viewed the Support tips? Search for "(NNMi) Support Tips" and order by Date to get the list
The views expressed in my contributions are my own and do not necessarily reflect the views and strategy of MicroFocus
If you find this or any post resolves your issue, please be sure to mark it as an accepted solution.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Trap payload gets "consumed" in trap engine

Hi Nuno,

Is there anything else we could help you with on this discussion thread?

If not, would you mind marking the most appropriate post as Accepted Solution so that we could close this discussion thread? 

This is because we are periodically reviewing the Open discussion threads to determine if any help is expected further on the topic. When it is no more the case, the best is to close the discussion thread by marking the most appropriate post as Accepted solution.

Without any answer, I may proceed and mark Dave's answer as Accepted Solution but the best would be for you to do it yourself if no more help is expected here.

All the best

Marie-Noelle

Micro Focus Customer Support

If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.

If you are satisfied with anyone’s response please remember to give them KUDOS and show your appreciation.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.