T.R | Title | User | Personal Name | Date | Lines |
---|
3494.1 | Alarms does not support variants | MOLAR::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Tue Aug 04 1992 14:35 | 8 |
|
Dan,
I believe that the Bridge AM support variants; which operating in LTM
mode would be. Alarms, however, does not support variants which could
be why its not working correctly for you.
/keith
|
3494.2 | No such animal | SLINK::CHILDS | Practice passive aggression. | Tue Aug 04 1992 18:31 | 16 |
| | When using a global alarm rule to determine operating status of
| bridges, alarms do not fire properly for bridges that are configured
| to be LTMs.
| Global alarm is:
| (BRIDGE * DEVICE STATUS <> "OPERATING", AT EVERY 00:05:00)
Two problems here. The first one is that there is no bridge attribute
called Device Status. There is one called Device State, though. But
the second problem is that LTM bridges do not support the Device State
attribute. If you type
MCC> show bridge <LTMid> all attributes
you will see all the valid attributes that you can legally specify for
a bridge acting as a LAN Traffic Monitor.
|
3494.3 | Corrections and restatement: Bridges & LTM | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Thu Aug 06 1992 01:49 | 15 |
| Sorry for the typo and lack of clarity in .0 .
The global rule did use DEVICE STATE <> "OPERATING".
I realize that a bridge, once downline loaded with LTM software, does
not respond the same when polled via the BRIDGE AM.
The problem is that, if you have LTMs on your network (we have 5), and
you wish to use a global alarm rule for BRIDGE, you will get garbage
notification messages with not entity name, one for each LTM.
In addition, the LTM bridge entity is not highlighted. This is a
problem and should be QARed, if it has not been already.
-Dan
|
3494.4 | | SLINK::CHILDS | Ed Childs | Thu Aug 06 1992 14:44 | 9 |
| | The problem is that, if you have LTMs on your network (we have 5), and
| you wish to use a global alarm rule for BRIDGE, you will get garbage
| notification messages with not entity name, one for each LTM.
OK, I can see why a global alarm rule on Device State would be desired.
But, I don't think there is anyway the Bridge AM can be "fixed" to make
this problem go away. I believe the PM (FCL or Iconic Map) is
returning the error "No such attribute." Comments/Clarification from
anyone else?
|
3494.5 | passing back a bad out_e? | POLE::LEMMON | | Thu Aug 06 1992 18:57 | 15 |
| If i understood .4 correct, the out_e returned from the bridge
access module is not correct? That is, the out entity instance
is NULL instead of one of the identifier attributes.
If this is the case I would say the iconic map and fcl will have
difficulty trying to convert it to a string. the error message in
.4 would be comming from the parse routine that does this conversion.
Not much can be done about this though. The generic interface
relies on the management modules to pass arguments across the call
interface correctly. For performance reasons it does not verify
the data.
/jim
|
3494.6 | If the LTM bridge does not return 'Device State' ... | MOLAR::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Fri Aug 07 1992 09:43 | 14 |
|
If the LTM bridge does not return 'Device State', the Alarms FM will
generate an error (something like)
"The entity did not return the specified Attribute"
Which makes sense - would be better if Alarms supported variants though
and indicated this somehow. Add it to the list .. 8)
I'm not sure what Alarms does with this error .. I doubt that it fires
the rule as 'True' .. I think it just records the 'latest' error, and
increments the error count.
/keith
|
3494.7 | Global alarms rule change requested | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Wed Aug 19 1992 00:44 | 9 |
| It would be nice to have the ability to EXCLUDE entities from a global
alarm rule. For example:
(BRIDGE * DEVICE STATE <> "OPERATING", EXCLUDE=(bridge2, bridge5), AT
EVERY 00:10)
This would be great for all global alarm rules. It should be added.
-Dan
|