[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

4364.0. "Logging topologyChange" by NNTPD::"[email protected]" (Feynman Lo) Thu Apr 17 1997 00:25

A customer is trying to log the topologyChange events
encountered in their network. They tried to do this
by monitoring DECswitch 900EF with Multichassis Manager  
but it is only logging the counters but no time stamps.
They got more than 10 DECswitch 900EFs and also 
bridges from other vendors. They are using Digital's DEChub
900 modules to form their coporate backbone network.

I think they can only log the events by trapping the 
topologyChange trap as defined in Bridge MIB(rfc-1493).

When I take a look at the mib file it stated that the
topologyChange  and newRoot are optional only.

Is it really possible to do so by trapping those events in
DECswitch 900EFs?
They are using Polycenter Netview as a managemnet station.

Rgds,
- feynman




[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name
DateLines
4364.1Use RMON Alarms and Events via Netview.NETCAD::GALLAGHERThu Apr 17 1997 11:0222
The DECswitch 900EF doesn't support the optional bridge MIB traps.
(No, I don't know why.)

If, by "traping those events" you mean to use RMON Alarms and Events,
then yes, it is possible.  You'll need firmware version 1.7 or greater.
(I'm not sure there is a "greater".)

You can alarm on the bridge MIB (rfc1493) dot1dStpTimeSinceTopologyChange
object.  Since it's type is "TimeTicks" you should create a rising
delta of 1 alarm so that a trap and/or log is generated each time the
value of the object changes.

      alarmVariable                dot1dStpTimeSinceTopologyChange.0
      alarmSampleType              deltaValue
      alarmStartupAlarm            risingOrFallingAlarm
      alarmRisingThreshold         1
      alarmFallingThreshold        0
      alarmRisingEventIndex        [the event index]
      alarmFallingEventIndex       0

						-Shawn
4364.2NETCAD::GALLAGHERThu Apr 17 1997 11:064
    p.s.  I *think* they only need to trap this object on the root bridge.
          They may want to install it on another switch in case the
    	  root fails.  My point is, I don't think they need to install
    	  it on each DECswitch900EF on their corporate backbone.
4364.3Succeed....but why alarmValue=100?NNTPD::"[email protected]"Feynman LoFri Apr 18 1997 09:5918
Thanks for the pretty advice. I have succeeded trapping
the topology change to Netview.

But why when I query the value of alarmValue, it is
shown up as equal to 100?

I find difficulty in this case because the variable I
am checking is itselt of type TimeTicks. I set
the alarmInterval=1 and alarmRisingThreshold=1.
But why don't the alarmValue equal to 1?

Could you please kindly enlighten me?

-feynman



[Posted by WWW Notes gateway]
4364.4Why not an alarmValue=100 ? ;-)NETCAD::GALLAGHERFri Apr 18 1997 12:0722
|But why when I query the value of alarmValue, it is
|shown up as equal to 100?
|
|I find difficulty in this case because the variable I
|am checking is itselt of type TimeTicks. I set
|the alarmInterval=1 and alarmRisingThreshold=1.
|But why don't the alarmValue equal to 1?

The object you're polling, TopologyChange, is a TimeTicks type.
Although it's in 100dth of a second, the bridge spanning tree
runs in seconds.  So a value of 100 indicates 1 second since the
last spanning tree topology change.  If you had set an 'absolute'
alarm, the alarmValue would be the actual value of TopologyChange.
Since you set a 'delta' alarm, the alarmValue is the difference
of TopologyChange from one poll to another - 1 second in this
case.  (Never mind the fact that an 'absolute' alarm wouldn't 
work for you in this case.)

I'm not sure why you expect an alarmValue of 1.

Does this help?
					-Shawn