Conference azur::mcc

5865.0. "decmcc and private traps" by COMICS::MISTRY () Fri Feb 11 1994 06:16

Hi,

I found this stars article, could someone please point me in the direction of
the patch.

Bipin



[DECmcc] Notification doesn't work on some private traps reception.


********************   CAUTION:  FOR INTERNAL USE ONLY   *********************
*                                                                            *
*      THIS INFORMATION IS FOR USE BY DIGITAL EQUIPMENT CORP. AND ITS        *
*      EMPLOYEES ONLY.  PLEASE USE EXTREME CARE IF YOU MUST DISCUSS ANY      *
*      PART OF THIS INFORMATION WITH ANYONE WHO IS NOT A DIGITAL EMPLOYEE.   *
*                                                                            *
******************************************************************************

PROBLEM/SOLUTION ARTICLE OUTLINE

-------------------------------------------------------------------------------
                                                         
PRODUCT: Polycenter Framework ( DECmcc Director ) V1.3
         Polycenter Network Mangager 200 ( DECmcc BMS ) V1.3
         Polycenter Network Mangager 400 ( DECmcc EMS ) V2.3
         VMS 5.4-X, 5.5-X
         Ultrix 4.X

DATE:   09-SEP-1993



SYMPTOMS/PROBLEM:

When receiving enterpriseSpecific SNMP traps whose variable list is not an
exact match of Dictionary definitions :
        1/  GETEVENT requests work BUT return a warning message.
        2/  NOTIFICATION requests DON'T work.
        

ANALYSIS:

Here is an example with a private trap named chipPortDown received from 
Chipcom hubs. The ASN1 source file describes the trap as follows :

    chipPortDown TRAP-TYPE
            ENTERPRISE      chipcom
            VARIABLES       { olPortSlotIndex,
                              olPortIndex,
                              olPortAdminState,
                              olPortStatus,
                              olEnetStatsPortLastSrcAddr}
            DESCRIPTION
                    "A chipPortDown trap indicates that a port's status
                    has changed to an error condition.  Multiple chipPortDown
                    traps may be sent if the port's status changes from
                    one error to another."
            ::= 11

After the compilation, all the variables are defined as arguments of the 
event chipPortDown.

In a first case, the variable 'olEnetStatsPortLastSrcAddr' is not set on 
the Chipcom hub : thus, it is not sent in the trap PDU by the remote agent. 
Issuing the following command :
        MCC>getevent snmp * chipcom chipportdown

the following event is received ( note the warning message -----+
                                                                |
    SNMP LOCAL_NS:.snmp.etoile1 chipcom                         |
    AT 1993-04-30-08:42:43.637I----- CONFIGURATION EVENTS       v
    Received event had less object ids than were defined in the dictionary:
    Event: chipPortDown
    A chipPortDown trap was received:
                                 enterprise = "1.3.6.1.4.1.49"
                                 agent-addr = 16.188.48.108
                               generic-trap = enterpriseSpecific
                              specific-trap = 11
                                 time-stamp = 62451
                            olPortSlotIndex = 3
                                olPortIndex = 1
                           olPortAdminState = enabled
                               olPortStatus = linkFailure

but a notification request as :
    MCC>notify domain .demo_openlink_v13 entity list=(snmp * chipcom),
      events=(any events)
never completes !

In a second case, after setting the 'olEnetStatsPortLastSrcAddr' variable on
the Chipcom hub, the same notification request completes successfully as
follows :

    %%%%%%%%%%%%%% Event, 1993-04-30-09:04:37. %%%%%%%%%%%%%% [1]
    Domain: LOCAL_NS:.demo_openlink_v13                   Severity:
    Indeterminate
    Notification Entity: SNMP LOCAL_NS:.snmp.etoile1 chipcom
    Event Source: SNMP LOCAL_NS:.snmp.etoile1 chipcom
    Event: chipPortDown
    A chipPortDown trap was received:
                                 enterprise = "1.3.6.1.4.1.49"
                                 agent-addr = 16.188.48.108
                               generic-trap = enterpriseSpecific
                              specific-trap = 11
                                 time-stamp = 4507
                            olPortSlotIndex = 4
                                olPortIndex = 2
                           olPortAdminState = disabled
                               olPortStatus = security_breach
                 olEnetStatsPortLastSrcAddr = %X08002b047f37

So it means that when the number of variables associated with a trap doesn't
exactly match the number expected by the AM ( defined in the dictionary ),
the AM associates to the event a response which is something other than
"success" and in this case the Notification FM drops the event.


SOLUTION:

The Notification FM needs to be fixed to handle this properly. In the 
meantime, a workaround has been set in the SNMP AM : it always returns 
success status, not depending on the fact that less or more variables might 
have been returned by the agent. This new image is available through CSC on 
both Ultrix and VMS.

>This new image is available through CSC on 
>both Ultrix and VMS.

Ha, ha, ha - the old joke again. I'm getting tired of those Stars 
articles. Does anybody care to supply the CSCs with those patches before 
publishing articles???  And CSC does NOT only mean Colorado!

*Robert (CSC Munich)