| 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
|
| .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
|