| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 453.1 | | NSSG::R_SPENCE | Nets don't fail me now... | Fri Nov 02 1990 17:59 | 4 |
| Is there supposed to be a backtranslation directory for the SNMP stuff
as well?
s/rob
|
| 453.2 | The bulb lights! | CLAUDI::PETERS | | Mon Nov 05 1990 09:39 | 2 |
| I agreed absolutely with .0! If these and other interface problems
aren't fixed DECmcc will fail to be used. /Claudia
|
| 453.3 | DECelms V1.0/DECmcc BMS V1.0 Alarm Evidence | TAZBOY::ZIGLER | Tom Zigler, DTN 432-7541 | Mon Nov 05 1990 12:14 | 39 |
| Here are the MCC alarm exceptions written to the alarm log file at the
customer site, seemingly pointing to a DECelms V1.0/DECmcc BMS V1.0
(SSB) interoperability problem (referenced in (1) in .0). DECelms
never failed whenever any of the below MCC alarms fired:
**** Exception occurred in rule MCC 0 ALARMS RULE plantfacbroken at 1-NOV-1990 13:35:08.67 ****
Rule name: MCC 0 ALARMS RULE plantfacbroken
Occurred at: 1-NOV-1990 13:35:08.67
Category: Device State Changing
Description: Bridge Plantfac Device State Changed
Expression: (change_of (BRIDGE .MCC_BRIDGE.PLANTFAC device state,*,*), at every = 00:05:00)
Exception: Cannot communicate with target
**** Exception occurred in rule MCC 0 ALARMS RULE 800TOPRMbroken at 1-NOV-1990 13:55:22.35 ****
Rule name: MCC 0 ALARMS RULE 800TOPRMbroken
Occurred at: 1-NOV-1990 13:55:22.35
Category: Device State Changing
Description: Bridge 800TOPRM Device State Changed
Expression: (change_of (BRIDGE .MCC_BRIDGE.800TOPRM device state,*,*), at every = 00:05:00)
Exception: The requested operation cannot be completed
%MCC-E-PROTOCOLINUSE, protocol is in use and not available.
**** Exception occurred in rule MCC 0 ALARMS RULE EC1TOTCPbroken at 2-NOV-1990 14:00:28.04 ****
Rule name: MCC 0 ALARMS RULE EC1TOTCPbroken
Occurred at: 2-NOV-1990 14:00:28.04
Category: Device State Changing
Description: Bridge EC1TOTCP Device State Changed
Expression: (change_of (BRIDGE .MCC_BRIDGE.EC1TOTCP device state,*,*), at every = 00:05:00)
Exception: The requested operation cannot be completed
%MCC-E-TRANSMITERROR, error trying to transmit a packet
%SYSTEM-F-DEVINACT, device inactive
|
| 453.4 | Bridge Errors explained... | WLYWLD::BRIENEN | DECmcc Bridge|Station Management. | Mon Nov 05 1990 17:42 | 53 |
| RE: DECelms V1.0 and DECmcc BMS interoperability
------------------------------------------------
We've been in contact with Tom, and here's a summary of what's
been determined thus far:
1. The test that resulted in these errors was run for 26 consecutive
hours, with 40 bridge rules firing once every five minutes.
In addition, DECelms was running its POLLER. At this point we
believe (not totally sure) that default Polling values were taken
for the test (i.e. DECelms was polling every bridge as fast as
the system allowed...).
2. A total of 17 DECmcc bridge alarm exceptions were logged during
this period, distributed as follows:
A) 10 Protocol-in-Use errors. Eight occurred to the SAME BRIDGE
consecutively (every 5 minutes) for a 35 minute period starting
at around 2pm. Note: the customer determined that DECelms
also generates this type of error running by itself, apparently
when the BML and POLLER are competing for the same bridge.
B) 4 Device Inactive errors. Two back-to-back, with all four in a
15 minute period. We typically see this error when a port device
is being reset by the driver while being driven hard. We don't
consider this a big problem.
C) 3 Cannot Communicate errors. Many possible reasons, one of which
is a management request dropped by the bridge while trying to
service another management request at the same time. Since we are
already doing retries here, there's not much else we can do.
So about the Protocol-in-Use errors
-----------------------------------
DECmcc's Ethernet Access (MCC_EA) routines return immediately in the
case of external protocol-in-use (or protocol/address-pair in use)
conflicts. Note that the MCC_EA routines coordinate access to the
driver by protocol/address/port-id using locks (i.e. Protocol-in-Use
errors don't occur between parts of DECmcc using MCC_EA routines).
The DECmcc V1.0 Bridge AM simply returns this MCC_EA error to the caller.
Change for DECmcc V1.1 EFT
--------------------------
For DECmcc V1.1 EFT, we have modified the Bridge AM to do retries when
receiving a protocol-in-use error from the MCC_EA routines. This should
increase the possibility of actually acquiring the protocol/address-pair
(thus dramatically reducing this problem RE: DECelms).
We will investigate adding this retry capability to the MCC_EA routines
later (if necessary, by DECmcc V1.1 FCS).
|
| 453.5 | More Test Results | TAZBOY::ZIGLER | Tom Zigler, DTN 432-7541 | Thu Nov 08 1990 11:48 | 29 |
| Here are the results of another recent test at the customer site:
1) Stopped DECelms V1.0 completely
2) Enabled DECmcc BMS V1.0 (SSB) 5 minute polling to 40 DEC LAN Bridges
which resulted in no bogus DECmcc BMS alarms the entire day.
3) Invoked DECelms, enabled the background poller, and received bogus
DECmcc BMS alarm exception messages "protocol in use". Attempted to
talk to the bridge with DECelms and could not because of "protocol in
use" conflict. We then turned off the DECelms background poller.
(Note: Listener was never running).
4) Disabled the DECmcc BMS alarm rule for that bridge and again
attempted to talk to the bridge with DECelms, but could not because of
"protocol in use" conflict again.
5) Exited DECmcc BMS completely. Only then could we successfully
talk to the bridge again with DECelms using SHOW commands.
Therefore, even with DECelms background poller and listener turned OFF,
we seem to have an interoperability problem still with DECelms with just
SHOW commands. My customer is performing a comparison between DECelms
V1.0 and DECmcc BMS V1.0 to evaluate the possibility of NOT using
DECelms to talk to the DEC LAN Bridge 100, 150, and 200s.
Comments? Please advise.
\Thanks in Advance
|