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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

3419.0. "RMON questions and DS900EF support?" by SNOFS1::63496::CHIUANDREW () Wed Apr 03 1996 04:45

    Hi,
    
    I am new to RMON, but customer would like to get more information our
    DEChub products in RMON area:
    
    After looking at notes 2575, it seems to me that most of our
    Repeater900 modules support alarm and event groups, and they are also
    configured (by default) to send out traps for 9 alarms namely,
    icomEnvironTotalFailures, ... erptrMauTotalMediaunvailable. 
    
    My questions are:
    
    1) Can I make use of these alarms/events to 'detect' port failure (e.g.
    UTP cable fault, port fault, etc..), since looking at the Rising or
    Falling traps, they tell me the alarmindex, alarmvariable,
    alarmsampletype, alarmvalue, alarmfallingthreshold. But I still do not
    understand what they tell me?
    
    
    2) Could we change the default values of the alarmfallingthreshold and
    alarmrisingthreshold for those pre-defined alarms/events?
    
    3) MAM and repeaters module support 20 alarms, 32 events and 64 log
    entries, is there any document, describle what are they? Are they
    sequenced from 1-20/1-32/1-64?
    
    4) With DECswitch900EF firmware V1.6, what are the supported RMON
    groups on DECswitch900EF? What is the support MAM verions for
    DECswitch900EF V1.6? What about HUBwatch?
    
    5) Is DECswitch900EF firmware V1.6 available now?
    
    thanks for any help/idea/comments!
    
    Andrew Chiu - Network services sydney
T.RTitleUserPersonal
Name
DateLines
3419.1NETCAD::GALLAGHERWed Apr 03 1996 13:1988
Hello,

>    After looking at notes 2575, it seems to me that most of our
>    Repeater900 modules support alarm and event groups, and they are also
>    configured (by default) to send out traps for 9 alarms namely,
>    icomEnvironTotalFailures, ... erptrMauTotalMediaunvailable. 
 
Amazingly, this is still true.
   
>    1) Can I make use of these alarms/events to 'detect' port failure (e.g.
>    UTP cable fault, port fault, etc..), since looking at the Rising or
>    Falling traps, they tell me the alarmindex, alarmvariable,
>    alarmsampletype, alarmvalue, alarmfallingthreshold. But I still do not
>    understand what they tell me?
 
The defaults alarms and events allow you the detect port failures.
If I were writing an *generic* RMON trap catcher application I'd use this 
information to display something like:

	RMON Rising Alarm
	The value of <alarmVariable - i.e. erptrMauMediaUnavailable.4 
        (1.3.6..blah)> rose to the value of <alarmValue - i.e. 2>

If I were writing a non-generic application for, say, ClearVISN (et. al.)
I might use this information to display something like:

	Hey, someone just attached to/detached from port 4 on 
	repeater 16.21.1.128.

(And this is one of the many reasons why I don't write management 
applications.)
 
>    2) Could we change the default values of the alarmfallingthreshold and
>    alarmrisingthreshold for those pre-defined alarms/events?
 
Yes.  You must delete the default and create a new alarm/event.  (This
is specified in RFC1757 [the RMON spec].) 
  
>    3) MAM and repeaters module support 20 alarms, 32 events and 64 log
>    entries, is there any document, describe what are they? Are they
>    sequenced from 1-20/1-32/1-64?
 
Yes, they are sequence starting at one.

To clarify (hopefully), there's room for 20 alarms.  We happen to use
9 of the for some defaults that we think are useful.  This leaves you
11 for things you think are useful.  And you can delete the 9 defaults
if you think our choices for defaults are whacked.

Ditto for events.  The device will hold 32.  We use some for defaults.
You're free to add and delete,

Log entries are read-only.  They capture the result of events.  The 64 most
recent are kept.
   
>    4) With DECswitch900EF firmware V1.6, what are the supported RMON
>    groups on DECswitch900EF? What is the support MAM verions for
>    DECswitch900EF V1.6? What about HUBwatch?

Alarms, Events, Ethernet statistics, and History.  Those 20, 32, 64 numbers
might change for the DECswitch.  

So far, no default alarms or events are used in the DECswitch.  Users will
have to configure their own.

RMON Statistics and History is, by default, enabled on all Ethernet ports.
History is kept on all ports at two rates:  a fast poll rate of 30 seconds,
and a slow poll rate of 300 seconds.

Statistics and history do not affect switching performance.

If you want full RMON, you can purchase a firmware upgrade that supports
turning any of your Ethernet switch ports into an RMON probe port.

   
>    5) Is DECswitch900EF firmware V1.6 available now?
 
No, soon.


I didn't answer the following questions:

>                                What is the support MAM verions for
>    DECswitch900EF V1.6? What about HUBwatch?

Maybe someone else can help you with these questions.

							-Shawn
3419.2DECswitch 900EF will have RMON support soon, I hear...NETCAD::BATTERSBYDon't use time/words carelesslyWed Apr 03 1996 13:2419
    > 4) With DECswitch900EF firmware V1.6, what are the supported RMON
    > groups on DECswitch900EF? What is the support MAM verions for
    > DECswitch900EF V1.6? What about HUBwatch?
         
    I believe the initial supported groups for the DECswitch 900EF will be 
    the 4 basic groups, that is stats, history, alarms and events. I'm not
    aware of what the MAM versions numbers would be or the HUBwatch rev,
    except to presume that it will probably be in the next release I would 
    think.
    
    > 5) Is DECswitch900EF firmware V1.6 available now?
    
    Soon I hear, but I'm not aware of an exact date, and as Tom Hood
    would say, us worker bees in the engineering groups here don't
    speculate on specific dates but rather defer these matters to our
    Product Management. I think Jack Forrest might be the contact for
    RMON info.
    
    Bob
3419.3<--- oops sorry for the notes collision... :-)NETCAD::BATTERSBYDon't use time/words carelesslyWed Apr 03 1996 13:291
    
3419.4Thanks, but do we get objects from dechub 900 mibs?SNOFS1::63496::CHIUANDREWWed Apr 03 1996 22:4818
    re .1/.2
    
    Thanks Shawn and Bob for your quick/clear answers!
    
    One more thing, I still do not have a clear picture is:
    
    When you say MAM supports 20 alarms, and 7 is defined by default, does
    it mean we can define our own alarms starting from number 8 for objects
    define in the DEChub900 MAM mibs (I mean the following mibs)?
    dec-hub900-chassis-v2-0.mib 
    dec-hub900-common-v2-0.mib
    dec-hub900-hubmgr-v1-1.mib
    
    I would think same token can be applied to other 900 modules, is it
    correct?
    
    thanks again!
    Andrew Chiu - Network services Sydney
3419.5You can alarm on any INTEGER object in the device's MIB(s).NETCAD::GALLAGHERWed Apr 03 1996 23:4336
Hi Andrew,

>    When you say MAM supports 20 alarms, and 7 is defined by default, does
>    it mean we can define our own alarms starting from number 8 for objects
>    define in the DEChub900 MAM mibs (I mean the following mibs)?
>    dec-hub900-chassis-v2-0.mib 
>    dec-hub900-common-v2-0.mib
>    dec-hub900-hubmgr-v1-1.mib
 
(I think the MAM has 9 defaults alarms, leaving 11 for other uses - but
to answer your real question...)

Yes, if you choose.  You could also define 11 additional alarms with
indices 10, 20, 42, 100, 300, 301, 302, 303, 304, 305, 306.  The point
is that you have 11 - you can make the index whatever you want - up to
the value 32K.  (Should be up to 64K, but there's a bug.)

And yes, you can define alarms on any INTEGER-like object in the MAM's MIB.  
(For repeaters, you can define alarms on any INTEGER-like object in the
repeater's MIB.)

Also, just to nit-pick:

    - The dec-hub900-hubmgr-v1-1.mib is now obsolete.  The objects in this 
      MIB just weren't useful.
   
    - The MAM supports some other MIBs related to token ring that aren't
      in your list.
   
>    I would think same token can be applied to other 900 modules, is it
>    correct?

Correct.

						Regards,
						-Shawn