SNMP traps in MIBs are to generic

Wriswith01 · ‎12-23-2011

Hi,

I am working in a network with many cisco devices. Recently we changed to a new monitoring system which works heavily with SNMP traps. For most traps I was able to find the MIBs, but some traps that are being sent have a more specific OID than the ones defined in the mibs.

Here is an example:

This is the trap that I receive:

enterprise:.1.3.6.1.2.1.14.16 generic:6 specific:13 from a cisco VPN device

These traps are defined in the mib on the Cisco website:

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.2.1.14.16#oidContent

.iso(1).org(3).dod(6).internet(1).mgmnt(2)

mib-2(1)

ospf(14)

ospfTrap(16)

ospfTrapControl(1)

ospfTraps(2)

ospfTrapConformance(3)

So as far as I can see the official Cisco documentation only goes up to 1.3.6.1.2.1.14.16 generic 3.

My question: Is the Cisco documentation outdated, or shouldn't my Cisco device be sending these traps?

Dan Frey · ‎12-23-2011

Are you sure your new NMS tool is displaying the entire trap and associated varbinds? OSPF-TRAP-MIB looks like this on my system when sent from an isr router.

2011/12/23 - 19:04:32 TRAP: 0.0 from 0.0.0.0

UDP: [192.168.0.1]:49798->[192.168.0.125] - isr, TRAP2, SNMP v2c, community public

EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (450248779) 52 days, 2:41:27.79

SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfTraps.16

OSPF-MIB::ospfRouterId = IpAddress: 192.168.99.1

OSPF-MIB::ospfIfIpAddress = IpAddress: 192.168.0.1

OSPF-MIB::ospfAddressLessIf = INTEGER: 0

OSPF-MIB::ospfIfState = INTEGER: down(1)

To get more info look at OSPF-TRAP-MIB::ospfTraps.16 and figure out what is 16 in the OSPF-TRAP-MIB.traps file.

$ more OSPF-TRAP-MIB.traps

### THIS FILE WAS GENERATED BY MIB2SCHEMA

enterprise 1.3.6.1.2.1.14.16.2

16 ospfIfStateChange

1 ospfVirtIfStateChange

2 ospfNbrStateChange

3 ospfVirtNbrStateChange

4 ospfIfConfigError

5 ospfVirtIfConfigError

6 ospfIfAuthFailure

7 ospfVirtIfAuthFailure

8 ospfIfRxBadPacket

9 ospfVirtIfRxBadPacket

10 ospfTxRetransmit

11 ospfVirtIfTxRetransmit

12 ospfOriginateLsa

13 ospfMaxAgeLsa

14 ospfLsdbOverflow

15 ospfLsdbApproachingOverflow

16 = ospfIfStateChange. Find this in the OSPF-TRAPS-MIB.my file.

ospfIfStateChange NOTIFICATION-TYPE

OBJECTS { ospfRouterId, -- The originator of the trap

ospfIfIpAddress,

ospfAddressLessIf,

ospfIfState -- The new state

}

STATUS current

DESCRIPTION

"An ospfIfStateChange trap signifies that there

has been a change in the state of a non-virtual

OSPF interface. This trap should be generated

when the interface state regresses (e.g., goes

from Dr to Down) or progresses to a terminal

state (i.e., Point-to-Point, DR Other, Dr, or

Backup)."

::= { ospfTraps 16 }

The OID has 4 varbinds of

ospfRouterId

ospfIfIpAddress,

ospfAddressLessIf,

ospfIfState

Make sure the trap received has all the associated varbinds.

Dan

Wriswith01 · ‎12-27-2011

Well the traps are generated very rarely and I don't have direct access to the device. But I can post the all the information my system gives me.

Trap .1.3.6.1.2.1.14.16.1.6.12

Received unformatted enterprise event (enterprise:.1.3.6.1.2.1.14.16 generic:6 specific:12). 5 args: .1.3.6.1.2.1.14.1.1="176327880"

.1.3.6.1.2.1.14.4.1.1="0"

.1.3.6.1.2.1.14.4.1.2="3"

.1.3.6.1.2.1.14.4.1.3="176327784"

.1.3.6.1.2.1.14.4.1.4="176327880"

Trap .1.3.6.1.2.1.14.16.1.6.13:

Received unformatted enterprise event (enterprise:.1.3.6.1.2.1.14.16 generic:6 specific:13). 5 args: .1.3.6.1.2.1.14.1.1="176327880"

.1.3.6.1.2.1.14.4.1.1="1"

.1.3.6.1.2.1.14.4.1.2="3"

.1.3.6.1.2.1.14.4.1.3="176327784"

.1.3.6.1.2.1.14.4.1.4="176327880"