| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2353.1 | | NETCAD::DOODY | Michael Doody | Wed Jun 07 1995 14:35 | 4 |
| (Q1.) What was the MAM fw version before the upgrade? What is in the
error log (all entries)? What modules are installed in this Hub?
-Mike
|
| 2353.2 | #8 might be the problem :^) | KAOFS::S_HYNDMAN | Ride life's curves | Wed Jun 07 1995 16:10 | 41 |
|
Previous MAM version was 3.1
Modules: Slot 1 Decbridge 900 MX
Slot 3 DECserver 900 TM
Slot 7 Packet Probe 90
Slot 8 DECrepeater 900 TM
Error Log
Entry = 8
Time Stamp = 0 0
Reset Count = 10
Stop Thrash; Cleared Nonvolatile Data
entry = 7
time stamp = 0 1300
reset count = 9
catch V0=07c SR=2000 PC=44d1ce
entry = 6
time stamp = 0 1400
reset count = 8
catch V0=07c SR=2000 PC=41b2ca
entry = 5
time stamp = 0 1300
reset count = 7
catch V0=07c SR=2009 PC=44d1be
entry = 4
time stamp = 0 1300
reset count = 6
catch V0=07c SR=2004 PC=44d1d2
entry = 3
time stamp = 0 0
reset count = 5
catch V0=07c SR=2700 PC=606c0a
Scott
|
| 2353.3 | More info needed | NETCAD::FORINO | | Wed Jun 07 1995 18:20 | 11 |
| What platform are you running the HUBloader from - OSF or Windows?
On Q.2 the messages you report are consistent with what should happen.
Once the load is complete you get a "device is resetting" message since
the device is doing the firmware upgrade. In the meantime the
HUBloader continues to perform SNMP shows to the device to check when
it comes back online. So you'll continue to receive SNMP timeouts
for some time until the device has upgraded itself. I'm not sure
offhand how long it takes the bridge to upgrade.
John
|
| 2353.4 | | KAOFS::S_HYNDMAN | Ride life's curves | Thu Jun 08 1995 10:30 | 9 |
|
I was running HUBloader from Windows.
Should I be logging a call with MCS to replace the bridge or is there a
way to cause the bridge to reset/reboot/bridge?
Scott
|
| 2353.5 | | KERNEL::MCSKEANEP | one bit brain with parity error | Thu Jun 08 1995 11:22 | 7 |
|
The DECbridge will send out a BOOTP request from port 2 (the first AUI
port). Connect this port to a network with a node setup up for BOOTP
and TFTP. Copy the bridge load image to the node and put an entry into
the bootptab file and the bridge should load and recover.
POL.
|
| 2353.6 | BOOTP available | NETCAD::FORINO | | Thu Jun 08 1995 13:31 | 4 |
| Note the TFTP loader provided with the HUBloader also has BOOTP
capabilities. Look at the READ_ME_.TXT and the online help of the
TFTP loader itself for more information.
John
|
| 2353.7 | It lives! | KAOFS::S_HYNDMAN | Ride life's curves | Thu Jun 08 1995 14:39 | 10 |
|
I was able to load the bridge from bootp on unix. I wasn't clear
what to do with the hubloader software.
What file would the bridge request? Should I have configured
"DEFAULT" to point to local file defba150.bin?
Scott
|
| 2353.8 | Yup default for your defbas should be defba150.bin... | NETCAD::BATTERSBY | | Thu Jun 08 1995 15:58 | 9 |
| The bridge doesn't actually ask for a specific file. It simply
asks for a load file when doing a bootp. The server determines what
kind of device is sending the bootp and sends the file defined in
some soft linked file (bootptab?), to point to the default file you
wish to have loaded to any defba's doing a bootp in your lan.
So you have to configure your bootp server to load the image you want
to have loaded to your switches (bridges).
Bob
|
| 2353.9 | Modules take a few minutes to update Flash | NETCAD::DJERBAKA | | Thu Jun 08 1995 17:15 | 8 |
| On the original load attempt, did you give the module plenty of time
to blast the flash with the new image. It sounds like you may have
power cycled before the image was completely written to FPROM.
HUBloader may display the "Device Time Out" for a few minutes, before
it comes back online. Do not Power Cycle during this time.
Paul
|
| 2353.10 | | KAOFS::S_HYNDMAN | Ride life's curves | Fri Jun 09 1995 14:01 | 13 |
|
Paul,
I waited one hour before attempting the a power failure. So I
don't think that was the problem.
Bob,
In DEC Unix I edited the bootptab file and gave it a file name.
However in the NetRider loader part of the Hubloader program I could
not find a way to do this.
Scott
|
| 2353.11 | NETrider functionality | NETCAD::FORINO | | Tue Jun 13 1995 10:44 | 5 |
| The NETrider EZloader give you the BOOTP capability of associating an
IP address to a particular MAC address. You then have to use the
TFTP Server part to do the actual load.
John
|
| 2353.12 | How do you use the TFTP server portion? | KAOFS::S_HYNDMAN | Ride life's curves | Tue Jun 13 1995 13:48 | 11 |
|
John,
I couldn't figure out how to use the TFTP server part. I could see
how you configured the bootp portion, but not the file name for the
bridge. Does the bridge request a specific file name or do you have to
define it some how?
Scott
|
| 2353.13 | Any progress? | NETCAD::FORINO | | Thu Jun 29 1995 10:45 | 3 |
| Has any progress been made against this problem?
John
|
| 2353.14 | | KAOFS::S_HYNDMAN | Ride life's curves | Thu Jun 29 1995 16:38 | 12 |
|
I was contacted off-line regarding the hub. There was no
resolution as it couldn't be duplicated. I have had another hub loose
its configuration after upgrading. However I have been able to upgrade
bridges. I have another round of upgrades next week, so we'll see.
As to the other problem of trying use the TFTP server, I've not
received a response.
Scott
|
| 2353.15 | hubloader reconfiguring switch | GRANPA::DMIGNOGNA | | Thu Sep 28 1995 14:59 | 121 |
| I have experienced the same problem on three HUB900's when down loading dmhub402.bin.
HUBloader reported "Device is Resetting" I waited an additional 1/2 hr. before hitting cancel, and lost contact with the HUB 900 from the FDDI ring. I did have the ability to connect to the DECswitch with HUBwatch but could not connect to the HUB900 agent.
When I went to the HUB 900 location the LCD version was showing as being updated and the
IP addresses were untouched. The DECswitch appeared to have been reset with the ports being configured out the front (ports 2,3,4,5,6 should be out the backplane), and not attached to the thinwire ethernet, which explained the loss of communication from the central location. This scenario occured on three hubs.
I have over twenty hubs needing upgraded and will be trying the newer versions of HUBloader and dmhub404.bin, although I am not holding my breath that it's fixed.
Don,
Hubloader Version 1.0.0
Netrider TFTP server Version 1.0-03
Windows for Workgroups
MS-DOS 6.22
DECpc with Etherworks 3 NIC
Previous MAM was Version 4.0.0
Slot 8 DEFBA-M DECswitch 900EF
Slot 7 DETMM-M DECrepeater 900TM
Slot 6 DSRVZ-M DECserver 900
DEChub 900 MultiSwitch
==============================================================================
Hub900MultiSwitch,DEChub 900 MultiSwitch,HW=F,RO=V1.1.6,SW=V4.0.2
SysUpTime : 00:48:28 4 resets
SNMP Read/Write Community : public
SNMP Trap Addresses : Not Configured
Status of Last Downline Upgrade : 15 days 02:11:07 3 resets
Load Successful
Out-of-Band Management RTS : Disabled
Interface IP Address Subnet Mask Def. Gateway Other Info
--------- ---------- ----------- ------------ ----------
OBM Port Speed 9600 bps
Hub Slot 7 170.115.160.205 255.255.252.0 170.115.160.2 Active
==============================================================================
DEChub 900 MultiSwitch
==============================================================================
DUMP ERROR LOG
Current Reset Count: 4
==============================================================================
Entry = 199
Time Stamp = 0 0
Reset Count = 4
SW V4.0.0 -> V4.0.2 ; Config retained.
Dump another entry [Y]/N?
Entry = 198
Time Stamp = 0 0
Reset Count = 1
SW V3.1.0-> V4.0.0 ; Config retained.
Enter selection number : 3
DECswitch 900EF - slot 8
==============================================================================
DECswitch 900EF, 6-Ethernet/FDDI Switch, HW=v1/2,RO=v0.4,SW=v1.5.0
SysUpTime : 00:32:42 7 resets
SNMP Read/Write Community : public
SNMP Trap Addresses : Not Configured
Status of Last Downline Upgrade : TFTP Write
6 days 03:46:08 29104 resets
Transfer Complete.
BootP : Disabled
Interface IP Address Subnet Mask Def. Gateway Other Info
--------- ---------- ----------- ------------ ----------
In-Band 170.115.160.206 255.255.252.0 170.115.160.2 08-00-2B-B0-D1-2F
OBM Port
IPX switch is disabled
==============================================================================
Enter selection number : 5
DECswitch 900EF - slot 8
==============================================================================
DUMP ERROR LOG
Current Reset Count: 7
==============================================================================
==============================================================================
No more Error Log entries.
==============================================================================
Enter selection : 3
DECrepeater 900TM - slot 7
==============================================================================
DECrepeater 900TM , 32 Port TP Ethernet Rptr SNMP, HW=v3,RO=v01.04,SW=V1.1.0
SysUpTime : 5 days 18:46:36 14 resets
SNMP Read/Write Community : public
SNMP Trap Addresses : Not Configured
Status of Last Downline Upgrade : No Status
In-Band Interface Hardware Address : 08-00-2B-B1-99-C1
In-Band Interface IP Address : 170.115.160.207
In-Band Interface Default Gateway Address : 170.115.160.2
|
| 2353.16 | | NETCAD::DOODY | Michael Doody | Thu Sep 28 1995 17:04 | 31 |
| Don,
Thanks for the detailed problem report. I will try to reproduce the
problem. To help me do this, can you send a description of the
backplane connections? Like, how many lans you have defined, which lans
are the DECswitch ports connected to, which lans are the DECserver
ports connected, the repeater etc.
Also, a description of what was done to the Hub prior to the upgrade
would help.
Are the 3 hubs where you saw the problem all configured the same? That
would be a very good clue to the problem.
Let me make sure I am clear: You see a problem upgrading from MAM
V4.0.0 to MAM V4.0.2? But there is no problem in going from MAM
V3.1.0 to MAM V4.0.0?
FYI, There is no reason to upgrade from MAM V4.0.0 to V4.0.2 or V4.0.4.
Those three versions are functionally the same except for some
manufacturing diagnostics that you can't see. So don't bother with
V4.0.4.
If you can, you should probably use MAM V4.1.0 just announced in note
#2. This is mostly a bugfix release. But I can't say if it will fix
this upgrade problem until I know what your problem is...
-Mike
p.s. No need to upgrade to interim versions to get to the latest: going
from V3.1.0 straight to V4.1.0 would be preferred at this point.
|
| 2353.17 | hubloader worked ok | GRANPA::DMIGNOGNA | | Wed Oct 11 1995 15:14 | 23 |
| Mike,
Sorry for the late response... I upgraded the 23 hubs to V4.0.4 also
the switches and repeaters without a hitch.. Looks like to new hubloader
didn't exhibit this issue... Great!!!!
To answer your questions...
All three hubs were configured the same.. only using one Thinwire LAN.
Nothing was done to the hubs prior to the download.. They were active
on the FDDI ring and seemed to be responding normally to Hubwatch.
We did see the problem with 3.1.0 to 4.0.0 but thought it was a fluke,
this was a new installation and we were still building the network.
I took notice when I had the other Hubs drop out during the 4.0.2
upgrade.
I will be upgrading to the V4.1.0 as you mentioned ... I'll let you
know if I run into a problem.
Don...
|