T.R | Title | User | Personal Name | Date | Lines |
---|
4703.1 | Looks like a bug - can you QAR this ? | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Thu Mar 18 1993 11:37 | 12 |
| Geert,
> The status now shows me: state: enabled
> substate: shutdown in progress
> error condition: management protocol error
> I don't think this situation is normal. Is this a known problem?
No - this is not a normal situation. Can you try doing a show
on the bridge (which is not up) and while waiting hit control/c ?
/keith
|
4703.2 | results of commands requested. | BACHUS::FOLENS | | Mon Mar 22 1993 11:44 | 22 |
| Without ctrl-c:
MCC> show bridge .mcc_bridges.bet112_116 all char
Bridge DECTOWN:.mcc_bridges.bet112_116
AT 22-MAR-1993 17:33:48 Characteristics
Cannot communicate with target
With ctrl-c:
MCC> show bridge .mcc_bridges.bet112_116 all char
Bridge DECTOWN:.mcc_bridges.bet112_116
AT 22-MAR-1993 17:34:21 Characteristics
Management protocol error
-Geert-
p.s. Maybe thi s problem is solved with v1.3 of ELM AM?
|
4703.3 | Looks like bridge is not reachable | QUIVER::HAROKOPUS | | Mon Mar 22 1993 12:40 | 6 |
| I don't understand what the problem is here. The first show
command indicates that you can't communicate with this bridge.
Have you been able to determine why the bridge is not reachable?
I doubt it is an ELM issue.
-Bob
|
4703.4 | Intended behaviour? | BACHUS::FOLENS | | Tue Mar 23 1993 03:04 | 8 |
|
Please read .0 carefully. It is not normal you cannot disable an alarm
rule for an entity that is not reachable or is this intended behaviour?
I added the info in .2 because it was requested in .1.
-Geert-
|
4703.5 | Need to understand how Alarm rule is disabled | QUIVER::HAROKOPUS | | Tue Mar 23 1993 10:26 | 9 |
| OOps sorry. I didn't read .0 too carefully. I'm not sure why
you can't disable the Alarm rule. Can one of the Alarms developers
explain the process that occurs when an Alarm rule is disabled?
That way I can better understand if the Bridge AM is doing anything
to prevent the rule from being disabled.
Thanks,
Bob
|
4703.6 | Enter - stage right | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Tue Mar 23 1993 13:00 | 42 |
| re: .2
> Without ctrl-c:
>
> MCC> show bridge .mcc_bridges.bet112_116 all char
>
> Bridge DECTOWN:.mcc_bridges.bet112_116
> AT 22-MAR-1993 17:33:48 Characteristics
>
> Cannot communicate with target
A show to a bridge has timed out (or something) - the command
completed with an exception (cannot communicate with target) returned.
>
> With ctrl-c:
> MCC> show bridge .mcc_bridges.bet112_116 all char
>
> Bridge DECTOWN:.mcc_bridges.bet112_116
> AT 22-MAR-1993 17:34:21 Characteristics
>
> Management protocol error
The same show to the same bridge .. but this time before the timeout
occured, Control/C was pressed. The FCL issues a Thread Alert Termination
which is caught by the Bridge AM. The Bridge AM should cancel the request
and return the MCC_S_ALERT_TERMREQ status. But instead, somehow the
Thread Alert Termination is causing the 'Management protocol error'
exception to pop out.
When you disable an Alarm rule, the same Thread Alert Termination is sent
to the Management Module (MM) which Alarms is calling .. again, in this case
the Bridge AM. The proper protocol is not followed. Alarms is expecting
the MM to return the MCC_S_ALERT_TERMREQ status, but instead is getting
an exception.
Because the MCC_S_ALERT_TERMREQ status is not being returned to Alarms, Alarms
has no idea that the Rule is shutting down. The bug appears to be in the
Bridge AM, or the MCC ethernet sub-system.
/keith
|
4703.7 | Will look ay Bridge AM | QUIVER::HAROKOPUS | | Wed Mar 24 1993 11:56 | 6 |
| Thanks Keith,
I'll take a look at how the Bridge AM handles the thread termination
request.
-Bob
|
4703.8 | I'd be glad to help ... | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Thu Mar 25 1993 08:21 | 7 |
| >> Thanks Keith,
>> I'll take a look at how the Bridge AM handles the thread termination
>> request.
Sure thing - let me know if I can be of any help
/keith
|