Conference azur::mcc

I'm note sure what information you are looking for.
You can set up DECmcc alarm rules on any attribute in the MIBs
supported by the devices you listed.  Are you asking for a list
of attributes?  Or sample rules?

-- Erik

    Erik,
    
    Basically, I was looking for a list of attirbutes and a sample rule for
    each.  I have written some alarms for a few decstation/200's using
    ifoperstatus, *, down for instance, and I was looking for a listing of
    like attributes for the CISCO and VITALINK MIBs.  I can look at certain
    attributes via the operations pull down menu, but based on the snmp
    access module documentation, I feel that there are some attributes that
    don't show up or that are referred to by specific 'names' , like
    ifoperstatus that I can't see.
    
    thanks,
    
    Michael

A real short-cut, but kinda messy if you've never browsed through your
dictionary:
If you want the real low-down on ANY objects 'alarm-able' attributes, crnak
up DAP on your MCC system and look at the class definition.   MCC will
effectively 'spill its guts' for you about object.

What kind of RULEs you want to create is a matter of POLICY.   In a happier
world, we'd have all sorts of 'out of the box' default alarm rules that you
could easily set up.   Failing that, you will have to rely on either the
kindness of strangers or your own resourcefullness to come up with some
interesting alarm rules.


/doug

P.S.

Do you have the Vitalink MIB?
If so, then when/how did you get it?

/doug

P.P.S.

Be VERY careful when you're in your dictionary.... One false move and you can
really hurt yourself.  [this is experience talking... ]

Here's a not-so-dangerous approach I remembered:

If you've run a vendor's MIB through the "Rahu-tool" MIB translator, then just
scan to the bottom of the <insert-mib-name-here>.LIS file that it generates.  
The listing file has an indented description of the MSL mappings of the SNMP
MIB structre.  

All of the info you need is there.

That's *much* safer than tip-toeing through your Dictionary!

/.doug

    Thanks Doug...
    
    I'll poke through the infamous *.lis file for the CISCO and VITALINK.
    If you can think of anything else drop me a line.  I think that this
    type of information is most valuable in trying to build the proper
    alarm settings.
    
    Michael

    There needs to be a clearing house for alarms that are useful.  Perhaps
    it's the job of the netmgt applications group - but it's clear that for
    MCC to be a network management system - it has to have the added value
    of alarm rules for each technology.  It probably belongs in the
    definition of an access module - ie, defining the appropriate rules for
    different standard kinds of situations.  It's pretty obvious that we
    could sell MCC better, if our sales people could talk about the alarms
    that were available for cisco and vitalink equipment.  Finding
    customers with the knowledge of what alarms they would like takes too
    much effort for a general sales force.
    
    bill
    
    

Hi,

I seem to be experiencing some additional problems with the TCP/IP SNMP access 
module.  I have created the alarm rule listed below:

create mcc 0 alarms rule oper_status_rtja41 -
  expression	= (change_of (snmp rtja41 interface 1 ifoperstatus, *,down) ,-
  		   at every 00:05:00, by password "xxxxx") ,-
  procedure           = mcc_common:mcc_alarms_mail_alarm.com ,-
  exception handler   = mcc_common:mcc_alarms_mail_exception.com ,-
  parameter 	      = "node::accnt" ,-
  category            = "RTJA41 Interface 1 Problems" ,-
  description         = "RTJA41 Interface 1 Token Ring 4Mbps Down" ,-
  queue               = "sys$batch" ,-
  preceived severity  = critical,-
  in domain	      = cus.domain

With the above syntax as specified in the TCP/IP manual and in speaking with
multiple people the above should work.  But, alas it doesn't.

If I remove the ,by password syntax and place this command on the enable command

mcc> enable mcc 0 alarms rule oper_status_rtja41,by password "xxxxx",in domain x

the alarm gets enabled properly but, if I issue a 

mcc> show mcc 0 alarms rule oper_status_rtja41 all status, in domain x

I reveive an Error Condition of "No response from entity."

Yet via the command line:

MCC> show snmp rtja41 interface 1 ifoperstatus ,by pass "xxxxx"

I get ifoperstatus = up....

It seems that I can't get around the community name of default "PUBLIC" no
what I place in the ,by password command.  I ahve a customer that has a
number of CISCO routers and are pleased at this time with the DECmcc director.
But, I don't want to chance anything so if there is anyone out there that can be
of any assitance please let me know...

    When you create the rule *with* the 'by password' in the rule
    expression are you returned any error messages?  I had thought that
    Alarms would not allow you to put passwords in the expression - and
    thus in the MIR (security reasons).
    
    /keith

Michael,

	The by password qualifier is not valid when creating an alarm rule
(for the reason that Keith pointed out, we don't want passwords stored in 
the MIR).  It is valid on the enable directive.  However, when I try it here
using the latest base level I encounter a "software logic error".  I've entered
a qar in the mcc_internal qar database (#2684) to flag this problem.

	You appear to be seeing a different problem, which is, that alarms may
not be passing the by password qualifier through to the TCP/IP SNMP AM.  This 
should work.  If it's not working, then it's a bug and it needs to get fixed.

	Thanks for pointing out this problem.

Dan

Dan,

As I previously stated in my earlier note, I don't use the ',by password' on the
Alarm Rule, when I attempted to perform this task I receive a "by password not
valid on the create" error message, which is goodness for all the right reasons,
like not having the password as part of the MIR.

I use the ,by password on the ENABLE MCC 0 ALARM RULE .... ,in domain ...,by pass
and it MCC accepts it.  Next the following events take place:

1.) The Alarm rule fails and the Station goes 'RED' alarm because it is set up
    as a critical alarm
2.) A mail message is sent to the account I specify in the Alarm Rule

3.) Contained in the mail response is the 'BY PASSWORD XXX' which I assume, the
    password is being passed correctly, albeit it may be passing the wrong
    password, meaning, one different than the one I specify.
4.) The error on the Alarm Rule is 'Unable to communicate with Entity'

5.) When I issue the show snmp entity all attibutes, in domain ... , by password
    private_password, I can see everything.

I hope that this is enough information to help whomever correct the problem.
The situation is getting warm with the customer.  If anyone has the fix or
knows where to find the answer please contact me as soon as possible.  I will
monitor this notesfile to check for responses.  Thanks for the help thusfar.

Michael

  Michael,

  I have found a few problems with Enabling a Rule with 'by password' 
  but for the v1.2 release.  You are using v1.1 .. right?  The
  v1.2 symptom is the 'software logic error' when you try to enable the
  rule.

  We have a v1.1 test system, and will continue to try and find out why
  you are getting an error.

  /keith

    Keith,
    
    Thanks.  Yes, I am using v1.1.  If you find anything please let me
    know.  I'd like to circumvent any customer concerns if you get my
    meaning.
    
    Michael

Hello,

Has anyone made any progress on the TCP/IP, MCC 1.1 situation with the ALARM
rule problem.  I'd like to get things going or talk to someone about creating
a work around.

Any information would be appreciated.

thanks,

Michael

Michael,

	I've tested this on the V1.1 system here in our lab and it seems to
work.

	You can verify that the password you specify on the enable command
is being passed to the SNMP AM and on to the agent by setting the following 
logical to dump SNMP Packets to the screen,

$ define MCC_TCPIP_AM_LOG 60	! Dump snmp packets to screen

I've included a small part of a sample run below, the password that's being
passed in the PDU that the SNMP AM is sending to the agent is shown in this
dump.  Please try this on your customer's system and see what happens.  If
the password you specify on the enable directive is not being passed through,
you'll see "public" as the password, instead of "vitalink" as shown below.

$ manage/ent
DECmcc (V1.1.0)

MCC> enable mcc 0 alarm rule myunix_sysuptime,by password "vitalink"
                                                              |
MCC 0 ALARMS RULE myunix_sysuptime                            |
AT  9-APR-1992 12:39:53                                       |
                                                              |   
Normal operation has begun.                                   |   Shows password
MCC>                                                          |  was passed by
                                                              |  alarms to snmp
                                                              |  AM.
        << Sent SNMP message: >>                              |
                                                              |
[  16 ] (                                                     |
    [  2 ] 00000000                                           | 
    [  4 ]     76 69 74 61 6c 69 6e 6b  -- vitalink <---------
    [  0 ] (
        [  2 ] 00000001
        [  2 ] 00000000
        [  2 ] 00000000
        [  16 ] (
            [  16 ] (
                [  6 ]                 01 00 00 00 03 00 00 00 06 00 00 00 01 00
 00 00 02 00 00 00
                01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00
                [  5 ]
                )
            [  16 ] (
                [  6 ]                 01 00 00 00 03 00 00 00 06 00 00 00 01 00
 00 00 02 00 00 00
                01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00
                [  5 ]
                )
            [  16 ] (
                [  6 ]                 01 00 00 00 03 00 00 00 06 00 00 00 01 00
 00 00 02 00 00 00
                01 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00

	.
	.   Much stuff deleted ...
	.

    Hi,
    
    I enabled the trace on my station and the result is:
    
    <<Sent SNMP Message>>
    
    [16]......
    
    [4]		70 75 62 6c 69 63 -- public
    
    
    Information on the TCP/IP access module
    
    Component Version: V1.1.1
    
    Let me know....
    
    Michael

	Would you please provide more info (send me mail if you'd rather).
I'd like to see a session log showing the enable alarms command as well
as the actual dump of the snmp pdu's (just the first packet).

	Thanks,

	Dan

Dan,

Here is the trace that you asked for:

MCC> enable mcc 0 alarms rule oper_status_rtja04,in domain .adams -
_MCC> ,by password "customer_password"

MCC 0 ALARMS RULE oper_status_rtja04
AT 15-APR-1992 11:51:46

Normal operation has begun.
MCC>


        << Sent SNMP message: >>

[  16 ] (
    [  2 ] 00000000
    [  4 ]     70 75 62 6c 69 63  -- public
    [  0 ] (
        [  2 ] 00000001
        [  2 ] 00000000
        [  2 ] 00000000
        [  16 ] (
            [  16 ] (
                [  6 ]                 01 00 00 00 03 00 00 00 06 00 00 00 01 00
 00 00 02 00 00 00
                01 00 00 00 01 00 00 

                01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00
                [  5 ]
                )
            [  16 ] (
                [  6 ]                 01 00 00 00 03 00 00 00 06 00 00 00 01 00
 00 00 02 00 00 00
                01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00
                [  5 ]
                )
            [  16 ] (
                [  6 ]                 01 00 00 00 03 00 00 00 06 00 00 00 01 00
 00 00 02 00 00 00
                01 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00
                [  5 ]
                )
            )
        )
    )

        << Sent SNMP message: >>


If there is any additional information that you need, please let me know....

	...let's make sure we're running same stuff, here's what I've got,

Neenee> dir sys$library:mcc_tcpip_am.exe,mcc_alarms_fm.exe

Directory SYS$COMMON:[SYSLIB]

MCC_TCPIP_AM.EXE;20	174  12-NOV-1991 15:40:00.38
MCC_ALARMS_FM.EXE;1     585  28-FEB-1991 09:59:23.81

Total of 2 files, 759 blocks.
Neenee>

	Are you running the same?

Dan

Dan,

Sorry for the long delay again.  Hopefully we can resolve this problem quickly.
Below is a directory listing and a anal/image of the executables that you
specified in your response.  I hope this helps....


Michael

Directory SYS$COMMON:[SYSLIB]


MCC_ALARMS_FM.EXE;1
                        590  16-APR-1991 09:36:07.00

 Image Identification Information

                image name: "MCC_ALARMS_FM"
                image file identification: "DECMCC V1.1"
                link date/time: 28-FEB-1991 09:58:51.96

MCC_TCPIP_AM.EXE;2      174  12-NOV-1991 15:40:00.38

 Image Identification Information

                image name: "MCC_TCPIP_AM"
                image file identification: "MCCTCPIP V1.1-0"
                link date/time: 12-NOV-1991 15:40:09.26
                linker identification: "05-05"

Well here is a followup on this problem.  Customer was getting very 
frustrated, so logged a call with the CSC.  After looking over the 
previous notes tried to duplicate the problem on my work station.  I
created  rule similar to that in .14, using the log bit verified this
rule worked fine.   I then dialed into the customer system, looking at 
the rule they are trying to enable found theirs uses a "CHANGE_OF" 
expression.  Back on my system I created a similar rule, it failed to 
pass the password specified on the enable command.

Summary:
Specifing a password with an alarm on an SNMP entity which contains a 
'change_of' expression DOES NOT WORK!!  Just for grins, I tried it on
T1.2.7, it does not work on the EFT release either.

Can this be QARed?  I know the customer will want his current probelm 
elevated, so it would be very nice to be able to tell them that it will 
be fixed in the next release.

As a work around to their current situation will give the the following
expression:

  Expression = (snmp xxxx interface 1 ifoperstatus = down, at every 00:05:00)

instead of:

  Expression = ( change_of (snmp xxxx interface 1 ifoperstatus, *, down),-
	 at every 00:05:00)

Hopefully this will work for them.
Steve Woestemeyer
CSC/CS - Network Support Team

    okay, I am *REAL* sorry to have been away so long, but shipping
    the kit has been top priority.
    
    So here is the scoop...I have **TEMPORARILY** enherited getting the
    alarms module to SSB; what I found was:
    
    	softare logic error
    		This has been fixed, you can now pass password information
    		when doing a create domain xxx rule yyy, auto enable=yes
    	passwords on change_of
    		This has been found and fixed, the password information
    		was not being passed to the access module for processing
    
    A number of other problems have also been corrected, but are unrelated
    to this topic. Currently the change_of has *NO* workaround to this
    problem. I has been reported and the person working on the CLD is
    considering taking the fixes I have an creating a V1.1 patch for
    the customer if they can not wait until V1.2. 
    
    Jill
    

    
    Changing the CHANGE-OF rule for SNMP entities to
    (SNMP cisco1 interface 1 ifoperstatus 1 = down) with the use of "by
    password" on the enable command has worked. 
    
    Glad to see that it will be fixed in v1.2.  
    
    When will v1.2 be available for customers?  there are a lot of v1.2
    features that we are looking for/waiting for?
    
    Marti