| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| 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 |
I have a customer who has approx 50+ DECswitch 900MX/EFs distributed
amongst 10+ DEChub 900MS. They use these 900MX/EFs as PE devices to
connect dedicated High powered SUN workstations. All 900 MS Backplanes
with 900EFs are interconnected to (2) Gigaswitch/FDDI This environment has
been extremely stable for well over 6 months.
Recently in the last 10 Days the customer has been getting via DECMCC --
Unsolicted resets messages from a large number of 900EFs (between 15-20).
HUBwatch has verified that indeed the bridges did reset. The only
thing that has changed in this last 10 days is that both Gigaswitches
have had the ARP Server functionality enabled on them.
What is a unsolicted reset of a 900EF and what could cause this ???
I have cross posted this note in the Gigaswitch notes conference
900MX/EF are running V1.4 firmware
900MS are running v3.1 MAM code
Gigaswitch is running V2.2 firmware
Any help would be appreciated
-Charlie
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2413.1 | <-------RE: Unsolicited resets | NETCAD::BATTERSBY | Thu Jun 22 1995 13:46 | 25 | |
>What is a unsolicted reset of a 900EF and what could cause this ???
Charlie an unsolicited reset is basically a reset caused by a fatal
error, or another way of putting it is it's a crash.
>900MX/EF are running V1.4 firmware
>900MS are running v3.1 MAM code
>Gigaswitch is running V2.2 firmware
Any idea of the customer's future intention of upgrading firmware
to wave 3 baselevel?
There were some bugs fixed in the 900MX/EF V1.4 code that may or
may not be related to your customers problem. Without alot of evidence
from you customer's site as to network config details, counters,
error logs, etc. etc., it would dificult in guessing as to what is going
wrong at your customer's site.
I don't have any idea what the ARP server functionality being enabled
is doing to the MX's/EF's (I don't even know what it is), so you will
have to get a definitive answer in the Gigaswitch conference.
However it does seem curious that there appears to be a coincident
reaction ( unsolicited resets) to the action of enabling this function
in the Gigaswitches.
Bob
| |||||
| 2413.2 | important upgrade procedures | NETCAD::CURRIER | Thu Jun 22 1995 14:35 | 17 | |
When you customer upgrades the hubs...
1st upgrade at least 1 hubwatch station
2nd upgrade the management agent
3rd upgrade the devices
VERY 1st OF ALL read the release notes that come with the agent code
DO NOT use old hubwatch to manage new mam & devices
DO NOT use new hubwatch to manage old mam & devices
mam & devices MUST be BOTH new or BOTH old .. NO mixing
| |||||
| 2413.3 | No upgrades have been performed | NCMAIL::SCHEID | Thu Jun 22 1995 14:58 | 5 | |
No upgrades have been performed ... everything has been running at the
current released level of firmware ...
| |||||
| 2413.4 | NPSS::WADE | Network Systems Support | Thu Jun 22 1995 15:01 | 10 | |
Take a look at the DEFBA error logs: From the DEChub console
redirect to each slot containing a DEFBA and look at the error log
entries. The 1st piece of information to get is the "Error code" field.
There are known reset problems that have been fixed in DEFBA 1.5.
Bill Wade
Network Product Support
| |||||