[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference taec::temip

Title:Telecom. Management Information Platform conference
Moderator:TAEC::LAVILLAT
Created:Fri Mar 08 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:725
Total number of notes:2431

674.0. "SNMP AM's mapping of traps to OSI Alarms" by 45862::BOND () Mon Jan 20 1997 18:54

T.RTitleUserPersonal
Name
DateLines
674.1Few more suggestions/requestsCHEFS::THORP_AANDREW THORPWed Feb 05 1997 10:4040
Hi all,

I've been working with Chris on this, and have a few more related
suggestions/requests for mapping SNMP traps to OSI alarms in TeMIP :-

   o) At the moment the SNMP AM maps an alarm to the SNMP object with the
      same IP address as the agent address contained in the SNMP trap PDU.
      It would be much better if this could be overridden via a trap variable
      specifying the managed object (in the same way severity, additional
      text and notification id are handled at the moment), e.g. :-
         MANAGED-OBJECT: trapManagedObject
      where the trap variable trapManagedObject is set to say
         snmp blobb
      or
         reference network
      This would also allow us to map traps to logical entities as well as
      just machines. As the agent address has been dropped from the V2 trap PDU,
      does anyone know how the SNMP AM maps V2 traps to managed objects ?
      Version 3.1.0 of TCP/IP SNMP AM Use doesn't seem to mention anything
      about this.

   o) 99 % of all traps received by the SNMP AM on our systems will be
      enterprise specific traps. At the moment these have a fixed probable
      cause and event type, and as such these fields will provide no management
      information to operators. If these too could be overridden as detailed
      above, this would be very useful, e.g.:-
         EVENT-TYPE: trapEventType
         PROBABLE-CAUSE: trapProbableCause
      where the trap variable trapEventType is set to CommunicationsAlarm and
      the trap variable trapProbableCause is set to TrunkCardProblem.

The main reason we need this type of functionality is that the customer has
requested we use SNMP as the protocol between TeMIP and lower level managers -
we are not using the SNMP AM to manage a router, we are using it as an SNMP
I/F to TeMIP.

Andy

DTN: 7 830 3741

674.2TAEC::HOUALWed Feb 05 1997 13:537
Hello,

You should send such suggestions to the TeMIP
support and maintenance team (TAEC::TEMIP_SUPP)

Best regards,
Beatrice.
674.3a few comments...TAEC::ANDREASSONCogito, ergo amThu Feb 06 1997 10:4432
.0:

>>When the SNMP AM maps Enterprise specific traps to OSI Alarms, why does
>>it display the number of the trap rather than the name in the specific
>>problem field?  In the MSL it seems that the name is known so why does
>>it appear as a number when displayed by TeMIP?

The SpecificProblems event argument is a user defined enumeration, which you
can define as you like. By default it's defined as Unsigned32, that's why
you see just a number. Please look in osi_types.ms file for more info. 
Further, there is no reason a priori that the SNMP macro identifier ('trap
name') should be used in place of the OSI enumeration. Another way to put
it, it would not be in line with the OSI recommendations if the TeMIP Event
*name* were used for mapping the SpecificProblems field.

.1:

Regarding SNMPv2, TeMIP currently supports the SMIv2 (RFC 1902), but not the
SNMPv2c protocol. Given the current status of the various post-SNMPv1
protocol drafts, plus the continuous discussions in the Internet community
about standardizing the missing aspects of the SNMP management framework, it
does not make sense today to implement one of the variants.


Regarding the other requirements for mapping SNMP trap fields into OSI Alarm
fields, we intend to address these in a coming version. Please contact the
TeMIP Product Manager, Philippe Gervaise @VBO if you need more information.


Regards,

Sigge Andreasson/SISB Telecom Engineering